17.4.2 レプリカの予期しない停止の処理

サーバーの予期しない停止 (クラッシュセーフとも呼ばれる) に対するレプリケーションを回復できるようにするには、レプリカが停止する前にその状態を回復できる必要があります。このセクションでは、レプリケーション中のレプリカの予期しない停止の影響、およびレプリケーションを続行するためのリカバリの最善の機会を得るためのレプリカの構成方法について説明します。

レプリカの予期しない停止後、再起動時に、レプリケーション SQL スレッドは、すでに実行されているトランザクションに関する情報をリカバリする必要があります。リカバリに必要な情報は、レプリカアプライアンスのメタデータリポジトリに格納されます。 MySQL 8.0 から、このリポジトリは mysql.slave_relay_log_info という名前の InnoDB テーブルとしてデフォルトで作成されます。このトランザクションストレージエンジンを使用すると、再起動時に情報が常に回復可能になります。アプライヤメタデータリポジトリへの更新は、トランザクションとともにコミットされます。つまり、予期しないサーバーが停止した場合でも、そのリポジトリに記録されるレプリカ進捗情報は、常にデータベースに適用されているものと一貫性があります。適用者メタデータリポジトリの詳細は、セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」を参照してください。

DML トランザクションおよびアトミック DDL は、アトミック操作としてのデータベースへの変更の適用とともに、mysql.slave_relay_log_info テーブルのレプリカアプリケーションメタデータリポジトリ内のレプリケーション位置を更新します。完全にアトミックではない DDL ステートメントや、アトミック DDL をサポートしない除外されたストレージエンジンなど、ほかのすべての場合、サーバーが予期せず停止した場合、レプリケートされたデータに関連付けられた更新が mysql.slave_relay_log_info テーブルに失われる可能性があります。この場合、更新のリストアは手動プロセスです。 MySQL 8.0 でのアトミック DDL のサポートおよび特定のステートメントのレプリケーションの結果の動作の詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。

予期しない停止からレプリカをリカバリするリカバリプロセスは、レプリカの構成によって異なります。リカバリプロセスの詳細は、レプリケーションの選択した方法、レプリカがシングルスレッドかマルチスレッドか、および関連するシステム変数の設定の影響を受けます。リカバリプロセスの全体的な目的は、予期しない停止が発生する前にレプリカデータベースにすでに適用されているトランザクションを識別し、予期しない停止の後にレプリカが見逃したトランザクションを取得して適用することです。

GTID ベースのレプリケーションの場合、回復プロセスには、レプリカによってすでに受信またはコミットされたトランザクションの GTID が必要です。 GTID 自動配置を使用すると、欠落しているトランザクションをソースから取得できます。GTID 自動配置では、ソーストランザクションがレプリカトランザクションと自動的に比較され、欠落しているトランザクションが識別されます。
ファイル位置ベースのレプリケーションの場合、リカバリプロセスには、レプリカに適用された最後のトランザクションを示す正確なレプリケーション SQL スレッド (適用者) 位置が必要です。その位置に基づいて、レプリケーション I/O スレッド (レシーバ) は、その時点からレプリカに適用する必要があるすべてのトランザクションをソースバイナリログから取得します。

GTID ベースのレプリケーションを使用すると、予期しない停止に対して回復可能になるようにレプリケーションを構成することがもっとも簡単になります。 GTID 自動配置とは、適用されたトランザクションのシーケンスにギャップがある場合でも、レプリカが欠落しているトランザクションを確実に識別して取得できることを意味します。

次の情報は、レプリケーションの制御下にあるかぎりリカバリを保証するために、様々なタイプのレプリカに適した設定の組合せを提供します。

重要

レプリケーションの制御外の一部の要因は、レプリケーションリカバリプロセスおよびリカバリプロセス後のレプリケーションの全体的な状態に影響を与える可能性があります。特に、個々のストレージエンジンの回復プロセスに影響する設定では、レプリカが予期せず停止したためにトランザクションが失われ、レプリケーションリカバリプロセスで使用できなくなる可能性があります。次のリストに示す innodb_flush_log_at_trx_commit=1 設定は、トランザクションで InnoDB を使用するレプリケーション設定の主要な設定です。ただし、InnoDB またはほかのストレージエンジン (特にフラッシュまたは同期に関連するもの) に固有のほかの設定も影響を与える可能性があります。選択したストレージエンジンによって作成されたクラッシュセーフ設定に関する推奨事項を常にチェックして適用します。

レプリカの次の設定の組合せは、予期しない停止に対する最も回復力があります:

