Aurora MySQL 互換 DB インスタンスでリードレプリカを使用す際の問題を解決する方法を教えてください。

解決策

Aurora MySQL 互換のリードレプリカを昇格させる

ライターインスタンスの再起動またはメンテナンスが必要な場合は、手動でフェイルオーバーを実行してリードレプリカをライターインスタンスとして昇格させます。

手動フェイルオーバーを行うには、次の手順を実行します。

1. Amazon RDS コンソールを開きます。
2. ナビゲーションペインで [データベース] を選択します。
3. Aurora DB クラスターのライターインスタンスを選択します。
4. [アクション] を選択し、[フェイルオーバー] を選択します。

ライターインスタンスを使用できない場合、Aurora MySQL 互換は自動的にリードレプリカインスタンスにフェイルオーバーします。ライターインスタンスは、リソースの競合やメンテナンス作業など、複数の要因で使用できなくなる可能性があります。

リーダーインスタンスが複数存在する場合は、クラスター内の各インスタンスで昇格優先度のレベルを指定します。ライターインスタンスに障害が発生すると、Aurora MySQL 互換は優先順位が最も高いレプリカを新しいライターとして昇格させます。

クロス AWS リージョン Aurora レプリカをスタンドアロン DB クラスターとして昇格させることもできます。昇格プロセスを開始すると、クロスリージョンレプリケーションは停止します。昇格されたクラスターは独立した DB クラスターとして機能し、読み取り操作と書き込み操作の両方を管理します。

レプリケーションの遅延を測定する

DB クラスター内のすべての Aurora DB インスタンスは共通のデータボリュームを共有しているため、レプリケーション遅延は最小限に抑えられます。ただし、シナリオによっては、リーダーの遅延が少し長くなる場合があります。

注: クロスリージョンレプリカはバイナリログレプリケーションを使用します。選択したリージョン間の変更レートと適用レート、およびネットワーク通信の遅延により、クロスリージョンレプリカが影響を受ける可能性があります。Aurora MySQL データベースを使用するクロスリージョンレプリカの遅延は通常、1 秒未満です。

レプリケーションの遅延を測定するには、次の Amazon CloudWatch メトリクスを使用します。

• AuroraReplicaLag メトリクスは、同じリージョンのライターノードとリーダーノード間のレプリケーション遅延をミリ秒単位で測定します。
• AuroraBinLogReplicaLag メトリクスは、バイナリログを使用する Aurora DB クラスター間のレプリケーション遅延を測定します。

上記のメトリクスに関する詳細については、「Amazon Aurora 用のインスタンスレベルのメトリクス」を参照してください。

レプリケーションのパフォーマンスを改善する

次の操作を行います。

• リーダーインスタンスへのワークロード集中を避けるために、クラスター内のすべてのインスタンスを同じサイズにすることをおすすめします。リーダーインスタンスがライターインスタンスよりも小容量の場合、変更量が多すぎるため、リーダーインスタンスは対応できません。
  注: ライターインスタンスにワークロードが集中した場合、リードレプリカに一時的な遅延が発生する可能性があります。リーダーインスタンスがライターインスタンスに対応できた後は、遅延は減少します。
• 長時間実行トランザクションの進行中にレプリケーションの遅延が発生しないようにするには、トランザクションを小規模なバッチで実行し、頻繁にコミットを実行します。

ネイティブバイナリログベースの MySQL レプリケーションを使用してレプリカラグをトラブルシューティングする方法については、「Amazon Aurora MySQL のレプリケーションに関する問題」を参照してください。

レプリケーションの遅延が大きい場合のトラブルシューティング

CloudWatch メトリクス AuroraReplicaLag を参照すると、大幅なレプリケーション遅延を確認できます。レプリケーションの遅延が大きいと、リーダーインスタンスが再起動する可能性があります。この問題を解決するには、「Amazon Aurora のリードレプリカで遅延が発生し、再起動した原因を教えてください」を参照してください。

GTID ベースのレプリケーションを設定する

Aurora では、レプリカインスタンスの読み取りには、ネイティブバイナリログによるデータの複製を行いません。グローバルトランザクション識別子 (GTID) を使用して同じクラスター内のインスタンス間でデータを複製することはできません。ただし、一部のシナリオでは GTID ベースのレプリケーションを設定できます。Aurora MySQL 互換で GTID ベースのレプリケーションを使用する方法の詳細については、「Amazon Aurora MySQL 互換において、グローバルトランザクション ID (GTID) を使用するレプリケーションのサポートを開始しました」を参照してください。

Aurora MySQL 互換バージョン 3.04 以降では、マルチスレッドでのバイナリログのレプリケーションが有効です。replica_parallel_workers はデフォルトで 4 に設定されます。マルチスレッド化されたバイナリログのレプリケーションが有効なため、予期しない停止に対するデータベースの耐障害性を改善する必要があります。ソースで GTID レプリケーションを有効化して、レプリカで GTID を許可することをおすすめします。

注: GTID ベースのレプリケーションは、Amazon Relational Database Service (Amazon RDS) for MySQL と Aurora クラスター間、または Aurora クラスター間で設定できます。ソースは外部プライマリサーバーである必要があります。レプリケーションプロセスを開始する前に、ソースでバイナリロギングが有効であることを確認します。

GTID の詳細については、MySQL のウェブサイトで「GTID の形式とストレージ」を参照してください。

関連情報

AWS リージョン間の Amazon Aurora MySQL DB クラスターのレプリケーション

Amazon Aurora によるレプリケーション