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

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

注

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

このチュートリアルでは、以下の内容を学習します。

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

前提条件

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

既存の MySQL インスタンス (ソースサーバー) を作成または使用します。
オンライン移行を正常に完了するには、次の前提条件が満たされていることを確認します。
- log_binコマンドを実行して、選択した MySQL コマンドラインツールを使用して、ソースサーバーでSHOW VARIABLES LIKE 'log_bin'が有効になっていることを確認します。 log_binが有効になっていない場合は、移行を開始する前に必ず有効にしてください。
- ユーザーが bin ログを読み取って適用するための REPLICATION CLIENT と REPLICATION REPLICA のアクセス許可をソースサーバーに付与していることを確認します。
- オンライン移行を対象としている場合は、レプリカが変更をコミットする前に binlog ファイルが消去されないように、ソースサーバーで binlog の有効期限を構成する必要があります。開始するには少なくとも 2 日間確保することをお勧めします。このパラメーターは、MySQL サーバーのバージョンによって異なります。 MySQL 5.7 の場合、パラメーターは expire_logs_days されます (既定では 0 に設定され、自動消去は行われません)。 MySQL 8.0 では、 binlog_expire_logs_seconds です (既定では 30 日に設定されています)。カットオーバーの成功後、値をリセットできます。
スキーマの移行を正常に完了するには、移行元サーバーで、移行を実行するユーザーに次の特権が必要です。
- ソースのサーバーレベルでの 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 では、オブジェクトの DEFINER 句の移行はサポートされていません。ソースの定義子を持つすべてのオブジェクト型は、ターゲットにドロップされます。移行後、定義子句をサポートし、スキーマ移行中に作成されるすべてのオブジェクトの既定の定義子は、移行の実行に使用されるログインに設定されます。
現在、DMS では、データ移動の一部としてのスキーマの移行のみがサポートされています。データ移動に何も選択されていない場合、スキーマの移行は行われません。スキーマ移行用のテーブルを選択すると、データ移動にもそのテーブルが選択されます。
オンライン移行のサポートは、ROW binlog 形式に制限されます。
Azure Database for MySQL - フレキシブルサーバーは、ミックスケースのデータベースをサポートしていません。ソース上の大文字と小文字が混在するデータベースは、オンライン移行には含まれません。
オンライン移行では、v8.0 または v5.7 Azure Database for MySQL フレキシブルサーバーのターゲットサーバーに移行するときの DDL ステートメントレプリケーションがサポートされるようになりました。
- ステートメントレプリケーションは、Azure DMS 移行アクティビティを構成するときにスキーマ移行用に選択されたデータベース、テーブル、およびスキーマオブジェクト (ビュー、ルーチン、トリガー) でサポートされます。選択されていないデータベース、テーブル、およびスキーマオブジェクトのデータ定義および管理ステートメントはレプリケートされません。移行のためにサーバー全体を選択すると、初期読み込みが完了した後にソースサーバー上に作成されたすべてのテーブル、データベース、およびスキーマオブジェクトのステートメントがレプリケートされます。
- Azure DMS ステートメントレプリケーションでは、次のコマンドを除くすべてのデータ定義ステートメントがサポートされます。
  - LOGFILE GROUP ステートメント
  - SERVER ステートメント
  - SPATIAL REFERENCE SYSTEM ステートメント
  - TABLESPACE ステートメント
- Azure DMS ステートメントレプリケーションでは、次のコマンドを除くすべてのデータ管理 - アカウント管理ステートメントがサポートされます。
  - 既定のロールの設定
  - パスワードの設定
- Azure DMS ステートメントレプリケーションでは、次のコマンドを除くすべてのデータ管理 - テーブルメンテナンスステートメントがサポートされます。
  - REPAIR TABLE
  - テーブルを解析する
  - チェックサムテーブル
- Azure DMS ステートメントまたは binlog レプリケーションでは、次の構文はサポートされていません: CREATE TABLE 'b' as SELECT * FROM 'a';。この DDL をレプリケーションすると、"START TRANSACTION ステートメントを使用した CREATE TABLE の後に BINLOG INSERT、COMMIT、ROLLBACK ステートメントのみが許可されます" というエラーが発生します。
移行期間は、バックエンドでのコンピューティングメンテナンスの影響を受ける可能性があり、進行状況がリセットされることがあります。

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

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

