移行ツール - Azure Database for PostgreSQL シングル サーバーからフレキシブル サーバー (プレビュー)

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

Azure Database for PostgreSQL フレキシブル サーバーには、ゾーン冗長高可用性、価格の制御、メンテナンス期間の制御が用意されています。 使用可能な移行ツールを使用して、データベースをシングル サーバーからフレキシブル サーバーに移動できます。 2 つのデプロイ オプションの違いを理解するには、この比較グラフを参照してください。

単一からフレキシブル サーバーへの移行ツールは、単一からフレキシブル サーバーへの移行タスクに役立つよう設計されています。 このツールを使用すると、複数のサーバーとデータベースの移行を反復可能な方法で開始できます。 このツールを使用すると、ほとんどの移行手順が自動化されるため、Azure プラットフォーム全体の移行作業を可能な限りシームレスに行うことができます。 このツールは、無料で提供されます。

Note

この移行ツールはパブリック プレビュー段階にあります。 機能やユーザー インターフェイスは変更されることがあります。 シングル サーバーからの移行の開始はプレビュー段階であり、次のリージョンで有効になっています。米国中部、米国西部、米国中南部、米国中北部、東アジア、スイス北部、オーストラリア東南部、アラブ首長国連邦北部、英国西部、カナダ東部。 ただし、すべてのリージョンで、フレキシブル サーバー側から移行ウィザードを使用することもできます。

移行ツールは、ソースとターゲットの PostgreSQL バージョンには依存しません。 ガイドラインを次に示します。

ソース Postgres バージョン (シングル サーバー) ターゲット Postgres の推奨バージョン (フレキシブル サーバー) 注釈
Postgres 9.5 (廃止) Postgres 13 Postgres 14 に直接移行することもできます。 アプリケーションの互換性を確認します。
Postgres 9.6 (廃止) Postgres 13 Postgres 14 に直接移行することもできます。 アプリケーションの互換性を確認します。
Postgres 10 (22 年 11 月廃止) Postgres 14 アプリケーションの互換性を確認します。
Postgres 11 Postgres 14 アプリケーションの互換性を確認します。
Postgres 11 Postgres 11 フレキシブル サーバーで同じバージョンに移行することを選択できます。 その後、フレキシブル サーバーで上位バージョンにアップグレードできます

重要

フレキシブル サーバーが単一サーバー リージョンで使用できない場合は、代替リージョンにフレキシブル サーバーをデプロイすることを選択できます。 引き続き、フレキシブル サーバーに関するサポートをより多くのリージョンに追加していきます。

概要

この移行ツールにより、データベースをシングル サーバー (ソース) からフレキシブル サーバー (ターゲット) に移行するためのインライン エクスペリエンスが提供されます。

ソース サーバーを選び、そこから最大 8 個のデータベースを選ぶことができます。 この制限は移行タスクごとのものです。 移行ツールにより、次の手順が自動化されます。

  1. ターゲット サーバーのリージョンに移行インフラストラクチャを作成します。
  2. パブリック IP アドレスを作成し、移行インフラストラクチャにそれをアタッチします。
  3. 移行インフラストラクチャの IP アドレスを、ソースとターゲットの両方のサーバーのファイアウォール規則の許可リストに追加します。
  4. ソースとターゲットの両方で種類を Azure Database for PostgreSQL として移行プロジェクトを作成します。
  5. ユーザーが指定したデータベースをソースからターゲットに移行するための移行アクティビティを作成します。
  6. ソースからターゲットにスキーマを移行します。
  7. フレキシブル サーバー ターゲットに同じ名前のデータベースを作成します。
  8. ソースからターゲットにデータを移行します。

次の図は、移行ツールを使用したシングル サーバーからフレキシブル サーバーへの移行のプロセス フローを示しています。

シングル サーバーからフレキシブル サーバーへの移行を示す図。

プロセスの手順を次に示します。

  1. フレキシブル サーバー ターゲットを作成します。
  2. 移行を呼び出します。
  3. Azure Database Migration Service を使用して移行インフラストラクチャをプロビジョニングします。
  4. 移行を開始する。
    1. 初期ダンプ/復元 (オンラインとオフライン)
    2. 変更のストリーミング (オンラインのみ)
  5. ターゲットに一括移行します。

