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

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

Azure Database for PostgreSQL の単一サーバーは廃止されました。 その結果、このサービスに関連する移行に関する記事は間もなく削除される予定です。 継続的なサービスとサポートを確保するには、Azure Database for PostgreSQL フレキシブル サーバーに移行することが不可欠です。 これらのリソースが使用できなくなる前に、フレキシブル サーバーへの必要な移行を確認して完了します。

Azure Database for PostgreSQL - 単一サーバーからフレキシブル サーバーへの自動移行は、単一サーバーの計画的ダウンタイム期間中に行われる、サービスによって開始される移行であり、パッチの適用やメンテナンス期間とは別に行われます。 サービスによって、対象となるサーバーが識別され、自動移行プロセスに関する詳細な手順を含む事前通知が送信されます。 ユーザーは、移行スケジュールを確認して必要に応じて調整したり、サーバーの自動移行をオプトアウトするためのサポート リクエストを送信したりできます。

自動移行では、Azure PostgreSQL 移行サービスを利用して、計画された移行期間中に回復性のあるオフライン移行が実施されます。 ダウンタイムは、ワークロードの特性によって異なります。 移行の速さのベンチマークについては、Azure PostgreSQL 移行速度ベンチマークに関する記事をご覧ください。 この移行により、サーバーを手動で移行する必要がなくなります。 移行後は、価格パフォーマンスの向上、詳細なデータベース構成制御、カスタム メンテナンス期間などのフレキシブル サーバー機能を利用できます。

単一サーバーを自動移行の対象として申請する

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

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

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

• 自動移行を行うためには、単一サーバー インスタンスは計画移行期間中に準備完了状態である必要があります。

• 単一サーバー インスタンスでは、[パブリック ネットワーク アクセスを拒否する] 設定が [いいえ] に構成されている必要があります。 このオプションは、Azure portal の [接続セキュリティ ] ページにあります。

• SSL が有効になっている単一サーバー インスタンスの場合、信頼されたルート ストアですべての証明書 (DigiCertGlobalRootG2 Root CA および DigiCertGlobalRootCA Root CA) が利用可能であることを確認します。 さらに、接続文字列にピン留めされた証明書がある場合は、移行後のビジネス継続性を確保するために、スケジュールされた自動移行の前に、3 つの証明書をすべて使用して結合 CA 証明書を作成します。

• ソースの Azure Database for PostgreSQL 単一サーバーのファイアウォール規則名が 80 文字を超える場合は、名前の長さが 80 文字未満になるように名前を変更します。 (フレキシブル サーバーでサポートされるファイアウォール規則名の長さは 80 文字ですが、単一サーバーでは 128 文字が許可されます。)

自動移行プロセス

自動移行プロセスには、いくつかの重要なフェーズが含まれます。

• 移行先フレキシブル サーバーの作成: 単一サーバーの SKU のパフォーマンスとコストと一致するように、フレキシブル サーバーが作成されます。 移行元の単一サーバーから、すべてのファイアウォール規則が継承されます。

• データ移行: データ移行は指定された移行期間中に行われ、通常は、サーバーのホスティング リージョンの営業時間外にスケジュールされます (サービスによって期間が選択される場合)。 ソースの単一サーバーは読み取り専用に設定されます。 移行により、すべてのデータ、スキーマ、ユーザー ロール、特権、およびデータベース オブジェクトの所有権がフレキシブル サーバーに転送されます。 さらに、既存のすべてのファイアウォール規則がフレキシブル サーバーにコピーされ、接続が中断されないようにします。

• DNS の切り替え: データ移行後に DNS の切り替えが実行され、既存の単一サーバーの接続文字列で新しいフレキシブル サーバーにシームレスに接続できるようになります。 単一とフレキシブル両方のサーバーの接続文字列形式と、ユーザー名の形式 (username@server_name と username) が、移行後のフレキシブル サーバーでサポートされます。

• フレキシブル サーバーの可視性: データ移行と DNS の切り替えが成功すると、新しいフレキシブル サーバーがユーザーのサブスクリプションの下に表示され、Azure portal または CLI を使って管理できるようになります。

• 更新された単一サーバーの接続文字列: 従来の単一サーバーの更新された接続文字列が、Azure portal のサービス正常性通知を介して送信されます。 [ 設定] -> [接続文字列] の [単一サーバー ポータル] ページでもアクセスできます。

• 単一サーバーの削除 - 単一サーバーは、移行後 7 日間保持されてから削除されます。

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

ターゲット フレキシブル サーバーのコンピューティング レベルと SKU は、ソースの単一サーバーの価格レベルと仮想コアに基づいてプロビジョニングされます。

