Azure Database for PostgreSQL は、データベース管理機能と構成設定に対するきめ細かな制御と柔軟性を提供するように設計されたフル マネージド データベース サービスです。 このサービスは、要件に基づいて高可用性とディザスター リカバリーの機能を提供します。
Azureを使用する場合、信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止、サービス メンテナンスなど、さまざまな障害や問題に対する Azure Database for PostgreSQL の回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Azure Database for PostgreSQL サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調します。
運用環境のデプロイに関する推奨事項
ソリューションの信頼性要件をサポートするために Azure Database for PostgreSQL をデプロイする方法と、信頼性がアーキテクチャの他の側面にどのように影響するかについては、「 Azure Well-Architected Framework での Azure Database for PostgreSQL のアーキテクチャのベスト プラクティス」を参照してください。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
Azure Database for PostgreSQL を使用する場合は、 データベース サーバーをサポートするために必要なコンピューティング リソースとストレージ リソースを表すサーバーをデプロイします。 1 つ以上の データベース をサーバーにデプロイします。
サーバーは、バースト可能、汎用、メモリ最適化の複数の コンピューティング レベルにデプロイできます。各コンピューティング レベルは、 さまざまな種類のワークロードに合わせて最適化されています。 一部の Azure リージョンでは、 Azure Confidential Computing を使用してサーバーをデプロイできます。
一般的なサービス アーキテクチャとデプロイ モデルの詳細については、「 Azure Database for PostgreSQL とは」を参照してください。
物理アーキテクチャ
コンピューティングとストレージの分離: Azure Database for PostgreSQL では、高可用性をサポートするためにコンピューティングとストレージの分離アーキテクチャが使用されます。 データベース エンジンは Linux 仮想マシン上で実行されますが、データ ファイルは Azure Storage に格納されます。これにより、データの持続性を確保するために、データベース ファイルの 3 つのローカル冗長同期コピーが維持されます。
高可用性: 必要に応じて、サーバーで 高可用性構成 を有効にすることができます。 高可用性構成を有効にすると、サービスによってウォーム スタンバイ サーバーがプロビジョニングされ、維持されます。 プライマリ サーバー上のデータ変更は、プライマリ サーバーの障害時にデータ損失がゼロになるように、スタンバイ サーバーに同期的にレプリケートされます。
このアーキテクチャでは、コンピューティング レイヤーとストレージ 層が分離されるため、サービスはさまざまな種類のエラーを適切に処理できます。 より高い回復性を実現するために、サーバーを可用性ゾーンに分散させることができます。
スタンバイ サーバーは、仮想コア、ストレージ、ネットワーク設定など、プライマリ サーバーと同じ VM 構成にデプロイされます。
フェールオーバーを実行することで、サーバーを切り替えることができます。 フェールオーバーには 2 種類があります。 強制フェールオーバーは、プライマリ サーバーで障害が発生したときに使用されます。 計画されたフェールオーバーは、一部のメンテナンス操作中に使用されます。また、フェールオーバー中にアプリケーションのダウンタイムを最小限に抑える必要があるその他のシナリオで使用されます。
停止、開始、再起動などの操作は、プライマリとスタンバイの両方のデータベース サーバーで同時に実行されます。 スケール コンピューティングやスケール ストレージなどの計画的なイベントは、最初にスタンバイで発生し、次にプライマリ サーバーで発生します。 現時点では、これらの計画された操作に対してサーバーはフェールオーバーされません。
詳細については、「 Azure Database for PostgreSQL の高可用性」を参照してください。
バックアップ： Azure Database for PostgreSQL では、サーバー バックアップが自動的に作成されます。 詳細については、「 バックアップと復元」を参照してください。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
アプリケーションは、メンテナンス、スケーリング操作、またはネットワークの中断中に発生する可能性のある一時的な接続エラーを処理する必要があります。 次の推奨事項に従ってください。
- アプリケーションで一時的な障害が発生した場合は、指数バックオフを使用して操作を再試行してください。 再試行の間の遅延を増やし、試行回数を制限します。 最大再試行の後も操作が失敗する場合は、失敗として扱います。
- 可能であれば、再試行を自動的に処理するクライアント ライブラリ (ドライバーとも呼ばれます) を使用します。
- 書き込み操作中に発生する一時的なエラーについては、より慎重に検討する必要があります。 あなたの書き込み操作を複数回安全に実行できるようにするため、べき等性を持たせることを検討してください。
詳細については、「 Azure Database for PostgreSQL での一時的な接続エラーの処理」を参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
高可用性構成を使用して、可用性ゾーンのサポートの種類を選択できます。 高可用性を有効にすると、プライマリ サーバーと共に スタンバイ サーバーがデプロイされます。 この高可用性モデルは、コミットされたデータが障害時に失われないようにするのに役立ちます。 サーバーが使用する高可用性デプロイ モデルに関係なく、データはプライマリ サーバーとスタンバイ サーバーの両方に同期的にコミットされます。 プライマリ サーバーに中断が発生した場合、サーバーは自動的にスタンバイ サーバーにフェールオーバーします。
データ ファイルと先書きログ (WAL) は、各可用性ゾーン内の Premium マネージド ディスクに格納されます。ローカル冗長ストレージ (LRS) では、各ゾーン内に 3 つのデータ コピーが自動的に格納されます。
Azure Database for PostgreSQL では、高可用性を使用する場合、次の 2 種類の可用性ゾーン構成がサポートされます。
ゾーン冗長高可用性: ゾーン冗長性は、1 つの可用性ゾーンにプライマリ サーバーをデプロイし、スタンバイ サーバーを別の可用性ゾーンにデプロイすることで、最高レベルのゾーンの回復性を実現します。 スタンバイ サーバーでは、プライマリと同様のコンピューティング、ストレージ、およびネットワーク構成が使用されます。 ゾーン冗長構成では、プライマリ サーバーとスタンバイ サーバー間でスタック全体が物理的に分離されます。
プライマリ サーバーとスタンバイ サーバーの可用性ゾーンを選択するか、Microsoft に選択させることができます。
運用サーバーにはゾーン冗長展開をお勧めします。
書き込み操作では、サービスがスタンバイ サーバーにデータを同期的にレプリケートするため、コミット待機時間が少し増加する可能性があります。 影響は、ワークロード、選択した SKU、リージョンによって異なります。
ゾーン (同じゾーン) の高可用性: プライマリ サーバーとスタンバイ サーバーは、同じ可用性ゾーンを使用します。 プライマリ サーバーに中断が発生しても、ゾーンがまだ正常な場合、サーバーは自動的にスタンバイ サーバーにフェールオーバーします。 ゾーン展開を使用すると、単一の可用性ゾーン内で高可用性を実現できます。 これにより、ノード レベルの障害からユーザーを保護し、計画されたダウンタイムイベントや計画外のダウンタイム イベント中のアプリケーションのダウンタイムを削減するのにも役立ちます。 ただし、そのゾーンでの停止に対する保護はありません。
ゾーン (同じゾーン) の高可用性は、次の状況でのみ使用できます。
- リージョンは可用性ゾーンをサポートしていません。 リージョンは実質的に 1 つのゾーンとして機能するため、選択できる高可用性構成は同じゾーンのみです。
- リージョンにゾーン冗長デプロイに十分な容量がない場合、サービスは最初に両方のサーバーを同じ可用性ゾーンに配置し、容量が使用可能になったときに自動的に別のゾーンに移行できます。 このオプションは、Azure portal または Azure CLI を使用してサーバーをデプロイするときに使用できます。 詳細については、「 Business Critical (高可用性) オプションの構成」を参照してください。
サーバーは同じゾーンにあるため、同じゾーン内にデプロイするアプリケーションへの書き込み待機時間を短縮できます。
高可用性なしでサーバーを構成した場合、サーバーは 1 つのサーバーで実行されます。 そのサーバーまたはそのゾーンがダウンした場合、サーバーは使用できません。 詳細については、「 可用性ゾーンのない構成」を参照してください。
必要条件
リージョンのサポート: Azure Database for PostgreSQL の可用性ゾーン構成のサポートは、Azure リージョンによって異なります。 リージョンの完全な一覧と可用性ゾーンのサポートの種類とそのリージョンに関する特定の考慮事項については、 Azure リージョンを参照してください。
コンピューティング レベル: 次の表に、可用性ゾーンのサポートの種類ごとのコンピューティング レベルのサポートを示します。
価格階層 ゾーン冗長 ゾーン内（同一ゾーン） バースト可能 サポートしていません サポートされている General Purpose サポートされている サポートされている メモリ最適化 サポートされている サポートされている サービス レベル: ゾーンの冗長性には、General Purpose レベルまたはメモリ最適化レベルが必要です。
ゾーン (同じゾーン) のデプロイは、すべての価格レベルでサポートされています。
考慮事項
リージョンの容量: リージョンにゾーン冗長デプロイに十分な容量がない場合、サービスは最初に両方のサーバーを同じ可用性ゾーンに配置し、容量が使用可能になったときに自動的に別のゾーンに移行できます。 このオプションは、Azure portal または Azure CLI を使用してサーバーをデプロイするときに使用できます。 詳細については、「 Business Critical (高可用性) オプションの構成」を参照してください。
Cost
高可用性を有効にすると、スタンバイ サーバーが作成され、プライマリと同じレートで課金されます。 可用性ゾーンの構成はコストに影響しません。 可用性ゾーン内または可用性ゾーン間のデータ レプリケーションには料金はかかりません。 バックアップ ストレージ ボリュームによっては、バックアップ ストレージの請求が発生する場合もあります。 価格の詳細については、 Azure Database for PostgreSQL の価格に関するページを参照してください。
可用性ゾーンのサポートを設定する
サーバーの可用性ゾーンのサポートを構成するには、高可用性設定を構成します。
ゾーン冗長サーバーを作成します。 高可用性とゾーン冗長性を有効にしたサーバーを作成する方法については、「 クイック スタート: Azure portal で Azure Database for PostgreSQL を作成する」を参照してください。
既存のサーバーの可用性ゾーンの構成を変更します 。高可用性設定を変更することで、既存のサーバーの可用性ゾーンの構成を変更できます。 詳細な手順については、「 既存のサーバーの高可用性を有効にする」を参照してください。
プライマリ サーバーまたはスタンバイ サーバーの作成後に使用されるゾーンを変更することはできません。 サーバーを再作成する必要があります。
ヒント
高可用性の構成を変更する前に、サーバー アクティビティが低くなるまで待機することをお勧めします。
高可用性を無効にする: 高可用性を無効にすると、スタンバイ サーバーが削除されるため、サーバーは可用性ゾーンの停止に対する回復性がありません。 詳細については、「高可用性を 無効にする」を参照してください。
すべてのゾーンが正常な場合の動作
このセクションでは、サーバーが高可用性と可用性ゾーンのサポートを使用して構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間操作: PostgreSQL クライアント アプリケーションは、データベース サーバー名を使用してプライマリ サーバーに接続します。 Azure Database for PostgreSQL では、すべてのデータベース接続とクエリがプライマリ 可用性ゾーンのプライマリ サーバーによって処理されるアクティブ/パッシブ構成を使用します。 スタンバイ サーバーは、通常の操作中にクライアント トラフィックを処理しません。
ゾーン間データ レプリケーション: データへの変更は、プライマリ サーバーとスタンバイ サーバーの間で同期的にレプリケートされます。 プライマリ サーバーとスタンバイ サーバーの両方が書き込みを確認するまで、トランザクションは完了と見なされません。
アプリケーションのトランザクションによってトリガーされた書き込みが、最初のログとしてプライマリサーバー上のWALにコミットされます。 プライマリ サーバーは、Postgres ストリーミング プロトコルを使用して、これらのログをスタンバイ サーバーにストリーミングします。 スタンバイ サーバー ストレージがログを保持すると、プライマリ サーバーは書き込みの完了を確認します。 アプリケーションは、この受信確認の後にのみトランザクションをコミットします。 この確認プロセスでは、スタンバイ サーバーへのログの適用を待機しません。
レプリケーションの効果は、サーバーが使用する可用性ゾーンの構成によって異なります。
ゾーン冗長: サーバーは別々のゾーンにあるため、この方法により、ゾーン障害時のデータ損失がゼロになります。 この状況は、ゾーン障害に対して目標復旧ポイント (RPO) を 0 に達成する場合とも呼ばれます。
ただし、クロスゾーン レプリケーションでは、少量の余分な待機時間が発生する可能性があります。 待機時間の影響はアプリケーションによって異なり、ほとんどのアプリケーションではごくわずかです。
ゾーン: 両方のサーバーが同じゾーンにあるため、ゾーン間でトラフィックはレプリケートされません。
注
システムは、ログ データをスタンバイ サーバーにリアルタイムでレプリケートします。 テーブルの誤削除や不適切なデータ更新など、プライマリ サーバー上のユーザー エラーは、スタンバイ サーバーにレプリケートされます。 そのため、スタンバイを使用してこれらの種類のエラーから回復することはできません。また、バックアップから特定の時点への復元を実行する必要があります。 詳細については、「 バックアップと復元」を参照してください。
ゾーン障害時の動作
このセクションでは、サーバーが高可用性と可用性ゾーンのサポートを使用して構成されていて、可用性ゾーンが停止した場合に想定される内容について説明します。
検出と応答: Azure では、プライマリ サーバーとスタンバイ サーバーの両方の正常性が定期的にチェックされます。 複数の ping を実行した後、正常性の監視でプライマリ サーバーに到達できないことが検出された場合、サービスはスタンバイ サーバーへの自動フェールオーバーを開始します。 正常性監視アルゴリズムは、誤検知の状況を回避するために複数のデータ ポイントを使用します。
ゾーン障害が発生した場合の動作は、サーバーが使用する可用性ゾーンの構成によって異なります。
ゾーン冗長: Azure Database for PostgreSQL は、可用性ゾーンの障害を自動的に検出します。 使用可能な高可用性の状態の種類を表示するには、「 高可用性の状態の種類」を参照してください。 ゾーンに障害が発生すると、Azure は、アクションを実行しなくても、スタンバイ サーバーへの 強制フェールオーバー を開始します。
ゾーン: ゾーン サーバーをホストする可用性ゾーンが利用できなくなった場合、プライマリ サーバーとスタンバイ サーバーの両方が利用できなくなります。 このシナリオでは、サービスは自動フェールオーバーを提供しません。 ゾーンの停止を検出し、別の可用性ゾーンまたはリージョン内の別のサーバーにゾーン冗長バックアップを復元するなど、復旧アクションを実行する必要があります。
通知： Azure Database for PostgreSQL での高可用性 (HA) の正常性状態の監視では、HA 対応インスタンスの正常性と準備の継続的な概要が提供されます。 監視機能は Azure Resource Health に基づいて構築されており、データベースのフェールオーバーの準備状況や全体的な可用性に影響を与える可能性のある問題を検出してアラートを生成できます。 接続状態、フェールオーバー状態、データ レプリケーションの正常性などの主要なメトリックを評価して、プロアクティブなトラブルシューティングを可能にし、データベースのアップタイムとパフォーマンスを維持するのに役立ちます。
HA の正常性状態の構成と解釈に関する詳細なガイドについては、 Azure Database for PostgreSQL の高可用性 (HA) の正常性状態の監視に関するページを参照してください。
アクティブな要求: 可用性ゾーンが使用できなくなった場合、影響を受けるゾーン内のサーバーに対する進行中の要求が終了する可能性があります。 アプリケーションは、これらの要求を再試行する必要があります。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。
予想されるデータ損失: データ損失の量は、サーバーが使用する可用性ゾーンの構成によって異なります。
ゾーン冗長: 異なるゾーン内のプライマリ サーバーとスタンバイ サーバー間の同期レプリケーションにより、ゾーンのフェールオーバー中にデータ損失が発生しません。
帯状： 影響を受けるゾーン内のサーバー上のデータは、ゾーンが回復するまで使用できません。
予想されるダウンタイム: ダウンタイムの量は、サーバーが使用する可用性ゾーンの構成によって異なります。
ゾーン冗長: 通常、フェールオーバーは 60 ~ 120 秒以内に完了します。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。
帯状： 影響を受けたゾーン内のサーバーは、可用性ゾーンが復旧するまで使用できません。
再 分配： トラフィックの再ルーティング動作は、サーバーが使用する可用性ゾーンの構成によって異なります。
ゾーン冗長: フェールオーバー後、以前のスタンバイ サーバーが新しいプライマリになり、新しい接続の受け入れが開始されます。 Azure では、復旧後、元のプライマリ ゾーンに新しいスタンバイ サーバーが自動的に確立されます。 詳細については、「 強制フェールオーバー」を参照してください。
ゾーン: ゾーンが使用できない場合、サーバーは使用できません。 別の可用性ゾーンまたはリージョンに事前に作成した別のサーバーがある場合は、そのサーバーへのトラフィックを再ルーティングする必要があります。
ゾーンの回復
ゾーンの回復動作は、サーバーが使用する可用性ゾーンの構成によって異なります。
ゾーン冗長: 可用性ゾーンが復旧すると、Azure Database for PostgreSQL によって、復旧されたゾーン内のスタンバイ サーバーが自動的に再構築され、現在のプライマリと同期されます。 回復されたゾーンは、スタンバイの場所として機能します。 サービスは、不要な中断を回避するために、プライマリ ロールを元のゾーンに自動的に戻すわけではありません。 プライマリを元のゾーンに戻す場合は、 計画されたフェールオーバーを手動で開始 できます。
ゾーン: ゾーンが正常な状態になった後、そのゾーンのサーバーは再び利用可能になります。 ワークロードに必要なゾーン回復手順とデータ同期は、お客様が担当します。
ゾーンエラーのテスト
ゾーンの障害をテストするためのオプションは、インスタンスが使用する可用性ゾーンの構成によって異なります。
ゾーン冗長:強制フェールオーバーを開始することで、フェールオーバーに対するアプリケーションの回復性をテストできます。 強制フェールオーバーを使用すると、ワークロードの実行中に計画外の停止シナリオをシミュレートし、アプリケーションのダウンタイムを観察できます。 非運用環境または静かな時間にシミュレーションを実行することをお勧めします。 詳細については、「 強制フェールオーバーの開始」を参照してください。
ゾーナル： ゾーン全体の停止をシミュレートすることはできませんが、ゾーン停止時に発生する状況と同様に、サーバーが使用できない状態をシミュレートできます。 詳細については、「 サーバーのコンピューティングの停止」を参照してください。
リージョン全体の障害に対する回復性
Azure Database for PostgreSQL では リージョン間の読み取りレプリカがサポートされています。このレプリカを使用して、データベースの同期されたコピーを別のリージョンに保持し、復旧を高速化できます。
サポートされているリージョンで geo 冗長バックアップを使用して、リージョン間の復旧を提供することもできます。 ただし、バックアップには通常、レプリケーションよりも多くのダウンタイムとデータ損失が伴います。 詳細については、「 バックアップと復元」を参照してください。
リージョン間の読み取りレプリカ
読み取りレプリカをデプロイして、リージョン レベルの障害からデータベースを保護できます。 各読み取りレプリカは、個別の Azure Database for PostgreSQL サーバーです。 2 番目の Azure リージョンに読み取りレプリカを配置すると、データベース サーバーはリージョン全体の問題に対する回復性を提供できます。 最大 5 つの読み取りレプリカをデプロイできます。必要に応じて、異なる Azure リージョンに配置できます。 PostgreSQL の物理レプリケーション テクノロジは、読み取りレプリカを非同期的に更新します。プライマリに遅延が発生する可能性があります。 リージョン間の読み取りレプリカは、必要に応じて読み取り専用ワークロードを提供して、グローバル分散アプリケーションの待機時間を短縮したり、プライマリ サーバーから読み取りトラフィックをオフロードしたりできます。 読み取りレプリカの機能と考慮事項の詳細については、読み取りレプリカに関する記事をご覧ください。
仮想エンドポイントは 、読み取り/書き込みエンドポイントと読み取り専用エンドポイントを提供し、レプリカの昇格時にトラフィックを自動的にリダイレクトします。これにより、フェールオーバー イベント中のダウンタイムを最小限に抑えることができます。 アプリケーションの回復性を向上させるために、リージョン間の読み取りレプリカで仮想エンドポイントを使用することを強くお勧めします。 詳細については、「 Azure Database for PostgreSQL の読み取りレプリカの仮想エンドポイント」を参照してください。
プライマリ リージョンで障害が発生した場合は、セカンダリ レプリカがプライマリになるように 昇格 をトリガーできます。 読み取りレプリカの使用方法に応じてトリガーできるフェールオーバーの種類は異なります。 読み取りレプリカを使用してリージョンの障害に対する回復性を提供する場合は、通常、 プライマリ サーバーへの昇格 アプローチを使用して、仮想エンドポイントを更新します。 リージョンの停止中は、 強制的な昇格を実行する必要があります。その結果、変換されていないデータに対してデータが失われる可能性があります。 プライマリ リージョンが正常である計画的なシナリオでは、データ損失を回避するために計画的な昇格を実行することを選択できます。 詳細については、「Azure Database for PostgreSQL での読み取りレプリカの昇格」を参照してください。
注
このセクションでは、読み取りレプリカがリージョン全体の障害に対する回復性をサポートする方法に関する重要な情報をいくつかまとめます。 読み取りレプリカを使用してパフォーマンスを向上させ、地理的に分散した大規模なユーザー ベースをサポートすることもできます。 詳細については、「レプリカの 読み取り」を参照してください。
必要条件
リージョンのサポート: リージョン間の読み取りレプリカは、Azure Database for PostgreSQL をサポートする任意のリージョンに作成できます。 Azure のペアになっているリージョンに限定されるわけではありません。
コンピューティング レベル: General Purpose コンピューティング レベルとメモリ最適化コンピューティング レベルでは、読み取りレプリカがサポートされます。 バースト可能レベルでは、読み取りレプリカはサポートされていません。
考慮事項
構成の違い: 読み取りレプリカは、プライマリ サーバーからすべての構成設定を継承するわけではありません。 フェールオーバー後に必要な設定を構成することを計画します。 プライマリ サーバーとレプリカは 対称である必要があります。つまり、一部の設定で同じレベル、ストレージ サイズ、値を持つ必要があります。 リージョンの障害時には、強制的な昇格に対して対称サーバー要件を免除できますが、予期しない問題を回避するために、可能な限り対称的な構成を行うことをお勧めします。 詳細については、「 構成管理」を参照してください。
レプリケーションのラグの監視: 非同期レプリケーション プロセスにはレプリケーションの遅延が必要です。これは、さまざまな要因によって異なる場合があります。 レプリケーションのラグが非常に大きい場合、サーバーで問題が発生する可能性があります。 問題がエスカレートする前に問題を軽減できるように、レプリケーションのラグを監視することが重要です。 詳細については、「 レプリケーションの監視」を参照してください。
高可用性: 読み取りレプリカでは高可用性を有効にすることはできず、昇格されるときにも高可用性は得られません。 レプリカの昇格後に高可用性を構成するのはあなたの責任です。
昇格プロセスに適用されるその他の考慮事項については、「 Azure Database for PostgreSQL での読み取りレプリカの昇格 - 考慮事項」を参照してください。
Cost
読み取りレプリカでは、コンピューティングとストレージのコストと、レプリケーションのリージョン間データ転送料金が発生します。 価格の詳細については、 Azure Database for PostgreSQL の価格 と 帯域幅の価格に関するページを参照してください。
複数リージョンのサポートを構成する
読み取りレプリカを作成します。 読み取りレプリカを作成する方法については、「読み取りレプリカ の作成」を参照してください。 レプリカは、プライマリ サーバーが実行され、アクセス可能である限り、プライマリ サーバーの作成後に構成できます。
仮想エンドポイントを作成するには、「 仮想エンドポイントの作成」を参照してください。
読み取りレプリカを削除します。 読み取りレプリカを削除する方法については、「読み取りレプリカ の削除」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、サーバーが別のリージョンと仮想エンドポイントの読み取りレプリカで構成されていて、すべてのリージョンが動作している場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: 通常の操作では、仮想エンドポイントは読み取り/書き込みエンドポイントのトラフィックをプライマリ リージョンのプライマリ サーバーに転送します。 仮想エンドポイントの読み取り専用エンドポイントも使用する場合は、構成したレプリカにトラフィックが送信されます。
リージョン間のデータ レプリケーション: リージョン間の読み取りレプリカでは、非同期レプリケーションを使用して、プライマリ サーバーのパフォーマンスへの影響を最小限に抑えます。 レプリケーションのラグの量は、書き込み負荷やプライマリ サーバーとレプリカ間の待機時間など、さまざまな要因によって異なります。 レプリケーションのラグは通常、少なくとも数分ですが、はるかに長くなる可能性があります。 詳細については、「 レプリケーションの監視」を参照してください。
リージョン障害時の動作
このセクションでは、サーバーが別のリージョンと仮想エンドポイントの読み取りレプリカを使用して構成されていて、プライマリ リージョンで停止が発生した場合に想定される内容について説明します。
検出と応答: プライマリ リージョンでの停止を検出し、読み取りレプリカを新しいプライマリ サーバーに手動で昇格させる必要があります。 リージョンの停止中は、強制的な昇格処理を実行する必要があります。その結果、複製されていないデータが失われます。
Important
昇格をトリガーする責任はユーザーにあります。 リージョンが障害を起こしても、Azure は読み取りレプリカを自動的に昇進させません。
昇格を開始する詳細な手順については、「 読み取りレプリカをプライマリに切り替える」を参照してください。
通知： リージョンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: プライマリ リージョンへのアクティブな接続はすべて削除されます。 アプリケーションは、昇格プロセスが完了した後、昇格されたレプリカへの接続を再試行する必要があります。
予想されるデータ損失: リージョンの停止中は、強制的な昇格を実行する必要があります。その結果、変換されていないデータが完全に失われます。
データ損失の量は、障害発生時のレプリケーションのラグによって異なります。 レプリケーションのラグは通常、少なくとも数分ですが、はるかに長くなる可能性があります。 詳細については、「 レプリケーションの監視」を参照してください。
予想されるダウンタイム: 強制昇格は通常、トリガーされてから 1 ~ 3 分以内に完了します。 アプリケーションは、正しいエンドポイントに再接続する必要がある場合もあります。 仮想エンドポイントは、強制昇格プロセスの一環として更新されます。 アプリケーションは、昇格が完了した後に適切なレプリカにすばやく再接続できるように、エンドポイントの DNS レコードの生存時間 (TTL) を遵守する必要があります。
トラフィックの再ルーティング: サーバーの仮想エンドポイントは、アプリケーション トラフィックを新しいプライマリ レプリカに自動的にリダイレクトします。
注
読み取りレプリカがプライマリ サーバーに昇格されると、高可用性構成は有効になりません。 高可用性構成を手動で有効にするか、独自の自動化プロセスに追加する必要があります。
リージョンの復旧
仮想エンドポイントを使用すると、プライマリ リージョンが復旧した後、古いプライマリ サーバーが読み取りレプリカとして自動的に構成されます。 別の昇格を実行して、プライマリ操作を優先プライマリ リージョンに返すことができます。
リージョン障害のテスト
読み取りレプリカの昇格手順を定期的にテストして、プロセスが有効であること、および機能が RTO と RPO の要件を満たしていることを確認します。
すべてのリージョンが正常な場合でも、読み取りレプリカをいつでもプライマリ サーバーに昇格させることができます。 テストの場合:
- 強制昇格テストを実行できます。 データが失われる可能性があるため、非運用環境でこれらのテストを実行することをお勧めします。 強制昇格テストは、リージョンの停止中に表示される動作をシミュレートするのに役立ちます。
- 計画メンテナンス、またはデータ損失を回避するテスト シナリオの場合は、代わりに計画的な昇格を使用します。 計画された昇格は、リージョンの停止中のプロモーションとは異なるプロセスに従う点に注意してください。
詳細な手順については、「 読み取りレプリカをプライマリに切り替える」を参照してください。
ディザスター リカバリー戦略の一環として、完全復旧訓練を定期的に実行します。 これらのドリルには、データ検証、アプリケーション機能テスト、および文書化されたロールバック手順が含まれている必要があります。
バックアップと復元
Azure Database for PostgreSQL は、特定の時点の復旧機能を提供するバックアップを自動的に実行し、データの偶発的な破損や削除からユーザーを保護するのに役立ちます。 バックアップは Microsoft によって完全に管理され、サーバーの可用性を中断せず、完全バックアップとトランザクション ログ バックアップの両方が含まれます。
バックアップ ストレージ: サーバーがゾーン冗長高可用性で構成されている場合、バックアップはゾーン冗長ストレージ (ZRS) に格納されます。 高可用性なしで構成されたサーバー、またはゾーン (単一ゾーン) の高可用性を使用して構成されたサーバーの場合、バックアップはローカル冗長ストレージ (LRS) に格納されます。
ペアの Azure リージョンでは、サーバー作成時に geo 冗長 (GRS) バックアップ ストレージ を構成して、リージョンの障害に対する保護を強化するために、Azure のペアになっているリージョンにバックアップをレプリケートできます。 バックアップは非同期的にレプリケートされます。
既定のバックアップ保有期間は 7 日間で、リテンション期間を最大 35 日まで延長するオプションがあります。 また、手動バックアップの長期保存に最大 10 年間 Azure Backup を使用することもできます。 すべてのバックアップが暗号化されます。
復元： ポイントインタイム リカバリーを使用すると、バックアップ保有期間内の任意の時点にデータベースを復元できます。 復元プロセスでは、ユーザーが指定した新しいサーバー名を持つ新しいデータベース サーバーが作成されます。これにより、as-is を使用したり、データをコピーしたりできます。
geo 冗長バックアップを復元する場合は、ペアのリージョンに新しいサーバーを作成します。
この機能は、偶発的なデータ変更、アプリケーション エラー、またはテスト シナリオからの復旧に役立ちます。
ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、レプリケーション、バックアップとは」を参照してください。
詳細については、「 Azure Database for PostgreSQL でのバックアップと復元」を参照してください。
サービス メンテナンスに対する回復性
Azure Database for PostgreSQL は、基になるハードウェア、オペレーティング システム、データベース エンジンの修正プログラムの適用など、重要なサービス タスクを自動的に処理します。 このサービスには、計画メンテナンスの一環として、セキュリティ更新プログラム、ソフトウェア更新プログラム、マイナー バージョンのアップグレードが含まれます。
メンテナンス期間中もサーバーを確実に使用できるようにするには、次の推奨事項に従います。
高可用性を有効にする: メンテナンス中に、更新プロセスの一環としてサーバーの再起動が必要になる場合があります。 高可用性を有効にしている場合、メンテナンス操作では通常、ローリング更新プログラムを使用してダウンタイムを最小限に抑えます。 マイナー バージョンのアップグレードなどの定期的なメンテナンス アクティビティは、最初にスタンバイ レプリカで行われます。 ダウンタイムを減らすために、スタンバイはプライマリに昇格されるため、残りのノードにメンテナンス タスクが適用されている間もワークロードを維持できます。 このシーケンス処理は、サーバーがゾーン冗長またはゾーンの高可用性を使用しているかどうかに適用されます。
高可用性が有効になっていないサーバーの場合は、メンテナンス操作中に短いダウンタイムが発生します。 高可用性を有効にすると、通常、メンテナンス操作は最小限のダウンタイムまたはダウンタイムなしで完了します。
カスタム メンテナンス期間を構成する: メンテナンス スケジュールをシステムで管理するように構成することも、ビジネス運用への影響を最小限に抑えるためにカスタム メンテナンス期間を定義することもできます。 ビジネスへの影響を最小限に抑えるために、アクティビティの少ない期間中にメンテナンスをスケジュールします。 詳細については、「 メンテナンスのスケジュール」を参照してください。
再試行ロジックを実装します。 メンテナンスの再起動中に発生する可能性のある短い接続の中断をアプリケーションで処理できることを確認します。 これらの種類の問題に対するアプリケーションの回復性を高める方法については、 一時的な障害に対する回復性に関するガイダンスを 参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
Azure Database for PostgreSQL では、サーバーの構成に基づいてさまざまな可用性 SLA が提供されます。
- ゾーン冗長高可用性で構成されたサーバー。
- ゾーン (単一ゾーン) の高可用性で構成されたサーバー。
- 高可用性なしで構成されたサーバー。
関連するコンテンツ
- Azure信頼性
- Azure Database for PostgreSQL のアーキテクチャのベスト プラクティス
- Azure Database for PostgreSQL でのビジネス継続性の概要
- Azure Database for PostgreSQL での地理的災害復旧
- Azure Database for PostgreSQL の回復性ソリューション アクセラレータ - この記事で説明する回復性と回復性の原則の多くを実装するための Terraform スクリプト。