Azure Database for PostgreSQL の高可用性 (信頼性)

この記事では、可用性ゾーンとリージョン間の復旧とビジネス継続性を含む Azure Database for PostgreSQL の高可用性について説明します。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

Azure Database for PostgreSQL では、同じ可用性ゾーン (ゾーン) 内または複数の可用性ゾーン (ゾーン冗長) 内で、物理的に分離されたプライマリレプリカとスタンバイレプリカをプロビジョニングすることで、高可用性がサポートされます。この高可用性モデルは、コミットされたデータが障害時に失われないように設計されています。高可用性 (HA) セットアップでは、データはプライマリサーバーとスタンバイサーバーの両方に同期的にコミットされます。このモデルは、データベースがソフトウェアアーキテクチャにおける単一障害点にならないように設計されています。高可用性と可用性ゾーンのサポートに関する詳細については、「可用性ゾーンのサポート」をご覧ください。

可用性ゾーンのサポート

可用性ゾーンは、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure Database for PostgreSQL では、高可用性構成用のゾーン冗長モデルとゾーンモデルの両方がサポートされています。どちらの高可用性構成でも、計画的なイベントと計画外のイベントの両方で、データ損失ゼロの自動フェールオーバー機能が有効になります。

ゾーン冗長。ゾーン冗長の高可用性では、別のゾーン内に自動フェールオーバー機能を備えたスタンバイレプリカがデプロイされます。ゾーン冗長性は最高レベルの可用性を提供しますが、ゾーン間でアプリケーションの冗長性を構成する必要があります。そのため、ゾーン冗長は、可用性ゾーンレベルの障害からの保護が必要な場合や、可用性ゾーン間の待機時間を許容できる場合に選択します。書き込みとコミットの待ち時間は同期レプリケーションによってある程度影響を受ける可能性がありますが、読み取りクエリへの影響はありません。この影響は、ワークロード、選択した SKU の種類、リージョンに固有です。

プライマリサーバーとスタンバイサーバーの両方について、リージョンと可用性ゾーンを選択できます。スタンバイレプリカサーバーは、同じリージョン内の選択した可用性ゾーンにプロビジョニングされ、コンピューティング、ストレージ、ネットワーク構成はプライマリサーバーと同じになります。データファイルとトランザクションログファイル (先書きログ、WAL とも呼ばれます) は、各可用性ゾーン内のローカル冗長ストレージ (LRS) に格納され、 3 つの データコピーが自動的に格納されます。ゾーン冗長構成では、プライマリサーバーとスタンバイサーバー間でスタック全体が物理的に分離されます。

ゾーン冗長オプションは、可用性ゾーンがサポートされているリージョンでのみ使用できます。

ゾーン冗長は、次の場合にサポートされていません。

バーストが可能なコンピュート階層
単一ゾーンの可用性を持つリージョン
ゾーンベース。単一の可用性ゾーン内で最高レベルの可用性を実現しながら、ネットワーク待機時間を最小限に抑えたい場合は、ゾーンデプロイを選択します。両方のプライマリデータベースサーバーをデプロイするリージョンと可用性ゾーンを選択できます。スタンバイレプリカサーバーは、同じ可用性ゾーンで自動的にプロビジョニングおよび管理され、コンピューティング、ストレージ、ネットワーク構成はプライマリサーバーと同じになります。ゾーン構成は、ノードレベルの障害からデータベースを保護し、計画的および計画外のダウンタイムイベント中のアプリケーションのダウンタイムを削減するのにも役立ちます。プライマリサーバーからのデータは、同期モードでスタンバイレプリカにレプリケートされます。プライマリサーバーが中断された場合、サーバーは自動的にスタンバイレプリカにフェールオーバーします。

ゾーン デプロイオプションは、フレキシブルサーバーをデプロイできるすべての Azure リージョンで利用できます。

注

ゾーンデプロイモデルとゾーン冗長デプロイモデルは、アーキテクチャ的にはどちらも同じように動作します。以下のセクションのさまざまな記述は、特に明記されていない限り、両方に適用されます。

