次の方法で共有


Azure Database for PostgreSQL シングル サーバーからフレキシブル サーバーへの自動移行

適用対象: Azure Database for PostgreSQL - 単一サーバー

Azure Database for PostgreSQL のシングル サーバーからフレキシブル サーバーへの自動移行は、計画メンテナンス期間にサービスによって開始される移行です。Basic、General Purpose、またはメモリ最適化 SKU を使用し、使用されているデータ ストレージが <= 5 GiB で、複雑な機能 (CMK、Microsoft Entra ID、読み取りレプリカ、Private Link、または VNet ルール) が有効になっていない、PostgreSQL 11 とデータベース ワークロードを実行しているシングル サーバーが対象です 対象となるサーバーがサービスによって識別され、移行の詳細を確認して必要に応じて変更を加えるための手順を詳細に示す事前通知が送信されます。

自動移行では、計画メンテナンス期間中に回復性が高く自己復旧型のオフライン移行エクスペリエンスが提供され、ダウンタイムは最大で 20 分です。 この移行サービスは、pgcopydb バイナリを使用するホスト型ソリューションで、ソース PostgreSQL インスタンスからターゲットにデータベースを迅速かつ効率的にコピーできます。 この移行により、サーバーを手動で移行するオーバーヘッドが排除されます。 移行後は、価格とパフォーマンスの向上、データベース構成のきめ細かな制御、カスタム メンテナンス期間などのフレキシブル サーバーの利点を利用できます。 移行の主要なフェーズを次に示します。

  • ターゲット フレキシブル サーバーがデプロイされ、パフォーマンスとコストの観点でシングル サーバー SKU と一致させられ、ソースのシングル サーバーからすべてのファイアウォール規則を継承します。

  • サービスまたはユーザーによって選択された移行期間中に、データが移行されます。 サービスによってウィンドウが選択される場合、通常は、サーバーがホストされている特定のリージョンの営業時間外になります。 ソース シングル サーバーは読み取り専用に設定され、データとスキーマがソース シングル サーバーからのターゲット フレキシブル サーバーに移行されます。 すべてのデータベース オブジェクトのユーザー ロール、特権、所有権もフレキシブル サーバーに移行されます。

  • DNS の切り替えと一括移行が最小限のダウンタイムで計画移行期間内に実行され、移行後に同じ接続文字列を使用できるようにします。 クライアント アプリケーションは、ユーザー主導の手動更新や変更なしで、ターゲット フレキシブル サーバーにシームレスに接続します。 移行されたフレキシブル サーバーでサポートされている接続文字列形式 (単一サーバーとフレキシブル サーバー) の両方に加えて、移行されたフレキシブル サーバーでは、username@server_name とユーザー名の両方のユーザー名形式もサポートされます。

  • 移行されたフレキシブル サーバーはオンラインであり、Azure portal/CLI を使用して管理できるようになりました。

  • Azure portal で Service Health の通知を有効にしている場合、古いシングル サーバーに接続するための更新された接続文字列をメールで受け取ります。 または、単一サーバー ポータル ページの [設定] > [接続文字列] で接続文字列を確認できます。 新しいフレキシブル サーバーに設定をコピーする場合は、この接続文字列を使用してシングル サーバーにログインできます。

  • レガシ シングル サーバーは、移行から 7 日後に削除されます。

Note

自動移行サービスは、次の条件に基づいて移行するシングル サーバーを選択します。

  • サーバーで PostgreSQL バージョン 11 が実行されている
  • CMK、Microsoft Entra ID、読み取りレプリカ、VNet ルール、プライベート エンドポイントなどの複雑な機能を持たないサーバー
  • データのサイズ <= 10 GB
  • パブリックアクセスが有効になっている

上記のフィルターは、自動移行するサーバーを選択するために使用されます。 サーバーは、ユーザーが自動移行に指定することもできます。 指名プロセスは柔軟性が高く、すべてのフィルターが適用されるわけではありません。

シングル サーバーを自動移行に指定する

指名プロセスは、フレキシブル サーバーへの移行を自発的に迅速に追跡したいユーザーを対象としています。 シングル サーバー ワークロードを所有している場合、(サービスによってまだスケジュールされていない場合) 自動移行を自分で指名できるようになりました。 このフォームを使用して、サーバーの詳細を送信してください。

移行アラートを構成し、移行スケジュールを確認する

自動移行の対象となるサーバーは、サービスによって事前に Azure 正常性通知が送信されます。 正常性通知は、移行日の 30 日前、14 日前、7 日前に送信されます。 また、移行の進行中、完了時、移行 から 6 日後にレガシ単一サーバーが削除される前にも通知が送信されます。 自動移行の通知を電子メールまたは SMS で受信するように Azure portal を確認して構成できます。

自動移行通知をチェックして構成する方法を次に示します。

  • 自動移行がスケジュールされている単一サーバーのサブスクリプション所有者は、電子メール通知を受け取ります。
  • こちらの手順に従って、自動移行のスケジュールと進行状況の通知を電子メールまたは SMS で受信するようにサービス正常性アラートを構成します。
  • こちらの手順に従って、Azure portal で自動移行の通知を確認します。

