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

  • [アーティクル]

注意

この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。 ソフトウェアからこの用語が削除された時点で、この記事から削除します。

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

注意

DMS のオンライン移行がプレビュー段階になりました。 DMS では、MySQL バージョン 5.7 および 8.0 の移行がサポートされており、下位バージョン (v5.7 以降) の MySQL サーバーから上位バージョンのサーバーへの移行もサポートされています。 また、DMS ではリージョン間、リソース グループ間、サブスクリプション間の移行もサポートされているため、ソース サーバーに指定したものとは異なるリージョン、リソース グループ、サブスクリプションをターゲット サーバーに選択できます。

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

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

前提条件

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

  • Azure Database for MySQL – 単一サーバー (ソース サーバー) の既存のインスタンスを作成または使用します。
  • 変更のレプリケートの移行を正常に完了するには、次の前提条件が満たされていることを確認します。
    • 任意の MySQL コマンド ライン ツールを使用して、コマンド SHOW VARIABLES LIKE 'log_bin' を実行して、ソース サーバーで log_bin が有効になっていることを確認します。 log_bin が有効になっていない場合は、移行を開始する前に有効にしてください。
    • bin ログを読み取って適用するために、ユーザーがソース サーバーで “REPLICATION CLIENT” と “REPLICATION SLAVE” のアクセス許可を持っていることを確認します。
    • 変更のレプリケートの移行をターゲットにしている場合は、ソース サーバーで binlog_expire_logs_seconds パラメーターを構成して、レプリカが変更をコミットする前に binlog ファイルが消去されないようにします。 開始するには少なくとも 2 日間確保することをお勧めします。 カットオーバーの成功後、値をリセットできます。
  • スキーマの移行を正常に完了するには、ソース サーバーで、移行を実行するユーザーに次の特権が必要です。
    • ソース データベースに対する "READ" 特権。
    • データベースからオブジェクトを選択できるようにするための "SELECT" 特権
    • ビューを移行する場合、ユーザーには "SHOW VIEW" 特権が必要です。
    • トリガーを移行する場合、ユーザーには "TRIGGER" 特権が必要です。
    • ルーチン (プロシージャや関数) を移行する場合、ルーチンの definer 句でユーザーに名前を指定する必要があります。 または、バージョンに基づいて、ユーザーに次の特権が必要です。
      • 5.7 の場合、"mysql.proc" テーブルへの "SELECT" アクセス権が必要です。
      • 8.0 の場合、"SHOW_ROUTINE" 特権、またはルーチンを含むスコープで付与された "CREATE ROUTINE"、"ALTER ROUTINE"、または "EXECUTE" 特権が必要です。
    • イベントを移行する場合、ユーザーには、イベントの表示元であるデータベースに対する "EVENT" 特権が必要です。

