Managing Slave Lag with MySQL Replication - Percona Database Performance Blog

MySQLのレプリケーションラグについての文章。翻訳して載せようかとも思ったけど、わりと当たり前の事ばかりだったので省略。
本文でも繰り返し出てくるように、MySQLのレプリケーションの実装は2スレッドで出来ている。1つはbinlogをマスタから取ってくるスレッド。もう一つが実行スレッド。マスタ側では当然複数のスレッドが並列実行されて更新処理が行われるのだけど、スレーブ側ではそれがbinlogという形で直列化されてしまう。これをスレーブ上では逐一実行していくがマスタ上の並列実行と比較すると、リソースを有効利用できなかったり一つの遅いクエリに足を引っぱられたりしがち。そのため遅延が発生する。
一つの巨大な更新処理を小さな更新処理に分割しましょうとか、突発的な負荷を避けましょうとか、まぁその通りなんだろうけどそれほど目新しい対策ではないのが並んでいるが、ちょっと気になったのもあった。
一つはALTER TABLE実行時の手法。実際にはこのクエリに限らず手動で実行するような内容で絶対に時間がかかると判っているときには使えそうな方法。マルチマスタなどでスレーブの参照を避けさせた上で個別のスレーブ毎に直接クエリを投げしまうというもの。もちろん、そのままマスタでも実行するとスレーブ上で二重に実行されてしまうので、実行前にSET SQL_BIN_LOG=0とし明示的にbinlogの対象から外す処理を行う。なんだかとても強引な方法にも思えるけど、激しく動いている実環境でやるにはこれしかないかも。
もう一つはMySQL toolkitに遅延を正確に測るツールが入っているので、これを使うと良いらしいこと。確かに実運用で使っていても、標準のshow slave statusで出てくる数値はあまり正確ではないというのが実感である。このtoolkitは遅延測定以外にも一定時間遅らせたレプリカを作るスクリプトとか使えそうなのが一杯含まれている。今度読もう。
あとはレプリケーション負荷を数値化するような指標が欲しいという実装希望とか。
最後はアプリ側で遅延を許容するような作りにしましょうね、とか。まぁ、Googleが同期レプリケーションのパッチを出していたりするが、それを当てない限り非同期レプリケーションというのはズレる代わりに簡単に使えるというのが売りだから過度の期待は禁物。