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

複数のデータベース ソースから 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 を使用した高速データ読み込みを確実にしてください。

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

  単一サーバーの価格レベル	単一サーバーの仮想コア数	フレキシブル サーバーのコンピューティング サイズ	フレキシブル サーバーのコンピューティング レベル
  基本 1	1	General Purpose	Standard_D16ds_v4
  基本 1	2	General Purpose	Standard_D16ds_v4
  General Purpose 1	4	General Purpose	Standard_D16ds_v4
  General Purpose 1	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 portal を使用して 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 リソース プロバイダーを登録するには、次の手順を実行します。

1. 最初の DMS インスタンスを作成する前に、Azure portal にサインインし、サブスクリプションを検索して選択します。

   

2. DMS インスタンスの作成に使用するサブスクリプションを選択してから、[リソース プロバイダー] を選択します。

   

3. "移行" という用語を検索し、Microsoft.DataMigration に対して [登録] を選択します。

   

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

1. Azure portal で [+ リソースの作成] を選択し、"Azure Database Migration Service" という用語を検索して、ドロップダウン リストから [Azure Database Migration Service] を選択します。

   

2. [Azure Database Migration Service] 画面で、 [作成] を選択します。

   

3. [移行シナリオと Database Migration Service の選択] ページの [移行シナリオ] で、ソース サーバーの種類として [Azure Database for MySQL - 単一サーバー] を選択し、ターゲット サーバーの種類として [Azure Database for MySQL] を選択し、[選択] を選択します。

   

4. [移行サービスの作成] ページの [基本] タブの [プロジェクトの詳細] で、適切なサブスクリプションを選択してから、既存のリソース グループを選択するか、新しいリソース グループを作成します。

5. [インスタンスの詳細] で、サービスの名前を指定し、リージョンを選択して、Azure がサービス モードとして選択されていることを確認します。

6. [価格レベル] の右側で [Configure tier] (レベルを構成する) を選択します。

   

7. [構成] ページで、DMS インスタンス用に 4 つの仮想コアを持つ [Premium] 価格レベルを選び、[適用] を選びます。

   DMS Premium 4-vCore は、DMS サービスの作成日から 6 か月間 (183 日間) は無料で、料金は発生しません。 DMS のコストと価格レベルの詳細については、価格に関するページを参照してください。

   

   次に、ソース単一サーバーとターゲット フレキシブル サーバーにアクセスできる DMS インスタンスを提供する VNet を指定する必要があります。

8. [移行サービスの作成] ページで、[次へ: ネットワーク>>] を選択します。

9. [ネットワーク] タブで、一覧から既存の 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 トラフィックのフィルター処理の詳細については、ネットワーク セキュリティ グループによるネットワーク トラフィックのフィルター処理に関する記事を参照してください。

   サービスにタグを追加する場合は、最初に [次へ: タグ] を選択して [タグ] タブに進みます。 サービスへのタグの追加は省略可能です。

10. [確認と作成] タブに移動し、構成を確認し、条件を表示して、[作成] を選択します。

    

    DMS のインスタンスのデプロイが開始されます。 "デプロイが進行中です" というメッセージが数分間表示されてから、"デプロイが完了しました" というメッセージに変わります。

11. [リソースに移動] を選択します。

    

12. リソースの概要ページから DMS インスタンスの IP アドレスを特定し、ソースの単一サーバーとターゲットのフレキシブル サーバーのファイアウォール規則を作成して、DMS インスタンスの IP アドレスの許可リストを登録します。

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

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

1. Azure ポータルで、 [All services](すべてのサービス) を選択し、Azure Database Migration Service を検索して、Azure Database Migration Service を選択します。

   

2. 検索結果で、作成した DMS インスタンスを選択し、[+ 新しい移行プロジェクト] を選択します。

   

3. [新しい移行プロジェクト] ページでプロジェクトの名前を指定し、[ソース サーバーの種類] 選択ボックスで [Azure Database For MySQL – 単一サーバー] を選択し、[ターゲット サーバーの種類] 選択ボックスで [Azure Database for MySQL] を選択し、[移行アクティビティの種類] 選択ボックスで [オフライン移行] を選択してから、[アクティビティの作成と実行] を選択します。

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

   

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

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

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

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

   または、オンライン移行を実行していた場合は、[選択] ソース スクリーンの [トランザクション一貫性を有効にする] チェック ボックスをオンにします。 整合性バックアップの詳細については、「MySQL から Azure Database for MySQL へのデータ移行 - MySQL 整合性スナップショット」を参照してください。

2. 移行プロジェクトの構成画面に戻り、[ソースの選択] 画面で、ソース MySQL インスタンスの接続の詳細を指定します。

   

3. [次へ: ターゲットの選択>>] を選択し、[ターゲットの選択] 画面でターゲット フレキシブル サーバーの接続の詳細を指定します。

   

4. [次へ: データベースの選択>>] を選び、[データベースの選択] タブの [[プレビュー] サーバー オブジェクトの選択] で、移行するサーバー オブジェクトを選びます。

   

5. [データベースの選択] セクションの [ソース データベース] で、移行するデータベースを 1 つ以上選択します。

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

6. [次へ: データベースの選択>>] を選択して、[テーブルの選択] タブに移動します。

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

7. 移行するテーブルを選択します。

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

   

   DMS によって入力が検証され、検証に合格した場合は、移行を開始できます。

8. スキーマの移行を構成した後、[移行のレビューと開始] を選択します。

   Note

   [移行の設定の構成] タブに移動する必要があるのは、移行に失敗してトラブルシューティングを行う場合のみです。

9. [概要] タブの [アクティビティ名] テキスト ボックスで、移行アクティビティの名前を指定します。概要を見直して、ソースとターゲットの詳細が先ほど指定した内容と一致していることを確認します。

   

10. [移行の開始] を選択します。

    移行アクティビティ ウィンドウが表示されます。アクティビティの [状態] は [初期化中] になります。 テーブルの移行が開始されると、 [状態] が [実行中] に変わります。

移行を監視する

1. 移行アクティビティ画面で [最新の情報に更新] を選択して表示を更新し、進行状況と完了したテーブル数を表示します。

2. 移行中に各テーブルの状態を表示するには、データベース名を選択し、[最新の情報に更新] を選択して表示を更新します。

3. 移行の状態が [完了] になるまで [最新の情報に更新] を選択して表示を更新します。

   

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

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

• ターゲット データベースに対してアプリケーションの健全性テストを実施して移行を認定します。

• 新しいターゲット フレキシブル サーバーを指す接続文字列を更新します。

• アプリケーションの継続性を確保した後、ソースの単一サーバーを削除します。

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

  単一サーバーの価格レベル	単一サーバーの仮想コア数	フレキシブル サーバーのコンピューティング サイズ	フレキシブル サーバーのコンピューティング レベル
  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 Migration Service とは何ですか
• Azure Database Migration Service (クラシック) の一般的な問題やエラーのトラブルシューティング
• ソース データベースへの接続時の DMS エラーのトラブルシューティング