MySQLのレプリケーション・エラーでの対処 |
| 2006/12/10 |
このところ、Vine4.0が出たこともあって、レプリケーション・エラーが2回ほどあったので、そのときの対処メモです。
HDDとか、ネットワークなどのIOエラーではない場合で、対処してみました。
以下をスレーブ側で操作します。
MySQLのエラーログを確認します。
デフォルトでは、/var/lib/mysql/*.errというファイルが出来ているので、ここに特別な情報がかかれていないかをチェックしておきます。
# tail /var/lib/mysql/*.err
mysqlコマンドで操作します。
$ mysql -u root -p
まず、スレーブ動作を止めておきます。
mysql> stop slave;
スレーブ情報を表示します。
mysql> show slave status\G
色々と情報が出てきますが、確認しておくのは以下です。
|
# SQL実行エラーでスレーブが止まっているのかを確認する。
# 「Slave_IO_Running」が「Yes」で、「Slave_SQL_Running」が「No」なら、スレーブ側のSQL実行エラーです。
Slave_IO_Running: Yes
Slave_SQL_Running: No
# ログ名と止まったログの位置を確認します。
Relay_Log_File: mysql-relay-bin.000194
Relay_Log_Pos: 77977584
|
mysql> \q
mysqlbinlogを使って、エラーとなったSQLを確認します。
$ mysqlbinlog -u root -p -j 77977584 /var/lib/mysql/mysql-relay-bin.000194
パラメータ「-j」に、「show slave status」で表示されたRelay_Log_Posの値を指定します。
最後に指定するファイル名はRelay_Log_Fileの値です。
Vineなど、EUC環境では以下のようにnkfを通したほうが文字化けしないかもしれません。
$ mysqlbinlog -u root -p -j 77977584 /var/lib/mysql/mysql-relay-bin.000194 | nkf -e
ここから先は、手動でその場その場の対応をしていきます。
たとえばキー違反なら、余分となっているレコードをスレーブ側で削除してしまうとか、その時の判断で決めます。
エラーとなったSQL自体、不用のものでスキップしてしまってもいいのなら次のようにします。
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;
ここでの「n」はスキップするSQL文の数です。
対処したと思ったら、スレーブを起動します。
mysql> START SLAVE;
正常にスレーブが動作しているかを確認します。
mysql> show slave status\G
僕の経験で意外に多いのはMySQLサーバのバージョンが、マスター/スレーブで異なるとレプリケーション・エラーが発生することがありました。
マイナーバージョンが違っていてもエラーが出ることがあるようです。
同時にバージョンUPすることが難しい局面もあるでしょうが、できればマスター/スレーブとも同一バージョンがいいと思います。
|