仮想エンドポイントは、Azure Database for PostgreSQL フレキシブル サーバーの現在のロールに関係なく一貫性を保つ読み取り/書き込みおよび読み取り専用リスナー エンドポイントです。 この一貫性は、プライマリ サーバーへの昇格アクションを実行した後に、アプリケーションの接続文字列を更新する必要がないようにすることを意味します。 エンドポイントは、ロールの変更後に正しいサーバーを自動的にポイントします。
プライマリ サーバーのコンテキストで、仮想エンドポイントに関連するすべての操作 (追加、編集、削除) を実行します。 Azure portal では、プライマリ サーバーのページでこれらのエンドポイントを管理します。 同様に、CLI、REST API、またはその他のユーティリティなどのツールを使用する場合、コマンドとアクションによるエンドポイント管理の対象はプライマリ サーバーになります。
仮想エンドポイントには、次の 2 種類の接続ポイントが用意されています。
ライター エンドポイント (読み取り/書き込み): このエンドポイントは常に現在のプライマリ サーバーを指します。 これにより、ユーザーがトリガーする昇格操作に関係なく、書き込み操作が確実に正しいサーバーに転送されます。 このエンドポイントは、レプリカを指すように変更することはできません。
読み取り専用エンドポイント: このエンドポイントは、読み取りレプリカまたはプライマリ サーバーを指すよう構成できます。 ただし、ターゲットにできるサーバーは一度に 1 つだけです。 複数のサーバー間の負荷分散はサポートされていません。 このエンドポイントのターゲット サーバーは、昇格の前後を問わず、いつでも調整できます。
注
プライマリ サーバーとそのレプリカごとに作成できるライターと読み取り専用エンドポイントは 1 つだけです。
仮想エンドポイントと行動の促進
昇格アクションをトリガーすると、これらのエンドポイントは予測可能な方法で動作します。 次のセクションでは、これらのエンドポイントがプライマリ サーバーへの昇格と独立したサーバーへの昇格の両方のシナリオにどのように対応するかを説明します。
| 仮想エンドポイント | 元のターゲット | "プライマリ サーバーへの昇格" がトリガーされたときの動作 | "独立したサーバーへの昇格" がトリガーされたときの動作 |
|---|---|---|---|
| ライター エンドポイント | プライマリ | 新しいプライマリ サーバーをポイントします。 | 変更されません。 |
| 読み取り専用エンドポイント | Replica | 新しいレプリカ (以前のプライマリ) をポイントします。 | プライマリ サーバーをポイントします。 |
| 読み取り専用エンドポイント | プライマリ | サポートされていません。 | 変更されません。 |
"プライマリ サーバーへの昇格" がトリガーされたときの動作
- ライター エンドポイント: このエンドポイントは、ロールの切り替えを反映して、新しいプライマリ サーバーをポイントするように更新されます。
-
読み取り専用エンドポイント
- 読み取り専用エンドポイントがレプリカを指している場合: 昇格アクションの後、読み取り専用エンドポイントは新しいレプリカ (以前のプライマリ) を指します。
- 読み取り専用エンドポイントがプライマリを指している場合: 昇格が正しく機能するためには、読み取り専用エンドポイントが昇格を目的としたサーバーを指している必要があります。 プライマリ サーバーを指す機能はサポートされていません。 昇格する前に、レプリカを指すエンドポイントを再構成する必要があります。
"独立したサーバーに昇格し、レプリケーションから削除する" がトリガーされたときの動作
- ライター エンドポイント: このエンドポイントは変更されません。 トラフィックは引き続き、プライマリ ロールを保持しているサーバーに転送されます。
-
読み取り専用エンドポイント
- 読み取り専用エンドポイントがレプリカを指している場合: 読み取り専用エンドポイントは、昇格されたレプリカからプライマリ サーバーを指すようリダイレクトします。
- 読み取り専用エンドポイントがプライマリを指している場合:読み取り専用エンドポイントは変更されず、同じサーバーを指し続けます。
ポイントインタイム リカバリー (PITR) またはスナップショットの復元中に一貫性のあるホスト名に仮想エンドポイントを使用する
このセクションでは、Azure Database for PostgreSQLフレキシブル サーバーで仮想エンドポイントを使用して、ポイントインタイム リカバリー (PITR) またはスナップショットの復元中に一貫性のあるホスト名を維持し、アプリケーション接続文字列を変更しないようにする方法について説明します。 次の手順に従います。
プライマリ サーバーに仮想エンドポイントを追加します。
- Azure ポータルでプライマリ サーバーを参照します。
- [ レプリケーション ] タブに移動します。[ 仮想エンドポイント] で、[ 仮想エンドポイントの追加] を選択します。
-
mydb-virtual-endpoint.postgres.database.azure.comなど、一貫性のあるホスト名を使用して仮想エンドポイントを構成します。 - 構成を保存します。
- 接続文字列でこの仮想エンドポイントを使用するようにアプリケーションを更新します。
ポイントインタイム リストア (PITR) またはスナップショット復元を実行します。
- 復旧を開始します。
- プライマリ サーバーの [バックアップ] セクションに移動します。
- 適切な復元オプション (
PITRまたはsnapshot) を選択し、目的の時点を指定します。
- 仮想エンドポイントを更新します。
- 新しいサーバーが作成されたら、古いプライマリ サーバーの [ レプリケーション ] タブに戻ります。
- 元のプライマリ サーバーから仮想エンドポイントを削除します。 仮想エンドポイントを削除するには、元のプライマリ サーバーが
succeeded状態である必要があります。 - 新しく作成したサーバーに同じ仮想エンドポイントを追加します。
- 復旧を開始します。
検証：
- 仮想エンドポイントを使用してアプリケーションが接続されていることを確認し、復旧後にデータベース操作を確認します。