チュートリアル: Azure portal を介して DMS を使用してオフラインで Azure Database for MySQL - 単一サーバーをフレキシブルサーバーに移行する

[アーティクル]
03/09/2023

複数のデータベースソースから Azure データプラットフォームへのシームレスな移行を可能にするように設計されたフルマネージドサービスである Azure Database Migration Service (DMS) を使用して、Azure Database for MySQL - 単一サーバーのインスタンスを Azure Database for MySQL - フレキシブルサーバーに移行できます。このチュートリアルでは、DMS 移行アクティビティを使用して、Azure Database for MySQL 単一サーバーから MySQL フレキシブルサーバー (両方ともバージョン 5.7 を実行) にサンプルデータベースをオフラインで移行します。

注意

DMS では、MySQL サーバーの下位バージョン (v5.6 以上) から上位バージョンへの移行をサポートします。また、DMS ではリージョン間、リソースグループ間、サブスクリプション間の移行もサポートされているため、ソースサーバーに指定したものとは異なるリージョン、リソースグループ、サブスクリプションをターゲットサーバーに選択できます。

重要

オンライン移行の場合は、DMS でサポートされているトランザクション一貫性を有効にする機能をデータインレプリケーションまたは変更のレプリケートと一緒に使用できます。また、オンライン移行シナリオを使用して、こちらのチュートリアルに従って移行することもできます。

このチュートリアルで学習する内容は次のとおりです。

DMS を使用して高速データ読み込み用のフレキシブルサーバーを作成するためのベストプラクティスを実装する。
ターゲットフレキシブルサーバーを作成して構成する。
DMS インスタンスを作成する。
DMS で MySQL 移行プロジェクトを作成する。
DMS を使用して MySQL スキーマを移行する。
移行を実行する。
移行を監視する。
移行後の手順を実行する。
移行を実行するためのベストプラクティスを実装する。

前提条件

このチュートリアルを完了するには、以下を実行する必要があります。

Azure Database for MySQL – 単一サーバー (ソースサーバー) の既存のインスタンスを作成または使用します。
スキーマの移行を正常に完了するには、ソースサーバーで、移行を実行するユーザーに次の特権が必要です。
- ソース上のサーバーレベルでの "SELECT" 特権。
- ビューを移行する場合、ユーザーはソースサーバー上で "SHOW VIEW" 特権、ターゲットサーバー上で "CREATE VIEW" 特権を持っている必要があります。
- トリガーを移行する場合、ユーザーはソースサーバーとターゲットサーバー上で "TRIGGER" 特権を持っている必要があります。
- ルーチン (プロシージャや関数) を移行する場合、ユーザーはターゲット上のサーバーレベルで付与された "CREATE ROUTINE" 特権と "ALTER ROUTINE" 特権を持っている必要があります。
- イベントを移行する場合、ユーザーはソースサーバーとターゲットサーバー上で "EVENT" 特権を持っている必要があります。
- ユーザー/ログインを移行する場合、ユーザーはターゲットサーバー上で "CREATE USER" 特権を持っている必要があります。
- 既に存在する可能性のあるテーブルをドロップするには、ターゲット上のサーバーレベルでの "DROP" 特権。たとえば、移行を再試行する場合などです。
- 外部キーを持つテーブルを作成するには、ターゲット上のサーバーレベルでの "REFERENCES" 特権。
- MySQL 8.0 に移行する場合、ユーザーはターゲットサーバー上で "SESSION_VARIABLES_ADMIN" 特権を持っている必要があります。
- ターゲット上のサーバーレベルでの "CREATE" 特権。
- ターゲット上のサーバーレベルでの "INSERT" 特権。
- ターゲット上のサーバーレベルでの "UPDATE" 特権。
- ターゲット上のサーバーレベルでの "DELETE" 特権。

制限事項

移行の準備をする際には、次の制限事項を必ず考慮してください。

テーブル以外のオブジェクトを移行する場合、DMS ではデータベースの名前変更はサポートされません。
bin_log が有効になっているターゲットサーバーに移行する場合、必ず、log_bin_trust_function_creators を有効にしてルーチンとトリガーを作成できるようにしてください。
スキーマを移行する場合、DMS ではターゲットサーバーでのデータベースの作成はサポートされません。
現在、DMS では、オブジェクトの DEFINER 句の移行はサポートされていません。ソース上で definer を持つすべてのオブジェクト型は削除され、移行後にテーブルの既定の definer が、移行の実行に使用されるログインに設定されます。
現在、DMS では、データ移動の一部としてのスキーマの移行のみがサポートされています。データ移動に何も選択されていない場合、スキーマの移行は行われません。スキーマ移行用のテーブルを選択すると、データ移動にもそのテーブルが選択されることに注意してください。