ポータルでゾーンの回復性を構成する

高可用性 (HA) は、最大の回復性のためにスタンバイサーバーを別の可用性ゾーンに配置するゾーン冗長 HA と、プライマリサーバーと同じゾーンにスタンバイサーバーをデプロイして待機時間を最小限に抑える同じゾーン HA の 2 つの方法で構成できます。

構成を簡略化し、ゾーンの回復性を確保するために、ポータルには、[有効] と [無効] の 2 つのラジオボタンがあるゾーンの回復性オプションが用意されています。 [有効] を選択すると、別の可用性ゾーン (ゾーン冗長 HA モード) にスタンバイサーバーの作成が試行されます。リージョンがゾーン冗長 HA をサポートしていない場合は、代わりにフォールバックチェックボックス (次の図で強調表示されています) を選択して、同じゾーン HA を有効にすることができます。

フォールバックチェックボックスを選択すると、システムによって同じゾーンにスタンバイサーバーが作成されます。ゾーン容量が後で使用可能になった場合、 PITR または読み取りレプリカを使用してゾーン冗長 HA 構成に移行することを選択できるように、Azure から通知されます。チェックボックスをオンにせず、ゾーン容量が使用できない場合、HA の有効化は失敗します。この設計では、ゾーン冗長 HA が既定として適用され、同じゾーン HA に制御されたフォールバックが提供されるため、ワークロードは最終的に手動介入なしで完全なゾーンの回復性を実現します。

高可用性機能

スタンバイレプリカは、プライマリサーバーと同じ VM 構成 (仮想コア、ストレージ、ネットワーク設定など) にデプロイされます。
既存のデータベースサーバーに可用性ゾーンのサポートを追加できます。
高可用性を無効にすることで、スタンバイレプリカを削除できます。
ゾーン冗長可用性を実現するために、プライマリデータベースサーバーとスタンバイデータベースサーバーの可用性ゾーンを選択できます。
停止、開始、再起動などの操作は、プライマリとスタンバイの両方のデータベースサーバーで同時に実行されます。
ゾーン冗長モデルとゾーンモデルでは、プライマリデータベースサーバーは自動バックアップを定期的に実行します。同時に、スタンバイレプリカは、バックアップストレージ内のトランザクションログを継続的にアーカイブします。リージョンで可用性ゾーンがサポートされている場合、バックアップデータがゾーン冗長ストレージ (ZRS) に保存されます。可用性ゾーンがサポートされていないリージョンでは、バックアップデータがローカル冗長ストレージ (LRS) に保存されます。
クライアントは常に、プライマリデータベースサーバーのエンドホスト名に接続されます。
サーバーパラメーターへの変更は、スタンバイレプリカにも適用されます。
サーバーを再起動して、静的サーバーパラメーターの変更を取得できます。
マイナーバージョンのアップグレードなどの定期的なメンテナンスアクティビティは、最初にスタンバイで行われます。ダウンタイムを減らすために、スタンバイはプライマリに昇格されるため、残りのノードにメンテナンスタスクが適用されている間もワークロードを維持できます。

注

高可用性機能を適切に確保するには、 max_replication_slots と max_wal_senders サーバーパラメーターの値を構成します。高可用性には、フェールオーバーとシームレスなアップグレードを処理するために、それぞれ 4 つが必要です。 5 つの読み取りレプリカと 12 個の論理レプリケーションスロットを使用した高可用性セットアップでは、 max_replication_slots と max_wal_senders の両方のパラメーター値を 21 に設定します。この構成が必要なのは、各読み取りレプリカと論理レプリケーションスロットには、それぞれ 1 つと、高可用性が正常に機能するために必要な 4 つが必要であるためです。 max_replication_slotsパラメーターとmax_wal_senders パラメーターの詳細については、ドキュメントを参照してください。

高可用性の正常性を監視する

