Tweet

Pocket

対処方法といっても、特定のケースに限る。

えー、レプリケーションて要するに「データベースの内容は自動で別サーバのDBに逐一コピーしてバックアップしておこうぜ」って事ですね。

コピーとレプリカの違いがよく分からないが、そういう事。

で、参照先となるデータベース（以下、マスタDB）とレプリケートする参照元のデータベース（以下、スレーブDB）がありますが、マスタDBがダウンした場合は、

レプリケートがどうこう言ってる場合じゃないので、今回のテーマとは外れます。

あと、本来であればマスタDB側でダンプを取って、スレーブDBへ反映してからレプリケーションを再開するのが王道みたいなのですが、

サービス稼働中のマスタDBへダンプ実行とか、恐ろしくてできないので、現実的ではないような気がする。

なので、スレーブDBのサーバがダウンした場合に、マスタ側でダンプとかせずに復旧するやり方について備忘録。

よほどの事でない限り、以下のケースがほとんどのようで、ググればいくらでも情報があります。

まずは、再起動したスレーブDBへログインして、以下でステータスを確認。

mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

本当はもっとズラ～っと出てきますが、確認するのは上記の項目。

両方「Yes」の場合は問題なくレプリケーションが動作しているので、反映を待つのみですが、どちらかが「No」となっている場合は以下の対処方法があります。

まずは、「Slave_IO_Running: No」の場合。

I/Oエラーとの事なので、HDD故障とか容量不足とかマスタDBへの接続が出来てないとか確認。

それらが問題無いようであれば、リセットします。

mysql> stop slave;

mysql> reset slave;

その後、

mysql> START SLAVE;

としてあげれば、再開されるはずですが、それでもダメな場合は、マスタDBにてステータス確認。

mysql> show master status \G;
*************************** 1. row ***************************
File: mysql-bin.005829
Position: 52932988

上記パラメータを控えつつ、スレーブDB側へ設定。

mysql> CHANGE MASTER TO
-> MASTER_LOG_FILE='mysql-bin.005829',
-> MASTER_LOG_POS=52932988;

再度、

mysql> START SLAVE;

で反映されるはず。

mysql> show slave status\G

で確認して「Yes」になっていればOK。

だが、以下の「Slave_SQL_Running: No」のケースと同様に、SQLのエラーが表示されている場合は、スレーブDBへの更新などが行われたせいでマスタDBとの整合が合わなくなっているとの事なので、以下で実行されてしまったSQLをスキップしてあげる事で整合が取れるらしい。

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

でもって、再度スタート。

mysql> START SLAVE SQL_THREAD;

mysql> show slave status\G

これで解消されると思いますです。ただ、これは最初から「Slave_SQL_Running: No」になってる場合のみって感じ。なんとなくですが、mysql> reset slave;これで、万事OKな気がする。試してないけどそんな気がする。それでもダメなら、MASTER_LOG_FILEとMASTER_LOG_POSをマスタDBと合わせて、再start。