Azure Database for PostgreSQL - フレキシブル サーバーの読み取りレプリカを昇格させる
適用対象:
Azure Database for PostgreSQL - フレキシブル サーバー
昇格とは、レプリカがレプリカ モードを終了し、完全な読み取り/書き込み操作に移行するように命令されるプロセスを指します。
重要
昇格操作は自動ではありません。 プライマリ サーバーで障害が発生した場合、システムは自立的に読み取りレプリカに切り替わることはありません。 昇格操作には常にユーザー アクションが必要です。
レプリカの昇格は、次の 2 つの異なる方法で行うことができます。
プライマリ サーバーへの昇格
このアクションにより、レプリカがプライマリ サーバーのロールに昇格されます。 このプロセスでは、現在のプライマリ サーバーがレプリカ ロールに降格され、ロールが入れ替えられます。 昇格が成功するには、仮想エンドポイントが、現在のプライマリに対してライター エンドポイントとしてと、昇格の対象となるレプリカに対してリーダー エンドポイントとして、両方に構成されている必要があります。 昇格は、対象のレプリカがリーダー エンドポイント構成に含まれている場合にのみ成功します。
図では、昇格前のサーバーの構成と、昇格操作が正常に完了した後の結果の状態が示されています。
独立したサーバーに昇格し、レプリケーションから削除する
このオプションを選ぶと、レプリカは昇格されて独立したサーバーになり、レプリケーション プロセスから削除されます。 その結果、プライマリ サーバーと昇格されたサーバーの両方が、2 つの独立した読み取り/書き込みサーバーとして機能します。 仮想エンドポイントを構成することは可能ですが、この操作には必須ではないことに注意してください。 新しく昇格されたサーバーは、リーダー エンドポイントが以前に指していた場合でも、既存の仮想エンドポイントの一部ではなくなります。 そのため、アプリケーションが新しく昇格されたレプリカに接続する必要がある場合は、アプリケーションの接続文字列を更新してそこに向かわせることが不可欠です。
この図は、昇格する前のサーバーのセットアップ方法と、独立したサーバーになった後の構成を示しています。
重要
独立したサーバーに昇格し、レプリケーションから削除するアクションは、以前の昇格機能と下位互換性があります。
重要
サーバー対称: プライマリ サーバーへの昇格操作を使用して昇格を成功させるには、プライマリ サーバーとレプリカ サーバーの両方に同じレベルとストレージ サイズが必要です。 たとえば、プライマリに 2 仮想コアがあり、レプリカに 4 仮想コアがある場合、唯一の実行可能なオプションは、"独立したサーバーに昇格し、レプリケーションから削除する" アクションを使用することです。 さらに、共有メモリを割り当てるサーバー パラメーターで同じ値を共有する必要があります。
どちらの昇格方法でも、考慮すべきオプションが他にもあります。
計画済み: このオプションにより、昇格する前にデータが確実に同期されます。 クライアント接続を受け入れる前に、保留中のすべてのログを適用してデータの整合性を確保します。
強制: このオプションは、リージョンの停止などのシナリオでの迅速な復旧のために設計されています。 プライマリからのすべてのデータの同期を待機する代わりに、最も近い一貫性のある状態を実現するために必要な WAL ファイルを処理すると、サーバーは動作可能になります。 このオプションを使ってレプリカを昇格させる場合、プライマリからレプリカのリンクを解除したときのラグによって、失われるデータの量が決まります。
重要
強制昇格オプションは、特にリージョンの停止に対処するように設計されており、そのような場合、サーバー対称性要件を含むすべてのチェックをスキップして、昇格を続行します。 これは、障害シナリオを処理するため、サーバーの即時可用性を優先するためです。 ただし、ドキュメントで指定されている読み取りレプリカの要件 (特にサーバー対称性要件) が満たされていない場合、リージョン停止シナリオ以外での強制オプションの使用は、レプリケーションの破損などの問題につながる可能性があるため許可されません。
レプリカをプライマリに昇格する方法、および独立したサーバーに昇格し、レプリケーションから削除する方法について確認してください。
構成管理
読み取りレプリカは、コントロール プレーン構成の観点からは、個別のサーバーとして扱われます。 このアプローチにより、読み取りスケールのシナリオに柔軟性が提供されます。 ただし、ディザスター リカバリーのためにレプリカを使用する場合、ユーザーは構成が必要どおりになっていることを確認する必要があります。
昇格操作では、特定の構成とパラメーターが引き継がれません。 重要なものをいくつか紹介します。
- PgBouncer: 組み込みの PgBouncer 接続プーラーの設定と状態は、昇格プロセス中にレプリケートされません。 PgBouncer がプライマリで有効になっていて、レプリカでは有効になっていなかった場合、昇格後もレプリカでは無効のままです。 新しく昇格されたサーバーで PgBouncer が必要な場合は、昇格アクションの前または後に有効にする必要があります。
- geo 冗長バックアップ ストレージ: geo バックアップ設定は転送されません。 レプリカでは geo バックアップを有効にできないため、昇格されたプライマリ (以前のレプリカ) には昇格後にそれが設定されていません。 この機能は、標準サーバーの作成時 (レプリカではありません) にのみアクティブ化できます。
- サーバー パラメーター: プライマリと読み取りレプリカで値が異なる場合、昇格中には変更されません。 共有メモリ サイズに影響を与えるパラメーターは、プライマリとレプリカの両方で同じ値である必要があることに注意してください。 この要件の詳細については、「サーバー パラメーター」のセクションを参照してください。
- Microsoft Entra 認証: プライマリに Microsoft Entra 認証が構成されており、レプリカが PostgreSQL 認証で設定されている場合、昇格後、レプリカは自動的に Microsoft Entra 認証に切り替わることはありません。 PostgreSQL 認証が維持されます。 ユーザーは、昇格プロセスの前または後に、昇格されたレプリカで Microsoft Entra 認証を手動で構成する必要があります。
- 高可用性 (HA): 昇格後に HA が必要な場合は、ロールの反転に続いて、新しく昇格されたプライマリ サーバーで HA を構成する必要があります。
考慮事項
昇格中のサーバーの状態
計画的と強制のどちらの昇格シナリオでも、サーバー (プライマリとレプリカの両方) が "使用可能" 状態である必要があります。 サーバーの状態が "使用可能" 以外 ("更新中" や "再起動" など) の場合、通常、昇格を問題なしに続けることはできません。 ただし、リージョンの停止の場合は例外とされます。
このようなリージョンの停止中は、プライマリ サーバーの現在の状態に関係なく、強制昇格方法を実装できます。 このアプローチにより、リージョンの災害の可能性に対応して迅速なアクションが可能になり、サーバーの可用性に関する通常のチェックをバイパスできます。
レプリカの昇格中に以前のプライマリ サーバーに障害が発生し復旧できない場合、唯一のオプションは、以前のプライマリを削除してレプリカ サーバーを再作成することです。
ペアになっていないリージョンでの昇格中の複数のレプリカの可視性
複数のレプリカを利用するときに、プライマリ リージョンにペアのリージョンがない場合、特別な考慮事項が必要になります。 プライマリに影響を与えるリージョンの停止が発生した場合、新しく昇格されたレプリカによって他のレプリカが自動的に認識されることはありません。 アプリケーションは引き続き昇格されたレプリカに向けることで操作を継続できますが、認識されないレプリカは停止中も切断されたままです。 これらの追加レプリカでのロールの再関連付けと再開は、元のプライマリ リージョンが復元された後でのみ行われます。
よく寄せられる質問
プライマリ サーバーで高可用性 (HA) が有効になっている場合、レプリカを昇格できますか?
はい。プライマリ サーバーが HA 対応かどうかに関係なく、読み取りレプリカを昇格できます。 読み取りレプリカをプライマリ サーバーに昇格させる機能は、プライマリの HA 構成とは無関係です。
HA が有効なプライマリと読み取りレプリカがあり、レプリカを昇格させた後、元のプライマリに戻した場合、サーバーの HA は維持されますか?
いいえ。HA が有効な読み取りレプリカはサポートされていないため、最初の昇格中に HA は無効にされます。 読み取りレプリカをプライマリに昇格させることは、元のプライマリのロールがレプリカに変更されることを意味します。 元に戻す場合は、元のプライマリ サーバーで HA を有効にする必要があります。