Amazon Aurora でリードレプリカを使用するときの一般的な問題を解決するにはどうすればよいですか?

最終更新日: 2021 年 2 月 1 日

Amazon Aurora MySQL DB インスタンスのリードレプリカで作業するときに問題が発生しています。Amazon Aurora でリードレプリカを使用するときの一般的な問題のトラブルシューティングを行うにはどうすればよいですか?

簡単な説明

Amazon Aurora MySQL は、同じ AWS リージョン内のライター DB インスタンスと共通の基盤ボリュームを共有するリードレプリカをサポートします。ライター DB インスタンスを変更した場合、更新は DB クラスター内のレプリカインスタンスに表示されます。クロスリージョン MySQL リードレプリカを作成することもできます。これらは、MySQL バイナリベースのレプリケーションエンジンを使用して実装されます。

読み取りオペレーションをスケーリングするときは、Aurora レプリカを使用するのがベストプラクティスです。これは、ライターの読み取りワークロードを減らすことによって行います。その後、可用性を高め、スケーリングの低速化やブロックの原因となるイベントを処理します。

解決方法

Aurora リードレプリカの昇格方法を教えてください。

手動フェイルオーバー - 次の手順に従って手動フェイルオーバーを実行し、別のリードレプリカインスタンスをライターインスタンスとして昇格させます。

  1. Amazon Relational Database Service (Amazon RDS) コンソールにサインインします。
  2. ナビゲーションペインで [データベース] をクリックします。
  3. Aurora DB クラスターのライターインスタンスを選択します。
  4. [アクション] を選択し、[ダウンロード] をクリックします。

自動フェイルオーバー - ライターインスタンスが使用できなくなった場合、Aurora はリードレプリカインスタンスに自動的にフェールオーバーします。これは、リソースの競合やメンテナンスアクティビティなど、さまざまな理由で発生します。複数のリーダーがある場合は、クラスター内の各インスタンスにプロモーションの優先枠を割り当てることができます。ライターインスタンスに障害が発生すると、Aurora は優先度が最も高いレプリカを新しいライターとして昇格します。

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

レプリケーションの遅延を測定するにはどうすればよいですか?

単一の DB クラスター内のすべての Aurora DB インスタンスは共通のデータボリュームを共有するため、レプリケーションの遅延は最小限に抑えられます。通常、遅延時間は 10 ミリ秒です。しかし、いくつかの特定の状況では、リーダーで遅延がわずかに増加することがあります。

注意: 論理レプリケーションを使用するクロスリージョンレプリカは、変更率または適用率、および選択された特定のリージョン間のネットワーク通信の遅延による影響を受けます。一般的に、Aurora データベースを使用するクロスリージョンレプリカでは 1 秒未満の遅延が生じます。

以下の Amazon CloudWatch メトリクスを使用して、レプリケーションラグを測定できます。

  • AuroraReplicaLag を使用すると、ライターノードとリーダーノード間のレプリカの遅延をミリ秒単位で測定できます (同じリージョン)。
  • AurorabinLogReplicaLag を使用すると、バイナリログを使用して Aurora DB クラスター間のレプリカの遅延を測定できます。

レプリケーションのパフォーマンスを向上させるにはどうすればよいですか?

レプリカの遅延を改善するには、次の推奨事項に従ってください。

  • リーダーインスタンスがライターインスタンスよりも小さい場合、変更の量が多すぎてリーダーが追いつかない可能性があります。リーダーインスタンスでのワークロードの過負荷を避けるベストプラクティスは、クラスター内のすべてのインスタンスを同じサイズにすることです。
  • ライターの負荷が大きい場合は、リードレプリカで一時的な遅延が発生することがあります。リーダーインスタンスの処理がライターインスタンスに追いついたら遅延は減少します。
  • 長時間実行しているトランザクションがある場合は、リーダーにレプリカの遅延が発生する可能性があります。レプリカの遅延を回避するには、トランザクションを小さなバッチで実行してコミットを頻繁に実行します。

ネイティブのバイナリベースの MySQL レプリケーションを使用したレプリカの遅延が大きい場合のトラブルシューティングの詳細については、「Aurora DB クラスターのバックアップと復元の概要」を参照してください。

グローバルトランザクション識別子 (GTID) を使用できますか?

グローバルトランザクション識別子は、そのコミット上のトランザクションに関連付けられた一意の文字列です。GTID はすべてのサーバーで一意であり、変更内容は GTID 値に基づいてターゲットに適用されます。詳細については、MySQL ドキュメントで GTID の概念を確認してください。

Aurora では、ネイティブバイナリログレプリケーションを使用してリードレプリカインスタンスにデータをレプリケートしません。GTID を使用して、同じクラスター内のインスタンス間でデータをレプリケートすることはできません。ただし、特定のシナリオで GTID ベースのレプリケーションを設定できます。Aurora MySQL での GTID ベースのレプリケーションの使用の詳細については、GTID に関する AWS ブログを参照してください。

注意: Amazon RDS MySQL と Aurora クラスターの間、および Aurora クラスター間で (ソースが外部マスターであると仮定して) GTID ベースのレプリケーションを設定できます。レプリケーションプロセスを開始する前に、ソースでバイナリログを有効にしてください。


この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?