自動移行の通知を受信した後に、移行スケジュールを確認する方法を次に示します。

Note

移行スケジュールは、スケジュールされた移行期間の 7 日前にロックされ、その間はスケジュールを変更できなくなります。

  • インスタンスの単一サーバーの概要ページには、移行スケジュールに関する情報を含むポータル バナーが表示されます。
  • 自動移行がスケジュールされているシングル サーバーの場合、[概要] ページが関連情報で更新されます。 シングル サーバー インスタンスの [概要] ページに移動することで、移行スケジュールを確認できます。
  • 移行を延期する場合は、Azure portal で一度に 1 か月延期できます。 移行を再スケジュールするには、1 か月以内に別の移行期間を選択します。

Note

通常、自動移行用に一時的にリストされる候補サーバーは、リージョン間または geo 冗長バックアップを使用しません。 これらの機能は、postgresql フレキシブル サーバーの作成中にのみ有効にすることができます。 これらの機能のいずれかを使用する予定の場合は、自動移行スケジュールをオプトアウトし、サーバーを手動で移行することをお勧めします。

自動移行の前提条件チェック

自動移行が正常に完了するように、以下の前提条件を確認してください。

  • 自動移行を行うためには、シングル サーバー インスタンスは計画移行期間中に準備完了状態である必要があります。
  • SSL が有効になっているシングル サーバー インスタンスの場合、信頼されたルート ストアですべての証明書 (DigiCertGlobalRootG2 Root CA および DigiCertGlobalRootCA Root CA) が利用可能であることを確認します。 さらに、接続文字列にピン留めされた証明書がある場合は、移行後のビジネス継続性を確保するために、スケジュールされた自動移行の前に、3 つの証明書をすべて使用して結合 CA 証明書を作成します。
  • ソースの Azure Database for PostgreSQL シングル サーバーのファイアウォール規則名が 80 文字を超える場合は、名前の長さが 80 文字未満になるように名前を変更します。 (フレキシブル サーバーでサポートされるファイアウォール規則名の長さは 80 文字ですが、シングル サーバーでは 128 文字が許可されます)。

ターゲットの PostgreSQL フレキシブル サーバーはどのようにプロビジョニングされるか

移行先フレキシブル サーバーのコンピューティング レベルと SKU は、以下に示すように、移行元シングル サーバーの価格レベルと仮想コア数に基づいてプロビジョニングされます。

単一サーバーの価格レベル 単一サーバーの仮想コア数 フレキシブル サーバーのレベル フレキシブル サーバーの SKU 名
Basic 1 バースト可能 B1ms
Basic 2 バースト可能 B2s
汎用 2 GeneralPurpose Standard_D2s_v3
汎用 4 GeneralPurpose Standard_D4s_v3
汎用 8 GeneralPurpose Standard_D8s_v3
汎用 16 GeneralPurpose Standard_D16s_v3
汎用 32 GeneralPurpose Standard_D32s_v3
汎用 64 GeneralPurpose Standard_D64s_v3
メモリ最適化 2 MemoryOptimized Standard_E2s_v3
メモリ最適化 4 MemoryOptimized Standard_E4s_v3
メモリ最適化 8 MemoryOptimized Standard_E8s_v3
メモリ最適化 16 MemoryOptimized Standard_E16s_v3
メモリ最適化 32 MemoryOptimized Standard_E32s_v3
  • 移行先フレキシブル サーバーの PostgreSQL バージョン、リージョン、接続文字列、サブスクリプション、リソース グループは、移行元シングル サーバーと同じままになります。
  • 20 GiB 未満のストレージを持つシングル サーバーの場合、ストレージ サイズは 32 GiB に設定されます。これは、Azure Database for PostgreSQL - フレキシブル サーバーの最小ストレージ制限です。
  • ストレージ要件がより大きいシングル サーバーの場合、シングル サーバーで使用されているものより 1.25 倍または 25% 多くのストレージに相当する十分なストレージが割り当てられます。 データの最初の基本コピーの間に、移行先に対して複数の INSERT ステートメントが実行されて、WAL (先書きログ) が生成されます。 これらの WAL がアーカイブされるまで、ログによって移行先のストレージが消費されるため、安全のためにマージンが設けられています。
  • 移行されたフレキシブル サーバーでは、username@server_name (単一サーバー) とユーザー名 (フレキシブル サーバー) の両方のユーザー名形式がサポートされます。
  • 両方の接続文字列形式 – 単一サーバーとフレキシブル サーバーは、移行されたフレキシブル サーバーでサポートされています。

移行後の手順

移行後に知っておく必要がある情報を次に示します。

  • フレキシブル サーバーのサーバー パラメーターは、コミュニティ規範に合わせて調整されます。 シングル サーバーと同じサーバー パラメーター値を保持する場合は、PowerShell を使用してログインし、このスクリプトを実行してパラメーター値をコピーできます。
  • クエリ パフォーマンス分析情報を有効にするには、フレキシブル サーバーで既定では有効になっていないクエリ ストアを有効にする必要があります。
  • 高可用性が必要な場合は、ダウンタイムなしで有効にすることができます。

