チュートリアル: 移行サービス プレビューを使用して Google Cloud SQL for PostgreSQL から Azure Database for PostgreSQL にオンラインで移行する

この記事では、PostgreSQL データベースを Google Cloud SQL for PostgreSQL から Azure Database for PostgreSQL にオンラインで移行する方法について説明します。

Azure Database for PostgreSQL の移行サービスは、Azure portal と Azure CLI に統合されたフル マネージド サービスです。 これは、Azure Database for PostgreSQL サーバーへの移行作業を簡略化するように設計されています。

• 前提条件
• 移行する
• 移行を監視する
• カットオーバー
• 完了時に移行を確認する

前提条件

移行を完了するには、次の前提条件が必要です。

Azure Database for PostgreSQL 移行サービスを使用して移行を開始する前に、オンライン移行シナリオ向けに特に設計された次の前提条件を満たすことが重要です。

• ソース バージョンを確認する
• test_decoding のインストール - ソースのセットアップ
• ターゲット セットアップを構成する
• ソースとして CDC を有効にする
• ネットワーク セットアップを構成する
• 拡張機能を有効にする
• サーバー パラメーターを確認する
• ユーザーとロールを確認する

ソース バージョンの確認

ソースの PostgreSQL サーバーのバージョンが 9.5 以降である必要があります。

ソース PostgreSQL のバージョンが 9.5 よりも古い場合は、移行を開始する前に 9.5 以上にアップグレードします。

Note

Azure Database for PostgreSQL の移行サービスでは、ソース Google Cloud SQL for PostgreSQL の IP アドレスを使用した接続がサポートされています。 myproject:myregion:myinstance 形式はサポートされていません。

test_decoding のインストール - ソースのセットアップ

• test_decoding は、論理デコード メカニズムを通じて WAL を受信し、実行された操作のテキスト表現にデコードします。
• Google Cloud SQL for PostgreSQL では、test_decoding プラグインがプレインストールされており、論理レプリケーションの準備ができています。 これにより、論理レプリケーション スロットを簡単に設定して WAL 変更をストリーミングできるため、変更データ キャプチャ (CDC) や外部システムへのレプリケーションなどのユース ケースが容易になります。
• test-decoding プラグインの詳細については、PostgreSQL のドキュメントを参照してください

ターゲット セットアップを構成する

• 移行する前に、Azure Database for PostgreSQL - フレキシブル サーバーを作成する必要があります。
• Azure Database for PostgreSQL - フレキシブル サーバー用にプロビジョニングされた SKU はソースと一致する必要があります。
• 新しい Azure Database for PostgreSQL を作成するには、Azure Database for PostgreSQL の作成に関するページを参照してください

ソースとして CDC を有効にする

• test_decoding 論理デコード プラグインは、変更されたレコードをソースから取り込みます。
• 移行ユーザーが必要なレプリケーション特権を持っていることを確認するには、次の SQL コマンドを実行します。

Alter user <<username>> with REPLICATION;

• Google Cloud Console で Google Cloud SQL PostgreSQL インスタンスに移動し、インスタンス名をクリックして詳細ページを開き、[編集] ボタンをクリックして、[フラグ] セクションで次のフラグを変更します。

  • フラグ cloudsql.logical_decoding = on を設定します。
  • フラグ max_replication_slots を 1 より大きい値に設定します。この値は、移行対象として選んだデータベースの数より大きくする必要があります。
  • フラグ max_wal_senders を 1 より大きい値に設定します。 これは、少なくとも max_replication_slots と同じ値に、インスタンスで既に使用されている送信者の数を加えたものである必要があります。
  • フラグ wal_sender_timeout は、指定されたミリ秒数を超えて非アクティブなレプリケーション接続を終了します。 値を 0 (ゼロ) に設定するとタイムアウト メカニズムが無効になり、移行に有効な設定となります。

• ターゲット フレキシブル サーバーで、オンライン移行でログを格納するストレージが不足しないようにするために、プロビジョニングされたマネージド ディスクを使用して十分なテーブルスペース領域があることを確認します。 これを実現するには、移行期間向けにサーバー パラメーター azure.enable_temp_tablespaces_on_local_ssd を無効にし、移行後に元の状態に復元します。

ネットワーク セットアップを構成する

ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの PostgreSQL サーバーがターゲットの Azure Database for PostgreSQL サーバーと通信できることを確認します。 移行を成功させるには、次のネットワーク構成が不可欠です。

ネットワーク セットアップの詳細については、移行サービスのネットワーク ガイドを参照してください。

拡張機能を有効にする

