MySQL では、レプリカサーバーが、少なくとも指定した時間だけソースより後のトランザクションを意図的に実行するように遅延レプリケーションをサポートしています。 このセクションでは、レプリカのレプリケーション遅延を構成する方法と、レプリケーション遅延を監視する方法について説明します。
MySQL 8.0 では、レプリケーションを遅延させる方法は、immediate_commit_timestamp および original_commit_timestamp (レプリケーション遅延タイムスタンプ を参照) の 2 つのタイムスタンプによって異なります。 レプリケーショントポロジ内のすべてのサーバーで MySQL 8.0 以上が実行されている場合、遅延レプリケーションはこれらのタイムスタンプを使用して測定されます。 即時ソースまたはレプリカがこれらのタイムスタンプを使用していない場合は、MySQL 5.7 からの遅延レプリケーションの実装が使用されます (Delayed Replication を参照)。 このセクションでは、これらのタイムスタンプをすべて使用しているサーバー間の遅延レプリケーションについて説明します。
デフォルトのレプリケーション遅延は 0 秒です。 CHANGE REPLICATION SOURCE TO SOURCE_DELAY= ステートメント (MySQL 8.0.23 の場合) または NCHANGE MASTER TO MASTER_DELAY= ステートメント (MySQL 8.0.23 の場合) を使用して、遅延を NN 秒に設定します。 ソースから受信したトランザクションは、N 秒以上が即時ソースでのコミットより後になるまで実行されません。 遅延はトランザクションごとに発生し (以前の MySQL バージョンとは異なり)、実際の遅延は gtid_log_event または anonymous_gtid_log_event にのみ適用されます。 トランザクション内の他のイベントは、常に待機時間なしでこれらのイベントに従います。
START REPLICA | SLAVE および STOP REPLICA | SLAVE はただちに有効になり、遅延は無視されます。 RESET REPLICA | SLAVE は遅延を 0 にリセットします。
replication_applier_configuration「パフォーマンススキーマ」テーブルには、SOURCE_DELAY | MASTER_DELAY オプションを使用して構成された遅延を示す DESIRED_DELAY カラムが含まれます。 replication_applier_status「パフォーマンススキーマ」テーブルには、残りの遅延秒数を示す REMAINING_DELAY カラムが含まれています。
遅延レプリケーションはいくつかの目的に使用できます。
ソースでのユーザーミスから保護します。 遅延により、遅延レプリカを誤った直前の時点にロールバックできます。
遅延があるときにシステムがどのように動作するかをテストするため。 たとえば、アプリケーションでは、レプリカの負荷が高いためにラグが発生する場合があります。 しかし、この負荷レベルを生成するのが難しい場合があります。 遅延レプリケーションは、負荷をシミュレートしなくても遅延をシミュレートできます。 また、遅延レプリカに関連する状態のデバッグにも使用できます。
バックアップを再ロードせずに、データベースが過去にどのように表示されていたかを検査します。 たとえば、1 週間の遅延でレプリカを構成することで、過去数日前にデータベースがどのように表示されたかを確認する必要がある場合は、遅延レプリカを検査できます。
MySQL 8.0 には、バイナリログに書き込まれる (各イベントではなく) 各トランザクションの GTID に関連付けられた次のタイムスタンプに依存するレプリケーショントポロジで遅延 (レプリケーションラグとも呼ばれる) を測定するための新しい方法が用意されています。
original_commit_timestamp: トランザクションが元のソースのバイナリログに書き込まれた (コミットされた) ときのエポック以降のマイクロ秒数。immediate_commit_timestamp: トランザクションが即時ソースのバイナリログに書き込まれた (コミットされた) ときのエポック以降のマイクロ秒数。
mysqlbinlog の出力には、これらのタイムスタンプがエポックからのマイクロ秒の形式で表示され、読みやすくするためにユーザー定義のタイムゾーンに基づく TIMESTAMP 形式でも表示されます。 例:
#170404 10:48:05 server id 1 end_log_pos 233 CRC32 0x016ce647 GTID last_committed=0
\ sequence_number=1 original_committed_timestamp=1491299285661130 immediate_commit_timestamp=1491299285843771
# original_commit_timestamp=1491299285661130 (2017-04-04 10:48:05.661130 WEST)
# immediate_commit_timestamp=1491299285843771 (2017-04-04 10:48:05.843771 WEST)
/*!80001 SET @@SESSION.original_commit_timestamp=1491299285661130*//*!*/;
SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;
# at 233
原則として、original_commit_timestamp は、トランザクションが適用されるすべてのレプリカで常に同じです。 ソースレプリケーションレプリケーションでは、(元の) ソースのバイナリログ内のトランザクションの original_commit_timestamp は、常にその immediate_commit_timestamp と同じです。 レプリカのリレーログでは、トランザクションの original_commit_timestamp と immediate_commit_timestamp はソースのバイナリログと同じですが、独自のバイナリログでは、レプリカがトランザクションをコミットした時点にトランザクションの immediate_commit_timestamp が対応します。
グループレプリケーション設定では、元のソースがグループのメンバーである場合、トランザクションをコミットする準備が整うと original_commit_timestamp が生成されます。 つまり、元のソースでの実行が終了し、その書込みセットを証明のためにグループのすべてのメンバーに送信する準備が整ったときです。 したがって、(グループメンバーであるか、メンバーからレプリケートされるグループ外のレプリカであるかに関係なく) すべてのサーバーに同じ original_commit_timestamp がレプリケートされ、トランザクションとそのバイナリログ内の各ストアに、immediate_commit_timestamp を使用したローカルコミット時間が記録されます。
グループレプリケーション専用の変更イベントの表示は特殊なケースです。 これらのイベントを含むトランザクションは各サーバーによって生成されますが、同じ GTID を共有します (そのため、最初にソースで実行されてからグループにレプリケートされるのではなく、グループのすべてのメンバーが同じトランザクションを実行して適用します)。 元のソースがないため、これらのトランザクションの original_commit_timestamp はゼロに設定されます。
以前の MySQL バージョンでレプリケーション遅延 (ラグ) を監視する最も一般的な方法の 1 つは、SHOW REPLICA | SLAVE STATUS の出力の Seconds_Behind_Master フィールドに依存することでした。 ただし、このメトリックは、グループレプリケーションなどの従来のソースレプリケーション設定より複雑なレプリケーショントポロジを使用する場合には適していません。 MySQL 8 に immediate_commit_timestamp および original_commit_timestamp を追加すると、レプリケーション遅延に関するより詳細な情報が提供されます。 これらのタイムスタンプをサポートするトポロジでレプリケーション遅延を監視するには、次の「パフォーマンススキーマ」テーブルを使用することをお薦めします。
replication_connection_status: ソースへの接続の現在のステータス。接続スレッドがリレーログにキューに入れた最後のトランザクションと現在のトランザクションに関する情報を提供します。replication_applier_status_by_coordinator: マルチスレッドレプリカの使用時にのみ情報を表示するコーディネータスレッドの現在のステータスは、コーディネータスレッドによってワーカーキューにバッファリングされた最後のトランザクションに関する情報と、現在バッファリングしているトランザクションに関する情報を提供します。replication_applier_status_by_worker: ソースから受信したトランザクションを適用しているスレッドの現在のステータス。レプリケーション SQL スレッド、またはマルチスレッドのレプリカを使用している場合は各ワーカースレッドによって適用されたトランザクションに関する情報を提供します。
これらのテーブルを使用して、対応するスレッドが処理した最後のトランザクションおよびスレッドが現在処理しているトランザクションに関する情報を監視できます。 この情報は次のもので構成されます:
トランザクションの GTID
レプリカのリレーログから取得されたトランザクション
original_commit_timestampおよびimmediate_commit_timestampスレッドがトランザクションの処理を開始した時刻
スレッドが最後に処理したトランザクションの処理を終了した時間
「パフォーマンススキーマ」テーブルに加えて、SHOW REPLICA | SLAVE STATUS の出力には次の 3 つのフィールドがあります:
SQL_Delay:CHANGE REPLICATION SOURCE TO SOURCE_DELAY=(MySQL 8.0.23 から) またはNCHANGE MASTER TO MASTER_DELAY=N(MySQL 8.0.23 より前) を使用して構成されたレプリケーション遅延を示す負でない整数 (単位は秒)。SQL_Remaining_Delay:Replica_SQL_Running_StateがWaiting until MASTER_DELAY seconds after master executed eventの場合、このフィールドには遅延の残り秒数を示す整数が含まれます。 ほかのときは、このフィールドはNULLです。Replica_SQL_Running_State: SQL スレッドの状態を示す文字列 (Replica_IO_Stateに類似)。 値は、SHOW PROCESSLISTで表示される、SQL スレッドのState値と同じです。
レプリケーション SQL スレッドがイベントの実行前に遅延が経過するのを待機している場合、SHOW PROCESSLIST はその State 値を Waiting until MASTER_DELAY seconds after master executed event として表示します。