DMS を使用して高速データ読み込み用のフレキシブルサーバーを作成するためのベストプラクティス

DMS ではリージョン間、リソースグループ間、サブスクリプション間の移行がサポートされるため、適切なリージョン、リソースグループ、サブスクリプションをターゲットフレキシブルサーバーに自由に選択できます。ターゲットフレキシブルサーバーを作成する前に、以下の構成ガイダンスを検討して、DMS を使用した高速データ読み込みを確実にしてください。

次の表の詳細を参照して、ソース単一サーバーの価格レベルと仮想コア数に基づいて、ターゲットフレキシブルサーバーのコンピューティングサイズとコンピューティングレベルを選択します。

単一サーバーの価格レベル	単一サーバーの仮想コア数	フレキシブルサーバーのコンピューティングサイズ	フレキシブルサーバーのコンピューティングレベル
Basic*	1	General Purpose	Standard_D16ds_v4
Basic*	2	General Purpose	Standard_D16ds_v4
General Purpose*	4	General Purpose	Standard_D16ds_v4
General Purpose*	8	General Purpose	Standard_D16ds_v4
General Purpose	16	General Purpose	Standard_D16ds_v4
General Purpose	32	General Purpose	Standard_D32ds_v4
General Purpose	64	General Purpose	Standard_D64ds_v4
メモリ最適化	4	Business Critical	Standard_E4ds_v4
メモリ最適化	8	Business Critical	Standard_E8ds_v4
メモリ最適化	16	Business Critical	Standard_E16ds_v4
メモリ最適化	32	Business Critical	Standard_E32ds_v4

* 移行の場合は、移行を高速化するために、ターゲットフレキシブルサーバーに General Purpose 16 仮想コアコンピューティングを選択します。移行が完了したら、この記事の後半にある「移行後のアクティビティの実行」に関するセクションでコンピューティングサイズに関する推奨事項に従って、ターゲットサーバーの適切なコンピューティングサイズにスケールバックします。

ターゲットフレキシブルサーバーの MySQL バージョンは、ソース単一サーバーの MySQL バージョン以上である必要があります。
特定のゾーンにターゲットフレキシブルサーバーをデプロイする必要がない限り、可用性ゾーンパラメーターの値を "優先設定なし" に設定します。
ネットワーク接続の場合、[ネットワーク] タブで、ソース単一サーバーにプライベートエンドポイントまたはプライベートリンクが構成されている場合は、[プライベートアクセス] を選択します。それ以外の場合は、[パブリックアクセス] を選択します。
ソース単一サーバーからターゲットフレキシブルサーバーにすべてのファイアウォール規則をコピーします。
作成時にすべての名前/値タグを単一サーバーからフレキシブルサーバーにコピーします。

ターゲットフレキシブルサーバーを作成して構成する

これらのベストプラクティスを念頭に置いて、ターゲットフレキシブルサーバーを作成し、構成します。

ターゲットフレキシブルサーバーを作成します。ガイド付きの手順については、クイックスタート「Azure Database for MySQL フレキシブルサーバーを作成する」に関するページを参照してください。
次に、新たに作成されたターゲットフレキシブルサーバーを構成するために、次の手順に従います。
- 移行を実行するユーザーには、次のアクセス許可が必要です。
  - ターゲット上にテーブルを作成するには、ユーザーに "CREATE" 権限が必要です。
  - "UNION" オプションを使用してテーブルを移行する場合、MERGE テーブルにマップするテーブルに対する "SELECT"、"UPDATE"、および "DELETE" 特権がユーザーに必要です。
  - ビューを移行する場合、"CREATE VIEW" 特権が必要です。ビューの内容によっては、何らかの特権が必要になる場合があることに注意してください。詳細については、“CREATE VIEW STATEMENT” のバージョンに固有の MySQL ドキュメントを参照してください
  - イベントを移行する場合、ユーザーには "EVENT" 特権が必要です。
  - トリガーを移行する場合、ユーザーには "TRIGGER" 特権が必要です。
  - ルーチンを移行する場合、ユーザーには "CREATE ROUTINE" 特権が必要です。
- ターゲットデータベースを作成します。ただし、テーブルやビューなどを取り込む必要はありません。
  - 移行を開始する前に、適切な文字、照合順序、およびその他の適用可能なスキーマ設定を設定します。これは、一部のオブジェクト定義で設定されている DEFAULT に影響する可能性があるためです。
  - また、テーブル以外のオブジェクトを移行する場合は、ソースで使用されているのと同じ名前をターゲットスキーマに使用してください。
