1

「1 マスター、1 スレーブ」の MySQL セットアップがあります。突然の停電が発生し、スレーブがダウンしました。マシンをバックアップした後、スレーブがマスターと同期していないことがわかりました。

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.0.0.1
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-log.001576
          Read_Master_Log_Pos: 412565824
               Relay_Log_File: mysqld-relay-bin.002671
                Relay_Log_Pos: 6930
        Relay_Master_Log_File: mysql-log.001573
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table: blah.table2
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1032
                   Last_Error: Could not execute Update_rows event on table blah.info; Can't find record in 'info', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-log.001573, end_log_pos 689031225
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 689030864
              Relay_Log_Space: 2944772417
              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
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1032
               Last_SQL_Error: Could not execute Update_rows event on table blah.info; Can't find record in 'info', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-log.001573, end_log_pos 689031225
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
1 row in set (0.00 sec)

「ROW」の binlog 形式を使用しているため、mysqlbinlog を使用して問題のある行を確認しようとしても、何も役に立ちません。単純にスキップ カウンターを設定したくありません。テーブルの同期がさらに外れてしまうと思うからです。

基本的に特定の時点に「ロールバック」して、マスターログ番号、位置などをリセットできるスレーブでできることはありますか? そうでない場合、同期を取り戻すためにできることはありますか?

4

1 に答える 1

1

通常、 pt-table-checksumとpt-table-syncを使用して小さな不一致から回復できます。

あなたのスレーブは、クラッシュしたときにバイナリログシーケンスでその場所を失ったようです。スレーブは最後に処理された binlog イベントを datadir /relay-log.info に継続的に書き込みますが、このファイルはバッファリングされた書き込みを使用するため、クラッシュ時にデータが失われる可能性があります。

そのため、Percona Server は、このシナリオから回復するために、同じレプリカ情報を InnoDB テーブルに格納する耐クラッシュ レプリケーション機能を作成しました。

MySQL 5.6 には同様の機能relay_log_info_repository=TABLEが実装されています。レプリカがその状態をクラッシュに強い方法で保存するように設定できます。

あなたのコメントについて：

はい、理論的にはpt-table-sync はレプリケーションのずれをいくらでも修正できますが、大きな不一致を修正するには必ずしも最も効率的な方法ではありません。ある時点で、古くなったレプリカを廃棄し、マスターからの新しいバックアップを使用して再初期化する方が迅速かつ効率的です。

Percona Xtrabackup を使用して、6 つの簡単な手順でレプリケーション用にスレーブをセットアップする方法を確認してください。

于 2013-07-09T22:45:51.547 に答える