Aurora インスタンスを起動するとき、「マルチ AZ 配置」のオプションがあります。これは、「DB インスタンスが別のアベイラビリティーゾーンに配置されたスタンバイを持つ必要があるかどうかを指定します」と説明しています。
ただし、Aurora のドキュメントには、Aurora は既にデータベースを異なるアベイラビリティーゾーンに自動的に分散していると記載されていますか?
さらに、Aurora マルチ AZ スタンバイと通常の Aurora レプリカの違いは何ですか。通常のレプリカはパフォーマンスの向上から読み取ることができますが、スタンバイから読み取ることはできませんか?
Auroraは、ストレージ レイヤーで 3 つのアベイラビリティ ゾーンにわたってデータをレプリケートしますが、データベース サーバー インスタンス自体は、単一のアベイラビリティ ゾーンにある単一の物理マシン上で実行される仮想マシンのままです。
Aurora ストレージ レイヤーはそのインスタンスの外部にあり、最大 2 つの AZ が失われた場合でも、データを失うことなくアクセスを中断せずに続行できますが、db インスタンスを含むゾーンが失われると、引き続き停止が発生します。クラスターに Aurora インスタンスが 1 つしかない場合 (マスター 1 つ、レプリカ 0)。アベイラビリティ ゾーン全体が失われることは、非常にありそうもないことの 1 つですが、不可能ではありません。db インスタンスは、1 つしかない場合でも単一障害点です。
マルチ AZ は、別の AZ で完全に冗長なデータベース インスタンスを考慮に入れます。これは、プライマリ インスタンスをホストしている AZ が失われた場合や壊滅的な災害が発生した場合に、設計どおりに機能する場合、1 分以内にプライマリを自動的に引き継ぎます。プライマリ インスタンスの障害。これは、2 番目の可用性ゾーンにある 2 番目の物理マシン上の 2 番目の仮想マシンです。常に実行されていますが、アクセスできません。これはバックグラウンドにあり、RDS インフラストラクチャによって管理および監視されていますが、プライマリ インスタンスに障害が発生した場合にのみアクセスできます。セカンダリ マシンを使用して、プライマリでソフトウェアのアップグレードやメンテナンス イベントが発生した場合のダウンタイムを短縮することもできます。フェイルオーバーが発生したときに、DNS を使用してデータベースに接続している場合 (そうすべきです)、
これを、読み取りのオフロードを許可することで、常にアクセスできる読み取りレプリカと比較して、パフォーマンスを大幅に向上させることができます。レプリカへのフェイルオーバーには、それをスタンドアロン マスターに昇格させ (以前のマスターから永久に切り離す)、代替エンドポイントを使用するようにアプリケーションを再構成する必要があります。もちろん、これは、ポイントインタイム スナップショットを使用して代替マスター インスタンスを作成することにより、マスターの障害から復旧するよりも高速です。