GTID ベースのレプリケーションが使用されている場合 (gtid_mode=ON)、SOURCE_AUTO_POSITION=1 | MASTER_AUTO_POSITION=1 を設定します。これにより、ソースへの接続の GTID 自動配置がアクティブ化され、欠落しているトランザクションが自動的に識別および取得されます。このオプションは、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 の場合) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 の場合) を使用して設定します。レプリカに複数のレプリケーションチャネルがある場合は、チャネルごとにこのオプションを個別に設定する必要があります。 GTID 自動配置の動作の詳細は、セクション17.1.3.3「GTID 自動配置」を参照してください。ファイル位置ベースのレプリケーションが使用されている場合、SOURCE_AUTO_POSITION=1 | MASTER_AUTO_POSITION=1 は使用されず、代わりにバイナリログ位置またはリレーログポジションを使用してレプリケーションの開始位置が制御されます。
受信した各トランザクションがディスクに書き込まれた後、リレーログをディスクに同期するようにレプリケーション I/O スレッドに指示する sync_relay_log=1 を設定します。つまり、ソースバイナリログ (アプライヤメタデータリポジトリ内) から読み取られた現在の位置のレプリカレコードが、リレーログに保存されたトランザクションのレコードより前になることはありません。この設定は最も安全ですが、関連するディスク書込みの数が原因で最も遅くなることにも注意してください。 sync_relay_log > 1 または sync_relay_log=0 (同期がオペレーティングシステムによって処理される) では、レプリカが予期せず停止した場合、コミットされたトランザクションがディスクに同期されていない可能性があります。このようなトランザクションでは、リカバリしているレプリカがディスクに最後に同期されたときのリレーログ内の情報に基づいて、トランザクションをスキップするのではなく、トランザクションの取得および適用を再試行する場合に、リカバリプロセスが失敗する可能性があります。 sync_relay_log=1 の設定は、マルチスレッドレプリカで特に重要です。マルチスレッドレプリカでは、リレーログの情報を使用して一連のトランザクションのギャップを埋めることができない場合、リカバリプロセスは失敗します。シングルスレッドレプリカの場合、リカバリプロセスでリレーログを使用する必要があるのは、関連情報がアプライヤメタデータリポジトリで使用できない場合のみです。
各トランザクションがコミットされる前に InnoDB ログをディスクに同期する innodb_flush_log_at_trx_commit=1 を設定します。この設定 (デフォルト) により、InnoDB テーブルおよび InnoDB ログがディスクに保存されるため、トランザクションに関する情報がリレーログに不要になります。この設定を sync_relay_log=1 の設定と組み合わせると、InnoDB テーブルと InnoDB ログの内容が常にリレーログの内容と一致するようになるため、予期しない停止が発生した場合にリレーログファイルをパージしてもトランザクションのレプリカ履歴に問題のないギャップが生じることはありません。
レプリケーション SQL スレッドの位置を InnoDB テーブル mysql.slave_relay_log_info に格納する relay_log_info_repository = TABLE を設定し、トランザクションコミットとともに更新して、常に正確なレコードを確保します。この設定は MySQL 8.0 のデフォルトであり、FILE 設定は非推奨です。 MySQL 8.0.23 では、システム変数自体の使用は非推奨であるため、省略してデフォルトにできます。 FILE 設定 (以前のリリースのデフォルト) を使用した場合、情報は、トランザクションの適用後に更新されるデータディレクトリ内のファイルに格納されます。これにより、レプリカが停止するトランザクションの処理ステージや、ファイル自体の破損に応じて、ソースとの同期が失われるリスクが発生します。 relay_log_info_repository = FILE の設定では、リカバリは保証されません。
サーバーの起動直後に自動リレーログリカバリを有効にする relay_log_recovery = ON を設定します。このグローバル変数はデフォルトで OFF に設定され、実行時には読取り専用ですが、レプリカの予期しない停止後、レプリカの起動時に --relay-log-recovery オプションを使用して ON に設定できます。この設定では、既存のリレーログファイルが破損または矛盾している場合に無視されることに注意してください。リレーログリカバリプロセスでは、新しいリレーログファイルが開始され、アプライヤメタデータリポジトリに記録されているレプリケーション SQL スレッド位置からソースからトランザクションがフェッチされます。以前のリレーログファイルは、レプリカの通常のパージメカニズムによって時間の経過とともに削除されます。

マルチスレッドレプリカの場合、relay_log_recovery = ON を設定すると、リレーログから実行された一連のトランザクションの不整合およびギャップが自動的に処理されます。これらのギャップは、ファイル位置ベースのレプリケーションが使用されている場合に発生することがあります。 (詳細は、セクション17.5.1.34「レプリケーションとトランザクションの非一貫性」を参照してください。) リレーログリカバリプロセスは、START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS ステートメントと同じ方法を使用してギャップを処理します。レプリカが一貫性のないギャップのない状態に達すると、リレーログリカバリプロセスが進行し、レプリケーション SQL スレッド位置からソースからさらにトランザクションがフェッチされます。 GTID ベースのレプリケーションが使用されている場合、このプロセスは不要であり、MASTER_AUTO_POSITION が ON に設定されている場合、MySQL 8.0.18 からマルチスレッドレプリカはリレーログのリカバリを自動的にスキップするため、relay_log_recovery の設定に違いはありません。