Azure Database for PostgreSQL での高可用性 (HA) の正常性状態の監視では、HA 対応インスタンスの正常性と準備の継続的な概要が提供されます。この監視機能は、Azure の Resource Health Check (RHC) フレームワークを適用して、データベースのフェールオーバーの準備または全体的な可用性に影響を与える可能性のある問題を検出してアラートを生成します。 HA 正常性状態の監視では、接続状態、フェールオーバー状態、データレプリケーションの正常性などの主要なメトリックを評価することで、予防的なトラブルシューティングが可能になり、データベースのアップタイムとパフォーマンスを維持するのに役立ちます。

HA ヘルスステータスの監視を利用して、次の操作を行います。

パフォーマンスの低下やネットワークのブロックなど、潜在的な問題を明らかにする状態インジケーターを使用して、プライマリレプリカとスタンバイレプリカの両方の正常性に関するリアルタイムの分析情報を取得します。
HA 状態の変更に関するタイムリーな通知のアラートを設定して、潜在的な中断に対処するための迅速なアクションを実行できるようにします。
データベース操作に影響を与える前に問題を特定して対処することで、フェールオーバーの準備を最適化します。

HA の正常性状態の構成と解釈に関する詳細なガイドについては、 Azure Database for PostgreSQL の高可用性 (HA) の正常性状態の監視に関するページを参照してください。

高可用性の制限

スタンバイサーバーへの同期レプリケーション (特にゾーン冗長構成の場合) により、アプリケーションでは書き込みとコミットの待機時間が長くなる可能性があります。
読み取りクエリにスタンバイレプリカを使用することはできません。
プライマリサーバーのワークロードとアクティビティによっては、スタンバイレプリカを昇格する前に復旧する必要があるため、フェールオーバープロセスに 120 秒以上かかる場合があります。
通常、スタンバイサーバーでは、40 MB/秒で WAL ファイルが復旧されます。より大きなバージョンの場合、このレートは 200 MB/秒まで増加する可能性があります。ワークロードがこの制限を超える場合、フェールオーバー中または新しいスタンバイの確立後、復旧完了までの時間が延びる可能性があります。
プライマリデータベースサーバーを再起動すると、スタンバイレプリカも再起動されます。
追加のスタンバイを構成することはできません。
管理メンテナンス期間中に、顧客が開始した管理タスクをスケジュールすることはできません。
スケールコンピューティングやスケールストレージなどの計画的なイベントは、最初にスタンバイで発生し、次にプライマリサーバーで発生します。現在、これらの計画的な操作については、サーバーのフェールオーバーは行われません。
HA 対応フレキシブルサーバーで論理デコードまたは論理レプリケーションを構成する場合:
- PostgreSQL 16 以前では、論理レプリケーションスロットは、既定でフェールオーバー後にスタンバイサーバーに保持されません。
- フェールオーバー後も論理レプリケーションが引き続き機能するようにするには、 pg_failover_slots 拡張機能を有効にして、 hot_standby_feedback = onなどのサポート設定を構成する必要があります。
- PostgreSQL 17 以降では、スロット同期が標準機能としてサポートされています。適切な PostgreSQL 構成 (sync_replication_slots、 hot_standby_feedback) を有効にした場合、論理レプリケーションスロットはフェールオーバー後に自動的に保持され、拡張機能は必要ありません。
- セットアップ手順と前提条件については、 PG_Failover_Slots拡張機能のドキュメントを参照してください。
プライベート (仮想ネットワーク) とプライベートエンドポイントを使用したパブリックアクセスの間の可用性ゾーンの構成はサポートされていません。仮想ネットワーク内の可用性ゾーン (リージョン内の可用性ゾーンにまたがる) またはプライベートエンドポイントを使用したパブリックアクセスを構成する必要があります。
可用性ゾーンは、1 つのリージョン内でのみ構成できます。リージョン間で可用性ゾーンを構成することはできません。

SLA

ゾーン モデルは、約 99.95%の SLA のアップタイムを提供します。
ゾーン冗長モデルは、約 99.99%の SLA のアップタイムを提供します。

可用性ゾーンが有効になっている Azure Database for PostgreSQL を作成する

可用性ゾーンを使用して高可用性を実現するために Azure Database for PostgreSQL を作成する方法については、「クイックスタート: Azure portal で Azure Database for PostgreSQL を作成する」を参照してください。

