View a markdown version of this page

Amazon Aurora MySQL で遅延レプリケーションを設定する - Amazon Aurora
遅延レプリケーションのユースケース遅延を伴う外部レプリケーションの設定既存のリードレプリカの遅延レプリケーションを変更するリードレプリカへのレプリケーションを停止する場所を設定するリードレプリカを昇格させる関連トピック

Amazon Aurora MySQL で遅延レプリケーションを設定する

遅延レプリケーションは、Aurora MySQL でのディザスタリカバリ用の戦略として使用できます。遅延レプリケーションでは、ソースからリードレプリカへのレプリケーションを遅延させる最小時間を秒数で指定します。障害発生時 (意図しないテーブルの削除など) には、以下のステップを実行して障害から早急に復旧します。

  1. 障害を起こした変更がソースから送られる前に、リードレプリカへのレプリケーションを停止します。レプリケーションを停止するには、mysql.rds_stop_replication ストアドプロシージャを使用します。

  2. レプリケーションをスタートし、レプリケーションがログファイルの場所で自動的に停止するように指定します。障害発生の直前の場所を指定するには、mysql.rds_start_replication_until(Aurora MySQL バージョン 3) ストアドプロシージャを使用します。

  3. 「リードレプリカの Aurora MySQL DB クラスターへの昇格」の手順を使用してリードレプリカを新しいソースの DB クラスターに昇格させます。

注記

Aurora MySQL は、バージョン 8.4.8 以降の遅延レプリケーションをサポートしています。

  • 遅延レプリケーションを設定するには、ストアドプロシージャを使用します。遅延レプリケーションを AWS マネジメントコンソール、AWS CLI、または Amazon RDS API で設定することはできません。

  • Aurora MySQL バージョン 8.4.8 以降の遅延レプリケーションの設定でグローバルなトランザクション識別子 (GTID) に基づくレプリケーションを使用できます。

  • GTID ベースのレプリケーションを使用する場合は、mysql.rds_start_replication_until_gtid(Aurora MySQL バージョン 3) ストアドプロシージャの代わりに、mysql.rds_start_replication_until(Aurora MySQL バージョン 3) ストアドプロシージャを実行します。

  • Aurora MySQL は、最大 15 チャネルのマルチソースレプリケーションをサポートします。_for_channel プロシージャのバリアントを使用して、特定のチャネルで遅延レプリケーションを設定します。

遅延レプリケーションのユースケース

Aurora MySQL での遅延レプリケーションは、バイナリログベースのレプリケーションに適用されます。これには、Aurora MySQL ライター DB クラスターからバイナリログレプリカへのレプリケーション、外部 MySQL ソースから Aurora MySQL DB クラスターへのレプリケーション、またはマルチソースレプリケーションチャネル間のレプリケーションが含まれます。1 つの DB クラスター内の Aurora レプリカには適用されません。これは、バイナリログからではなく、共有クラスターストレージから読み取られるためです。一般的なユースケースには以下が含まれます。

  • オペレーターエラーからのディザスタリカバリ – 設定された間隔でソースを遅延させるバイナリログレプリカを維持します。破壊的なステートメントが意図せずに実行された場合 (テーブルの削除など)、ソースが変更を適用する前に遅延レプリカのレプリケーションを停止します。次に、mysql.rds_start_replication_until(Aurora MySQL バージョン 3) または mysql.rds_start_replication_until_gtid(Aurora MySQL バージョン 3) を使用して、イベントの直前にロールフォワードします。最後に、レプリカを昇格させます。このアプローチは、クラッシュリカバリとバイナリログの再生を必要とするポイントインタイムリカバリよりも高速な復旧パスを提供します。

  • 論理データの破損に対する保護 – 遅延レプリカは、徐々にデータを破損させる障害のあるアプリケーションのデプロイや移行も防ぎます。レプリカは、遅延時間中に破損前の状態を保持するため、障害のあるトランザクションが適用される前に復旧できます。

  • メジャーバージョンとブルー/グリーンアップグレード – アップグレード中またはブルー/グリーンデプロイ中に遅延バイナリログレプリカを安全策として保持し、アップグレードで問題が発生した場合に既知の正常な状態にフォールバックできるようにします。

  • 外部ソースからの変更データキャプチャ (CDC) – 外部 MySQL ソースから Aurora MySQL DB クラスターに変更を取り込む場合、意図的な遅延により、変更がダウンストリームに適用される前に、制御されたバッファが提供されます。

  • 復元なしの履歴検査 – 遅延レプリカをクエリして、以前の時点におけるデータの状態を確認します。これは、クローンのプロビジョニングやポイントインタイムリストアを行うことなく、変更点をデバッグ、監査、調査するのに役立ちます。

  • レプリケーション遅延下でのアプリケーション動作のテスト – 意図的に増やした遅延を使用して、レプリカが遅延したときのアプリケーションの動作を検証し、遅延を再現するために重い負荷を発生させることなく、遅延の影響を受けやすい条件のリグレッションテストを実行します。

