はじめまして。プラットフォーム開発本部のせじまです。好きなものはDisk I/Oです。
今回はMySQL（on Linux）のレプリケーションにまつわる、ちょっとしたお話をさせていただきたいと思います。

はじめに

MySQL4.0以降のレプリケーションは、

1. Masterのmysqldが、INSERT/UPDATE/DELETEなどの更新情報を、バイナリログに記録する。
2. Slaveのmysqld(IOスレッド)は、masterのmysqldに接続し、バイナリログを転送する。
3. Slaveのmysqld(IOスレッド)は、受信したバイナリログ内容を、リレーログに記録する。
4. Slaveのmysqld(SQLスレッド)は、リレーログを読み込み、更新内容をslaveのDBに反映する。

といった仕組みになっています。図にすると次の通りです(*1)。

MySQLのレプリケーションはとても良くできた仕組みなのですが、グリーではある問題を抱えていました。稼働中のMasterにSlave を増設するとき、Masterが刺さってしまう(*2)ことがあったのです。問題は、Masterのバイナリログの転送にありました。

Masterを停止させずにSlaveを増設する場合、

• ファイルシステム等の機能を利用して、既存のDBのスナップショットをとる
• 既存のSlaveを一時停止して、新しいSlaveに、データをまるまるコピーする

いずれかの方法で増設するSlaveにデータをコピーして、レプリケーションを開始することが一般的だと思います。ただ、スナップショットをとったりデータをコピーしている間もMasterのバイナリログは更新され続けています。更新頻度が高い == バイナリログを大量に吐くMasterに対してSlaveを増設したとき、

• Masterの古いバイナリログがページキャッシュ上に載っておらず、Slaveに転送する際、Disk Readが多発してしまう。
• バイナリログの転送で、ネットワークの帯域を食われてしまう。

といった問題が起こりえます。
特に、バイナリログの転送に伴う突発的なDisk Readは、致命的な問題といえます。

基本的に、Diskへのwriteはバッファリングないしスケジューリングの余地があります。しかし、（キャッシュに載ってない）readは、Diskからの応答を待つしかありません。read の IOPS が高くなると MySQL はわりと容易に刺さるので、私はMySQLの負荷を見るとき、write の IOPS よりも read の IOPS を気にすることが多いです。(*3)

どうするか

今回は次のような対処を行いました。

• max_binlog_size のデフォルト(1GB)は大きすぎるので、小さくする。
  • バイナリログがページキャッシュを何GBも使わないでほしい
  • バイナリログの読み込みは sequential read になるとはいえ、一度に1GBもreadしたくない
• 増設対象のSlaveで実行するスクリプトを作成。疑似コードは次の通り。

ionice は I/O scheduler が cfq じゃないと効果ないです。

さいごに

つまるところ、

1. ionice cat ${binlog}
2. バイナリログをちょっとずつ転送
3. バイナリログ一個分転送できたら、IOスレッド止めて、転送したバイナリログのクエリを実行
4. 1. にもどる

を繰り返すだけのお粗末な対応ですが、これがなかなか効き目ありました。
かつては、vmstat等でMasterの負荷を見ながら手動でSTOP SLAVE && START SLAVE を叩いて、少しずつSlave増設していたこともありましたが、いまではピークタイムのSlave増設が危なげなく行えるようになりました。また、一台のMasterに対して、複数台のSlaveを同時に追加したりもできています。

今回のお話が皆様の参考になればさいわいです。
これからもGREE Engineers’ Blogをよろしくおねがいします！