可用性ゾーンの再デプロイと移行

ゾーン冗長デプロイモデルとゾーンデプロイモデルの両方でフレキシブルサーバーの高可用性構成を有効または無効にする方法については、「フレキシブルサーバーでの高可用性の管理」を参照してください。

高可用性コンポーネントとワークフロー

トランザクションの完了

アプリケーショントランザクションは、最初にプライマリサーバー上の WAL にログを記録する書き込みとコミットをトリガーします。プライマリサーバーは、Postgres ストリーミングプロトコルを使用して、これらのログをスタンバイサーバーにストリーミングします。スタンバイサーバーストレージがログを保持すると、プライマリサーバーは書き込みの完了を確認します。アプリケーションは、この受信確認の後にのみトランザクションをコミットします。この余分なラウンドトリップにより、アプリケーションに待機時間が追加されます。影響率は、アプリケーションによって異なります。この確認プロセスでは、スタンバイサーバーへのログの適用を待機しません。スタンバイサーバーは、プロモートされるまでリカバリモードのままです。

健康診断

フレキシブルサーバーの正常性監視では、プライマリサーバーとスタンバイサーバーの両方の正常性が定期的にチェックされます。複数の ping を実行した後、正常性の監視でプライマリサーバーに到達できないことが検出された場合、サービスはスタンバイサーバーへの自動フェールオーバーを開始します。正常性監視アルゴリズムは、誤検知の状況を回避するために複数のデータポイントを使用します。

フェールオーバーモード

フレキシブルサーバーは、計画フェールオーバーと計画外フェールオーバーの 2 つのフェールオーバーモードをサポートします。どちらのモードでも、レプリケーションが中断されると、スタンバイサーバーはプライマリとして昇格する前に復旧を実行し、読み取り/書き込みのために開きます。新しいプライマリサーバーエンドポイントで自動 DNS エントリが更新された場合、アプリケーションは同じエンドポイントを使用してサーバーに接続できます。新しいスタンバイサーバーがバックグラウンドで確立されるので、それによってアプリケーションは接続性を維持できます。

高可用性の状態

システムは、プライマリサーバーとスタンバイサーバーの正常性を継続的に監視します。スタンバイサーバーへのフェールオーバーのトリガーなど、問題を解決するための適切なアクションが実行されます。次の表に、考えられる高可用性の状態を示します。

地位	説明
初期化中	新しいスタンバイサーバーの作成中です。
データのレプリケート中	スタンバイの作成後、そのスタンバイがプライマリにキャッチアップ中です。
Healthy	レプリケーションは安定状態にあり、正常です。
フェールオーバー中	データベースサーバーはスタンバイにフェールオーバー中です。
スタンバイの削除中	スタンバイサーバーの削除中です。
無効	高可用性が有効ではありません。

注

高可用性は、サーバーの作成時または後で有効にすることができます。作成後のステージで高可用性を有効または無効にする場合は、プライマリサーバーのアクティビティが少ないときに有効または無効にします。

安定状態の操作

PostgreSQL クライアントアプリケーションは、DB サーバー名を使用してプライマリサーバーに接続します。プライマリサーバーは、アプリケーションの読み取りを直接処理します。同時に、アプリケーションはコミットの確認を受け取り、ログデータがプライマリサーバーとスタンバイレプリカの両方に保持された後にのみ書き込みを行います。この余分なラウンドトリップのため、アプリケーションでは、書き込みとコミットの待機時間が長くなることが予想されます。高可用性の正常性をポータルで監視できます。

高可用性の安定状態の操作ワークフローを示す図。

クライアントがフレキシブルサーバーに接続し、書き込み操作を実行します。
変更は待機サイトに複製されます。
プライマリが受信確認を受け取ります。
書き込みとコミットが確認されます。

高可用性サーバーのポイントインタイムリストア

