MySQLスレーブライブラリの復元の実践記録

状況の説明:

今日、MySQL データベースのスレーブノードホストにログインしたところ、/var/lib/mysql に大量の mysql-relay-bin ファイルが格納されているのを発見しました。最も古いファイル作成日は 2018 年でした。スレーブライブラリがマスターのログ操作記録を同期した後、これらのファイルは削除されると記憶しています (デフォルト設定では削除されませんでしたが、間違って記憶していました)。そこで、スレーブライブラリのステータスを確認したところ、次のエラーが見つかりました。

mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
        Slave_IO_State: マスターがイベントを送信するのを待機中
         マスターホスト: *.*.*.*
         マスターユーザー: dbsync
         マスターポート: 3306
        接続再試行: 60
       マスターログファイル:mysql-bin.000095
     読み取りマスターログ位置: 869242147
        リレーログファイル:mysqld-relay-bin.000146
        リレーログ位置: 871280529
    リレーマスターログファイル: mysql-bin.000075
       スレーブIO実行中: はい
      スレーブSQL実行中: いいえ
       Replicate_Do_DB: cdb、cdb_admin
     レプリケート_無視_DB: mysql
      テーブルの複製: 
    無視テーブルを複製: 
   Replicate_Wild_Do_Table: 
 Replicate_Wild_Ignore_Table: 
          最終エラー番号: 1594
          Last_Error: リレー ログの読み取り失敗: リレー ログ イベント エントリを解析できませんでした。考えられる原因は、マスターのバイナリ ログが破損している (バイナリ ログで 'mysqlbinlog' を実行すると確認できます)、スレーブのリレー ログが破損している (リレー ログで 'mysqlbinlog' を実行すると確認できます)、ネットワークの問題、またはマスターまたはスレーブの MySQL コードのバグです。マスターのバイナリ ログまたはスレーブのリレー ログを確認する場合は、このスレーブで 'SHOW SLAVE STATUS' を発行すると、それらの名前を知ることができます。
         スキップカウンタ: 0
     実行マスターログポジション: 871280384
       リレーログスペース: 19994786573
       Until_Condition: なし
        ログファイルまで: 
        ログ位置まで: 0
      マスターSSL許可: いいえ
      マスターSSLCAファイル: 
      マスターSSLCAパス: 
       マスターSSL証明書: 
      マスターSSL暗号: 
        マスターSSLキー: 
    マスターより遅れている秒数: NULL
Master_SSL_Verify_Server_Cert: いいえ
        最終IOエラー番号: 0
        最後のIOエラー: 
        最終SQLエラー番号: 1594
        Last_SQL_Error: リレー ログの読み取り失敗: リレー ログ イベント エントリを解析できませんでした。考えられる原因は、マスターのバイナリ ログが破損している (バイナリ ログで 'mysqlbinlog' を実行すると確認できます)、スレーブのリレー ログが破損している (リレー ログで 'mysqlbinlog' を実行すると確認できます)、ネットワークの問題、またはマスターまたはスレーブの MySQL コードのバグです。マスターのバイナリ ログまたはスレーブのリレー ログを確認する場合は、このスレーブで 'SHOW SLAVE STATUS' を発行すると、それらの名前を知ることができます。
セット内の 1 行 (0.00 秒)

エラー： 
クエリが指定されていません

理由：

マスターノード上のmysql-bin.00007という形式の名前のファイル（mysql-bin.000075を含む）を削除しました。その結果、スレーブライブラリはファイルを見つけられず、同期できませんでした。

解決：

1. スレーブライブラリの同期位置を再指定します。（実現不可能）

スレーブ停止;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=869242147; //mysql マスター ノード スレーブ上の mysql-bin.000095 の既存の位置 start;

スレーブノードで show slave status を実行すると、依然としてエラーメッセージが報告されます。具体的なエラーメッセージは書き留めていませんが、errno が 1236、Slave_IO_Running プロセスが実行されておらず、Slave_SQL_Running プロセスが実行されていることを覚えています。一般的な説明は、特定のライブラリのテーブルに問題があるということです。

異なる同期場所 (エラーが報告された場所、マスター上の mysql-bin-000095 が書き込まれた場所) を指定するために複数回試行した後も、エラーは引き続き発生しました。

実際、テーブルレコードにはすでに問題があります。説明に記載されているテーブルを例に挙げてみましょう。スレーブデータベースには約 1,200 件のレコードが格納されていますが、マスターデータベースには 1,900 件を超えるレコードがあります。このデータを手動で追加しない限り、操作データを記録したログが失われている (私が削除した) ため、最新の一貫したログ操作実行場所を見つけることができません。

2. スレーブライブラリをやり直します。

データの差が大きすぎるため、問題は 1 つのテーブルに限定されないと思われるため、スレーブデータベースをクリーンにしてやり直してください。
1) マスターノードとスレーブノードのライブラリ構成情報を比較して一貫性を確保します。 (デュアルマスターモードが設定されている理由はわかりませんが、実際にはマスターノードで実行されているインスタンスは 1 つだけですか?)

2) マスターノードとスレーブノードのトラフィックの状態をチェックし (show processlist)、再実行するスレーブデータベースにビジネストラフィックが接続されていないことを確認します。

3) マスターノード上のスレーブプロセスを停止します。（止まってから開けてないので、問題がないかは分かりません。様子見します）

4) マスターノード上のライブラリのログレコードの場所を記録し、データベースをバックアップします。

mysql> マスターステータスを表示します。
+------------------+----------+--------------------------------+------------------+
| ファイル | 位置 | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------------------------+------------------+
| mysql-bin.000095 | 871760173 | cdb、cdb_admin | mysql |
+------------------+----------+--------------------------------+------------------+
セット内の1行（0.01秒）
 mysqldump -u root -p --databases cdb、cdb_admin > bak.master.sql

5) 安全のために、スレーブノードライブラリをバックアップします。

mysqldump -u root -p --databases cdb、cdb_admin > bak.slave.sql

6) 再起動: マスターデータベースのバックアップファイルをスレーブノードにコピーし、バックアップファイルをインポートします。

mysql -u ルート -p < bak.master.sql

7) スレーブノードで、マスターログを読み取る場所を再指定します。

スレーブ停止;
MASTER を MASTER_LOG_FILE='mysql-bin.000095'、MASTER_LOG_POS=871760173 に変更します。//POS は、スレーブ開始時に記録されたマスター ノードのログ レコード位置です。

8) スレーブノードでスレーブステータスを表示します。この時点で、Slave_IO_Running と Slave_SQL_Running は両方とも実行中です。スレーブステータスを更新すると、Read_Master_Log_Pos の値も増加し始め、同期が再び開始されます。

要約:

ファイルをクリーンアップするときは、マスターノードとスレーブノードのログの読み取りと書き込みにおける mysql-bin ファイルの場所に注意してください。削除する前に、マスターノードとスレーブノードの両方でログ位置が読み取られていることを確認する必要があります。無作為に削除しないでください。そうしないと、スレーブデータベースが同期できなくなります。スレーブノードでマスターログの読み取り位置を強制的に指定したり、エラーをスキップしたりした場合でも、スレーブデータベースでデータが失われる可能性を排除できません。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: