Amazon Aurora MySQL を使用したシングルマスターレプリケーション - Amazon Aurora

Amazon Aurora MySQL を使用したシングルマスターレプリケーション

Aurora MySQL レプリケーション機能は、クラスターの高可用性とパフォーマンスにとって重要な要素です。Aurora では、最大 15 個の Aurora レプリカを使用して、簡単にクラスターの作成またはサイズ変更を行うことができます。

すべてのレプリカは同じ基盤となるデータから機能します。一部のデータベースインスタンスがオフラインになると、他のデータベースインスタンスがクエリの処理を続行します。あるいは、必要に応じてライターの機能を引き継ぐことができます。Aurora は複数のデータベースインスタンスに読み取り専用接続を自動的に分散させ、Aurora クラスターがクエリ負荷の重いワークロードをサポートできるようにします。

以下は、Aurora MySQL レプリケーションのしくみと、レプリケーション設定を最大限の可用性とパフォーマンスを得るために調整する方法について説明しています。

注記

次に、シングルマスターレプリケーションを使用した Aurora クラスターのレプリケーション機能について説明します。この種類のクラスターは、Aurora のデフォルトです。Aurora マルチマスタークラスターについては、Aurora マルチマスタークラスターを使用する を参照してください。

Aurora レプリカの使用

Aurora レプリカは、Aurora DB クラスター内の独立したエンドポイントであり、読み取りオペレーションのスケーリングと可用性の向上に最適です。最大 15 個の Aurora レプリカを、1 つの AWS リージョンの中で DB クラスターが処理するアベイラビリティーゾーン全体に分散できます。DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されますが、クラスターボリューム内のデータは、DB クラスター内のプライマリインスタンスと Aurora レプリカに対する単一の論理ボリュームとして表されます。Aurora レプリカの詳細については、「Aurora レプリカ」を参照してください。

Aurora レプリカは、クラスターボリュームでの読み取りオペレーションに特化しているため、読み取りのスケーリングに最適です。書き込みオペレーションはプライマリインスタンスによって管理されます。クラスターボリュームは Aurora MySQL DB クラスター内のすべてのインスタンスで共有されるため、Aurora レプリカごとにデータのコピーをレプリケートする追加作業は必要ありません。対照的に、MySQL のリードレプリカは、単一スレッドで、ソース DB インスタンスからローカルデータストアへのすべての書き込みオペレーションを再生する必要があります。この制限により、大量の読み取りトラフィックをサポートする MySQL リードレプリカの能力に影響を与える可能性があります。

Aurora MySQL では、Aurora レプリカが削除されるとそのインスタンスエンドポイントは直ちに削除され、Aurora レプリカも読み込みエンドポイントから削除されます。削除中の Aurora レプリカで実行されているステートメントがある場合は、削除までに 3 分の猶予期間があります。既存のステートメントは、猶予期間中に適切に終了する場合があります。猶予期間が終了すると、Aurora レプリカはシャットダウンし、削除されます。

重要

Aurora MySQL の Aurora レプリカは常に、InnoDB テーブル上のオペレーションに、デフォルトのトランザクション分離レベル REPEATABLE READ を使用します。SET TRANSACTION ISOLATION LEVEL コマンドは、Aurora MySQL DB クラスターのプライマリインスタンスのトランザクションレベルを変更する場合にのみ使用できます。この制限により、Aurora レプリカ上でのユーザーレベルのロックを回避し、Aurora レプリカがレプリカの遅延を最小限に抑えたまま何千ものアクティブユーザーの接続のサポートをできるようにします。

注記

プライマリインスタンスで実行された DDL ステートメントにより、関連付けられた Aurora レプリカのデータベース接続が中断される場合があります。Aurora レプリカ接続でテーブルなどのデータベースオブジェクトを使用中である場合、そのオブジェクトが DDL ステートメントを使用してプライマリインスタンスで変更されると、Aurora レプリカ接続は中断されます。

注記

中国 (寧夏) リージョンは、クロスリージョンリードレプリカをサポートしません。