• ターゲット フレキシブル サーバーの postgresql のバージョン、リージョン、接続文字列、サブスクリプション、およびリソース グループは、ソースの単一サーバーの設定と同じままです。
• 20 GiB 未満のストレージを持つ単一サーバーの場合、ストレージ サイズは 32 GiB に設定されます。これは、Azure Database for PostgreSQL - フレキシブル サーバーの最小ストレージ制限です。
• ストレージ要件がより大きい単一サーバーの場合、単一サーバーで使用されているものより 1.25 倍または 25% 多くのストレージに相当する十分なストレージが割り当てられます。 データの最初の基本コピーの間に、移行先に対して複数の INSERT ステートメントが実行されて、WAL (先書きログ) が生成されます。 これらの WAL がアーカイブされるまで、ログによって移行先のストレージが消費されるため、安全のためにマージンが設けられています。
• 移行されたフレキシブル サーバーでは、username@server_name (単一サーバー) とユーザー名 (フレキシブル サーバー) の両方のユーザー名形式がサポートされます。
• 両方の接続文字列形式 – 単一サーバーとフレキシブル サーバーは、移行されたフレキシブル サーバーでサポートされています。

PostgreSQL のメジャー バージョン間の自動移行

この移行には、PostgreSQL Single Server (バージョン 9.5、9.6、または 10) からフレキシブル サーバー上の PostgreSQL 11 へのデータの移動が含まれる場合があります。 PostgreSQL コミュニティは、これらの以前のバージョンを廃止しました。 セキュリティ、安定性、パフォーマンスを確保するために、サポートされているコミュニティ バージョンを採用することをお勧めします。

PostgreSQL のメジャー バージョン間で移行する場合は、次の重要な要素を考慮して、移行が成功するように、スムーズに進めます。

• 廃止された機能 - 古いバージョンで廃止された機能は、PostgreSQL 11 では使用できなくなる可能性があります。 アプリケーションに影響を与える可能性がある重大な変更や非推奨の機能については、 リリース ノート を確認することが重要です。

• アプリケーションのテスト - PostgreSQL 11 でアプリケーションの徹底的なテストを行います。 SQL クエリ、関数、またはサード パーティ製ツールの潜在的な問題に注意してください。これは、新しいバージョンの変更によって動作が異なるか、完全に失敗する可能性があるためです。

• 構成の変更 - メジャー バージョンのアップグレードでは通常、新しいパラメーターの追加、または既存のパラメーターの既定値の変更により、サーバー パラメーターの変更があります。 これらの変更は、照合順序、クエリ実行、データ ストレージに影響を与える可能性があります。 互換性を確保するために、これらの更新された設定に対してアプリケーションをテストし、発生した問題に対処します。 問題が発生した場合は、「移行後の手順」セクションに記載されているスクリプトを使用して、既存のサーバー パラメーターを単一サーバー インスタンスから自動移行されたフレキシブル サーバーにコピーします。

移行後の手順

自動移行後の手順に関して注意する必要がある情報を次に示します。

• 自動移行で PostgreSQL のメジャー バージョン間での移行が行われる場合は、アプリケーションを十分にテストして、最新の変更やパラメーターの調整による影響を特定します。 互換性と最適なパフォーマンスを確保するために必要な変更を行います。

• フレキシブル サーバーの参照を使用して、単一サーバーのインスタンスを管理するためにホストされているすべての Terraform/CLI スクリプトを更新する必要があります。

• フレキシブル サーバーのサーバー パラメーターは、コミュニティ規範に合わせて調整されます。 単一サーバーと同じサーバー パラメーター値を保持する場合は、PowerShell を使用してサインインし、 ここで スクリプトを実行してパラメーター値をコピーできます。

• フレキシブル サーバーのアクセス制御 (IAM) 設定は、サブスクリプション設定から継承されます。 単一サーバーに固有のロールの割り当てを指定した場合は、フレキシブル サーバーでこれらのロールの割り当てを作成する必要があります。

• 監視ページの設定 (アラート、メトリック、診断設定) をフレキシブル サーバーにコピーします。

• クエリ パフォーマンス分析情報を有効にするには、フレキシブル サーバーで既定では有効になっていないクエリ ストアを有効にする必要があります。

• 高可用性が必要な場合は、ダウンタイムなしで有効にすることができます。

• フレキシブル サーバー SKU が、Service Health の自動マイグレーション通知に記載されている SKU と一致することを確認します。 異なる場合は、通知で指定された SKU に戻してください。 これは、請求が正しく行われるようにするために重要です。

• これで、単一サーバーの既存の接続文字列がフレキシブル サーバーを指すようになりました。 単一サーバーにアクセスするために、新しい接続文字列のセットが生成されます。 これらは、単一サーバーの自動移行用に送信された Service Health の通知から取得できます。

フレキシブル サーバーでの仮想ネットワーク 規則の処理

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

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

長期保有バックアップ

単一サーバーの自動移行では、フレキシブル サーバーへの移行後に長期保有 (LTR) バックアップが自動的に構成されることはありません。 Azure Backup を使用して、長期保有を指定で Azure Database for PostgreSQL フレキシブル サーバーをバックアップできます。

単一サーバーの自動移行がスケジュールされているかどうかを確認する方法

単一サーバーが自動移行の対象に選ばれているかどうかを確認するには、次の手順のようにします。