Azure Database for PostgreSQL の移行サービスを使用して移行を確実に成功させるには、ソース PostgreSQL インスタンスの拡張機能を検証することが必要な場合があります。 拡張機能は、アプリケーションに必要になる可能性がある機能を提供します。 移行プロセスを開始する前に、ソース PostgreSQL インスタンス上の拡張機能を必ず検証してください。

Azure Database for PostgreSQL - フレキシブル サーバーのターゲット インスタンスで、ソース PostgreSQL インスタンスで特定されたサポート対象の拡張機能を有効にします。

詳細については、Azure Database for PostgreSQL の拡張機能に関するページを参照してください。

Note

shared_preload_libraries パラメーターに何らかの変更を加えた場合は、再起動が必要になります。

サーバー パラメーターを確認する

これらのパラメーターはターゲット環境に自動的に移行されないので手動で構成する必要があります。

• Azure portal の [サーバー パラメーター] セクションにアクセスし、それに応じて値を手動で更新して、ソース PostgreSQL データベースのサーバー パラメーター値を Azure Database for PostgreSQL と照合します。

• パラメーターの変更を保存し、必要に応じて Azure Database for PostgreSQL を再起動して新しい構成を適用します。

ユーザーとロールを確認する

Azure Database for PostgreSQL に移行する場合は、ユーザーとロールの移行には手動による介入が必要なので、個別に対処することが不可欠です:

• ユーザーとロールの手動移行: ユーザーとそれに関連付けられているロールは、Azure Database for PostgreSQL に手動で移行する必要があります。 このプロセスを容易にするために、--globals-only フラグ付きの pg_dumpall ユーティリティを使用して、ロールやユーザー アカウントなどのグローバル オブジェクトをエクスポートできます。 <<username>> を実際のユーザー名に、<<filename>> を目的の出力ファイル名に置き換えて、次のコマンドを実行します:

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

• スーパーユーザー ロールの制限: Azure Database for PostgreSQL では、スーパーユーザー ロールはサポートされていません。 そのため、スーパーユーザー特権を持つユーザーは、移行前にこれらの特権を削除する必要があります。 必要に応じてアクセス許可とロールを調整してください。

これらの手順に従うことで、スーパーユーザーの制限に関連する問題が発生することなく、ユーザー アカウントとロールが Azure Database for PostgreSQL に正しく移行することができます。

ターゲットで高可用性 (信頼性) と読み取りレプリカを無効にする

• ターゲット環境で高可用性 (信頼性) と読み取りレプリカを無効にすることが不可欠です。 これらの機能は、移行が完了した後にのみ有効にする必要があります。

• これらのガイドラインに従うと、HA と読み取りレプリカによって導入された変数を追加することなく、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、Azure のデータベース環境の可用性とスケーラビリティを向上させることができます。

移行する

Azure portal または Azure CLI を使用して移行することができます。

ポータル

Azure portal では、シンプルで直感的なウィザードベースのエクスペリエンスが提供され、移行の手順が示されます。 このチュートリアルで説明されている手順に従うと、データベースを Azure Database for PostgreSQL - フレキシブル サーバーにシームレスに転送でき、その強力な機能とスケーラビリティを活用できます。

Azure portal を使用して移行するには、まず移行タスクを構成し、ソースとターゲットに接続してから、移行を実行します。

移行タスクを構成する

移行サービスには、Azure portal に関する簡単なウィザード ベースのエクスペリエンスが付属しています。 開始する方法は次のとおりです。

1. Web ブラウザーを開き、ポータルに移動します。 資格情報を入力してサインインします。 既定のビューはサービス ダッシュボードです。

2. お使いの Azure Database for PostgreSQL フレキシブル サーバーに移動します。

3. フレキシブル サーバーの [概要] タブの左側のメニューで、下にスクロールして [移行] を選びます。

   

4. [作成] ボタンを選択し、Google Cloud SQL for PostgreSQL から Azure Database for PostgreSQL - フレキシブル サーバーに移行します。 初めて移行サービスを使う場合、空のグリッドと最初の移行の開始を促すプロンプトが表示されます。

   

   Azure Database for PostgreSQL ターゲットへの移行を既に作成している場合、グリッドには試行された移行に関する情報が含まれています。

5. [作成] ボタンを選択します。 次に、ウィザードベースの一連のタブを使用して、PostgreSQL ソース インスタンスからこの Azure Database for PostgreSQL ターゲットへの移行を作成します。

セットアップ

最初のタブは [セットアップ] タブで、ユーザーは移行を開始するために移行名やソースの種類などの移行の詳細を指定する必要があります。

