バックアップ サーバーで MySQL レプリケーション クライアントが稼働しています。先週の停電以来、レプリケーションが停止しています。それ以前は数か月間中断することなく稼働していました。
マスターとスレーブの両方を再起動しようとしましたが、効果はありませんでした。スレーブからマスター サーバーにアクセスできるので、ネットワークに問題はありません。
問題が何であるかを診断するために他に何かできることはありますか?
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: master
Master_User: username
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000060
Read_Master_Log_Pos: 46277494
Relay_Log_File: mysqld-relay-bin.000348
Relay_Log_Pos: 98
Relay_Master_Log_File: mysql-bin.000060
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 46277494
Relay_Log_Space: 98
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
1 row in set (0.00 sec)
ERROR:
No query specified
mysql> show master status\G;
*************************** 1. row ***************************
File: mysql-bin.000069
Position: 851796
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
ERROR:
No query specified
更新: エラーは mysql.err ではなく daemon.log に記録されていたため、見つけられなかった理由が説明できます。問題は、マスターがログが利用できないと言っていることのようですが、そのログ (および以前のログ) はマスター上でまだ利用できるため、あまり意味がありません。
090710 9:17:35 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350' position: 98
090710 9:17:35 [Note] Slave I/O thread: connected to master 'username@master:3306', replication started in log 'mysql-bin.000060' at position 46277494
090710 9:17:35 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
090710 9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
090710 9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000060', position 46277494
答え1
MySQL レプリケーションの素晴らしい世界へようこそ。私はあなたのような特定の問題に遭遇したことはありませんが、他の奇妙な問題にたくさん遭遇しました。近似した解決策は、マスターからまったく新しいスレーブであるかのように再同期して、それで終わりにすることです。
答え2
スレーブのエラー ログを調べる必要があります。通常、問題が何であるかが明確に示されています。
MySQL エラー ログを監視システムに結び付ける必要があります。そうしないと、スレーブが役に立たなくなる可能性があります。
さらに、スレーブの状態をチェックするモニターも必要です。
また、何らかの役に立つようにするには、mk-table-checksum などを使用して、スレーブの同期を定期的にチェックすることも必要です。理想的には、その結果も監視システムに結び付けます。
答え3
多くの人は、スレーブが起動前にレプリケーションを停止した場合にすべてが正常であることを確認できるように、skip-slave-start を設定します。「start slave」を実行して、何かが変わるか、何かがログに記録されるかを確認してください。さらに、SlaveSQL プロセスが実行されているのに SlaveIO が実行されていないのは奇妙です。スレーブのローカルリレーログが破損している可能性がありますが、すべきログに報告されます。Mysql を停止してからリレー ログを削除してみてください。
答え4
上記のレポートから問題が見つかりました。このフィールドは (Slave_IO_Running): yes に設定する必要がありますが、上記のレポートでは Slave_IO_Running: No と表示されています。
これが問題の原因です。この変数が「いいえ」と表示される場合、IO スレッドが停止したことになります。そのため、レプリケーションはもう行われません。原因の詳細については、Last_SQL_Errno と Last_SQL_Err を確認する必要があります。エラー番号 0 と空の文字列のメッセージは、「エラーなし」を意味します。Last_SQL_Error はスレーブのエラー ログに表示されます。
この問題を解決するには、スレーブを停止します
次に設定:
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
これはスレーブに 1 つのクエリ (レプリケーションの停止の原因となった無効なクエリ) をスキップするように指示します。2 つのクエリをスキップする場合は、代わりに SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; を使用します。
次にスレーブを再起動してログを確認します。これで問題が解決することを期待します...