高可用性
Managed Postgres は、耐久性およびパフォーマンス要件に応じた複数レベルの高可用性を提供します。データベースのプロビジョニング時に 1 つまたは 2 つのスタンバイレプリカを追加できるほか、必要に応じて後から Settings ページでこの設定を調整できます。
高可用性構成オプション
2 Standbys
standby を 2 台構成する場合、primary に加えて 2 台のレプリカノードがプロビジョニングされます。両方の standby は primary と同じサイズであり、primary に障害が発生した場合には、どちらもフェイルオーバー先として引き継ぐことができます。
この構成は synchronous replication を使用し、primary は書き込みを確定する前に、少なくとも 1 台の standby からの確認応答を待機します。これは asynchronous replication と比べて、より強い耐久性の保証を提供します。2 台ともからではなく 1 台からの確認応答のみが必要なため、単一の standby で synchronous replication を行う場合と比べて、パフォーマンスへの影響は小さく抑えられます。
スタンバイ 1 台
スタンバイを 1 台構成する場合、プライマリと併せてレプリカノードがプロビジョニングされます。スタンバイはプライマリと同じサイズで構成され、プライマリに障害が発生した場合に引き継ぐことができます。
データは 非同期レプリケーション を使用してスタンバイにレプリケーションされます。これは、スタンバイからの応答を待たずに、書き込みがプライマリへコミットされることを意味します。非同期レプリケーションにより、高可用性を確保しても、追加のネットワークレイテンシーによって書き込み性能が低下しないようにできます。ただしその一方で、プライマリ障害発生時点で、スタンバイが最新のトランザクションをまだ受信していない可能性もあります。多くのアプリケーションでは、このパフォーマンスとごく最近の書き込みを失うごく小さなリスクとのトレードオフは十分に許容できます。書き込みの永続性が必須である場合は、スタンバイを 2 台構成することを推奨します。
スタンバイなし
このオプションでは、選択したサイズでプライマリノードのみがプロビジョニングされます。スタンバイノードは作成されません。プライマリノードは引き続き障害が発生しないか監視されますが、引き継ぐ準備ができているレプリカが存在しないため、問題の内容によっては復旧に時間がかかる場合があります。この構成は、開発環境、テスト環境、またはある程度のダウンタイムが許容される重要度の低いワークロードに最適です。
スタンバイと読み取りレプリカ
Managed Postgres では、スタンバイと読み取りレプリカは目的が異なり、別々に構成されます。
スタンバイは、高可用性と自動フェイルオーバー専用です。ストリーミングレプリケーションを用いてプライマリからデータを複製し、プライマリに障害が発生した場合に昇格できるよう常に待機しています。スタンバイは読み取りクエリのためには提供されません。
読み取りレプリカは、読み取りスケーリングのために設計されています。オブジェクトストレージから WAL (Write-Ahead Log) データを取得し、独立したネットワーク環境で独自の接続エンドポイントを持って動作します。読み取りレプリカを使用すると、高可用性 (HA) の保証に影響を与えることなく、プライマリに対する読み取りトラフィックを肩代わりさせることができます。
スタンバイが読み取りクエリを処理しない理由
一部のデータベースプロバイダは、読み取り専用クエリ向けにホットスタンバイを提供していますが、Managed Postgres はあえてそうしていません。スタンバイで読み取りクエリを許可すると、本来の目的である「プライマリ障害時に即座に引き継ぐ」能力が損なわれる可能性があります。
主な懸念点は 2 つあります。
-
WAL リプレイとの競合: 書き込み負荷が高いワークロードでは、スタンバイ上の読み取りクエリが WAL リプレイとシステムリソースを奪い合います。この競合によってレプリケーション遅延が大きくなり、スタンバイがプライマリに追随できなくなることがあります。スタンバイが遅延している状態でフェイルオーバーが発生すると、最新データが揃っておらず、整合性の取れた形で引き継ぐことができない可能性があります。
-
VACUUM への干渉: スタンバイ上で長時間実行される読み取りクエリは、プライマリ上で
VACUUM（およびAUTOVACUUM）が不要になったタプルをクリーンアップすることを妨げる可能性があります。PostgreSQL は、いずれかのレプリカ上でアクティブなクエリがまだアクセスする可能性のある行を削除できません。この結果、テーブルの肥大化とパフォーマンス低下が時間の経過とともに発生し得ます。
スタンバイをフェイルオーバー専用に保つことで、Managed Postgres は常に同期が取れ、データ損失とダウンタイムを最小限に抑えて引き継ぎができる状態を保証します。読み取りスケールアウトには、代わりに read replicas を使用してください。
障害処理
高可用性の有無にかかわらず、すべての Managed Postgres インスタンスは、障害発生に備えて継続的に監視されています。いずれの場合も、システムは障害からの自動復旧を試みます。
スタンバイが利用可能な場合、自動復旧はより迅速かつ容易になります。システムは通常、スタンバイをプライマリに昇格させることで数分以内に復旧します。スタンバイが存在しない場合は、復旧に手動での対応が必要になることがあり、その分、停止時間が大幅に長くなる可能性があります。