高可用性で構成されたフレキシブルサーバーの場合、システムはリアルタイムでログデータをスタンバイサーバーにレプリケートします。テーブルの誤削除や不適切なデータ更新など、プライマリサーバー上のユーザーエラーは、スタンバイレプリカにレプリケートされます。そのため、このような論理エラーから回復するためにスタンバイを使用することはできません。このようなエラーから復旧するには、バックアップからポイントインタイムリストアを実行する必要があります。フレキシブルサーバーのポイントインタイムリストア機能を使用すると、エラーが発生する前の時刻に復元できます。新しいデータベースサーバーが、高可用性が構成されたデータベースのために単一ゾーンフレキシブルサーバーとして復元され、ユーザーが指定した新しいサーバー名が付けられます。復元されたサーバーは、いくつかのユースケースで使用できます。

復元されたサーバーを運用環境に使用し、必要に応じて、同じゾーンまたは同じリージョン内の別のゾーンのスタンバイレプリカで高可用性を有効にします。
オブジェクトを復元する場合は、復元されたデータベースサーバーからオブジェクトをエクスポートして、運用データベースサーバーにインポートします。
テストおよび開発目的でデータベースサーバーを複製する場合や、その他の目的のために復元する場合は、ポイントインタイムリストアを実行できます。

フレキシブルサーバーのポイントインタイムリストアを実行する方法については、「フレキシブルサーバーのポイントインタイムリストア」をご覧ください。

フェールオーバーのサポート

計画されたフェールオーバー

計画的なダウンタイムのイベントには、Azure のスケジュールされた定期的なソフトウェア更新やマイナーバージョンのアップグレードが含まれます。計画フェールオーバーを使用して、プライマリサーバーを優先可用性ゾーンに戻すこともできます。高可用性を構成する場合、これらの操作はまずスタンバイレプリカに適用され、アプリケーションは引き続きプライマリサーバーにアクセスします。プロセスによってスタンバイレプリカが更新されると、プライマリサーバー接続がドレインされ、同じデータベースサーバー名を持つプライマリサーバーとしてスタンバイレプリカがアクティブ化されるフェールオーバーがトリガーされます。クライアントアプリケーションは、同じデータベースサーバー名で新しいプライマリサーバーに再接続し、操作を再開できます。このプロセスにより、古いプライマリと同じゾーンに新しいスタンバイサーバーが確立されます。

スケールコンピューティングやスケールストレージなど、ユーザーが開始するその他の操作の場合、プロセスは最初にスタンバイ、次にプライマリに変更を適用します。現時点では、サービスはスタンバイにフェールオーバーしません。そのため、スケール操作はプライマリサーバーで実行されますが、アプリケーションでは短いダウンタイムが発生します。

また、この機能を使用すると、ダウンタイムを短縮してスタンバイサーバーにフェールオーバーできます。たとえば、プライマリサーバーは、計画外のフェールオーバー後にアプリケーションとは異なる可用性ゾーンに存在する可能性があります。アプリケーションと併置するために、プライマリサーバーを前のゾーンに戻す必要があります。

この機能を実行すると、プロセスは最初にスタンバイサーバーが最新のトランザクションに追いつくために準備し、アプリケーションが読み取りと書き込みの実行を続行できるようにします。このプロセスでは、スタンバイがプライマリに昇格され、既存のプライマリへの接続が切断されます。プロセスがバックグラウンドで新しいスタンバイサーバーを確立している間、アプリケーションは引き続きプライマリに書き込むことができます。次の表では、計画されたフェールオーバーに関連する手順について説明します。

ステップ	説明	アプリのダウンタイムが予想されるか?
1	スタンバイサーバーがプライマリに追いつくのを待ちます。	いいえ
2	内部監視システムによって、フェールオーバーワークフローが開始されます。	いいえ
3	スタンバイサーバーがプライマリのログシーケンス番号 (LSN) に近い場合、アプリケーションの書き込みはブロックされます。	イエス
4	スタンバイサーバーが独立したサーバーに昇格されます。	イエス
5	DNS レコードがスタンバイサーバーの新しい IP アドレスで更新されます。	イエス
6	アプリケーションは再接続し、新しいプライマリとの読み取り/書き込みを再開します。	いいえ
7	別のゾーンの新しいスタンバイサーバーが確立されます。	いいえ
八	スタンバイサーバーで、確立中に失われたログの復旧が (Azure BLOB から) 開始されます。	いいえ
9	プライマリサーバーとスタンバイサーバーの間に安定した状態が確立されます。	いいえ
10	計画フェールオーバーのプロセスが完了します。	いいえ

