1

レプリケーション設定とともに、次のMySQLインスタンスがあります。

S1 ----->（M1 <-> M2）、ここで：

M1-M2はマルチマスターレプリケーションのセットアップであり、

S1-マスターM1で行われる書き込みを複製するスレーブ。

現在、M1がダウンした場合に、S1がM2から複製を開始する、チャネルフェイルオーバーメカニズムを使用してセットアップを強化しようとしています。現在、私が見ているこれを行う唯一の方法は次のとおりです。

（S1マシンのM1障害検出メカニズム）、次に：

-> S1は、ローカルリレーログファイルからM1のクエリの最新のタイムスタンプを取得します。

-> M2は、ローカルのbinlogファイル+ S1の最新のタイムスタンプに対応するbinlogインデックスを検索します（mysqlbinlogユーティリティを使用したbashスクリプト）。

-> S1は、最終的に「STOP SLAVE」、「CHANGE MASTER TO master_host = M2 ... master_log_file = ... master_log_pos = ...」などのコマンドを実行してレプリケーションを続行できますが、今回はM2から

これを行うためのより良い（そしてエラーが発生しにくい）方法はありますか？

ありがとうございました

編集Xid：現在、これは、公的にアクセス可能なMySQLクラスタリングソリューションで一般的に使用されている独自のbinlogクエリタグのおかげで、はるかに簡単に実現できます。

4

1 に答える 1

1

必要なbinlogと位置を取得するためのより単純な方法があります。

M2が知っているように、現在のbinlogと位置を使用する方が理にかなっていますか？M2のスレーブステータスを確認する必要があります。

例

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.130
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000463
          Read_Master_Log_Pos: 453865699
               Relay_Log_File: relay-bin.001226
                Relay_Log_Pos: 453865845
        Relay_Master_Log_File: mysql-bin.000463
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           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: 453865699
              Relay_Log_Space: 453866038
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 106451130
1 row in set (0.00 sec)

mysql>

このディスプレイには、5つの重要なコンポーネントがあります。

  • Master_Log_File（6行目）：位置が最後に読み取られたマスターのログファイル
  • Read_Master_Log_Pos（7行目）：マスターからスレーブで読み取られた最後の位置
  • Relay_Master_Log_File（10行目）：位置が最後に実行されたマスターのログファイル
  • Exec_Master_Log_Pos（22行目）：マスターからスレーブで実行された最後の位置
  • Relay_Log_Space（23行目）：すべてのリレーログからのバイトの合計

Relay_Log_Space

ご注意くださいRelay_Log_Space。この数の増加が停止すると、マスターからインポートされたすべてのSQLステートメントが読み取られます。残念ながら、突然のフェイルオーバーが原因で、最後のリレーログが破損しているか、単に不完全である可能性があります。

Replication Coordinates

レプリケーション座標にも注意してください(Relay_Master_Log_File, Exec_Master_Log_Pos)。これはあなたが探しているポジションです。しかし、Relay_Log_Spaceそれがまだ増加しているかもしれないように。実際、これらのレプリケーション座標は他のレプリケーション座標と同じである必要があります(Master_Log_File,Read_Master_Log_Pos )。それはあなたがすべてが追いついていることを知っているときです。レプリケーション座標のペアが一致しない場合は、Relay_Log_Space増分が停止するタイミングに関してもう少し信頼する必要があります。

どうSeconds_Behind_Masterですか？

使えない理由Seconds_Behind_Masterは簡単です。マスターが完全にダウンすると、レプリケーションスレッド（Slave_IO_RunningまたはSlave_SQL_Running）が1つだけで、にNoなりSeconds_Behind_MasterますNULL。

于 2013-02-08T13:02:39.780 に答える