Amazon Aurora MySQL のレプリケーションオプション

次のいずれのオプションの間でもレプリケーションを設定できます。

注記

また、Amazon Aurora DB クラスターのプライマリインスタンスを再起動すると、DB クラスター全体の一貫した読み取り/書き込みを保証するエントリポイントを再確立するために、DB クラスターの Aurora レプリカも自動的に再起動します。

Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項

以下の機能を使用して、Aurora MySQL レプリケーションのパフォーマンスを微調整することができます。

Aurora MySQL 1.17.4 以降では、レプリカログ圧縮機能を使用して、レプリケーションメッセージのネットワーク帯域幅を自動的に縮小できます。各メッセージはすべての Aurora レプリカに送信されるため、大規模なクラスターではメリットが大きくなります。この機能には、圧縮を実行する書き込みノードの CPU オーバーヘッドが含まれます。そのためこの機能は、CPU 容量が大きい 8xlarge および 16xlarge インスタンスクラスでのみ使用できます。これらのインスタンスクラスでは、デフォルトで有効になっています。aurora_enable_replica_log_compression パラメータをオフにして、この機能を制御できます。例えば、書き込みノードが CPU 容量の最大に近い場合、大きなインスタンスクラスのレプリカログ圧縮をオフにすることができます。

Aurora MySQL 1.17.4 以降では、バイナリログフィルタ処理機能を使用して、レプリケーションメッセージのネットワーク帯域幅を自動的に縮小できます。レプリケーションメッセージに含まれるバイナリログ情報は、Aurora レプリカで使用されないため、これらのノードに送信されるメッセージからは除外されます。この機能を制御するには、aurora_enable_repl_bin_log_filtering パラメータを変更します。このパラメータはデフォルトでオンになっています。この最適化は透過的であることを意図されているため、この設定をオフにできるのは、レプリケーションに関する問題の診断時またはトラブルシューティング時に限られる場合があります。この機能を使用できない古い Aurora MySQL クラスターなどの場合は、その動作に合わせてこの設定をオフにすることができます。

ダウンタイムのない再起動 (ZDR) (Amazon Aurora MySQL 用)

ダウンタイムのない再起動 (ZDR) 機能は、特定の種類の再起動中に DB インスタンスへのアクティブな接続の一部または全部を保持できます。ZDR は、Aurora がエラー条件 (レプリカがソースより遅すぎるなど) を解決するために自動的に実行する再起動に適用されます。

重要

ZDR メカニズムはベストエフォートベースで動作します。ZDR が適用される場合を決定する Aurora MySQL バージョン、インスタンスクラス、エラー条件、互換性のある SQL オペレーション、およびその他の要因は、いつでも変更される可能性があります。

ZDR が利用可能な Aurora MySQL 1.* バージョンでは、クラスターパラメータグループの aurora_enable_zdr パラメータをオンにすることによって、この機能を有効にします。Aurora MySQL 2.* の ZDR にはバージョン 2.10 以降が必要です。これらのバージョンでは、ZDR メカニズムはデフォルトでオンになっており、Aurora は aurora_enable_zdr パラメータを使用しません。

Aurora は、停止時間ゼロの再起動に関連するアクティビティに関するレポートを、 [イベント] ページに表示します。Aurora は、ZDR メカニズムを使用して再起動を試みる際にイベントを記録します。このイベントは、Aurora が再起動を実行する理由を示します。その後、Aurora は再起動の完了時に別のイベントを記録します。この最終イベントは、再起動中にプロセスに要した時間、および保持またはドロップされた接続の数を報告します。データベースエラーログを参照して、再起動中に発生した処理の詳細を確認できます。