• サービス正常性通知 - Azure portal で、[サービスの正常性] > [計画メンテナンス] イベントに移動します。 'Azure Database for PostgreSQL 単一サーバーへのスケジュールされた自動移行の通知' というラベルが付いたイベントを探します。 通知は、移行日の 30、14、7 日前に送信され、移行ステージの間にも、進行中、完了時、単一サーバーの使用停止の 6 日前に送信されます。

  注

  これらの通知は、既定では受信トレイに表示されません。 メールまたは SMS で受信するには、Service Health アラートを設定する必要があります。 詳細については、「 サービス正常性アラートの設定」を参照してください。

• 単一サーバーの概要ページ: Azure portal で単一サーバー インスタンスに移動し、[概要] ページを調べます。 自動マイグレーションがスケジュールされている場合は、ここで詳細を確認できます。

  注

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

• Azure CXP のメール通知: Azure Customer Experience (CXP) も、単一サーバーを含むサブスクリプションに関連付けられているクラシック ロールと RBAC ロールに直接メールを送信し、今後の自動移行に関する情報を提供します。

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

質問 自動移行されるのはなぜですか?

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

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

A. フレキシブル サーバーは、単一サーバーと同じ仮想コアとストレージにほぼ一致するようにプロビジョニングされます。 次に、ソースの単一サーバーは読み取り専用の状態になり、スキーマとデータがターゲット フレキシブル サーバーにコピーされます。 DNS スイッチは、既存のすべての接続をターゲットにルーティングするために実行され、ターゲット フレキシブル サーバーがオンラインになります。 自動移行により、データベース (スキーマ、データ、ユーザーとロール、特権を含む) が移行されます。 移行はオフラインです。ワークロードのサイズに応じて、数分から数時間のダウンタイムが発生します。 移行の速さのベンチマークについては、Azure PostgreSQL 移行速度ベンチマークに関する記事をご覧ください。

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

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

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

質問 単一サーバーのスケジュールされた自動移行からオプトアウトするにはどうすればよいですか?

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

質問 単一サーバーで仮想ネットワーク 規則規則が使用されている場合は、移行後の手順に従う必要がありますか?

A. フレキシブル サーバーでは、仮想ネットワーク規則はサポートされていません。 こちらのセクションを参照してください

質問 フレキシブル サーバーで長期保有バックアップを再構成する必要がありますか?

A. はい。 こちらのセクションを参照してください

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

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

質問 postgresql Basic Single Server から postgresql フレキシブル サーバーへの移行を検討する際に、価格に違いがあります

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

質問 移行しない場合、または 2025 年 3 月 28 日までにサーバーが自動移行されない場合はどうなりますか

A. 2025 年 3 月 28 日の提供終了期限を過ぎると、移行されていない既存のすべての単一サーバーが強制的にフレキシブル サーバーに移行されます。 プライベート エンドポイントや読み取りレプリカなどのアドオン機能を備えたサーバーでは、通常の操作を確保するために、移行後のユーザーによるより多くのアクションが必要です。 提供終了日の延長はありません。

質問 自動移行されたサーバーで メジャーバージョンアップグレード (MVU) を実行する際の注意事項はありますか?

A. はい。注意すべき重要な注意事項が 1 つあります。 フレキシブル サーバーでサポートされている PostgreSQL バージョンへのメジャー バージョンのアップグレードは、自動移行されたサーバーで完全にサポートされていますが、接続文字列の形式はアップグレードが成功すると少し変わります。 具体的には、アップグレード後にユーザー名の形式 "username@servername" はサポートされなくなります。 現在、アプリケーションまたはスクリプトで接続文字列でこの形式が使用されている場合は、" username" という標準形式を使用するように更新する必要があります。 接続の問題を回避するために、アップグレード後に影響を受けるすべての接続文字列を確認して更新してください。

質問 自動移行では、Microsoft Entra で認証されたロールの移行がサポートされていますか?

A。 はい。自動移行では、Microsoft Entra で認証されたロールの移行がサポートされます。 サーバーがフレキシブル サーバーに自動移行されたら、Entra ID を使用してログインするときに、ユーザー名として entraid@servername 形式を使用する必要があります。 現在、 entraid より単純な形式はサポートされていません。

例:

Entra ID が abc@xyz.com で、サーバー名が server1 の場合、自動移行されたフレキシブル サーバーへのログインユーザー名は abc@xyz.com@server1 です。 abc@xyz.comをユーザー名として使用してログインしようとするのは機能しません。

これは既知の問題であり、Microsoft は今後の更新プログラムで積極的に対処しています。

関連コンテンツ

• Azure portal を使用して Azure Database for postgresql - フレキシブル サーバーを管理します。 2つの変更:1つの追加&1削除2
  articles/postgresql/migrate/partners-migration-postgresql.md
• Azure Database for PostgreSQL - フレキシブル サーバー
• Azure Database for PostgreSQL - フレキシブル サーバーの価格