• 移行名は、このフレキシブル サーバーへの移行ごとの一意識別子です。 このフィールドで使用できる文字は英数字のみで、ハイフン (-) 以外の特殊文字は使用できません。 名前はハイフンから開始できず、1 つのターゲット サーバーに対して一意である必要があります。 同じフレキシブル サーバー ターゲットへの 2 つの移行の名前を同じにすることはできません。

• ソース サーバーの種類 — PostgreSQL ソースに応じて、対応するソースの種類 (クラウドベースの PostgreSQL サービス、オンプレミスのセットアップ、仮想マシンなど) を選択できます。

• [移行オプション] では、移行をトリガーする前に検証を実行できます。 次のいずれかのオプションを選択できます。

  • [検証] - サーバーとデータベースがターゲットに移行できる状態になっていることを調べます。
  • [移行] - 検証をスキップして移行を始めます。
  • [検証して移行] - 移行をトリガーする前に検証を実行します。 移行は、検証エラーがない場合にのみトリガーされます。

移行を実行する前に移行前検証を実行する場合は、常に [検証] または [検証して移行] オプションを選ぶことをお勧めします。 移行前検証の詳細については、このドキュメントを参照してください。

• 移行モードでは、移行のモードを選択できます。 [オフライン] が既定のオプションです。

[次へ: ソースに接続] ボタンを選びます。

ランタイム サーバーの選択

移行ランタイム サーバーは、移行サービス内の特殊な機能であり、移行中に中間サーバーとして機能するように設計されています。 これは、ターゲット サーバーではない、別の Azure Database for PostgreSQL - フレキシブル サーバー インスタンスですが、プライベート ネットワーク経由でのみアクセスできるソース環境からのデータベースの移行を容易にするために使用されます。

ランタイム サーバーについて詳しくは、移行ランタイム サーバーに関する記事を参照してください。

ソースに接続する

[ソースに接続] タブでは、[セットアップ] タブで選んだソース (データベースのソース) に関連する詳細を入力するよう求められます。

• サーバー名 - ソース PostgreSQL インスタンスのホスト名または IP アドレスを指定します
• ポート - ソース サーバーのポート番号
• サーバー管理者ログイン名 - ソース PostgreSQL サーバーのユーザー名
• パスワード - ソース PostgreSQL サーバーのパスワード
• SSL モード - サポートされている値は prefer と require です。 ソース PostgreSQL サーバーの SSL がオフの場合は、SSLMODE=prefer を使用します。 ソース サーバーの SSL がオンの場合は、SSLMODE=require を使用します。 SSL 値は Postgresql.conf ファイルで決定できます。
• 接続テスト - ターゲットとソース間の接続テストを実行します。 接続が成功すると、ユーザーは次の手順に進むことができます。 それ以外の場合は、ターゲットとソースの間のネットワークの問題を特定し、ソースのユーザー名/パスワードを確認する必要があります。 テスト接続の確立には数分かかります。

テスト接続が成功したら、[次へ: 移行ターゲットの選択] を選びます

移行ターゲットの選択

[移行ターゲットの選択] タブには、サブスクリプション名、リソース グループ、サーバー名、場所、PostgreSQL バージョンなど、フレキシブル サーバー ターゲットのメタデータが表示されます。

• 管理者ユーザー名 - ターゲット PostgreSQL サーバーの管理者ユーザー名
• パスワード - ターゲット PostgreSQL サーバーのパスワード
• カスタム FQDN/IP (省略可能): カスタム FQDN/IP フィールドは省略可能であり、ターゲットがカスタム DNS サーバーの背後にある場合、またはカスタム DNS 名前空間がある場合に使用でき、特定の FQDN または IP アドレス経由でのみアクセスできるようになります。 たとえば、カスタム DNS サーバーに DNS ゾーン postgres.database.azure.com が含まれる場合、またはこのゾーンのクエリを 168.63.129.16 に転送し、FQDN が Azure パブリック DNS ゾーンまたはプライベート DNS ゾーンで解決される場合、これには、flexibleserver.example.com や 198.1.0.2、または flexibleserver.postgres.database.azure.com のような PostgreSQL FQDN などのエントリを含めることができます。
• 接続テスト - ターゲットとソース間の接続テストを実行します。 接続が成功すると、ユーザーは次の手順に進むことができます。 それ以外の場合は、ターゲットとソースの間のネットワークの問題を特定し、ターゲットのユーザー名/パスワードを確認する必要があります。 テスト接続では、ターゲットとソースの間の接続が確立されるまでに数分かかります。

テスト接続が成功したら、[次へ: 移行のデータベースの選択] を選択します

移行するデータベースを選択する