ZDR オペレーションが成功した後も接続はそのまま残りますが、一部の変数と機能は再初期化されます。次の種類の情報は、ダウンタイムのない再起動によって生じる再起動を通じては保持されません。

  • グローバル変数 Aurora はセッション変数を復元しますが、再起動後のグローバル変数の復元は行いません。

  • ステータス変数。特に、エンジンのステータスによって報告される稼働時間の値はリセットされます。

  • LAST_INSERT_ID.

  • テーブルのメモリ内 auto_increment 状態。メモリ内自動インクリメント状態が再初期化されます。自動インクリメント値の詳細については、MySQL リファレンスマニュアルを参照してください。

  • INFORMATION_SCHEMA および PERFORMANCE_SCHEMA テーブルからの診断情報。この診断情報は、SHOW PROFILESHOW PROFILES などのコマンドの出力にも表示されます。

次の表では、クラスター内の DB インスタンスを再起動するときに Aurora が ZDR メカニズムを使用できるかどうかを決定するバージョン、インスタンスロール、インスタンスクラス、およびその他の状況を示しています。

Aurora MySQL バージョン ZDR はライターに適用されますか? ZDR はリーダーに適用されますか? コメント

Aurora MySQL バージョン 1.*、1.17.3 以下

いいえ

いいえ

ZDR はこれらのバージョンでは利用できません。

Aurora MySQL バージョン 1.*、1.17.4 以降

いいえ

はい

これらの Aurora MySQL バージョンでは、ZDR メカニズムに次の条件が適用されます。

  • DB インスタンスでバイナリログ記録が有効になっている場合、Aurora は ZDR メカニズムを使用しません。

  • Aurora は、アクティブな接続で進行中のトランザクションをロールバックします。アプリケーションはトランザクションを再試行する必要があります。

  • Aurora は、TLS/SSL、一時テーブル、テーブルロック、またはユーザーロックを使用するすべての接続をキャンセルします。

Aurora MySQL バージョン 2.*、2.10.0 より前

いいえ

いいえ

ZDR はこれらのバージョンでは利用できません。aurora_enable_zdr パラメータは、Aurora MySQL バージョン 2 のデフォルトのクラスターパラメータグループでは使用できません。

Aurora MySQL バージョン 2.*、2.10.0 以降

はい

はい

ZDR メカニズムは常に有効になっています。

これらの Aurora MySQL バージョンでは、ZDR メカニズムに次の条件が適用されます。

  • Aurora は、アクティブな接続で進行中のトランザクションをロールバックします。アプリケーションはトランザクションを再試行する必要があります。

  • Aurora は、TLS/SSL、一時テーブル、テーブルロック、またはユーザーロックを使用するすべての接続をキャンセルします。

Amazon Aurora MySQL レプリケーションのモニタリング

読み取りのスケーリングと高可用性は最短遅延時間に左右されます。Amazon CloudWatch AuroraReplicaLag メトリクスをモニタリングすることによって、Aurora レプリカが Aurora MySQL DB クラスターのプライマリインスタンスからどれくらい遅延しているかを確認できます。AuroraReplicaLag メトリクスは各 Aurora レプリカに記録されます。

プライマリ DB インスタンスは、AuroraReplicaLagMaximum メトリクスと AuroraReplicaLagMinimum Amazon CloudWatch メトリクスも記録します。AuroraReplicaLagMaximum メトリクスは、DB クラスターのプライマリ DB インスタンスと各 Aurora レプリカの間の最大遅延量を記録します。AuroraReplicaLagMinimum メトリクスは、DB クラスターのプライマリ DB インスタンスと各 Aurora レプリカの間の最小遅延量を記録します。

Aurora レプリカの遅延について最新の値が必要な場合は、Aurora MySQL DB クラスターのプライマリインスタンスの mysql.ro_replica_status テーブルをクエリし、Replica_lag_in_msec 列の値を確認します。この列の値は AuroraReplicaLag メトリクスの値として Amazon CloudWatch に渡されます。Aurora レプリカの遅延は、Aurora MySQL DB クラスターの INFORMATION_SCHEMA.REPLICA_HOST_STATUS テーブル内の各 Aurora レプリカにも記録されます。

RDS インスタンスと CloudWatch メトリックスのモニタリングの詳細については、「Amazon Aurora DB クラスターのモニタリング」を参照してください。