アプリケーションのダウンタイムは手順 3 から開始され、手順 5 の後に操作を再開できます。残りの手順は、アプリケーションの書き込みとコミットに影響を与えることなく、バックグラウンドで行われます。

ヒント

フレキシブルサーバーを使用すると、必要に応じて、データベース上のアクティビティが低いことが予想される日に 60 分の期間を選択することで、Azure によって開始されるメンテナンスアクティビティをスケジュールできます。修正プログラムの適用やマイナーバージョンのアップグレードなどの Azure メンテナンスタスクは、その期間中に発生します。カスタムウィンドウを選択しない場合、システムは、サーバーの現地時刻の午後 11 時から午前 7 時の間に 1 時間のウィンドウを割り当てます。これらの Azure によって開始されるメンテナンスアクティビティは、可用性ゾーンで構成されたフレキシブルサーバーのスタンバイレプリカでも実行されます。

発生する可能性のある計画的なダウンタイムイベントの一覧については、「計画的なダウンタイムイベント」をご覧ください。

計画外のフェールオーバー

計画外のダウンタイムは、基になるハードウェア障害、ネットワークの問題、ソフトウェアのバグなど、予期しない中断の結果として発生する可能性があります。高可用性で構成されたデータベースサーバーが予期せず停止した場合、プロセスによってスタンバイレプリカがアクティブ化され、クライアントは操作を再開できます。高可用性 (HA) を構成せず、再起動の試行が失敗した場合、プロセスによって新しいデータベースサーバーが自動的にプロビジョニングされます。計画外のダウンタイムを回避することはできませんが、フレキシブルサーバーは、人間の介入を必要とせずに自動的に復旧操作を実行することで、ダウンタイムを軽減するのに役立ちます。

考えられるシナリオなど、計画外のフェールオーバーとダウンタイムの詳細については、「計画外のダウンタイムの軽減」をご覧ください。

フェールオーバーテスト (強制フェールオーバー)

強制フェールオーバーを使用すると、運用ワークロードの実行中に計画外の停止シナリオをシミュレートし、アプリケーションのダウンタイムを観察できます。プライマリサーバーが応答しなくなったときに強制フェールオーバーを使用することもできます。

強制フェールオーバーによってプライマリサーバーが停止され、スタンバイ昇格操作が実行されるフェールオーバーワークフローが開始されます。スタンバイは、最後にコミットされたデータまで復旧プロセスを完了すると、プライマリサーバーに昇格されます。 DNS レコードが更新され、アプリケーションは昇格されたプライマリサーバーに接続できます。新しいスタンバイサーバーがバックグラウンドで確立されている間、アプリケーションは引き続きプライマリに書き込みを行うことができます。これが稼働時間に影響を及ぼすことはありません。

強制フェールオーバー中の手順を次の表に示します。

ステップ	説明	アプリのダウンタイムが予想されるか?
1	プライマリサーバーは、フェールオーバー要求を受信した直後に停止します。	イエス
2	プライマリサーバーがダウンしているため、アプリケーションでダウンタイムが発生します。	イエス
3	内部監視システムによってエラーが検出され、スタンバイサーバーへのフェールオーバーが開始されます。	イエス
4	スタンバイサーバーは、独立したサーバーとして完全に昇格される前に、回復モードに移行します。	イエス
5	フェールオーバープロセスは、スタンバイの復旧が完了するまで待機します。	イエス
6	サーバーが稼働すると、プロセスは同じホスト名で DNS レコードを更新しますが、スタンバイの IP アドレスを使用します。	イエス
7	アプリケーションは新しいプライマリサーバーに再接続して操作を再開できます。	いいえ
八	優先ゾーン内のスタンバイサーバーが確立されます。	いいえ
9	スタンバイサーバーで、確立中に失われたログの復旧が (Azure BLOB から) 開始されます。	いいえ
10	プライマリサーバーとスタンバイサーバーの間に安定した状態が確立されます。	いいえ
11	強制フェールオーバープロセスが完了します。	いいえ

