次の方法で共有

Azure Database for PostgreSQL - フレキシブル サーバーの読み取りレプリカの仮想エンドポイント

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

仮想エンドポイントは読み取り/書き込みおよび読み取り専用リスナーのエンドポイントであり、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの現在のロールに関係なく一貫性が保たれます。 つまり、プライマリ サーバーへの昇格アクションを実行した後に、アプリケーションの接続文字列を更新する必要はありません。これは、エンドポイントがロールの変更後に正しいインスタンスを自動的にポイントするためです。

仮想エンドポイントに関連するすべての操作は、追加、編集、削除のいずれであっても、プライマリ サーバーのコンテキストで実行されます。 Azure portal では、プライマリ サーバーのページでこれらのエンドポイントを管理します。 同様に、CLI、REST API、またはその他のユーティリティなどのツールを使用する場合、コマンドとアクションによるエンドポイント管理の対象はプライマリ サーバーになります。

仮想エンドポイントには、次の 2 種類の異なる接続ポイントが用意されています。

ライター エンドポイント (読み取り/書き込み): このエンドポイントは常に現在のプライマリ サーバーを指します。 これにより、ユーザーがトリガーする昇格操作に関係なく、書き込み操作が確実に正しいサーバーに転送されます。 このエンドポイントは、レプリカを指すように変更することはできません。

読み取り専用エンドポイント: このエンドポイントは、読み取りレプリカまたはプライマリ サーバーを指すようにユーザーが構成できます。 ただし、ターゲットにできるサーバーは一度に 1 つだけです。 複数のサーバー間の負荷分散はサポートされていません。 このエンドポイントのターゲット サーバーは、昇格の前後を問わず、いつでも調整できます。

Note

プライマリとそのレプリカごとに作成できるライターと読み取り専用エンドポイントはそれぞれ 1 つずつだけです。

仮想エンドポイントと昇格動作

昇格アクションが発生した場合、これらのエンドポイントの動作は予測可能なままです。 以下のセクションでは、これらのエンドポイントがプライマリ サーバーへの昇格と独立したサーバーへの昇格の両方のシナリオでどのように対応するかを詳しく説明します。

仮想エンドポイント 元のターゲット "プライマリ サーバーへの昇格" がトリガーされたときの動作 "独立したサーバーへの昇格" がトリガーされたときの動作
ライター エンドポイント プライマリ 新しいプライマリ サーバーをポイントします。 変更されません。
読み取り専用エンドポイント [レプリカ] 新しいレプリカ (以前のプライマリ) をポイントします。 プライマリ サーバーをポイントします。
読み取り専用エンドポイント プライマリ サポートされていません。 変更されません。

"プライマリ サーバーへの昇格" がトリガーされたときの動作

  • ライター エンドポイント: このエンドポイントは、ロールの切り替えを反映して、新しいプライマリ サーバーをポイントするように更新されます。
  • 読み取り専用エンドポイント
    • 読み取り専用エンドがレプリカをポイントしている場合: 昇格アクションの後、読み取り専用エンドポイントは新しいレプリカ (以前のプライマリ) をポイントします。
    • 読み取り専用エンドポイントがプライマリをポイントしている場合 :昇格が正しく機能するためには、読み取り専用エンドポイントが昇格を意図しているサーバーを指し示すようにする必要があります。 この場合、プライマリをポイントすることはサポートされていないため、昇格の前にレプリカを指すように再構成する必要があります。

"独立したサーバーに昇格し、レプリケーションから削除する" がトリガーされたときの動作

  • ライター エンドポイント: このエンドポイントは変更されません。 トラフィックは引き続き、プライマリ ロールを保持しているサーバーに転送されます。
  • 読み取り専用エンドポイント
    • 読み取り専用エンドがレプリカをポイントしている場合: 読み取り専用エンドポイントは、昇格されたレプリカからプライマリ サーバーをポイントするようにリダイレクトされます。
    • 読み取り専用エンドポイントがプライマリをポイントしている場合 読み取り専用エンドポイントは変更されず、引き続き同じサーバーをポイントします。

仮想エンドポイントを使用してポイントインタイム リストア (PITR) またはスナップショットの復元中にホスト名の一貫性を維持する

このセクションでは、Azure Database for PostgreSQL - フレキシブル サーバーの仮想エンドポイントを使用して、ポイントインタイム リストア (PITR) またはスナップショットの復元中にホスト名の一貫性を保ち、アプリケーション接続文字列が変更されないようにする方法について説明します。 次の手順に従ってください：

  1. プライマリ サーバーに仮想エンドポイントを追加する

    • Azure portal でプライマリ サーバー インスタンスを参照します。
    • [レプリケーション] タブに移動し、[仮想エンドポイント] の [仮想エンドポイントの追加] をクリックします。
    • 一貫性のあるホスト名 (mydb-virtual-endpoint.postgres.database.azure.com など) を使用して仮想エンドポイントを構成します。
    • 構成を保存します。
    • 接続文字列でこの仮想エンドポイントを使用するようにアプリケーションを更新します。

  2. ポイントインタイム リストア (PITR) またはスナップショットの復元を実行する

    • 復旧の開始：
      • プライマリ サーバーの [バックアップ] セクションに移動します。
      • 適切な復元オプション (PITR または snapshot) を選択し、目的の時点を指定します。
    • 仮想エンドポイントの更新:
      • 新しいインスタンスが作成されたら、以前のプライマリ サーバーの [レプリケーション] タブに戻ります。
      • 元のプライマリ サーバーから仮想エンドポイントを削除します。 仮想エンドポイントを削除するには、以前のプライマリが succeeded 状態である必要があります
      • 新しく作成したサーバーに同じ仮想エンドポイントを追加します。

  3. 検証:

    • アプリケーションがその仮想エンドポイントを使用して接続されていることを確認し、復旧後にデータベース操作を確認します。

関連するコンテンツ