ソース MySQL サーバーの構成に基づいて、ターゲットフレキシブルサーバーのコンピューティングサイズとコンピューティングレベルを選択します。

¹ 移行の場合は、移行を高速化するために、ターゲットフレキシブルサーバーの General Purpose 16 仮想コアコンピューティング以上を選択することをお勧めします。移行が完了したら、ターゲットサーバーの目的のコンピューティングサイズにスケールバックします。
ターゲットフレキシブルサーバーの MySQL バージョンは、ソース MySQL サーバーの MySQL バージョン以上である必要があります。
ターゲットフレキシブルサーバーを特定のゾーンにデプロイする必要がない限り、可用性ゾーンパラメーターの値を [No preference]\(優先なし\) に設定します。
ネットワーク接続の場合は、[ネットワーク] タブで [プライベートアクセス] を選択します。それ以外の場合は、[パブリックアクセス] を選択して、ターゲットフレキシブルサーバーへのアクセスを許可するようにファイアウォール規則を構成します。

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

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

ターゲットフレキシブルサーバーを作成します。ガイド付きの手順については、「クイックスタート: Azure portal を使用して Azure Database for MySQL のインスタンスを作成する」を参照してください。
新しいターゲットフレキシブルサーバーを次のように構成します。
- 移行を実行するユーザーには、次のアクセス許可が必要です。
  - ユーザーが bin ログを適用するための REPLICATION_APPLIER または BINLOG_ADMIN アクセス許可をターゲットサーバーに付与していることを確認します。
  - ユーザーがターゲットサーバーに対する REPLICATION REPLICA アクセス許可を持っていることを確認します。
  - ユーザーが bin ログを読み取って適用するための REPLICATION CLIENT と REPLICATION REPLICA アクセス許可をソースサーバーに付与していることを確認します。
  - ターゲットにテーブルを作成するには、ユーザーが CREATE 特権を持っている必要があります。
  - DATA DIRECTORYまたはINDEX DIRECTORYパーティションオプションを使用してテーブルを移行する場合、ユーザーはFILE特権を持っている必要があります。
  - UNION オプションを使用してテーブルに移行する場合、ユーザーは、SELECT テーブルにマップするテーブルのUPDATE、DELETE、およびMERGE権限を持っている必要があります。
  - ビューを移行する場合は、 CREATE VIEW 特権が必要です。
  ビューの内容によっては、何らかの特権が必要になる場合があることに注意してください。詳細については、お使いのバージョンに固有の MySQL ドキュメントを参照 CREATE VIEW STATEMENT 。
  - イベントを移行する場合、ユーザーは EVENT 特権を持っている必要があります。
  - トリガーを移行する場合、ユーザーは TRIGGER 特権を持っている必要があります。
  - ルーチンを移行する場合、ユーザーは CREATE ROUTINE 特権を持っている必要があります。
- ターゲットフレキシブルサーバーのサーバーパラメーターを次のように構成します。
  - ソースサーバーの値と一致するように、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 に変更します。
- ソースサーバー上のレプリカと一致するようにターゲットサーバー上のレプリカを構成します。

DMS を設定する

ターゲットのフレキシブルサーバーをデプロイして構成したら、次にソース MySQL サーバーをフレキシブルサーバーに移行するように 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 の選択] ページの [移行シナリオ] で、[ソースサーバーの種類] として [MySQL] を選び、[ターゲットサーバーの種類] として [Azure Database for MySQL] を選び、[選択] を選びます。
[移行サービスの作成] ページの [基本] タブの [プロジェクトの詳細] で、適切なサブスクリプションを選択してから、既存のリソースグループを選択するか、新しいリソースグループを作成します。
[インスタンスの詳細] で、サービスの名前を指定し、リージョンを選択して、Azure がサービスモードとして選択されていることを確認します。
[価格レベル] の右側で [Configure tier] (レベルを構成する) を選択します。
[構成] ページで、DMS インスタンス用に 4 つの仮想コアを持つ [Premium] 価格レベルを選び、[適用] を選びます。

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

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

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

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

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

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

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

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

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

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

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

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