このタブでは、[セットアップ] タブで選んだソース サーバー内のユーザー データベースの一覧が表示されます。1 回の移行試行で最大 8 つのデータベースを選択して移行できます。 ユーザー データベースが 8 つを超える場合は、ソース サーバーとターゲット サーバーの間で、次のデータベース セットに対して移行プロセスが繰り返されます。

データベースを選んだ後、[次へ: 概要] を選びます

まとめ

[概要] タブには、検証または移行を作成するためのすべてのソースとターゲットの詳細がまとめられています。 詳細を確認して、[開始] ボタンを選びます。

移行を監視する

[開始] ボタンを選ぶと、検証または移行の作成が成功したことを示す通知が数秒で表示されます。 その後、フレキシブル サーバーの [移行] ページに自動的にリダイレクトされ、最近作成された検証または移行の新しいエントリが表示されます。

移行を表示するグリッドには、[名前]、[状態]、[移行モード]、[移行の種類]、[ソース サーバー]、[ソース サーバーの種類]、[データベース]、[期間]、[開始時刻] の列があります。 エントリは、開始日時の降順に表示され、最新のエントリが先頭になります。 [最新の情報に更新] ボタンを使って、検証または移行の状態を更新できます。 グリッドで移行の名前を選んで、関連する詳細を表示します。

検証または移行が作成されると、InProgress 状態および PerformingPreRequisiteSteps サブ状態に推移します。 ワークフローで移行インフラストラクチャとネットワーク接続が設定されるまで、2 から 3 分かかります。

移行の詳細

[セットアップ] タブで、移行オプションとして [検証して移行] を選びました。 このシナリオでは、最初に検証が実行されてから移行が開始されます。 PerformingPreRequisiteSteps サブ状態が完了すると、ワークフローは Validation in Progress サブ状態になります。

• 検証にエラーがある場合、移行は Failed 状態になります。
• 検証がエラーなしで完了すると、移行が開始され、ワークフローは Migrating Data サブ状態に推移します。

検証と移行の結果は、インスタンスおよびデータベース レベルで確認できます。

移行の状態には、次のものがあります。

移行の状態

State	説明
InProgress	移行インフラストラクチャのセットアップが進行中、または実際のデータ移行が進行中です。
取り消されました	移行が取り消されたか削除されました。
Failed	移行は失敗しました。
Validation Failed	検証が失敗しました。
Succeeded	移行が成功し、完了しました。
WaitingForUserAction	オンライン移行にのみ適用されます。 ユーザー アクションがカットオーバーを実行するのを待機しています。

移行サブ状態

下位状態	説明
PerformingPreRequisiteSteps	データ移行のためのインフラストラクチャのセットアップが進行中です。
Validation in Progress	検証を実行中です。
MigratingData	データ移行が進行中です。
CompletingMigration	移行は完了の最終段階です。
完了	移行が完了しました。
Failed	移行は失敗しました。

検証のサブ状態

下位状態	説明
Failed	検証が失敗しました。
Succeeded	検証が成功しました。
警告	検証で警告が発生しています。

カットオーバー

移行と検証して移行の両方がある場合、オンライン移行を完了するには別の手順が必要で、ユーザーは一括移行アクションを実行する必要があります。 基本データのコピーまたは複製が完了した後、移行は WaitingForUserAction 状態と WaitingForCutoverTrigger サブ状態になります。 この状態では、ユーザーは移行を選ぶことでポータルから一括移行をトリガーできます。

一括移行を開始する前に、次のことを確認するのが重要です。

• ソースへの書き込みは停止されています - Latency は 0 または 0 に近い値です。 Latency 情報は、以下に示す移行の詳細画面から取得できます。

  

• latency が 0 または 0 に近い値まで低下しています

• latency 値は、ターゲットが最後にソースと同期した時期を示します。 この時点で、ソースへの書き込みを停止し、一括移行を開始することができます。 ソースに大量のトラフィックがある場合は、最初に書き込みを停止して、Latency が 0 に近づくようにしてから一括移行を開始することをお勧めします。 一括移行操作では、ソースからターゲットへの保留中のすべての変更が適用され、そして移行が完了します。 Latency, がゼロ以外の場合でも "一括移行" をトリガーすると、レプリケーションはその時点までで停止します。 一括移行ポイントがターゲットに適用されるまで、すべてのデータはソースにあります。 たとえば、一括移行の時点で待機時間が 15 分の場合、過去 15 分間に変更されたすべてのデータがターゲットに適用されます。 時間は、過去 15 分間に発生した変更のバックログによって異なります。 そのため、一括移行をトリガーする前に、待機時間をゼロまたはゼロに近い値にすることをお勧めします。

  