アプリケーションのダウンタイムは、手順 1 の後に開始され、手順 6 が完了するまで続行されます。他の手順は、アプリケーションの書き込みとコミットに影響を与えずにバックグラウンドで実行されます。

Important

エンドツーエンドのフェールオーバープロセスには、(a) プライマリの障害発生後のスタンバイサーバーへのフェールオーバーと (b) 定常状態での新しいスタンバイサーバーの確立が含まれます。スタンバイへのフェールオーバーが完了するまでアプリケーションでダウンタイムが発生するため、エンドツーエンドのフェールオーバープロセス全体ではなく 、アプリケーション/クライアントの観点からダウンタイムを測定 します。

強制フェールオーバーを実行するときの考慮事項

全体的なエンドツーエンドの操作時間は、アプリケーションによって発生した実際のダウンタイムよりも長くなる可能性があります。

Important

常にアプリケーションの観点からダウンタイムを観察してください。
フェールオーバーをすぐに連続して実行することはしないでください。新しいスタンバイサーバーを完全に確立できるように、フェールオーバーの間に少なくとも 15 ~ 20 分待ちます。
ダウンタイムを減らすために、アクティビティの少ない期間中に強制フェールオーバーを実行します。

フェールオーバー後の PostgreSQL 統計のベストプラクティス

PostgreSQL フェールオーバー後、最適なデータベースパフォーマンスを維持するには、 pg_statistic テーブルと pg_stat_* テーブルの個別のロールを理解する必要があります。 pg_statistic テーブルにはオプティマイザー統計が格納されます。これはクエリプランナーにとって非常に重要です。これらの統計にはテーブル内のデータ分散が含まれており、フェールオーバー後もそのまま残ります。これにより、クエリプランナーは、正確な履歴データ分散情報に基づいてクエリの実行を効果的に最適化し続けることができます。

これに対し、 pg_stat_* テーブルは、スキャンの数、読み取られたタプル、更新などのアクティビティの統計情報を記録し、フェールオーバー時にリセットします。このようなテーブルの例として、ユーザー定義テーブルのアクティビティを追跡する pg_stat_user_tables テーブルがあります。このリセットは、新しいプライマリの運用状態を正確に反映しますが、自動バキュームプロセスやその他の運用効率を通知する可能性のある履歴アクティビティメトリックの損失も意味します。

この違いを考えると、PostgreSQL フェールオーバー後に ANALYZE を実行します。このアクションにより、新しいアクティビティ統計などを含むpg_stat_* テーブル (例えば pg_stat_user_tables) が更新され、自動バキュームプロセスに役立ち、新しいロールでデータベースのパフォーマンスが最適なまま維持されます。このプロアクティブな手順は、データベースの現在の状態に合わせて、基本的なオプティマイザー統計を保持することとアクティビティメトリックを更新することとのギャップを埋めます。

ゾーンダウンエクスペリエンス

ゾーン: ゾーンレベルの障害から復旧するには、バックアップを使用してポイントインタイムリストアを実行します。最新時刻のカスタム復元ポイントを選択して、最新のデータを復元できます。影響を受けていない別のゾーンに、新しいフレキシブルサーバーがデプロイされます。復元にかかる時間は、前回のバックアップと、復旧するトランザクションログの量によって異なります。

ポイントインタイムリストアの詳細については、「Azure Database for PostgreSQL フレキシブルサーバーでのバックアップと復元」を参照してください。

ゾーン冗長: フレキシブルサーバーは、データ損失をゼロにして、60 ~ 120 秒以内にスタンバイサーバーに自動的にフェールオーバーします。

可用性ゾーンのない構成

