実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
MySQL 5.7のmysqld --initializeと鶏卵問題 - （ひ）メモ
MySQLのデータディレクトリの初期化にはこれまで mysql_install_db が使われてきましたが、MySQL 5.7からは mysqld --initialize を使うことが推奨されています。 mysqld --initialize は datadir 配下にファイルやサブディレクトリがあるとエラー終了します。 # mysqld --initialize --user=mysql 2016-10-04T11:39:01.313174Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting. 2016-10-04T11:39:01.313222Z 0 [ERROR] Abortingなので datadir をスッカラカンにして再度実行してみます。my.cnf はこんな内容
perlbrewを使うにあたっていろいろな小細工をした件 - （ひ）メモ
最近perlbrewを使っています。で、いろいろ小細工をしたので問題点とその解決方法のまとめです。 補足すると、深遠な理由とかマリファナ海峡より深い事情とかがなければ、バッチ用、shebang用に(↓で書いてる)appperl的なラッパーを用意するだけでいけるんじゃないかと思います。 問題点 perlbrewのサイトを見るとビールがのみたくなる http://perlbrew.pl/ perlbrewedなperlの実行方法 対話シェル上で スクリプトのshebang (#!) cronで実行する場合 サーバーワイドな共通の@INC perlbrewedなperlの実行方法 perlbrewedなperlをどう実行するか、3つの局面にわけて考えます。 対話シェル上で 基本、~/.bashrcで $PERLBREW_ROOT/etc/bashrcを読めばOK。 なのですが、(深淵なる理由があ
Apache 2.4.1 で気になった新機能などのメモ - （ひ）メモ
Overview of new features in Apache HTTP Server 2.4 - Apache HTTP Server Expressions http://httpd.apache.org/docs/2.4/en/expr.html やSetEnvIfExpr, RewriteCond, Headerで使える評価式 の追加 http://httpd.apache.org/docs/2.4/en/mod/core.html#if ヘッダや環境変数を参照して細かい制御ができるようになったことに加え、else的なブロックを書くのに苦労したことがあるんで朗報です ErrorLogFormat http://httpd.apache.org/docs/2.4/en/mod/core.html#errorlogformat ErrorLogも書式設定できるように。 %L (L
dstatの万能感がハンパない - （ひ）メモ
サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
MySQLで、指定したときだけクエリキャッシュする - （ひ）メモ
今までMySQLのクエリキャッシュはは有効にしてたんですが、Webサービスだとキャッシュヒットするようなクエリはそんなに多くないし、どこかで見かけたんですが(失念…)クエリキャッシュをオフにしたら(逆に)パフォーマンスが上がっただか負荷が下がっただかというのも目にしたので、今度クエリキャッシュはオフにしようと思ってました。(どのみちヒット率悪いし) そんなとき、同僚に query_cache_type を教えてもらいました。(4.0からあるオプションなのに今まで知りませんでした。。。＞＜) http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_query_cache_type てっきりクエリキャッシュはオンかオフかしかできないと思い込んでたんですが、"DEMAND" を指定すると、「原則キャッシ
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
tcpdumpとiptablesの関係 - （ひ）メモ
追記 2009-04-03 まったくもってブコメでいただいた指摘の通りです＞＜ h2onda linux, tcpdump tcpdump(というかlibpcap)は、データリンク層(OSI layer2)レベルでパケットを取得する packet プロトコルを使ってるので、そうなります。参照: man packet(7) 2009/04/02 はてなブックマーク - h2ondaのブックマーク / 2009年4月2日 tt_clown network 細かいけど，図は逆（NIC が下）のが良いかなと思った．/ "ip"tables と言う位だから，IP層でパケットをフィルタしてるて事だろうな．tcpdumpはEthernet Frameも見えるので，後は分かるな？・・・てとこか． 2009/04/02 はてなブックマーク - tt_clownのブックマーク / 2009年4月2日 pack
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