• Migrating Data サブ状態または一括移行 (オンライン移行) が正常に完了すると、移行は Succeeded 状態に推移します。 Migrating Data サブ状態で問題が発生した場合、移行は Failed 状態に移行します。

  

CLI

この記事では、PostgreSQL データベースを Google Cloud SQL for PostgreSQL から Azure Database for PostgreSQL に移行するための Azure CLI の使用について説明します。 Azure CLI には、データベースの移行など、さまざまなタスクを実行できる強力で柔軟なコマンド ライン インターフェイスが用意されています。 この記事で説明されている手順に従うと、データベースを Azure にシームレスに転送でき、その強力な機能とスケーラビリティを活用できます。

移行サービスでの Azure CLI の詳細については、移行サービス用に Azure CLI を設定する方法に関するページを参照してください。

CLI がインストールされたら、コマンド プロンプトを開き、以下のコマンドを使用して自分の Azure アカウントにログインします。

az login

移行タスクを構成する

移行を開始するには、移行の詳細を含む JSON ファイルを作成する必要があります。 この JSON ファイルには、次の情報が含まれています:

• 以下のプレースホルダー << >> を JSON 行で編集し、CLI が呼び出されている <<filename>>.json としてローカル コンピューター内にこれらを格納します。 このチュートリアルでは、ファイルを C:\migration-CLI\migration_body.json に保存しました

{
	"properties": {
		"SourceDBServerResourceId": "<<source hostname or IP address>>:<<port>>@<<username>>",
		"SecretParameters": {
			"AdminCredentials": {
				"SourceServerPassword": "<<Source Password>>",
				"TargetServerPassword": "<<Target Password>>"
			},
			"targetServerUserName": "<<Target username>>"
		},
		"DBsToMigrate": "<<comma separated list of databases in a array like - ["ticketdb","timedb","inventorydb"]>>",
		"OverwriteDBsInTarget": "true",
		"sourceType": "GCP_CloudSQL",
		"sslMode": "Require"
	}
}

• 次のコマンドを実行して、移行が実行されているかどうかを確認します。 移行名は、Azure Database for PostgreSQL フレキシブル サーバー ターゲット内の移行全体で一意です。

  az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

• 上記の手順では、移行は実行されないため、次のコマンドを実行して新しい移行を開始します

  az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

• 次のコマンドを実行して、前の手順で移行状態を開始します。 移行名を指定して、移行の状態を確認できます

  az postgres flexible-server migration show --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

• 移行の進行状況の状態が Azure CLI に表示されます。

• Azure portal で Azure Database for PostgreSQL フレキシブル サーバーの状態を確認することもできます。

• cancel コマンドを使用して、進行中の移行の試行を取り消すことができます。 このコマンドは、特定の移行の試行を停止し、ターゲット サーバー上でのすべての変更をロールバックします。 移行を削除する CLI コマンドを次に示します。

  az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

カットオーバー

• オンライン移行で基本データの移行が完了すると、移行タスクは WaitingForCutoverTrigger サブ状態に推移します。 この状態では、ユーザーは以下のコマンドを使用して CLI 経由で一括移行をトリガーできます。 ポータルから移行グリッド内の移行名を選択することで、一括移行をトリガーすることもできます。

• Azure portal から一括移行を開始することもできます。

  az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --cutover
  

完了時に移行を確認する

データベースが完了したら、ソースとターゲット間のデータを手動で検証し、ターゲット データベース内のすべてのオブジェクトが正常に作成されたことを確認する必要があります。

移行後、次のタスクを実行できます:

• フレキシブル サーバー上のデータを確認し、ソース インスタンスの正確なコピーであることを確認します。
• 検証後、必要に応じてフレキシブル サーバーで高可用性オプションを有効にします。
• アプリケーションのニーズに合わせてフレキシブル サーバーの SKU を変更します。 この変更には、データベース サーバーの再起動が必要です。
• ソース インスタンスの既定値からサーバー パラメーターを変更する場合は、フレキシブル サーバーでこれらのサーバー パラメーターの値をコピーします。
• タグ、アラート、ファイアウォール規則 (該当する場合) などの他のサーバー設定をソース インスタンスからフレキシブル サーバーにコピーします。
• 接続文字列がフレキシブル サーバーをポイントするように、アプリケーションに変更を加えます。
• データベースのパフォーマンスを厳密に監視して、パフォーマンス チューニングが必要かどうかを確認します。

関連するコンテンツ

• Google Cloud SQL for PostgreSQL からオフラインで移行する
• 移行サービス
• オンプレミスと Azure VM からの移行
• 既知の問題と制限事項