この移行ツールは、Azure portal および使いやすい Azure CLI コマンドを介して公開されます。 これにより、移行の作成、移行の一覧表示、移行の詳細の表示、移行の状態の変更、移行の削除を行うことができます。

移行モードの比較

このツールでは、シングル サーバーからフレキシブル サーバーへの移行に 2 つのモードがサポートされています。 "オンライン" オプションを使用すると、論理レプリケーションの制限により、移行のダウンタイムが短縮されます。 "オフライン" オプションを使用すると、移行は簡単になりますが、データベースのサイズによっては長時間のダウンタイムが発生する可能性があります。

次の表は、移行モード間の違いをまとめたものです。

機能 オンライン オフライン
移行の間にデータベースを読み取りに利用できるかどうか 利用可能 利用可能
移行の間にデータベースを書き込みに利用できるかどうか 利用可能 移行後に開始された書き込みはキャプチャまたは移行されないため、通常はお勧めしません
'アプリケーションの適合性 最大限のアップタイムが必要なアプリケーション 計画的なダウンタイム期間を許容できるアプリケーション
環境の適合性 運用環境 通常、開発環境、テスト環境、ダウンタイムを許容できる一部の運用環境
書き込み負荷の高いワークロードの適合性 適しているが、移行中はワークロードの低下が予想される 移行開始後のソースでの書き込みはターゲットにレプリケートされないため、適合しません
手動での一括移行 必須 必要なし
必要なダウンタイム 未満 詳細
論理レプリケーションの制限 適用できます 該当なし
移行に必要な時間 データベースのサイズと一括移行までの書き込みアクティビティに依存します データベースのサイズに依存します

上記の違いに基づいて、ワークロードに最適なモードを選びます。

オフライン モードの移行に関する考慮事項

オフライン モードの移行プロセスでは、ソース シングル サーバー データベースのダンプと、それに続くフレキシブル サーバー ターゲットでの復元が必要です。

次の表では、さまざまなサイズのデータベースについてオフライン移行の実行にかかるおおよその時間を示します。

Note

移行タスクごとに移行インフラストラクチャをデプロイするために約 15 分を追加します。 タスクごとに最大 8 個のデータベースを移行できます。

データベース サイズ おおよその所要時間 (HH:MM)
1 GB 00:01
5 GB 00:05
10 GB 00:10
50 GB 00:45
100 GB 06:00
500 GB 08:00
1,000 GB 09:30

オンライン モードの移行に関する考慮事項

オンライン モードの移行プロセスでは、シングル サーバー データベースのダンプ、フレキシブル サーバー ターゲットでのそのダンプの復元、進行中の変更のレプリケーションが必要です。 論理デコードを使用して変更データをキャプチャします。

オンライン移行の完了にかかる時間は、ソース サーバーへの受信書き込み数によって異なります。 ソースでの書き込みワークロードが高いほど、データをフレキシブル サーバーにレプリケートするのにかかる時間が長くなります。

オンラインまたはオフライン モードで移行を開始するには、以下の前提条件から開始できます。

移行の前提条件

注意

このツールを使用して移行を開始する前に、このセクションの前提条件の手順を完了することが非常に重要です。

Azure Database Migration Service のサブスクリプションを登録する

  1. Azure portal で、ターゲット サーバーのサブスクリプションに移動します。

    Azure portal のサブスクリプション詳細のスクリーンショット。

  2. 左側のメニューで、[リソース プロバイダー] を選びます。 Microsoft.DataMigration を検索し、[登録] を選びます。

    Azure データ移行サービスの [登録] ボタンのスクリーンショット。

論理レプリケーションを有効にする

ソース サーバーで論理レプリケーションを有効にします

Azure portal での論理レプリケーション サポートのスクリーンショット。

Note

論理レプリケーションを有効にするには、変更を有効にするためにサーバーの再起動が必要です。

Azure Database for PostgreSQL フレキシブル サーバーを作成する

ターゲットとして使用する Azure Database for PostgreSQL フレキシブル サーバーを作成します (まだ作成されていない場合)。