推奨はされませんが、高可用性を有効にせずにフレキシブルサーバーを構成することもできます。高可用性なしで構成されたフレキシブルサーバーの場合、サービスはローカル冗長ストレージに 3 つのデータコピー、ゾーン冗長バックアップ (サポートされているリージョン)、組み込みのサーバーの回復性を提供して、クラッシュしたサーバーを自動的に再起動し、サーバーを別の物理ノードに再配置します。この構成では、 99.9%のアップタイム SLA が提供されます。計画されたフェールオーバーイベントまたは計画外のフェールオーバーイベント中に、サーバーがダウンした場合、サービスは次の自動化された手順を使用してサーバーの可用性を維持します。

新しいコンピューティング Linux VM がプロビジョニングされます。
データファイルを含むストレージが新しい仮想マシンにマップされます。
新しい仮想マシン上で PostgreSQL データベースエンジンがオンラインになります。

次の図は、VM とストレージ障害の間の遷移を示しています。

ゾーン冗長の高可用性 (HA) がない状態での可用性を示す図。

リージョン間のディザスターリカバリーおよび事業継続

リージョン全体の障害が発生した場合、Azure は、別のリージョンを利用してディザスターリカバリーを使用して、地域または大規模な地域の災害からの保護を提供できます。 Azure ディザスターリカバリーアーキテクチャの詳細については、「Azure から Azure へのディザスターリカバリーアーキテクチャ」を参照してください。

フレキシブルサーバーは、計画的および計画外のダウンタイムイベント中に、ミッションクリティカルなデータベースのデータを保護し、ダウンタイムを軽減する機能を提供します。フレキシブルサーバーは堅牢な回復性と可用性を提供する Azure インフラストラクチャ上に構築されており、障害からの保護を強化し、復旧時間要件に対処し、データ損失の発生を減らすビジネス継続性機能を備えています。アプリケーションを設計するときは、ダウンタイムの許容度 (目標復旧時間 (RTO))、データ損失の露出 (目標復旧時点 ) を考慮してください。たとえば、ビジネスクリティカルなデータベースでは、テストデータベースよりも厳しいアップタイムが必要になります。

複数リージョンの地域でのディザスターリカバリー

geo 冗長バックアップと復元

geo 冗長バックアップと復元を使用すると、障害が発生した場合に別のリージョンでサーバーを復元できます。さらにこれにより、バックアップオブジェクトの年間 99.99999999999999% (9 が 16 個) 以上の持続性が実現されます。

geo 冗長バックアップは、サーバーの作成時にのみ構成できます。 geo 冗長バックアップを使用してサーバーを構成すると、バックアップデータとトランザクションログが、ストレージレプリケーションを介してペアになっているリージョンに非同期的にコピーされます。

地理的冗長バックアップと復元の詳細については、「地理的冗長バックアップと復元」を参照してください。

読み取りレプリカ

リージョン間の読み取りレプリカをデプロイして、リージョンレベルの障害からデータベースを保護できます。読み取りレプリカは、PostgreSQL の物理レプリケーションテクノロジを使用して非同期的に更新され、プライマリに遅れる可能性があります。汎用コンピューティングレベルとメモリ最適化コンピューティングレベルでは、読み取りレプリカがサポートされます。

読み取りレプリカの機能と考慮事項の詳細については、読み取りレプリカに関する記事をご覧ください。

停止の検出、通知、管理

geo 冗長バックアップを使用してサーバーを構成する場合は、ペアのリージョンで geo リストアを実行できます。新しいサーバーがプロビジョニングされ、そのリージョンにコピーされた使用可能な最後のデータに復旧されます。

リージョンにまたがる読み取りレプリカも使用できます。リージョンの障害が発生した場合は、読み取りレプリカをスタンドアロンの読み取り/書き込み可能サーバーに昇格することで、ディザスターリカバリー操作を実行できます。 RPO は、障害発生時に RPO がレプリケーションのラグに近い場合に重大なリージョン障害が発生する場合を除き、最大 5 分 (データ損失の可能性) が予想されます。

計画外のダウンタイム軽減策とリージョン障害後の復旧の詳細については、「計画外のダウンタイムの軽減」をご覧ください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-12-03