2011年 12月 18日
タグ： #MySQL
遅延対策のベストプラクティス
エントリのまとめとして、レプリケーションを運用する上で実施するべきことについて列挙しておこう。
まず、巨大なトランザクション（一度に大量の行を更新するもの）は実行しないというのが鉄則である。バッチ処理的なものであれば、可能であればコミットする行数を少しずつに絞り込むようにしよう。大きなテーブルのALTER TABLEのようにいかんともし難い処理は、メンテナンスウィンドウを設けて実施しよう。
スレーブでI/O boundなボトルネックが生じている場合には、innodb_flush_log_at_trx_commit=2の設定を検討しよう。こうすると、スレーブ上ではCOMMIT時にログがディスクへ同期されなくなるが、スレーブはいざとなればバックアップから再構築すれば良いので、特にスレーブが複数あってひとつぐらいダウンしても問題がない場合には、ログの同期をOFFにすることは悪い選択肢ではない。
ワーキングセットがInnoDBバッファプールよりずっと大きい場合、松信さんが紹介していたプリフェッチのテクニックが有効であろう。ただし、そのような状況ではバッファプールを大きくするのも重要である。バッファプールが足りないと、参照の性能にも影響するからだ。
CPUリソースが枯渇している場合には、CPUを増設する（スケールアップ）か、スレーブを追加する（スケールアウト）しかないが、一般的にはスケールアウトのほうが安くつくので好まれる傾向にある。スレーブ数が増えすぎるとNICの帯域が限界に達してネットワークの遅延が生じることになるが、その場合にはマスター上でNICを増設したり、スレーブを多段構成（孫スレーブ）にするなどの工夫が求められる。
漢(オトコ)のコンピュータ道: MySQLにおけるレプリケーション遅延の傾向と対策
2ヶ月前 | 固定リンク | 2011年 12月 18日 | 