フレキシブル サーバーでの VNet ルールの処理

Azure Database for PostgreSQL 単一サーバーでは、仮想ネットワーク (VNet) 規則は、サーバーのアクセス制御リスト (ACL) に表示されるサブネットです。 この規則により、単一サーバーは特定のサブネット内のノードからの通信を受け入れることができます。 フレキシブル サーバーの場合、VNet 規則はサポートされていません。 代わりに、フレキシブル サーバーを使用すると、プライベート エンドポイントを作成し、サーバーが仮想ネットワーク内で機能できるようになります。 プライベート エンドポイントにより、プライベート IP がフレキシブル サーバーに割り当てられ、仮想ネットワークとサーバー間のすべてのトラフィックは Azure バックボーン ネットワーク経由で安全に送信されるため、パブリック インターネットに公開する必要がなくなります。

移行後は、これまでは単一サーバー上の VNet 規則でカバーされていたすべてのサブネットのプライベート エンドポイントをフレキシブル サーバーに追加する必要があります。 このプロセスは、Azure Portal または Azure CLI を使用して完了できます。 この手順が完了すると、単一サーバーからの移行後も、ネットワーク接続はフレキシブル サーバー上でそのまま残ります。

よく寄せられる質問 (FAQ)

Q. 自動移行されるのはなぜですか?

A. お使いの Azure Database for PostgreSQL - シングル サーバー インスタンスが、主力製品である Azure Database for PostgreSQL - フレキシブル サーバーへの自動移行の対象となっています。 この自動移行により、サーバーを手動で移行するオーバーヘッドが排除されます。 価格とパフォーマンスの向上、データベース構成のきめ細かな制御、カスタム メンテナンス期間などのフレキシブル サーバーの利点を利用できます。

Q. 自動統合はどのように行われますか? 何が移行されますか?

A. フレキシブル サーバーは、シングル サーバーと同じ仮想コアとストレージにほぼ一致するようにプロビジョニングされます。 次に、ソースのシングル サーバーは読み取り専用の状態になり、スキーマとデータがターゲット フレキシブル サーバーにコピーされます。 DNS スイッチが実行されて、既存のすべての接続がターゲットにルーティングされ、ターゲットのフレキシブル サーバーがオンラインになります。 自動移行により、データベース (スキーマ、データ、ユーザーとロール、特権を含む) が移行されます。 移行はオフラインで、最大 20 分のダウンタイムが発生します。

Q. 自動移行のアラートを設定または表示するにはどうすればよいですか?

A. アラートを設定する方法を次に示します。

  • こちらの手順に従って、自動移行のスケジュールと進行状況の通知を電子メールまたは SMS で受信するようにサービス正常性アラートを構成します。
  • こちらの手順に従って、Azure portal で自動移行の通知を確認します。

Q. スケジュールされたシングル サーバーの移行を延期するにはどうすればよいですか?

A. シングル サーバー インスタンスの [概要] ページに移動することで、移行スケジュールを確認できます。 移行を延期する場合は、Azure portal のシングル サーバー インスタンスの [概要] ページに移動して、最大で 1 か月延期できます。 移行を再スケジュールするには、1 か月以内に別の移行期間を選択します。 移行の詳細は、スケジュールされた移行期間の 7 日前にロックされ、その後は再スケジュールできません。 この自動移行は、2025 年 3 月 30 日まで毎月延期できます。

Q. シングル サーバーのスケジュールされた自動移行からオプトアウトするにはどうすればよいですか?

A. 自動移行からオプトアウトする場合は、その目的のためのサポート チケットを発行できます。

Q. 移行されたフレキシブル サーバーでサポートされるユーザー名と接続文字列は何ですか? ​​

A. 移行されたフレキシブル サーバーでは、username@server_name (単一サーバー形式) とユーザー名 (フレキシブル サーバー形式) の両方のユーザー名形式がサポートされるため、移行後にアプリケーションの継続性を維持するために更新する必要はありません。 また、移行されたフレキシブル サーバーでは、両方の接続文字列形式 (単一サーバーとフレキシブル サーバー形式) もサポートされます。

Q. PostgreSQL Basic シングル サーバーから PostgreSQL フレキシブル サーバーへの移行した場合に、価格に変更があるようなのですが。

A. 移行後に一部のサーバーで価格が若干変更される場合があります。これは、両方のオファリングで最小ストレージ制限が異なるためです (単一サーバーでは 5 GiB、フレキシブル サーバーでは 32 GiB)。 フレキシブル サーバーのストレージ コストは、シングル サーバーよりもわずかに高くなります。 価格の上昇分は、シングル サーバーと比較したスループットとパフォーマンスが向上によって相殺されます。 フレキシブル サーバーの価格の詳細については、こちらをクリックしてください。