Azure Active Directory (Azure AD) アプリを設定して構成する

Azure Active Directory (Azure AD) アプリを設定して構成します。 Azure AD アプリは、移行ツールの重要なコンポーネントです。 移行ツールがソースとターゲットの両方のサーバーにアクセスするため、ロールベースのアクセス制御に役立ちます。

共同作成者ロールを Azure リソースに割り当てる

ソース サーバー、ターゲット サーバー、移行リソース グループに共同作成者ロールを割り当てます。 ソース/ターゲット サーバーのプライベート アクセスの場合は、対応する VNet にも共同作成者特権を追加します。

単一サーバーの管理者ユーザーのレプリケーション特権を確認する

次のクエリを実行し、単一サーバーの管理者ユーザーにレプリケーション特権があるか確認してください。

   SELECT usename, userepl FROM pg_catalog.pg_user;

単一サーバーの管理者ユーザーの userpl 列の値が true であることを確認します。 false に設定されている場合、単一サーバーで次のクエリを実行し、管理者ユーザーにレプリケーション特権を付与してください。

  ALTER ROLE <adminusername> WITH REPLICATION;

必要な拡張機能を許可リストに登録する

シングル サーバーで PostgreSQL 拡張機能を使用している場合は、次の手順を使用して移行を開始する前に、それをそのフレキシブル サーバーの許可リストに登録する必要があります。

  1. シングル サーバー環境で select コマンドを使用して、使用中のすべての拡張機能を一覧表示します。

    select * from pg_extension
    

    上記のコマンドの出力では、シングル サーバーで現在アクティブな拡張機能の一覧が表示されます

  2. 手順 1 で取得した拡張機能の一覧をフレキシブル サーバーで有効にします。 サイド ウィンドウの [サーバー パラメーター] タブを選択して、"azure.extensions" パラメーターを検索します。 許可する拡張機能を選択し、[保存] をクリックします。

    フレキシブル サーバーの Azure portal での PG 拡張機能サポートのスクリーンショット。

データとスキーマの移行

前提条件を完了したら、次のいずれかの方法を使用してデータとスキーマを移行します。

移行後のアクションと考慮事項

  • シーケンスを使用している場合は、移行が正常に完了した後、ターゲット データベース内のシーケンスの現在の値を、ソース データベースの値と一致するように更新してください。

  • 移行ツールによって作成されるすべてのリソースは、移行が成功、失敗、または取り消されたかどうかに関係なく、自動的にクリーンアップされます。 ユーザーによる操作は必要ありません。

  • 移行が失敗した場合は、異なる名前で新しい移行タスクを作成して、操作をもう一度試すことができます。

  • シングル サーバーに 9 個以上のデータベースがあり、それらをすべて移行する場合は、複数の移行タスクを作成することをお勧めします。 タスクごとに最大 8 個のデータベースを移行できます。

  • 移行によって、ソース サーバーのデータベース ユーザーとロールは移動されません。 これらを手動で作成し、移行後にターゲット サーバーに適用する必要があります。

  • セキュリティ上の理由から、移行の完了後に Azure AD アプリを削除することを強くお勧めします。

  • データの検証が済み、アプリケーションでフレキシブル サーバーをポイントするようにしたら、シングル サーバーの削除を検討できます。

制限事項

サイズ

  • このツールを使用して、最大 1 TB のサイズのデータベースを移行できます。 より大規模なデータベースまたは大量の書き込みワークロードを移行するには、アカウント チームに連絡して Microsoft に問い合わせるか、サポート チケットを提出してください。

  • 1 回の移行の試みで、シングル サーバーからフレキシブル サーバーに最大 8 個のユーザー データベースを移行できます。 それより多くのデータベースを移行する場合は、同じシングル サーバーとフレキシブル サーバーの間に複数の移行を作成できます。

パフォーマンス

  • 移行インフラストラクチャは、移行パフォーマンスを制限する可能性がある 4 仮想コア仮想マシンにデプロイされます。

  • データのサイズや移行モード (オンラインまたはオフライン) に関係なく、実際のデータ移行が始まる前の移行インフラストラクチャのデプロイに、約 10 から 15 分かかります。