[ ソースの選択 ] 画面で、DMS がソースサーバーに接続されている仮想ネットワーク内にあることを確認する必要があります。ここで、ソースサーバーのサーバー名、サーバーポート、ユーザー名、パスワードを入力します。
[次へ: ターゲット >>の選択] を選択し、[ターゲットの選択] 画面で、サブスクリプション、場所、およびリソースグループに基づいてサーバーを見つけます。ユーザー名が自動入力されたら、ターゲットフレキシブルサーバーのパスワードを指定します。
[次へ: >>データベースを選択し、[データベースの選択] タブの [サーバー移行オプション] で [該当するすべてのデータベースの移行] を選択するか、[データベースの選択] で移行するサーバーオブジェクトを選択します。

[適用可能なすべてのデータベースを移行する] オプションが表示されるようになりました。このオプションを選択すると、ユーザーが作成したすべてのデータベースとテーブルが移行されます。 Azure Database for MySQL - フレキシブルサーバーは大文字と小文字が混在するデータベースをサポートしていないため、ソース上の大文字と小文字が混在するデータベースはオンライン移行には含まれません。
[ データベースの選択 ] セクションの [ ソースデータベース] で、移行するデータベースを選択します。

指定したデータベース内のテーブル以外のオブジェクトは移行されますが、選択しなかった項目はスキップされます。ソースとターゲットのサーバーでデータベースの名前が一致する場合にのみ、ソースとターゲットのデータベースを選択できます。

ターゲットサーバーに存在しないソースサーバー上のデータベースを選択すると、ターゲットサーバーに作成されます。
[次へ: テーブルの選択] を選択して、テーブルの選択 タブに移動します。

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

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

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

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

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

移行を監視する

初期ロード アクティビティが完了したら、[初期ロード] タブに移動して、完了状態と完了したテーブルの数を表示します。

初期ロード アクティビティが完了すると、[Replicate Data Changes] (データ変更のレプリケート) タブに自動的に移動します。画面が 30 秒ごとに自動更新されるため、移行の進行状況を監視できます。
必要に応じて、[最新の情報に更新] を選択して表示を更新し、ソースからの遅れ時間 (秒) を表示します。
[ソースからの遅れ時間 (秒)] を監視し、これが 0 に近づいたら、移行アクティビティ画面の上部にある [カットオーバーの開始] メニュータブに移動して、カットオーバーの開始に進みます。
カットオーバーを実行する準備が整う前に、カットオーバーウィンドウの手順に従います。
すべての手順を完了したら、[確定] を選択し、[適用] を選択します。

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

移行が完了したら、次の移行後のアクティビティを完了します。

ターゲットデータベースに対してアプリケーションの健全性テストを実施して移行を認定します。
新しいフレキシブルサーバーを指す接続文字列を更新します。
移行を高速化するためにターゲットフレキシブルサーバーをスケールアップした場合は、ソース MySQL サーバーの構成に基づいてフレキシブルサーバーのコンピューティングサイズとコンピューティングレベルを選択してスケールバックします。
- 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 に移行する場合は、アプリケーションの互換性をテストします。
- テストが完了したら、運用データベースを移行できます。この時点で、運用環境への移行の日時を確定する必要があります。この日時にはアプリケーションの使用量が少なくなることが理想的です。関与する必要があるすべての利害関係者が参加でき、準備ができている必要があります。運用環境への移行には、厳密な監視が必要です。オンライン移行の場合、データ損失を防ぐため、一括移行を実行する前にレプリケーションを完了する必要があります。
依存するすべてのアプリケーションをリダイレクトして、新しいプライマリデータベースにアクセスするようにし、ソースサーバーを読み取り専用にします。その後、運用環境で使用するアプリケーションを開きます。
ターゲットフレキシブルサーバーでのアプリケーションの実行が始まったら、データベースのパフォーマンスをよく監視して、パフォーマンスのチューニングが必要かどうかを確認します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-30

次の方法で共有

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