読み取りレプリカは、プライマリ サーバーと同じリージョンまたは別の地理的リージョンに作成できます。 Geo レプリケーションは、ディザスター リカバリーの計画や、ユーザーの近くにデータを配置するような場合に役立ちます。
任意の Azure Database for PostgreSQL フレキシブル サーバー サービス リージョンにプライマリ サーバーを配置できます。 プライマリ サーバーは、Azure Database for PostgreSQL フレキシブル サーバーをサポートする Azure の任意のグローバル リージョンにレプリカを配置することもできます。 さらに、このサービスは、ソブリン クラウドであるAzure GovernmentおよびMicrosoft Azure operated by 21Vianet内のリージョンもサポートします。
ディザスター リカバリーのためにはペアのリージョン
サポートされている任意のリージョンにレプリカを作成できますが、特にディザスター リカバリーを目的として設計する場合は、ペアの Azure リージョンでレプリカを選択すると、顕著な利点が得られます。
リージョンの復旧シーケンス: 地理的な停止では、ペアになっているセットごとに 1 つのリージョンの復旧が優先されます。 この優先順位により、ペアになっているリージョン間のアプリケーションに、復旧のためのリージョンが常に迅速に割り当てられます。
順次更新: ペアになっているリージョンの更新は時系列にずれているため、更新に関連する問題によるダウンタイムのリスクが最小限に抑えられます。
データ所在地: いくつかの例外を除き、ペアセット内のリージョンは同じ地域内に存在するため、データ所在地の要件を満たします。
パフォーマンス: ペアになっているリージョンでは通常、ネットワーク待機時間が短く、データのアクセシビリティとユーザー エクスペリエンスが向上しますが、常に待機時間が最も短いリージョンであるとは限りません。 ディザスター リカバリーに優先順位を付けるのではなく、ユーザーに近いデータを提供することが主な目的である場合は、使用可能なすべてのリージョンの待機時間を評価します。 場合によっては、ペアになっていないリージョンが最も短い待機時間を示すことがあります。 包括的に把握するために、Azure のラウンドトリップ待機時間の数値を参照して、情報に基づいた選択を行うことができます。
ペアになっているリージョンの利点の詳細については、リージョン間レプリケーションに関する Azure のドキュメントを参照してください。
リージョンの障害と復旧
さまざまなリージョンにある Azure の施設は、信頼性が高くなるように設計されています。 ただし、まれな状況では、ネットワーク障害から自然災害などの深刻なシナリオに至るまでの理由により、リージョン全体にアクセスできなくなる可能性があります。 Azureの機能を使用すると、複数のリージョンに分散されたアプリケーションを作成して、1 つのリージョンの障害が他のリージョンに影響しないようにすることができます。
地域災害に備え
潜在的なリージョンの災害に備えることは、アプリケーションとサービスの運用が中断されないようにするために不可欠です。 Azure Database for PostgreSQLフレキシブル サーバーの堅牢なコンティンジェンシー計画を検討している場合は、次の主要な手順と考慮事項を検討してください。
- 地理冗長の読み取りレプリカを作成する: プライマリとは異なるリージョンに読み取りレプリカを設定します。 この設定により、プライマリ リージョンで障害が発生した場合の継続性が確保されます。
-
サーバーの対称性を確保する: リージョンの障害を処理するための最も推奨されるアクションは プライマリ サーバーに昇格することですが、 サーバーの対称性 の要件が伴います。 この要件は、プライマリ サーバーとレプリカ サーバーの両方に、特定の設定の同じ構成が必要です。 このアクションを使用すると、次の利点があります。
- 仮想エンドポイントを使用する場合は、アプリケーション接続文字列を変更する必要はありません。
- 影響を受けたリージョンがオンラインに戻ると、元のプライマリ サーバーがその機能を (新しいレプリカ ロールで) 自動的に再開し、シームレスな復旧プロセスが実現します。
- 仮想エンドポイントを設定する: 仮想エンドポイントを使用すると、停止が発生した場合にアプリケーションを別の Azure リージョンへとスムーズに移行できます。 これにより、アプリケーションの接続文字列を変更する必要がなくなります。
- 読み取りレプリカを構成する: プライマリ サーバーのすべての設定が読み取りレプリカにレプリケートされるわけではありません。 読み取りレプリカで必要なすべての構成と機能 (PgBouncer など) を適切に設定してください。 詳細については、「構成管理」のセクションを参照してください。
- 高可用性 (HA) の準備: セットアップで高可用性が必要な場合、昇格されたレプリカでは自動的に有効になりません。 昇格後にアクティブにする準備をしてください。 ダウンタイムを最小限に抑えるために、この手順を自動化することを検討してください。
- 定期的なテスト: リージョンの障害シナリオを定期的にシミュレートして、既存のしきい値、ターゲット、構成を検証します。 これらのテスト シナリオで、アプリケーションが期待どおりに応答することを確認してください。
- Azure の一般的なガイダンスに従う: Azure では、信頼性と災害への備えに関する包括的なガイダンスを用意しています。 これらのリソースを参照し、ベスト プラクティスを準備計画に統合します。
地域的な災害に備え、事前に準備することで、アプリケーションとデータの回復性と信頼性が確保されます。
停止が SLA に影響を与える場合
アプリケーションのサービス レベル アグリーメント (SLA) を脅かす特定のリージョンのAzure Database for PostgreSQLフレキシブル サーバーで長時間の停止が発生した場合は、次のセクションで説明する両方のアクションがサービス主導型ではない点に注意してください。 どちらのアクションでも、ユーザーの介入が必要です。 プロセス全体を可能な限り自動化し、堅牢な監視を実施します。 停止中に提供される情報の詳細については、「サービス停止」のページを参照してください。 リージョン ダウンのシナリオでは強制昇格のみが可能です。つまり、データ損失の量は、レプリカとプライマリの間の現在のラグとほぼ同じです。 そのため、ラグを監視することが重要です。 次のオプションを検討してください。
プライマリ サーバーへの昇格
仮想エンドポイントを構成する場合、このオプションでは、アプリケーション内の接続文字列を更新する必要はありません。 アクティブ化されると、ライター エンドポイントは別のリージョンの新しいプライマリに再ポイントし、Azure ポータルのレプリケーション状態列に "再構成" と表示されます。 影響を受けるリージョンが復元されると、以前のプライマリ サーバーは自動的に再開しますが、現在はレプリカ ロールになっています。
独立したサーバーに昇格し、レプリケーションから削除する
場合によっては、このオプションが唯一の実行可能なオプションである可能性があります。 サーバーを昇格したら、アプリケーションの接続文字列を更新します。 元のリージョンが復元されると、古いプライマリが再びアクティブになる可能性があります。 不要なコストが発生しないように、必ず削除してください。 前のトポロジを維持する場合は、読み取りレプリカを再作成してください。