- ターゲットフレキシブルサーバーのサーバーパラメーターを次のように構成します。
  - ソースサーバーの値と一致するように、TLS バージョンと require_secure_transport サーバーパラメーターを設定します。
  - sql_mode サーバーパラメーターをソースサーバーの値と一致するように設定します。
  - ソースサーバーで使用される既定値以外の値と一致するように、ターゲットサーバーのサーバーパラメーターを構成します。
  - DMS を使用するときにデータの読み込みを高速化するには、説明に従って次のサーバーパラメーターを構成します。
    - max_allowed_packet – 1073741824 (1 GB) に設定して、行が大きいために発生する接続の問題を防ぎます。
    - slow_query_log – OFF に設定して、低速のクエリログを無効にします。これにより、データの読み込み中の低速クエリログによって発生するオーバーヘッドがなくなります。
    - innodb_buffer_pool_size – Azure Database for MySQL サーバーのコンピューティングをスケールアップしないと増やすことができません。移行中にサーバーをポータルの [価格レベル] から 64 仮想コア General Purpose SKU にスケールアップし、innodb_buffer_pool_size を増やします。
    - innodb_io_capacity & innodb_io_capacity_max - IO 使用率を向上させて移行速度を最適化するために、Azure portal のサーバーパラメーターから 9000 に変更します。
    - innodb_write_io_threads - Azure portal のサーバーパラメーターから 4 に変更し、移行の速度を向上させます。
- ターゲットサーバー上のレプリカを、ソースサーバー上のものと一致するように構成します。
- 次のサーバー管理機能をソース単一サーバーからターゲットフレキシブルサーバーにレプリケートします。
  - ロールの割り当て、ロール、拒否の割り当て、従来の管理者、アクセスの制御 (IAM)
  - ロック (読み取り専用と削除)
  - 警告
  - タスク
  - リソース正常性アラート

DMS を設定する

ターゲットフレキシブルサーバーをデプロイして構成したら、次に、単一サーバーをフレキシブルサーバーに移行するように DMS を設定する必要があります。

リソースプロバイダーの登録

Microsoft.DataMigration リソースプロバイダーを登録するには、次の手順を実行します。

最初の DMS インスタンスを作成する前に、Azure portal にサインインし、サブスクリプションを検索して選択します。
DMS インスタンスの作成に使用するサブスクリプションを選択してから、[リソースプロバイダー] を選択します。
"移行" という語を検索し、Microsoft.DataMigration に対して [登録] を選択します。

Database Migration Service (DMS) インスタンスを作成する

Azure portal で [+ リソースの作成] を選択し、"Azure Database Migration Service" という語を検索して、ドロップダウンリストから [Azure Database Migration Service] を選択します。
[Azure Database Migration Service] 画面で、 [作成] を選択します。
[移行シナリオと Database Migration Service の選択] ページの [移行シナリオ] で、ソースサーバーの種類として [Azure Database for MySQL - 単一サーバー] を選択し、ターゲットサーバーの種類として [Azure Database for MySQL] を選択し、[選択] を選択します。
[移行サービスの作成] ページの [基本] タブの [プロジェクトの詳細] で、適切なサブスクリプションを選択してから、既存のリソースグループを選択するか、新しいリソースグループを作成します。
[インスタンスの詳細] で、サービスの名前を指定し、リージョンを選択して、Azure がサービスモードとして選択されていることを確認します。
[価格レベル] の右側で [Configure tier] (レベルを構成する) を選択します。
[構成] ページで、DMS インスタンス用に 4 つの仮想コアを持つ [Premium] 価格レベルを選び、[適用] を選びます。 DMS Premium 4-vCore は、DMS サービスの作成日から 6 か月間 (183 日間) は無料で、料金は発生しません。 DMS のコストと価格レベルの詳細については、価格に関するページを参照してください。

次に、ソース単一サーバーとターゲットフレキシブルサーバーにアクセスできる DMS インスタンスを提供する VNet を指定する必要があります。
[移行サービスの作成] ページで、[次へ: ネットワーク>>] を選択します。
[ネットワーク] タブで、一覧から既存の VNet を選択するか、作成する新しい VNet の名前を指定して、[確認と作成] を選択します。

詳細については、「Azure portal を使用した仮想ネットワークの作成」をご覧ください。
重要

