Azure Database for PostgreSQL の移行サービスを使用して移行を開始する前に、オフライン移行シナリオに適用される次の前提条件を満たす必要があります。
ソース PostgreSQL のバージョンは >= 9.5
である必要があります。 ソース PostgreSQL のバージョンが 9.5
より小さい場合は、移行前にソース PostgreSQL のバージョンを 9.5
以上にアップグレードします。
移行プロセスを開始する前に、Azure Database for PostgreSQL フレキシブル サーバーを Azure にデプロイし、適切に構成する必要があります。
Azure Database for PostgreSQL 用に選択された SKU は、互換性と適切なパフォーマンスを確保するために、ソース データベースの仕様に対応している必要があります。
新しい Azure Database for PostgreSQL を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。
PostgreSQL のバージョン (メジャーまたはマイナー) 間で移行する場合、リリースノートで破壊的変更の可能性を確認し、データベースとアプリケーション間の互換性を確保してください。
ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの PostgreSQL サーバーがターゲットの Azure Database for PostgreSQL サーバーと通信できることを確認します。 移行を成功させるには、次のネットワーク構成が不可欠です。
ネットワーク セットアップの詳細については、移行サービスのネットワーク ガイドを参照してください。
Azure Database for PostgreSQL の移行サービスを使用して移行を確実に成功させるには、ソース PostgreSQL インスタンスの拡張機能を検証することが必要な場合があります。 拡張機能は、アプリケーションに必要になる可能性がある機能を提供します。 移行プロセスを開始する前に、ソース PostgreSQL インスタンス上の拡張機能を必ず検証してください。
Azure Database for PostgreSQL - フレキシブル サーバーのターゲット インスタンスで、ソース PostgreSQL インスタンスで特定されたサポート対象の拡張機能を有効にします。
詳細については、Azure Database for PostgreSQL の拡張機能に関するページを参照してください。
注意
shared_preload_libraries
パラメーターに変更を加えた場合は、再起動が必要です。
これらのパラメーターはターゲット環境に自動的に移行されないので手動で構成する必要があります。
ソース PostgreSQL データベースのサーバー パラメーター値を Azure Database for PostgreSQL と照合します。そのためには、Azure portal の [サーバー パラメーター] セクションにアクセスし、手動で値を適宜更新します。
パラメーターの変更を保存し、必要に応じて Azure Database for PostgreSQL フレキシブル サーバーを再起動して新しい構成を適用します。
ターゲットで高可用性 (信頼性) と読み取りレプリカを無効にする
ターゲット環境で高可用性 (信頼性) と読み取りレプリカを無効にすることが不可欠です。 これらの機能は、移行が完了した後にのみ有効にする必要があります。
これらのガイドラインに従うと、高可用性と読み取りレプリカによって導入された変数を追加することなく、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、Azure のデータベース環境の可用性とスケーラビリティを向上させることができます。
Azure Database for PostgreSQL フレキシブル サーバーを構成する
移行サービスには、Azure portal に関する簡単なウィザード ベースのエクスペリエンスが付属しています。 開始する方法は次のとおりです。
Web ブラウザーを開き、ポータルに移動します。 サインインするには、資格情報を入力します。 既定のビューはサービス ダッシュボードです。
お使いの Azure Database for PostgreSQL フレキシブル サーバーに移動します。
フレキシブル サーバーの [概要] タブの左側のメニューで、下にスクロールして [移行] を選びます。
[作成] ボタンを選んで、単一サーバーからフレキシブル サーバーへの移行を始めます。 初めて移行サービスを使う場合、空のグリッドと最初の移行の開始を促すプロンプトが表示されます。
フレキシブル サーバー ターゲットへの移行を既に作成してある場合は、単一サーバーからこのターゲットに対して試みられた移行に関する情報がグリッドに含まれます。
ウィザードベースの一連のタブを使用して、考えられるさまざまなソースからこのフレキシブル サーバー ターゲットへの移行を作成します。 既定では、[ソース サーバーの種類] は [Azure Database for PostgreSQL 単一サーバー] に設定されています。このシナリオでは、これを取り上げます。
または、Azure Database for PostgreSQL 単一サーバーから移行プロセスを開始することもできます。
Web ブラウザーを開き、ポータルに移動します。 サインインするには、資格情報を入力する必要があります。 既定のビューはサービス ダッシュボードです。
シングル サーバーを選択すると、概要タブで移行に関連するバナーを確認できます。[今すぐ移行する] を選択して開始します。
2 つのオプションがあるページが表示されます。 フレキシブル サーバーを既に作成してあり、それをターゲットとして使う場合は、[既存から選択] を選んで、対応する [サブスクリプション]、[リソース グループ]、[サーバー名] の詳細を選択します。 選択が完了したら、[移行ウィザードに移動] を選択し、[セットアップ] セクションの手順に進みます。
新しいフレキシブル サーバーを作成することを選んだ場合は、[新規作成] を選択し、[作成ウィザードに移動] を選択します。 このアクションにより、フレキシブル サーバーの作成プロセスが実行され、フレキシブル サーバーがデプロイされます。
フレキシブル サーバーをデプロイした後、「移行タスクを構成する」のステップ 3 から 5 を行います。
最初のタブは [セットアップ] です。 これを行っていなかった場合は、移行を開始する前に、「Azure Database for PostgreSQL フレキシブル サーバーを構成する」の説明に従って、必要な拡張機能を許可リストに載せてください。
移行名は、このフレキシブル サーバーへの移行ごとの一意識別子です。 このフィールドで使用できる文字は英数字のみで、アンダースコア (_) とハイフン (-) 以外の特殊文字は使用できません。 名前は英数字で始まる必要があります。 同じフレキシブル サーバー ターゲットへの 2 つの移行の名前を同じにすることはできないため、名前はターゲット サーバーに対して一意である必要もあります。
[ソース サーバーの種類] はソースを示します。 この場合は、Azure Database for PostgreSQL 単一サーバーです
[移行オプション] では、移行をトリガーする前に検証を実行できます。 次のいずれかのオプションを選択できます。
- [検証] - サーバーとデータベースがターゲットに移行できる状態になっていることを調べます。
- [移行] - 検証をスキップして移行を始めます。
- [検証と移行] - 移行をトリガーする前に検証を実行します。 検証エラーがない場合にのみ、移行がトリガーされます。
[検証] または [検証と移行] オプションを選び、移行を実行する前に移行前の検証を実行することを常にお勧めします。
[移行モード] では、オンラインとオフラインのどちらかの移行を選択できます。ここでは、[オフライン] に設定する必要があります。
[次: ランタイム サーバーの選択] ボタンを選択します。
移行ランタイム サーバーは、Azure Database for PostgreSQL の移行サービス内の特殊な機能であり、移行中に中間サーバーとして機能するように設計されています。 これは、ターゲット サーバーではない、別の Azure Database for PostgreSQL - フレキシブル サーバー インスタンスですが、プライベート ネットワーク経由でのみアクセスできるソース環境からのデータベースの移行を容易にするために使用されます。
ランタイム サーバーについて詳しくは、移行ランタイム サーバーに関する記事を参照してください。
[次へ: ソースに接続] ボタンを選択します。
[ソース] セクションでは、データベースのソースである単一サーバーに関連する詳細の指定を求められます。
[サブスクリプション] と [リソース グループ] を選ぶと、サーバー名のドロップダウン リストに、リージョン全体のそのリソース グループの下にシングル サーバーが表示されます。 データベースの移行元のソースを選びます。 単一サーバーから同じリージョン内のターゲットのフレキシブル サーバーに、データベースを移行できます。 リージョン間の移行は、インド、中国、UAE のサーバーについてのみ有効になります。
単一サーバー ソースを選ぶと、[場所] と [PostgreSQL バージョン] のボックスが自動的に設定されます。 データベースを正常に移行するために移行サービスで必要となるため、管理者ロールの資格情報を必ず指定してください。
[カスタム FQDN/IP] フィールドは省略可能であり、ソースがカスタム DNS サーバーの背後にある場合、またはソースにカスタム DNS 名前空間がある場合に使用できます。これにより、特定の FQDN または IP アドレス経由でのみソースにアクセスできるようにすることができます。 たとえば、カスタム DNS サーバーに DNS ゾーン postgres.database.azure.com
が含まれている場合、またはサーバーによってこのゾーンのクエリが 168.63.129.16
に転送される場合、このフィールドには singleserver.example.com
や 198.1.0.2
などのエントリ、または singleserver.postgres.database.azure.com
のような PostgreSQL FQDN を含めることができます。その場合、FQDN は、Azure パブリックまたはプライベート DNS ゾーンで解決されます。
すべてのフィールドに入力したら、[ソースに接続する] リンクを選びます。 これにより、入力されたソース サーバーの詳細が正しく、ソース サーバーに到達可能であることが検証されます。
[次: 移行ターゲットを選択] ボタンを選択して続行します。
[移行ターゲットの選択] セクションには、[サブスクリプション]、[リソース グループ]、[サーバー名]、[場所]、[PostgreSQL バージョン] など、フレキシブル サーバー ターゲットのメタデータが表示されます。
[カスタム FQDN/IP] フィールドは省略可能であり、ターゲットがカスタム DNS サーバーの背後にある場合、またはターゲットにカスタム DNS 名前空間がある場合に使用できます。これにより、特定の FQDN または IP アドレス経由でのみターゲットにアクセスできるようにすることができます。 たとえば、カスタム DNS サーバーに DNS ゾーン postgres.database.azure.com
が含まれている場合、またはサーバーによってこのゾーンのクエリが 168.63.129.16
に転送される場合、このフィールドには flexibleserver.example.com
や 198.1.0.2
などのエントリ、または flexibleserver.postgres.database.azure.com
のような PostgreSQL FQDN を含めることができます。その場合、FQDN は、Azure パブリックまたはプライベート DNS ゾーンで解決されます。
[認証方法] とすべての認証関連フィールドの適切な値を選択します。 指定した ID はターゲット サーバーの管理者ユーザーのものであることが必要です。 必要なすべての情報を入力した後、[ターゲットに接続] リンクを選択します。 これにより、入力されたターゲット サーバーの詳細が正しく、ターゲット サーバーに到達可能であることが検証されます。
[次: 移行するデータベースの選択] ボタンを選択して、移行するデータベースを選択します。
このタブには、単一サーバー内のユーザー データベースの一覧が表示されます。 1 回の移行試行で最大 8 つのデータベースを選択して移行できます。 ユーザー データベースが 8 つを超える場合は、ソース サーバーとターゲット サーバーの間で、次のデータベース セットに対して移行プロセスが繰り返されます。 ターゲット サーバー上に存在する正確に同じ名前の選択したデータベースが上書きされます。
[次: サマリー] ボタンを選択して詳細を確認します。
[概要] タブには、検証または移行の作成に関するすべての詳細がまとめられています。 詳細を確認し、[検証して移行の開始] ボタンを選択します。
移行を開始すると、検証または移行の作成が成功したことを示す通知が表示されます。 フレキシブル サーバーの [移行] ページに、自動的にリダイレクトされます。 ここには、最近作成された検証または移行に関する新しいエントリがあります。
移行を表示するグリッドには、[名前]、[状態]、[移行モード]、[移行の種類]、[ソース サーバー]、[ソース サーバーの種類]、[データベース]、[開始時刻]、[実行時間] の列があります。 エントリは、開始日時の降順に表示され、最新のエントリが先頭に表示されます。
[最新の情報に更新] ボタンを使って、検証または移行の状態を更新できます。
グリッドで特定の移行の名前を選んで、関連する詳細を表示することもできます。
作成された検証または移行は、InProgress 状態と PerformingPreRequisiteSteps サブ状態になります。 ワークフローで移行インフラストラクチャとネットワーク接続が設定されるまで、2 から 3 分かかります。
移行の各オプションについて、移行を監視する方法を見てみましょう。
PerformingPreRequisiteSteps サブ状態が完了すると、検証は Validation in Progress サブ状態になります。このサブ状態では、ソース サーバーとターゲット サーバーで移行の準備状況を評価するチェックが行われます。
すべての検証が Succeeded または Warning 状態の場合、検証は Succeeded 状態になります。
検証グリッドには次の情報があります
- [インスタンスの検証の詳細] と [データベースの検証の詳細] セクション: 移行の準備状況の確認に使われる検証ルールを表します。
- [検証名] - 特定の各検証規則の名前。
- [検証状態] - 各規則の結果を表し、3 つの値のいずれかになります。
- [成功] - エラーが見つからなかった場合。
- [失敗] - 検証エラーがある場合。
- [警告] - 検証の警告がある場合。
- [実行時間] - 検証操作にかかった時間。
- [開始時刻 (UTC)] と [終了時刻 (UTC)] - 検証操作の UTC での開始時刻と終了時刻。
検証中にエラーが発生した場合、[検証状態] は [失敗] 状態になります。 失敗した [検証名] または [データベース名] の検証を選ぶと、ファンアウト ペインに、詳細と、このエラーを回避するために実行する必要がある是正措置が表示されます。
PerformingPreRequisiteSteps というサブ状態が完了すると、移行は、データベースの複製/コピーが行われる [データを移行しています] のサブ状態に移ります。 移行が完了するまでの時間は、移行するデータベースのサイズと形状によって異なります。 データがすべてのテーブルにほぼ均等に分散されている場合、移行はすぐに完了します。 テーブル サイズにスキューがあると、相対的に長い時間がかかります。
移行中のいずれかのデータベースを選ぶと、ファンアウト ペインが表示されます。 すべてのテーブル数 (コピー済み、キュー済み、コピー中、エラー) と、データベースの移行状態が表示されます。
MigratingData 状態が正常に完了すると、移行は Succeeded 状態に移ります。 Migrating Data 状態で問題が発生した場合、移行は Failed 状態に移ります。
移行が Succeeded 状態になると、単一サーバーからフレキシブル サーバー ターゲットへのスキーマとデータの移行が完了します。 ページを更新して進行状況を確認できます。
このオプションでは、最初に検証が実行されてから移行が開始されます。 PerformingPreRequisiteSteps サブ状態が完了すると、ワークフローは Validation in Progress サブ状態になります。
- 検証にエラーがある場合、移行は Failed 状態になります。
- 検証がエラーなしで完了すると、移行が開始され、ワークフローは Migrating Data のサブストレートに移ります。
操作が完了したら、[検証と移行] の結果を表示できます。
Azure Database for PostgreSQL の移行サービスを使用して移行を開始する前に、オフライン移行シナリオに適用される次の前提条件を満たすことが不可欠です。
ソース PostgreSQL のバージョンは >= 9.5
である必要があります。 ソース PostgreSQL のバージョンが 9.5
より小さい場合は、移行前にソース PostgreSQL のバージョンを 9.5
以上にアップグレードします。
オンライン移行の場合、ソース PostgreSQL サーバーのレプリケーション設定で、レプリケーションのサポートを [論理] に設定する必要があります。 さらに、サーバー パラメータ max_wal_senders
と max_replication_slots
は、移行する必要があるデータベースの数より大きい値になっている必要があります。 パラメーターは、Azure portal の [設定] > [サーバー パラメーター] で設定するか、次のコマンドを使ってコマンド ラインで構成できます。
- ALTER SYSTEM SET wal_level = logical;
- ALTER SYSTEM SET max_wal_senders =
number of databases to migrate
+ 1;
- ALTER SYSTEM SET max_replication_slots =
number of databases to migrate
+ 1;
実行時間の長いトランザクションがないことを確認します。 実行時間の長いトランザクションがあると、レプリケーション スロットを作成できません。 実行時間の長いトランザクションがすべてコミットまたはロールバックされた場合、レプリケーション スロットの作成は成功します。 オンライン移行のすべての前提条件が整った後、ソース PostgreSQL サーバーを再起動する必要があります。
注意
Azure Database for PostgreSQL 単一サーバーでのオンライン移行の場合、Azure portal の単一サーバー ページのレプリケーション設定で、Azure レプリケーションのサポートを論理に設定します。
オンライン移行でログを格納するストレージが不足しないようにするには、プロビジョニングされたマネージド ディスクを使用して十分なテーブルスペース領域があることを確認します。 これを実現するには、移行中にフレキシブル サーバーでサーバー パラメーター azure.enable_temp_tablespaces_on_local_ssd
を無効にし、移行後に元の状態に復元します。
移行する前に、Azure Database for PostgreSQL を Azure で設定する必要があります。
Azure Database for PostgreSQL 用に選択された SKU は、互換性と適切なパフォーマンスを確保するために、ソース データベースの仕様に対応している必要があります。
新しい Azure Database for PostgreSQL を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。
サーバー パラメータ max_replication_slots
は、移行する必要があるデータベースの数より大きい値になっている必要があります。 それは、Azure portal の [設定] > [サーバー パラメーター] で設定するか、次のコマンドを使ってコマンド ラインで構成できます。
ALTER SYSTEM SET max_replication_slots = number of databases to migrate
+ 1;
PostgreSQL のバージョン (メジャーまたはマイナー) 間で移行する場合、リリースノートで破壊的変更の可能性を確認し、データベースとアプリケーション間の互換性を確保してください。
ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの PostgreSQL サーバーがターゲットの Azure Database for PostgreSQL サーバーと通信できることを確認します。 移行を成功させるには、次のネットワーク構成が不可欠です。
ネットワーク セットアップの詳細については、移行サービスのネットワーク ガイドを参照してください。
Azure Database for PostgreSQL の移行サービスを使用して移行を確実に成功させるには、ソース PostgreSQL インスタンスの拡張機能を検証することが必要な場合があります。 拡張機能は、アプリケーションに必要になる可能性がある機能を提供します。 移行プロセスを開始する前に、ソース PostgreSQL インスタンス上の拡張機能を必ず検証してください。
Azure Database for PostgreSQL - フレキシブル サーバーのターゲット インスタンスで、ソース PostgreSQL インスタンスで特定されたサポート対象の拡張機能を有効にします。
詳細については、Azure Database for PostgreSQL の拡張機能に関するページを参照してください。
注意
shared_preload_libraries
パラメーターに変更を加えた場合は、再起動が必要です。
これらのパラメーターはターゲット環境に自動的に移行されないので手動で構成する必要があります。
ターゲットで高可用性 (信頼性) と読み取りレプリカを無効にする
ターゲット環境で高可用性 (信頼性) と読み取りレプリカを無効にすることが不可欠です。 これらの機能は、移行が完了した後にのみ有効にする必要があります。
これらのガイドラインに従うと、HA と読み取りレプリカによって導入された変数を追加することなく、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、Azure のデータベース環境の可用性とスケーラビリティを向上させることができます。
注意
オンライン移行には、こちらに記載されている特定の制限が適用されます。 データベースがオンライン移行の実行に準拠していることを確認してください。
Azure Database for PostgreSQL フレキシブル サーバーを構成する
移行サービスには、Azure portal に関する簡単なウィザード ベースのエクスペリエンスが付属しています。 開始する方法は次のとおりです。
Web ブラウザーを開き、ポータルに移動します。 サインインするには、資格情報を入力します。 既定のビューはサービス ダッシュボードです。
お使いの Azure Database for PostgreSQL フレキシブル サーバーに移動します。
フレキシブル サーバーの [概要] タブの左側のメニューで、下にスクロールして [移行] を選びます。
[作成] ボタンを選んで、単一サーバーからフレキシブル サーバーへの移行を始めます。 初めて移行サービスを使う場合、空のグリッドと最初の移行の開始を促すプロンプトが表示されます。
フレキシブル サーバー ターゲットへの移行を既に作成してある場合は、単一サーバーからこのターゲットに対して試みられた移行に関する情報がグリッドに含まれます。
ウィザードベースの一連のタブを使用して、考えられるさまざまなソースからこのフレキシブル サーバー ターゲットへの移行を作成します。 既定では、[ソース サーバーの種類] は [Azure Database for PostgreSQL 単一サーバー] に設定されています。このシナリオでは、これを取り上げます。
または、Azure Database for PostgreSQL 単一サーバーから移行プロセスを開始することもできます。
Web ブラウザーを開き、ポータルに移動します。 サインインするには、資格情報を入力する必要があります。 既定のビューはサービス ダッシュボードです。
シングル サーバーを選択すると、概要タブで移行に関連するバナーを確認できます。[今すぐ移行する] を選択して開始します。
2 つのオプションがあるページが表示されます。 フレキシブル サーバーを既に作成してあり、それをターゲットとして使う場合は、[既存から選択] を選んで、対応する [サブスクリプション]、[リソース グループ]、[サーバー名] の詳細を選択します。 選択が完了したら、[移行ウィザードに移動] を選択し、[セットアップ] セクションの手順に進みます。
新しいフレキシブル サーバーを作成することを選んだ場合は、[新規作成] を選択し、[作成ウィザードに移動] を選択します。 このアクションにより、フレキシブル サーバーの作成プロセスが実行され、フレキシブル サーバーがデプロイされます。
フレキシブル サーバーをデプロイした後、「移行タスクを構成する」のステップ 3 から 5 を行います。
最初のタブは [セットアップ] です。 これを行っていなかった場合は、移行を開始する前に、「Azure Database for PostgreSQL フレキシブル サーバーを構成する」の説明に従って、必要な拡張機能を許可リストに載せてください。
移行名は、このフレキシブル サーバーへの移行ごとの一意識別子です。 このフィールドで使用できる文字は英数字のみで、アンダースコア (_) とハイフン (-) 以外の特殊文字は使用できません。 名前は英数字で始まる必要があります。 同じフレキシブル サーバー ターゲットへの 2 つの移行の名前を同じにすることはできないため、名前はターゲット サーバーに対して一意である必要もあります。
[ソース サーバーの種類] はソースを示します。 この場合は、Azure Database for PostgreSQL 単一サーバーです
[移行オプション] では、移行をトリガーする前に検証を実行できます。 次のいずれかのオプションを選択できます。
- [検証] - サーバーとデータベースがターゲットに移行できる状態になっていることを調べます。
- [移行] - 検証をスキップして移行を始めます。
- [検証と移行] - 移行をトリガーする前に検証を実行します。 検証エラーがない場合にのみ、移行がトリガーされます。
[検証] または [検証と移行] オプションを選び、移行を実行する前に移行前の検証を実行することを常にお勧めします。
[移行モード] では、オンラインとオフラインのどちらかの移行を選択できます。ここでは、[オンライン] に設定する必要があります。
[オンライン] 移行モードを選ぶ場合は、移行元の単一サーバーで論理レプリケーションが有効になっている必要があります。 有効にされていない場合は、移行サービスによって移行元の単一サーバーで論理レプリケーションが自動的に有効にされます。 また、単一サーバーのリソース メニューの [設定] で [レプリケーション] 項目を選択し、[Azure レプリケーションのサポート] を [論理] に設定することで、手動でレプリケーションを設定することもできます。 どちらの方法でも、ソースの単一サーバーを再起動します。
[次: ランタイム サーバーの選択] ボタンを選択します。
移行ランタイム サーバーは、Azure Database for PostgreSQL の移行サービス内の特殊な機能であり、移行中に中間サーバーとして機能するように設計されています。 これは、ターゲット サーバーではない、別の Azure Database for PostgreSQL - フレキシブル サーバー インスタンスですが、プライベート ネットワーク経由でのみアクセスできるソース環境からのデータベースの移行を容易にするために使用されます。
ランタイム サーバーについて詳しくは、移行ランタイム サーバーに関する記事を参照してください。
[次へ: ソースに接続] ボタンを選択します。
[ソース] セクションでは、データベースのソースである単一サーバーに関連する詳細の指定を求められます。
[サブスクリプション] と [リソース グループ] を選ぶと、サーバー名のドロップダウン リストに、リージョン全体のそのリソース グループの下にシングル サーバーが表示されます。 データベースの移行元のソースを選びます。 単一サーバーから同じリージョン内のターゲットのフレキシブル サーバーに、データベースを移行できます。 リージョン間の移行は、インド、中国、UAE のサーバーについてのみ有効になります。
単一サーバー ソースを選ぶと、[場所] と [PostgreSQL バージョン] のボックスが自動的に設定されます。 データベースを正常に移行するために移行サービスで必要となるため、管理者ロールの資格情報を必ず指定してください。
すべてのフィールドに入力したら、[ソースに接続する] リンクを選びます。 これにより、入力されたソース サーバーの詳細が正しく、ソース サーバーに到達可能であることが検証されます。
[次: 移行ターゲットを選択] ボタンを選択して続行します。
[移行ターゲットの選択] セクションには、[サブスクリプション]、[リソース グループ]、[サーバー名]、[場所]、[PostgreSQL バージョン] など、フレキシブル サーバー ターゲットのメタデータが表示されます。
[認証方法] とすべての認証関連フィールドの適切な値を選択します。 指定した ID はターゲット サーバーの管理者ユーザーのものであることが必要です。 必要なすべての情報を入力した後、[ターゲットに接続] リンクを選択します。 これにより、入力されたターゲット サーバーの詳細が正しく、ターゲット サーバーに到達可能であることが検証されます。
[次: 移行するデータベースの選択] ボタンを選択して、移行するデータベースを選択します。
このタブには、単一サーバー内のユーザー データベースの一覧が表示されます。 1 回の移行試行で最大 8 つのデータベースを選択して移行できます。 ユーザー データベースが 8 つを超える場合は、ソース サーバーとターゲット サーバーの間で、次のデータベース セットに対して移行プロセスが繰り返されます。 ターゲット サーバー上に存在する正確に同じ名前の選択したデータベースが上書きされます。
[次: サマリー] ボタンを選択して詳細を確認します。
[概要] タブには、検証または移行の作成に関するすべての詳細がまとめられています。 詳細を確認し、[検証して移行の開始] ボタンを選択します。
移行を開始すると、検証または移行の作成が成功したことを示す通知が表示されます。 フレキシブル サーバーの [移行] ページに、自動的にリダイレクトされます。 ここには、最近作成された検証または移行に関する新しいエントリがあります。
移行を表示するグリッドには、[名前]、[状態]、[移行モード]、[移行の種類]、[ソース サーバー]、[ソース サーバーの種類]、[データベース]、[開始時刻]、[実行時間] の列があります。 エントリは、開始日時の降順に表示され、最新のエントリが先頭に表示されます。
[最新の情報に更新] ボタンを使って、検証または移行の状態を更新できます。
グリッドで特定の移行の名前を選んで、関連する詳細を表示することもできます。
作成された検証または移行は、InProgress 状態と PerformingPreRequisiteSteps サブ状態になります。 ワークフローで移行インフラストラクチャとネットワーク接続が設定されるまで、2 から 3 分かかります。
移行の各オプションについて、移行を監視する方法を見てみましょう。
PerformingPreRequisiteSteps サブ状態が完了すると、検証は Validation in Progress サブ状態になります。このサブ状態では、ソース サーバーとターゲット サーバーで移行の準備状況を評価するチェックが行われます。
すべての検証が Succeeded または Warning 状態の場合、検証は Succeeded 状態になります。
検証グリッドには次の情報があります
- [インスタンスの検証の詳細] と [データベースの検証の詳細] セクション: 移行の準備状況の確認に使われる検証ルールを表します。
- [検証名] - 特定の各検証規則の名前。
- [検証状態] - 各規則の結果を表し、3 つの値のいずれかになります。
- [成功] - エラーが見つからなかった場合。
- [失敗] - 検証エラーがある場合。
- [警告] - 検証の警告がある場合。
- [実行時間] - 検証操作にかかった時間。
- [開始時刻 (UTC)] と [終了時刻 (UTC)] - 検証操作の UTC での開始時刻と終了時刻。
検証中にエラーが発生した場合、[検証状態] は [失敗] 状態になります。 失敗した [検証名] または [データベース名] の検証を選ぶと、ファンアウト ペインに、詳細と、このエラーを回避するために実行する必要がある是正措置が表示されます。
PerformingPreRequisiteSteps というサブ状態が完了すると、移行は、データベースの複製/コピーが行われる [データを移行しています] のサブ状態に移ります。 移行が完了するまでの時間は、移行するデータベースのサイズと形状によって異なります。 データがすべてのテーブルにほぼ均等に分散されている場合、移行はすぐに完了します。 テーブル サイズにスキューがあると、相対的に長い時間がかかります。
移行中のいずれかのデータベースを選ぶと、ファンアウト ペインが表示されます。 すべてのテーブル数 (コピー済み、キュー済み、コピー中、エラー) と、データベースの移行状態が表示されます。
MigratingData 状態が正常に完了すると、移行は Succeeded 状態に移ります。 Migrating Data 状態で問題が発生した場合、移行は Failed 状態に移ります。
移行が Succeeded 状態になると、単一サーバーからフレキシブル サーバー ターゲットへのスキーマとデータの移行が完了します。 ページを更新して進行状況を確認できます。
このオプションでは、最初に検証が実行されてから移行が開始されます。 PerformingPreRequisiteSteps サブ状態が完了すると、ワークフローは Validation in Progress サブ状態になります。
- 検証にエラーがある場合、移行は Failed 状態になります。
- 検証がエラーなしで完了すると、移行が開始され、ワークフローは Migrating Data のサブストレートに移ります。
操作が完了したら、[検証と移行] の結果を表示できます。
[移行] および [検証と移行] の移行オプションの場合、オンライン移行を完了するには、一括移行アクションをトリガーする追加の手順をユーザーが完了する必要があります。 基本データのコピー/複製が完了すると、移行は WaitingForUserAction 状態かつ `WaitingForCutoverTrigger サブ状態に移行します。 この状態では、ユーザーはポータルで移行を選び、[一括移行] ボタンを選択して一括移行をトリガーできます。
一括移行を始める前に、次のことを確認する必要があります。
- ソースへの書き込みが停止している -
Latency (minutes)
パラメーターが 0 または 0 に近い。Latency (minutes)
の情報は、移行の詳細画面から取得できます。
Latency (minutes)
パラメーターは、ターゲットがソースと最後に同期されたタイミングを示します。 たとえば、上の Orders データベースの場合は 0.33333 です。 これは、Orders データベースの場合、ソースで過去約 0.3 分間に発生した変更が、まだターゲットまで送信されていないことを意味します。 この時点で、ソースへの書き込みを停止し、一括移行を開始することができます。 ソースに大量のトラフィックがある場合は、最初に書き込みを停止して、Latency (minutes)
が 0 に近づくようにしてから、その後に一括移行を開始することをお勧めします。 一括移行操作は、ソースからターゲットに保留中のすべての変更を適用して、移行を完了します。 待機時間がゼロではない状態で一括移行をトリガーした場合、レプリケーションはその時点までで停止します。 その場合、一括移行の時点までのソース上のすべてのデータが、ターゲットに適用されます。 たとえば、一括移行の時点で待機時間が 15 分の場合、過去 15 分間に変更されたすべてのデータがターゲットに適用されます。 所要時間は、その過去 15 分間に発生した変更のバックログによって異なります。 そのため、一括移行をトリガーする前に、待機時間をゼロまたはゼロに近い値にすることをお勧めします。
[データを移行しています] サブ状態または一括移行 (オンライン移行モードの場合) が正常に完了するとすぐに、移行は [成功しました] 状態になります。 [データを移行しています] サブ状態で問題が発生した場合、移行は [失敗しました] 状態に移ります。
移行の状態には、次のものがあります。
- InProgress: 移行インフラストラクチャのセットアップが進行中、または実際のデータ移行が進行中です。
- Canceled: 移行が取り消されたか削除されました。
- Failed: 移行は失敗しました。
- Validation Failed: 検証は失敗しました。
- Succeeded: 移行が成功し、完了しました。
移行のサブ状態には、次のものがあります。
- PerformingPreRequisiteSteps: データ移行のためのインフラストラクチャのセットアップが進行中です。
- Validation in Progress: 検証は進行中です。
- MigratingData: データ移行が進行中です。
- CompletingMigration: 移行が完了の最終段階にあります。
- Completed: 移行が正常に完了しました。