遅延を伴う外部レプリケーションの設定

外部ソースと遅延レプリケーションを設定するには、mysql.rds_set_external_source_with_delay (Aurora MySQL バージョン 8.4.8 以降) ストアドプロシージャを使用します。すべてのレプリケーションストアドプロシージャの詳細については、「バイナリログレプリケーションの設定、開始、停止」を参照してください。

例 (デフォルトチャネル):

CALL mysql.rds_set_external_source_with_delay(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600);

例 (特定のチャネル):

CALL mysql.rds_set_external_source_with_delay_for_channel(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600,
  'channel_1');

パラメータ :

host_name

外部ソースのホスト名または IP アドレス。

host_port

外部ソースのポート番号。

replication_user_name

外部ソースのレプリケーションユーザー。

replication_user_password

レプリケーションユーザーのパスワード。

mysql_binary_log_file_name

外部ソースのバイナリログファイルの名前。

mysql_binary_log_file_location

レプリケーションを開始するバイナリログファイル内の位置。

ssl_encryption

このパラメータを 1 に設定すると、レプリケーション接続の SSL 暗号化が有効になり、0 に設定すると SSL 暗号化が無効になります。

delay

秒単位の最小遅延 (0～259,200)。

channel

(for_channel variant only) マルチソースレプリケーションのチャネル名。

制約:

  • Aurora MySQL は、最大 15 個のレプリケーションチャネルをサポートします。

  • 各チャネルは、異なるソース (host:port の組み合わせ) からレプリケートする必要があります。

  • 遅延は 0～259,200 秒 (72 時間) の間でなければなりません。

  • チャネル設定を変更する前にレプリケーションを停止します。

既存のリードレプリカの遅延レプリケーションを変更する

既存のリードレプリカの遅延レプリケーションを変更するには、mysql.rds_set_source_delay (Aurora MySQL バージョン 8.4.8 以降) ストアドプロシージャを実行します。すべてのレプリケーションストアドプロシージャの詳細については、「バイナリログレプリケーションの設定、開始、停止」を参照してください。

既存のリードレプリカの遅延レプリケーションを変更するには:

  1. MySQL クライアントを使用して、管理者ユーザーとしてリードレプリカに接続します。

  2. レプリケーションを停止するには、mysql.rds_stop_replication ストアドプロシージャを使用します。

  3. mysql.rds_set_source_delay (Aurora MySQL バージョン 8.4.8 以降) ストアドプロシージャを実行します。

  4. mysql.rds_start_replication ストアドプロシージャを使用してレプリケーションを開始します。

例 (デフォルトチャネル):

CALL mysql.rds_set_source_delay(3600);

例 (特定のチャネル):

CALL mysql.rds_set_source_delay_for_channel(3600, 'channel_1');

これは、リードレプリカへのレプリケーションを少なくとも 1 時間 (3,600 秒) 遅延させることを指定します。遅延値は 0～259,200 秒 (72 時間) である必要があります。

注記

遅延を設定する前にレプリケーションを停止します。レプリケーションが実行されている場合、最初に mysql.rds_stop_replication (または特定のチャネルに対して mysql.rds_stop_replication_for_channel) を呼び出すよう求めるエラーが表示されます。

リードレプリカへのレプリケーションを停止する場所を設定する

リードレプリカへのレプリケーションが停止したら、mysql.rds_start_replication_until(Aurora MySQL バージョン 3) ストアドプロシージャを使用してレプリケーションをスタートしてバイナリログファイルの指定した位置で停止できます。

レプリケーションを開始し、特定の場所で停止するには:

  1. MySQL クライアントを使用して、管理者ユーザーとしてリードレプリカに接続します。

  2. mysql.rds_start_replication_until(Aurora MySQL バージョン 3) ストアドプロシージャを実行します。

例:

CALL mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

これにより、レプリケーションが開始され、mysql-bin-changelog.000777 バイナリログファイルの場所 120 に達するまで変更がレプリケートされます。ディザスタリカバリシナリオでは、場所 120 は災害発生直前の時点として想定されます。

Aurora MySQL が停止ポイントに達すると、レプリケーションは自動的に停止します。Aurora MySQL は、Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure というイベントを生成します。

GTID ベースのレプリケーションを使用する場合は、代わりに mysql.rds_start_replication_until_gtid(Aurora MySQL バージョン 3) ストアドプロシージャを使用します。

リードレプリカを昇格させる

レプリケーションが停止したら、ディザスタリカバリシナリオでリードレプリカを新しいソース DB クラスターに昇格させることができます。リードレプリカの昇格については、「リードレプリカの Aurora MySQL DB クラスターへの昇格」を参照してください。

関連トピック