vNet は、ソース単一サーバーとターゲットフレキシブルサーバーの両方にアクセスできるように構成する必要があるため、必ず次のようにしてください。
- Azure Database Migration Service 用の VNet からソースデータベースとターゲットデータベースにアクセスできるよう、サーバーレベルのファイアウォール規則を作成するか、ソースとターゲットの両方の Azure Database for MySQL サーバーの VNet サービスエンドポイントを構成します。
- VNet のネットワークセキュリティグループ (NSG) の規則によって、ServiceBus、Storage、Azure Monitor の ServiceTag の送信ポート 443 がブロックされていないことを確認します。 VNet NSG トラフィックのフィルター処理の詳細については、ネットワークセキュリティグループによるネットワークトラフィックのフィルター処理に関する記事を参照してください。
注意

サービスにタグを追加する場合は、最初に [次へ: タグ] を選択して [タグ] タブに進みます。サービスへのタグの追加は省略可能です。
[確認と作成] タブに移動し、構成を確認し、条件を表示して、[作成] を選択します。

DMS のインスタンスのデプロイが開始されます。 "デプロイが進行中です" というメッセージが数分間表示されてから、"デプロイが完了しました" というメッセージに変わります。
[リソースに移動] を選択します。
リソースの概要ページから DMS インスタンスの IP アドレスを特定し、ソースの単一サーバーとターゲットのフレキシブルサーバーのファイアウォール規則を作成して、DMS インスタンスの IP アドレスの許可リストを登録します。

移行プロジェクトを作成する

移行プロジェクトを作成するには、次の手順を実行します。

Azure ポータルで、 [All services](すべてのサービス) を選択し、Azure Database Migration Service を検索して、Azure Database Migration Service を選択します。
検索結果で、作成した DMS インスタンスを選択し、[+ 新しい移行プロジェクト] を選択します。
[新しい移行プロジェクト] ページでプロジェクトの名前を指定し、[ソースサーバーの種類] 選択ボックスで [Azure Database For MySQL – 単一サーバー] を選択し、[ターゲットサーバーの種類] 選択ボックスで [Azure Database for MySQL] を選択し、[移行アクティビティの種類] 選択ボックスで [オンライン移行] を選択してから、[アクティビティの作成と実行] を選択します。

注意

移行アクティビティの種類として [プロジェクトのみの作成] を選択すると、移行プロジェクトのみが作成されます。後で移行プロジェクトを実行できます。

移行プロジェクトを構成する

DMS 移行プロジェクトを構成するには、次の手順を実行します。

オフライン移行を始めるには、Azure portal で画面の [ソースの選択] を構成する前に新しいウィンドウタブを開き、ソースサーバーの概要ページに移動して、[Server Parameters] (サーバーパラメーター) ブレードに進みます。ソースサーバーの read_only サーバーパラメーターの値を ON として構成します。

移行を開始する前にサーバーパラメーターを更新してソースサーバーを読み取り専用モードに設定すると、移行中にソースサーバーに対する書き込みまたは削除操作が防止され、ソースの移行時にターゲットデータベースのデータ整合性が確保されます。

Note

または、オンライン移行を実行していた場合は、[選択] ソーススクリーンの [トランザクション一貫性を有効にする] チェックボックスをオンにします。整合性バックアップの詳細については、「MySQL 整合性バックアップ」を参照してください。
移行プロジェクトの構成画面に戻り、[ソースの選択] 画面で、ソース MySQL インスタンスの接続の詳細を指定します。
[次へ: ターゲットの選択>>] を選択し、[ターゲットの選択] 画面でターゲットフレキシブルサーバーの接続の詳細を指定します。
[次へ: データベースの選択>>] を選び、[データベースの選択] タブの [[プレビュー] サーバーオブジェクトの選択] で、移行するサーバーオブジェクトを選びます。
[データベースの選択] セクションの [ソースデータベース] で、移行するデータベースを 1 つ以上選択します。

指定したデータベース内のテーブル以外のオブジェクトは移行されますが、選択しなかった項目はスキップされます。
[次へ: データベースの選択]>> を選択して、[テーブルの選択] タブに移動します。

タブが設定される前に、DMS はソースとターゲットで選択したデータベースからテーブルをフェッチし、テーブルが存在し、データが含まれているかどうかを判断します。
移行するテーブルを選択します。

ターゲットデータベースに存在しないテーブルをソースデータベースで選択した場合は、[スキーマの移行] の下のボックスが既定で選択されます。ターゲットデータベースに存在するテーブルの場合、選択したテーブルに既にデータが含まれており、切り捨てられることがメモに示されます。さらに、ターゲットサーバー上のテーブルのスキーマがソースのスキーマと一致しない場合、移行が続行される前にテーブルが削除されます。