レプリケーション

  • この移行ツールでは、PostgreSQL の論理デコード機能を使ってオンライン移行が実行されます。 このデコード機能には次の制限があります。 論理レプリケーションの制限の詳細については、PostgreSQL のドキュメントを参照してください。

    • データ定義言語 (DDL) コマンドはレプリケートされません。

    • シーケンス データはレプリケートされません。

    • 切り捨てコマンドはレプリケートされません。

      この制限を回避するには、TRUNCATE の代わりに DELETE を使用します。 偶発的な TRUNCATE 呼び出しを回避するために、テーブルから TRUNCATE 特権を取り消すことができます。

    • ビュー、具体化されたビュー、パーティション ルート テーブル、外部テーブルは移行されません。

  • 論理デコードでは、シングル サーバー内のリソースが使われます。 移行の間に、シングル サーバーで、ワークロードの削減を検討するか、CPU やメモリ リソースのスケーリングを計画してください。

その他の制限事項

  • この移行ツールを使用すると、シングル サーバー データベースのデータとスキーマのみがフレキシブル サーバーに移行されます。 サーバー パラメーター、接続セキュリティの詳細、ファイアウォール規則、ユーザー、ロール、アクセス許可などの他の機能は移行されません。 つまり、データとスキーマを除くすべてのものは、フレキシブル サーバー ターゲットで手動で構成する必要があります。

  • 移行ツールでは、移行後にフレキシブル サーバー ターゲット内のデータは検証されません。 この検証は手動で行う必要があります。

  • 移行ツールを使用すると、Postgres データベースを含むユーザー データベースのみが移行されます。 システム データベースまたはメンテナンス データベースは移行されません。

  • 移行が失敗した場合、同じ移行タスクをもう一度試みるオプションはありません。 一意の名前で新しい移行タスクを作成する必要があります。

  • 移行ツールには、シングル サーバーの評価は含まれません。

ベスト プラクティス

  • 検出と評価の一環として、移行に役立つ重要なデータの一部として、サーバー SKU、CPU 使用率、ストレージ、データベース サイズ、拡張機能の使用状況を取得します。

  • データベースごとに移行のモードを計画します。 より単純な移行や、小規模なデータベースの場合は、オフライン モードを検討してください。

  • 1 つの移行タスクには似たサイズのデータベースをまとめます。

  • ソース側の負荷と移行の失敗を回避するため、大きなデータベースの移行は、一度に 1 つまたは 2 つのデータベースで実行します。

  • 運用環境に移行する前に、テスト移行を実行します。

    • テスト移行は、アプリケーション テストを含むデータベース移行のすべての側面を確実にカバーするために重要です。

      ベスト プラクティスとしては、テストのために移行全体の実行を始めます。 新しく開始された移行が最小のラグで継続的なレプリケーション (CDC) フェーズに入った後、フレキシブル サーバー ターゲットをプライマリ データベース サーバーにします。 そのターゲットをアプリケーションのテストに使用して、期待されるパフォーマンスと結果を確認します。 より高いバージョンの Postgres に移行する場合は、アプリケーションの互換性をテストします。

    • テストが完了したら、運用データベースを移行できます。 この時点で、運用環境への移行の日時を確定する必要があります。 この日時にはアプリケーションの使用量が少なくなることが理想的です。 関与する必要があるすべての利害関係者が参加でき、準備ができている必要があります。

      運用環境への移行には、厳密な監視が必要です。 オンライン移行の場合、データ損失を防ぐため、一括移行を実行する前にレプリケーションを完了する必要があります。

  • すべての依存アプリケーションを一括移行し、新しいプライマリ データベースにアクセスして、運用環境で使用するためにアプリケーションを開きます。

  • フレキシブル サーバーでのアプリケーションの実行が始まったら、データベースのパフォーマンスをよく監視して、パフォーマンスのチューニングが必要かどうかを確認します。

その他の移行方法

このツールの目的は、ほとんどのワークロードにシームレスな移行エクスペリエンスを提供することです。 ただし、ダンプ/復元または Azure Database Migration Service (DMS) を使用するか、サード パーティ製ツールを使用して移行する他のオプションを選択することもできます。

次のステップ