MySQL 8.0 リファレンスマニュアル


17.1.7.1 レプリケーションステータスの確認

レプリケーションプロセスを管理する場合の最も一般的なタスクは、レプリケーションが実行され、レプリカとソースの間にエラーがないことを確認することです。

各レプリカで実行する必要がある SHOW REPLICA | SLAVE STATUS ステートメントは、レプリカサーバーとソースサーバー間の接続の構成およびステータスに関する情報を提供します。 MySQL 8.0.22 から、SHOW SLAVE STATUS は非推奨になり、かわりに SHOW REPLICA STATUS を使用できます。 パフォーマンススキーマには、この情報をよりアクセスしやすい形式で提供するレプリケーションテーブルがあります。 セクション27.12.11「パフォーマンススキーマレプリケーションテーブル」を参照してください。

パフォーマンススキーマレプリケーションテーブルに表示されるレプリケーションハートビート情報を使用すると、ソースが最近レプリカにイベントを送信していない場合でも、レプリケーション接続がアクティブであることを確認できます。 ソースは、ハートビート間隔より長い期間バイナリログに更新がなく、未送信のイベントがない場合に、ハートビートシグナルをレプリカに送信します。 (CHANGE MASTER TO ステートメントで設定された) ソースの MASTER_HEARTBEAT_PERIOD 設定では、ハートビートの頻度を指定します。これは、レプリカ (slave_net_timeout) の接続タイムアウト間隔の半分にデフォルト設定されます。 replication_connection_status「パフォーマンススキーマ」テーブルには、レプリカが最新のハートビートシグナルをいつ受信したか、および受信したハートビートシグナルの数が表示されます。

SHOW REPLICA | SLAVE STATUS ステートメントを使用して個々のレプリカのステータスを確認している場合、ステートメントは次の情報を提供します:

mysql> SHOW REPLICA STATUS\G
*************************** 1. row ***************************
             Replica_IO_State: Waiting for master to send event
                  Source_Host: source1
                  Source_User: root
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000004
          Read_Source_Log_Pos: 931
               Relay_Log_File: replica1-relay-bin.000056
                Relay_Log_Pos: 950
        Relay_Source_Log_File: mysql-bin.000004
           Replica_IO_Running: Yes
          Replica_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_Source_Log_Pos: 931
              Relay_Log_Space: 1365
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids: 0

ステータスレポートの中で調査すべき主要フィールドは、次のとおりです。

  • Replica_IO_State: レプリカの現在のステータス。 詳細は、セクション8.14.5「レプリケーション I/O スレッドの状態」およびセクション8.14.6「レプリケーション SQL スレッドの状態」を参照してください。

  • Replica_IO_Running: ソースバイナリログを読み取るための I/O スレッドが実行されているかどうか。 通常、レプリケーションをまだ開始していないか、STOP REPLICA | SLAVE で明示的に停止していないかぎり、これを Yes にします。

  • Replica_SQL_Running: リレーログ内のイベントを実行するための SQL スレッドが実行中かどうか。 I/O スレッドと同様、これは通常は Yes にすることをお勧めします。

  • Last_IO_ErrorLast_SQL_Error: リレーログを処理するときに I/O および SQL スレッドによって登録された最後のエラー。 理想的には、これらはエラーがないことを示すブランクであるべきです。

  • Seconds_Behind_Source: レプリケーション SQL スレッドがソースバイナリログの処理を遅れている秒数。 高い数値 (または増加する数値) は、レプリカがソースからのイベントを適時に処理できないことを示します。

    Seconds_Behind_Source の値 0 は通常、レプリカがソースに追いついたことを意味するものとして解釈できますが、厳密には true でない場合もあります。 たとえば、これは、ソースとレプリカの間のネットワーク接続が切断されたが、レプリケーション I/O スレッドがまだこれに気付いていない (slave_net_timeout がまだ経過していない) 場合に発生することがあります。

    Seconds_Behind_Source の一時的な値が状況を正確に反映しない場合もあります。 レプリケーション SQL スレッドが I/O, Seconds_Behind_Source でキャッチアップされると 0 が表示されますが、レプリケーション I/O スレッドがまだ新しいイベントをキューに入れている場合、レプリケーション SQL スレッドが新しいイベントの実行を終了するまで、Seconds_Behind_Source に大きな値が表示されることがあります。 これは、イベントに古いタイムスタンプがある場合に特に発生する可能性があります。このような場合、比較的短い期間に SHOW REPLICA | SLAVE STATUS を複数回実行すると、この値が 0 から比較的大きい値まで繰り返し変更されることがあります。

フィールドのいくつかのペアは、ソースバイナリログからイベントを読み取り、リレーログでそれらを処理する際のレプリカの進行状況に関する情報を提供します:

  • (Master_Log_file, Read_Master_Log_Pos): レプリケーション I/O スレッドがそのログからイベントを読み取る距離を示す、ソースバイナリログ内の座標。

  • (Relay_Master_Log_File, Exec_Master_Log_Pos): レプリケーション SQL スレッドがそのログから受信したイベントを実行した距離を示すソースバイナリログ内の座標。

  • (Relay_Log_File, Relay_Log_Pos): レプリケーション SQL スレッドがリレーログを実行した距離を示すレプリカリレーログ内の座標。 これらは前述の座標に対応していますが、ソースバイナリログ座標ではなくレプリカリレーログ座標で表されます。

ソースでは、SHOW PROCESSLIST を使用して接続レプリカのステータスを確認し、実行中のプロセスのリストを調べることができます。 レプリカ接続では、Command フィールドに Binlog Dump があります:

mysql> SHOW PROCESSLIST \G;
*************************** 4. row ***************************
     Id: 10
   User: root
   Host: replica1:58371
     db: NULL
Command: Binlog Dump
   Time: 777
  State: Has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL

これはレプリケーションプロセスを駆動するレプリカであるため、このレポートで使用できる情報はほとんどありません。

--report-host オプションで開始され、ソースに接続されているレプリカの場合、ソースの SHOW REPLICAS | SHOW SLAVE HOSTS ステートメントにレプリカに関する基本情報が表示されます。 出力には、レプリカサーバーの ID、--report-host オプションの値、接続ポートおよびソース ID が含まれます:

mysql> SHOW REPLICAS;
+-----------+----------+------+-------------------+-----------+
| Server_id | Host     | Port | Rpl_recovery_rank | Source_id |
+-----------+----------+------+-------------------+-----------+
|        10 | replica1 | 3306 |                 0 |         1 |
+-----------+----------+------+-------------------+-----------+
1 row in set (0.00 sec)

関連キーワード:  ソース, Log, ステートメント, ログ, バイナリ, ベース, 接続, 実行, イベント, 構成