制限事項

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

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

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 フレキシブル サーバーを作成する」に関するページを参照してください。
  • 新しいターゲット フレキシブル サーバーを次のように構成します。
    • 移行を実行するユーザーには、次のアクセス許可が必要です。
      • bin ログを適用するためのターゲット サーバーに対して、ユーザーが "REPLICATION_APPLIER" または "BINLOG_ADMIN" アクセス許可を持っていることを確認します。
      • ユーザーがターゲット サーバーに対して "REPLICATION SLAVE" アクセス許可を持っていることを確認します。
      • bin ログを読み取って適用するために、ユーザーがソース サーバーで “REPLICATION CLIENT” と “REPLICATION SLAVE” のアクセス許可を持っていることを確認します。
      • ターゲット上にテーブルを作成するには、ユーザーに "CREATE" 権限が必要です。
      • "DATA DIRECTORY" または "INDEX DIRECTORY" パーティション オプションを使用してテーブルを移行する場合、ユーザーには "FILE" 特権が必要です。
      • "UNION" オプションを使用してテーブルを移行する場合、MERGE テーブルにマップするテーブルに対する "SELECT"、"UPDATE"、および "DELETE" 特権がユーザーに必要です。
      • ビューを移行する場合、"CREATE VIEW" 特権が必要です。 ビューの内容によっては、何らかの特権が必要になる場合があることに注意してください。 詳細については、“CREATE VIEW STATEMENT” のバージョンに固有の MySQL ドキュメントを参照してください
      • イベントを移行する場合、ユーザーには "EVENT" 特権が必要です。
      • トリガーを移行する場合、ユーザーには "TRIGGER" 特権が必要です。
      • ルーチンを移行する場合、ユーザーには "CREATE ROUTINE" 特権が必要です。
    • ソース サーバーと同じ名前のターゲット データベースを作成しますが、テーブルやビューなどを設定する必要はありません。
      • 移行を開始する前に、適切な文字、照合順序、およびその他の適用可能なスキーマ設定を設定します。これは、一部のオブジェクト定義で設定されている DEFAULT に影響する可能性があるためです。
      • また、テーブル以外のオブジェクトを移行する場合は、ソースで使用されているのと同じ名前をターゲット スキーマに使用してください。
    • ターゲット フレキシブル サーバーのサーバー パラメーターを次のように構成します。
      • ソース サーバーの値と一致するように、TLS バージョンと require_secure_transport サーバー パラメーターを設定します。
      • ソース サーバーで使用される既定値以外の値と一致するように、ターゲット サーバーのサーバー パラメーターを構成します。
      • 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 にサインインし、サブスクリプションを検索して選択します。 Azure Marketplace からのサブスクリプションの選択のスクリーンショット。

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

  3. "移行" という語を検索し、Microsoft.DataMigration に対して [登録] を選択します。 リソース プロバイダーの登録のスクリーンショット。

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

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

  2. [Azure Database Migration Service] 画面で、 [作成] を選択します。 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 は、ソース単一サーバーとターゲット フレキシブル サーバーの両方にアクセスできるように構成する必要があるため、必ず次のようにしてください。

    注意

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

  10. [確認と作成] タブに移動し、構成を確認し、条件を表示して、[作成] を選択します。 [確認と作成] の選択のスクリーンショット。 DMS のインスタンスのデプロイが始まります。 "デプロイが進行中です" というメッセージが数分間表示されてから、"デプロイが完了しました" というメッセージに変わります。

  11. [リソースに移動] を選択します。 [リソースに移動] の選択のスクリーンショット。

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

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

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

    Azure Database Migration Service のすべてのインスタンスを検索のスクリーンショット。

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

    新しい移行プロジェクトが選択されているスクリーンショット。

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

    注意

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

    新しい移行プロジェクトの作成のスクリーンショット。

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

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

  1. [ソースの選択] 画面で、ソース MySQL インスタンスの接続の詳細を指定します。 ソースの詳細の追加画面のスクリーンショット。

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

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

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

    指定したデータベース内のテーブル以外のオブジェクトは移行されますが、選択しなかった項目はスキップされます。 ソースとターゲットのサーバーでデータベースの名前が一致する場合にのみ、ソースとターゲットのデータベースを選択できます。 ターゲット データベースに存在しないソース サーバー上のデータベースを選択すると、"ターゲットでは使用できません" という警告メッセージが表示され、移行のためにそのデータベースを選択できなくなります。

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

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

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

    選択したソース テーブルがターゲット サーバーに存在しない場合、オンライン移行プロセスにより、テーブル スキーマとデータがターゲット サーバーに移行されます。 テーブルの選択のスクリーンショット。

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

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

    注意

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

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

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

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

移行を監視する

  1. 初期ロード アクティビティが完了したら、[初期ロード] タブに移動して、完了状態と完了したテーブルの数を表示します。 完了した初期ロード移行のスクリーンショット。

    初期ロード アクティビティが完了すると、[Replicate Data Changes] (データ変更のレプリケート) タブに自動的に移動します。 画面が 30 秒ごとに自動更新されるため、移行の進行状況を監視できます。

  2. [最新の情報に更新] を選択して表示を更新し、必要に応じてソースからの遅れ時間を確認します。

    移行の監視のスクリーンショット。

  3. [ソースからの遅れ時間 (秒)] を監視し、これが 0 に近づいたら、移行アクティビティ画面の上部にある [カットオーバーの開始] メニュー タブに移動して、カットオーバーの開始に進みます。

  4. カットオーバーを実行する準備が整う前に、カットオーバー ウィンドウの手順に従います。

  5. すべての手順を完了したら、[確定] を選択し、[適用] を選択します。 カットオーバーの実行のスクリーンショット。

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

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

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

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

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

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

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

  • DMS リソースをクリーンアップするには、次の手順を実行します。

    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 に移行する場合は、アプリケーションの互換性をテストします。
    • テストが完了したら、運用データベースを移行できます。 この時点で、運用環境への移行の日時を確定する必要があります。 この日時にはアプリケーションの使用量が少なくなることが理想的です。 関与する必要があるすべての利害関係者が参加でき、準備ができている必要があります。 運用環境への移行には、厳密な監視が必要です。 オンライン移行の場合、データ損失を防ぐため、一括移行を実行する前にレプリケーションを完了する必要があります。
  • すべての依存アプリケーションをリダイレクトし、新しいプライマリ データベースにアクセスして、運用環境で使用するためにアプリケーションを開きます。
  • ターゲット フレキシブル サーバーでのアプリケーションの実行が始まったら、データベースのパフォーマンスをよく監視して、パフォーマンスのチューニングが必要かどうかを確認します。

次の手順