DMS によって入力が検証され、検証に合格した場合は、移行を開始できます。
スキーマの移行を構成した後、[移行のレビューと開始] を選択します。

注意

[移行の設定の構成] タブに移動する必要があるのは、移行に失敗したときのトラブルシューティングを行う場合のみです。
[概要] タブの [アクティビティ名] テキストボックスで、移行アクティビティの名前を指定します。概要を見直して、ソースとターゲットの詳細が先ほど指定した内容と一致していることを確認します。
[移行の開始] を選択します。移行アクティビティウィンドウが表示されます。アクティビティの [状態] は [初期化中] になります。テーブルの移行が開始されると、 [状態] が [実行中] に変わります。

移行を監視する

移行アクティビティ画面で [最新の情報に更新] を選択して表示を更新し、進行状況と完了したテーブル数を表示します。
移行中に各テーブルの状態を表示するには、データベース名を選択し、[最新の情報に更新] を選択して表示を更新します。
移行の状態が [完了] になるまで [最新の情報に更新] を選択して表示を更新します。

移行後のアクティビティを実行する

移行が完了したら、以下の移行後のアクティビティを必ず完了してください。

ターゲットデータベースに対してアプリケーションの健全性テストを実施して移行を認定します。
新しいターゲットフレキシブルサーバーを指す接続文字列を更新します。
アプリケーションの継続性を確保した後、ソースの単一サーバーを削除します。

移行を高速化するためにターゲットフレキシブルサーバーをスケールアップした場合は、次の表の詳細を参照して、ソース単一サーバーの価格レベルと仮想コア数に基づいて、ターゲットフレキシブルサーバーのコンピューティングサイズとコンピューティングレベルを選択することでスケールバックします。

単一サーバーの価格レベル	単一サーバーの仮想コア数	フレキシブルサーバーのコンピューティングサイズ	フレキシブルサーバーのコンピューティングレベル
Basic	1	バースト可能	Standard_B1s
Basic	2	バースト可能	Standard_B2s
General Purpose	4	General Purpose	Standard_D4ds_v4
General Purpose	8	General Purpose	Standard_D8ds_v4

Data Migration Service リソースをクリーンアップします。
1. Azure ポータルで、 [All services](すべてのサービス) を選択し、Azure Database Migration Service を検索して、Azure Database Migration Service を選択します。
2. 検索結果から移行サービスのインスタンスを選択し、[サービスの削除] を選択します。
3. 確認ダイアログボックスで、[TYPE THE DATABASE MIGRATION SERVICE NAME] (DATABASE MIGRATION SERVICE の名前を入力してください) テキストボックスにサービスの名前を指定し、[削除] を選択します。

移行のベストプラクティス

移行を実行するときは、次のベストプラクティスに留意してください。

検出と評価の一環として、移行に役立つ重要なデータの一部として、サーバー SKU、CPU 使用率、ストレージ、データベースサイズ、拡張機能の使用状況を取得します。
データベースごとに移行のモードを計画します。より単純な移行や、小規模なデータベースの場合は、オフラインモードを検討してください。
運用環境に移行する前に、テスト移行を実行します。
- テスト移行は、アプリケーションテストを含むデータベース移行のすべての側面を確実にカバーするために重要です。より高いバージョンの MySQL に移行する場合は、アプリケーションの互換性をテストします。
- テストが完了したら、運用データベースを移行できます。この時点で、運用環境への移行の日時を確定する必要があります。この日時にはアプリケーションの使用量が少なくなることが理想的です。関与する必要があるすべての利害関係者が参加でき、準備ができている必要があります。運用環境への移行には、厳密な監視が必要です。
すべての依存アプリケーションをリダイレクトし、新しいプライマリデータベースにアクセスして、運用環境で使用するためにアプリケーションを開きます。
ターゲットフレキシブルサーバーでのアプリケーションの実行が始まったら、データベースのパフォーマンスをよく監視して、パフォーマンスのチューニングが必要かどうかを確認します。

次の手順

Azure Database for MySQL - フレキシブルサーバーについては、概要 - Azure Database for MySQL のフレキシブルサーバーに関するページを参照してください。
Azure Database Migration Service の詳細については、「Azure Database Migration Service とは」を参照してください。
DMS を使用した移行の実行時の既知の問題と制限事項については、Azure Database Migration Service の一般的な問題に関する記事を参照してください。
DMS の使用中に発生するソースデータベースの接続の問題のトラブルシューティングについては、ソースデータベースへの接続時の問題に関する記事を参照してください。

チュートリアル: Azure portal を介して DMS を使用してオフラインで Azure Database for MySQL - 単一サーバーをフレキシブル サーバーに移行する