提供終了のお知らせの後、Azure Database for PostgreSQL - 単一サーバーはどうなりますか?
適用対象: Azure Database for PostgreSQL - 単一サーバー
**Azure Database for PostgreSQL - Single Server は廃止が予定されており、2025 年 3 月 28 日までに廃止される予定です。
Azure Database for PostgreSQL – 単一サーバーは 2018 年に一般提供されました。 お客様からのフィードバックと、Azure データベース ランドスケープの計算、可用性、スケーラビリティ、パフォーマンス機能の新しい進歩を踏まえると、Single Server のオファリングは廃止し、新しいアーキテクチャにアップグレードする必要があります。 Azure Database for PostgreSQL - Flexible Server は、次世代のサービスであり、最良の Azure オープンソース データベース プラットフォームを実現します。
この廃止の一環として、2023 年 11 月 30 日以降、Azure portal からの新しい単一サーバー インスタンスの作成はサポートされなくなりますが、 ビジネス継続性を確保するために、単一サーバー インスタンスを作成する必要がある場合は、2025 年 3 月までは Azure CLI を引き続き使用できます。
現在、運用サーバーをホストしている Azure Database for PostgreSQL - 単一サーバー サービスがある場合は、ご使用の Azure Database for PostgreSQL - 単一サーバーを Azure Database for PostgreSQL - フレキシブル サーバーに移行できます。
Azure Database for PostgreSQL - フレキシブル サーバーは、データベース管理機能と構成設定のよりきめ細かな制御と柔軟性のために設計された、運用環境対応のフル マネージド データベース サービスです。 詳細については、「Azure Database for PostgreSQL - Flexible Server」を参照してください。
Azure Database for PostgreSQL - 単一サーバー から Azure Database for PostgreSQL - フレキシブル サーバーに移行する
PostgreSQL 移行サービスを使用して、Azure Database for PostgreSQL - 単一サーバーから Azure Database for PostgreSQL - フレキシブル サーバーに移行する方法について説明します。
よく寄せられる質問 (FAQ)
Q. Azure Database for PostgreSQL - 単一サーバーはなぜ廃止されるのですか?
A. Azure Database for PostgreSQL – 単一サーバーは 2018 年に一般提供されました。 お客様からのフィードバックと、Azure データベース ランドスケープの計算、可用性、スケーラビリティ、パフォーマンス機能の新しい進歩を踏まえると、Single Server のオファリングは廃止し、新しいアーキテクチャにアップグレードする必要があります。 Azure Database for PostgreSQL - Flexible Server は、次世代のサービスであり、最良の Azure オープンソース データベース プラットフォームを実現します。
Q. Azure Database for PostgreSQL - フレキシブル サーバーへの移行を求められるのはなぜですか?
A.Azure Database for PostgreSQL - フレキシブル サーバーは、Azure ですべてのオープンソース PostgreSQL ワークロードを実行するのに最適なプラットフォームです。 Azure Database for PostgreSQL - Flexible Server は経済的であり、すべてのサービス レベルでパフォーマンスが向上しています。また、コストを制御する方法が増えたことで、より安価かつ高速でのディザスター リカバリーを実現しています。 フレキシブル サーバーのその他の機能強化は次のとおりです。
- Postgres バージョン 11 以降のサポートと組み込みのセキュリティ強化
- バースト可能レベルのコンピューティング オプションのサポートが含まれた、より優れた価格パフォーマンス。
- 同一または異なる可用性ゾーンでのホット スタンバイとユーザーが制御するメンテナンス期間を構成することによるアップタイムの改善。
- 高パフォーマンスのデータ ワークロードを実現する簡素化された開発者エクスペリエンス。
Q. いつまでに単一サーバーをフレキシブル サーバーに移行する必要がありますか?
A. Azure Database for PostgreSQL - 単一サーバーは 2025 年 3 月 28 日までに廃止される予定であるため、できるだけ早い機会に単一サーバーをフレキシブル サーバーに移行することを強くお勧めします。それにより、移行ライフサイクルを実行するための十分な時間を確保し、フレキシブル サーバーによって提供される利点を使用できるようになります。
Q. 既存の Azure Database for PostgreSQL - 単一サーバー インスタンスはどうなりますか?
A. 既存の Azure Database for PostgreSQL - Single Server ワークロードは、2025 年 3 月までサポートされます。
Q. 2023 年 11 月のコミュニティの EOL 日の後も、新たにバージョン 11 の Azure Database for PostgreSQL - 単一サーバーを作成できますか?
A. 2023 年 11 月 30 日以降は、Azure portal を使用して PostgreSQL バージョン 11 の新しい単一サーバー インスタンスを作成できなくなります。 ただし、2025 年 3 月までは CLI を使用して引き続き作成できます。 バージョン管理サポート ポリシーを通じて単一サーバーをサポートしています。 Azure Database for PostgreSQL - Flexible Server への移行をすぐに開始するのが最良の方法です。
Q. 最終日の 2025 年 3 月 28 日を過ぎても Azure Database for PostgreSQL - 単一サーバー インスタンスを引き続き実行できますか?
A. 最終日の 2025 年 3 月 28 日まで単一サーバーをサポートする予定です。できるだけ早く移行計画を開始することを強くお勧めします。 2025 年 3 月 28 日の終了日に Single Server のデプロイのサポートを終了する予定です。
Q. 単一サーバー廃止のお知らせの後、ビジネス ニーズを満たすために新しい単一サーバーを作成する必要がある場合はどうすればよいですか?
A. 新しい単一サーバーを作成する機能はすぐには停止されないため、CLI を使用して引き続き新しい単一サーバーを作成し、Azure Database for PostgreSQL - 単一サーバーでサポートされているすべての PostgreSQL バージョンでビジネス ニーズを満たすことができます。 フレキシブル サーバーを検討し、それがニーズを満たすかどうかを確認することを強くお勧めします。 必要に応じてお気軽にお問い合わせください。最適な方法をご説明、ご提案させていただきます。
Q. 移行には追加コストがかかりますか?
A. 移行中は、移行先のフレキシブル サーバーと移行元の単一サーバーに対して料金が発生します。 移行先のフレキシブル サーバーの構成とコンピューティングによって、発生する追加コストが決まります (詳細については、価格に関するページを参照してください)。 移行が正常に行われた後に移行元の単一サーバーの使用を停止した時点で、フレキシブル サーバーに対してのみ料金が発生します。 単一サーバーからフレキシブル サーバーへの移行サービスの使用には、追加コストはかかりません。 単一サーバーからフレキシブル サーバーへの移行コストについて質問や懸念がある場合は、Microsoft アカウントの担当者にお問い合わせください。
Q. Azure Database for PostgreSQL - 単一サーバーではなく、Azure Database for PostgreSQL - フレキシブル サーバーを実行することで、課金には影響がありますか?
A. Azure Database for PostgreSQL - 単一サーバーと同様の構成を選択した場合、課金は同程度になります。 ただし、移行先のフレキシブル サーバーで同一のゾーンまたは高可用性を備えたゾーン冗長を選択した場合、請求額は単一サーバーの場合よりも高くなります。 同一ゾーンまたはゾーン冗長の高可用性では、追加のホット スタンバイ サーバーをスピンアップして冗長バックアップ データを格納する必要があるため、2 番目のサーバーの追加コストが発生します。 このアーキテクチャにより、計画外の停止や計画メンテナンス中のダウンタイムを短縮できます。 一般的には、Flexible Server では価格パフォーマンスは向上しますが、これはワークロードによって異なります。
Q. Azure Database を PostgreSQL - 単一サーバーからフレキシブル サーバーに移行するときにダウンタイムは発生しますか?
A. PostgreSQL 移行サービスでは、オフライン移行とオンライン移行がサポートされています。 オフライン移行では、移行プロセス中にアプリケーションにダウンタイムが必要です。 オンライン移行は、非常に限られたダウンタイムでデータベースを移行するのに役立ちますが、いくつかの制限があります。 詳細については、「PostgreSQL 移行サービス - Azure Database for PostgreSQL 単一サーバーからフレキシブル サーバー」を参照してください。
ダウンタイムは、データベースの数やサイズ、各データベース内のテーブルの数、インデックスの数、テーブル間のデータの分散など、いくつかの要因によって決まります。 また、移行元と移行先サーバーの SKU と、移行元と移行先サーバーで使用できる IOPS にも左右されます。
移行に関連する多くの要因を考慮すると、アプリケーションのダウンタイムを見積もる最善の方法は、プライマリ サーバーから復元された PITR サーバーで移行を試みて運用環境の移行を計画することです。
オフライン移行はそれほど複雑ではなく、失敗する可能性はほとんどありません。 この方法は、サービス ウィンドウを使用するワークロードを 1 台のサーバーからフレキシブル サーバーに移行する場合に推奨されます。 オンライン移行は、ダウンタイムの許容度が低い運用環境に使用できます。
Q. 今後、最新の PostgreSQL バージョンをサポートするための更新プログラムは単一サーバーに対して提供されますか?
A. 最新の PostgreSQL エンジン バージョンで実行する必要がある場合は、フレキシブル サーバーに移行することをお勧めします。 2023 年 11 月にコミュニティによって廃止されるまで、コミュニティによってリリースされた Postgres バージョン 11 のマイナー バージョンは引き続きデプロイされます。
注意
Microsoft では、コミュニティの廃止日以降も Postgres バージョン 11 のサポートを延長する予定であり、この移行を容易にするために単一サーバーとフレキシブル サーバーの両方で PostgreSQL バージョン 11 をサポートします。 最新の Postgres エンジン バージョンの利点を使用するために、フレキシブル サーバーへの移行を検討してください。
Q. Flexible Server の 99.99% 可用性 SLA は Single Server とどのくらい違いますか?
A. フレキシブル サーバーのゾーン冗長デプロイでは、99.99% の可用性とゾーン レベルの回復性が提供されますが、単一サーバーでは 99.99% の可用性は提供されるものの、ゾーンの回復性はありません。 フレキシブル サーバーの高可用性 (HA) アーキテクチャでは、冗長コンピューティングとストレージを備えたホット スタンバイ サーバーをデプロイします (各サイトのデータを 3 つのコピーで保存)。 単一サーバーの HA アーキテクチャには、ゾーン障害からの復旧に役立つパッシブ ホット スタンバイはありません。 フレキシブル サーバーの HA アーキテクチャにより、計画外の停止や計画メンテナンス時のダウンタイムが短縮されます。
Q. 単一サーバーをデプロイしているリージョンで、フレキシブル サーバーがサポートされていません。 この移行を進めるにはどうすればよいですか?
A. 単一サーバーとのリージョンの違いはなくなりつつあります。 以下のリージョンには、フレキシブル サーバーが存在しません。
- 中国東部 (CE と CE2)
- 中国北部 (CN と CN2)
- インド西部
- スウェーデン北部
CN3/CE3、インド中部、スウェーデン中部、スウェーデン南部のリージョンに移行することをお勧めします。 Q. 1 台のサーバー用にプライベート リンクが構成されています。 移行する方法
A. Flexible Server で Private Link のサポートを利用できるようになりました。 ランタイム サーバーを使用して、プライベート リンクがサポートされているフレキシブル サーバーに移行できます。 詳細については、「ランタイム サーバー - Azure Database for PostgreSQL 単一サーバーからフレキシブル サーバー」を参照してください。
Q. 単一サーバーからフレキシブル サーバーへの移行をロールバックするオプションはありますか?
A. 任意の数のテスト移行を実行し、移行の成功をテストし、準備ができたら最終的な移行を実行できます。 テスト移行は単一サーバーのソースには影響しません。これは、フレキシブル サーバーを指すように接続文字列を移行および変更するまで動作し続けます。 テスト移行を行っているときにエラーが発生した場合は、最終的な移行を延期し、移行元サーバーを実行し続けることができます。 エラーを解決した後で、最終的な移行を再試行できます。 フレキシブル サーバーへの最終的な移行を実行し、運用ワークロード用に開いた後は、データ損失を発生させずに Single Server に戻る機能は失われます。
Q. DB (> 1 TB) を移行するにはどうすればいいですか?
A. PostgreSQL 移行サービスでは、あらゆるサイズのデータベースを単一サーバーからフレキシブル サーバーに移行できます。 移行サービスには、データベースのサイズに関する制限はありません。
Q. リージョン間の移行はサポートされていますか?
A. はい。
Q. サブスクリプション間の移行はサポートされていますか?
A. PostgreSQL 移行サービスでは、サブスクリプション間の移行がサポートされています。
Q. リソース グループ間のサブスクリプションはサポートされていますか?
A. PostgreSQL 移行サービスでは、リソース グループ間の移行がサポートされます。
Q. バージョン間のサポートはありますか?
A. PostgreSQL 移行サービスでは、PostgreSQL の下位バージョン (PG 9.5 以降) から上位バージョンへの移行がサポートされています。 この場合も、PostgreSQL 上位バージョンとアプリケーションの互換性を事前に確認しておく必要があります。
PostgreSQL 移行サービス
PostgreSQL 移行サービスは、SQL Server データベースを単一サーバーからフレキシブル サーバーに簡単に移行できる、強力なサービスです。 このサービスを使用すると、オンプレミスのサーバーまたは仮想マシンからクラウド内のフレキシブル サーバーにデータベースを簡単に移動できるため、クラウド コンピューティングのスケーラビリティと柔軟性を活用できます。
Q. 移行の一環として移行されるデータ、スキーマ、およびメタデータ コンポーネントはどれですか?
A. PostgreSQL 移行サービスでは、スキーマ、データ、およびメタデータがソースから移行先に移行されます。 次のすべてのデータ、スキーマ、メタデータ コンポーネントが、データベース移行の一環として移行されます。
データ移行
- すべてのデータベースまたはスキーマのすべてのテーブル。
スキーマの移行:
- 名前を付ける
- Primary key (プライマリ キー)
- データ型
- 序数位置
- 既定値
- NULL 値の許容
- 自動増分属性
- セカンダリ インデックス
メタデータの移行:
- ストアド プロシージャ
- 関数
- トリガー
- ビュー
- 外部キー制約
Q. オフライン移行とオンライン移行の違いは何ですか?
A. オフライン移行では、移行が開始されるとアプリケーションのダウンタイムが始まります。 オンライン移行では、ダウンタイムは移行の最後の切り替えに必要な時間だけに限定されます。 ただしこれは、いくつかの制限の対象となる論理レプリケーション メカニズムを使用します。
次の表は、オフライン オプションとオンライン オプションの概要を示しています。
オプション | 長所 | 短所 | 推奨対象 |
---|---|---|---|
オフライン | - 実行するのがシンプルかつ簡単で、それほど複雑ではない。 - 失敗する可能性が非常に少ない。 - 処理できるデータベース オブジェクトに関する制限がない。 |
アプリケーションのダウンタイム。 | - シンプルさと高い成功率が不可欠なシナリオに最適。 - 事業運営に大きな影響を与えずにデータベースをオフラインにできるシナリオに最適。 - 計画メンテナンス期間内に移行プロセスを完了できるデータベースに適している。 |
オンライン | - アプリケーションのダウンタイムを最小限に抑える。 - 大規模なデータベースや、ダウンタイム要件が限られているお客様に最適。 |
- オンライン移行で使用されるレプリケーションには、いくつかの制限がある (主キーがすべてのテーブルで必要など)。 - オフライン移行よりも実行が困難ではるかに複雑。 - 移行の複雑さにより、失敗の可能性が高くなる。 - 移行が長時間実行される場合、ソース インスタンスのストレージとコンピューティングに影響を及ぼす。 移行中は、影響を注意深く監視する必要があります。 |
- 継続性が重要であり、ダウンタイムを最小限に抑える必要がある企業に最適。 - 進行中の操作を中断せずに移行プロセスを実行する必要があるデータベースに推奨される。 |
Q. 単一サーバーからフレキシブル サーバーへの移行パフォーマンスを最適化するための推奨事項はありますか?
A. はい。 より高速で移行を実行するには、フレキシブル サーバーに対してより高い SKU を選択します。 移行をすばやく完了するには、最低 4 個以上の仮想コアを選択します。 SKU は、移行後にアプリケーションのニーズに合わせていつでも変更できます。 その他の成功事例を確認してください。
Q. 移行サービスを使用して、単一サーバーからフレキシブル サーバーへのオフライン移行を実行するには、どのくらいの時間がかかりますか?
A. 次の表は、PostgreSQL 移行サービスを使用して、さまざまなサイズのデータベースに対してオフライン移行を実行するのにかかる時間を示しています。 移行は、次の SKU のフレキシブル サーバーを使用して実行されました。
Standard_D4ds_v4 (4 コア、16 GB メモリ、500 IOPS)
データベース サイズ | 時間 (HH:MM) |
---|---|
1 GB | 00:01 |
5 GB | 00:03 |
10 GB | 00:08 |
50 GB | 00:35 |
100 GB | 01:00 |
500 GB | 04:00 |
1,000 GB | 07:00 |
注意
上記の数値は、移行が完了するまでにかかった時間を概算したものです。 サーバーに移行するために必要な正確な時間を取得するには、単一サーバーの PITR (ポイントインタイム リストア) を取得し、PostgreSQL 移行サービスを使用して移行することを強くお勧めします。
Q. 移行サービスを使用して、単一サーバーからフレキシブル サーバーへのオンライン移行を実行するには、どのくらいの時間がかかりますか?
A. オンライン移行では次の手順を実行する必要があります。
- データベースの初期コピー
- 変更データ キャプチャ - 手順 1 の間の移行元でのすべてのトランザクションを移行先に対して再生します。
手順 1 でかかった時間は、オフライン移行の場合と同じです (前の質問を参照してください)。
手順 2 の所要時間は、移行元で発生するトランザクションによって決まります。 書き込み負荷の高いワークロードの場合は、かかる時間は長くなります。
Q. 単一サーバーからフレキシブル サーバーへの移行に関して Microsoft が提供するサポートはありますか?
A. はい。 移行サービスの継続的な更新に加え、Microsoft は移行プロセス全体を通じてお客様と連携できる内部パートナー チームと連携しています。 詳細については、アカウント担当者にお問い合わせください。
Q. Microsoft は、単一サーバーをフレキシブル サーバーに自動的に移行するのに役立ちますか? A. はい。 自動移行にサーバーを指定できます。 詳細を確認し、こちらで自動移行にサーバーを指定することができます。
追加のサポート
Q. 提供終了についてさらに質問があります。
A. 詳細情報は、いくつかの方法で取得できます。
Microsoft Q&A でコミュニティの専門家から回答を得ます。
サポート プランに加入していて技術的な支援が必要な場合は、サポート リクエストを作成してください。- [要約] に、問題の説明を入力します。 - [問題の種類] で、[技術] を選択します。 - [サブスクリプション] で、ご使用のサブスクリプションを選択します。 - [サービス] で、[マイ サービス] を選びます。 - [サービスの種類] では、[Azure Database for MySQL 単一サーバー] を選択します。 - [リソース] で、お使いのリソースを選びます。 - [問題の種類] で、[Azure DB for PostgreSQL への移行] を選択します。 - [問題のサブタイプ] で、[単一サーバーからフレキシブル サーバーへの移行] を選択します。
警告
この記事は、Azure Database for PostgreSQL - フレキシブル サーバーのユーザー向けではありません。 これは、Azure Database for PostgreSQL - フレキシブル サーバーにアップグレードする必要がある Azure Database for PostgreSQL - 単一サーバーのお客様向けです。
サービスの移行は骨の折れる作業になる可能性があります。お客様に迷惑をおかけする可能性があることをあらかじめお詫びいたします。 自分と環境に最適なシナリオを選択できます。