注
この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。 ソフトウェアからこの用語が削除された時点で、この記事から削除します。
複数のデータベース ソースから 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 への移行をサポートしており、下位バージョン (v5.6 以上) の MySQL サーバーから上位バージョンのサーバーへの移行もサポートしています。 また、DMS ではリージョン間、リソース グループ間、サブスクリプション間の移行もサポートされているため、ソース サーバーに指定したものとは異なるリージョン、リソース グループ、サブスクリプションをターゲット サーバーに選択できます。
このチュートリアルで学習する内容は次のとおりです。
- DMS を使用して高速データ読み込み用のフレキシブル サーバーを作成するためのベスト プラクティスを実装する。
- ターゲット フレキシブル サーバーを作成して構成する。
- DMS インスタンスを作成する。
- DMS で MySQL 移行プロジェクトを作成する。
- DMS を使用して MySQL スキーマを移行する。
- 移行を実行する。
- 移行を監視する。
- 移行後の手順を実行する。
- 移行を実行するためのベスト プラクティスを実装する。
前提条件
このチュートリアルを完了するには、以下を実行する必要があります。
- 既存の MySQL インスタンス (ソース サーバー) を使用する、または新規作成します。
- オンライン移行を正常に完了させるために、次の前提条件が満たされていることを確認してください。
- 任意の MySQL コマンド ライン ツールを使用して、コマンド: SHOW VARIABLES LIKE 'log_bin' を実行し、ソース サーバーで log_bin が有効になっていることを確認します。 log_bin が有効になっていない場合は、移行を開始する前に有効にしてください。
- bin ログを読み取って適用するために、ユーザーがソース サーバーで “REPLICATION CLIENT” と “REPLICATION SLAVE” のアクセス許可を持っていることを確認します。
- オンライン移行を実行する場合は、ソース サーバーでバイナリログ (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 句の移行はサポートされていません。 ソース上の definer を持つすべてのオブジェクト型が削除され、移行後に、definer 句をサポートしスキーマの移行中に作成されるすべてのオブジェクトの既定の 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 * FROMa
;’ という構文‘はサポートされていません。 この DDL のレプリケーションの結果、"START TRANSACTION ステートメントによる CREATE TABLE 後は、ステートメントとして BINLOG INSERT、COMMIT、ROLLBACK のみがサポートされます" というエラーが発生します。
移行期間は、バックエンドでのコンピューティング メンテナンスの影響を受ける可能性があり、進行状況がリセットされることがあります。
DMS を使用して高速データ読み込み用のフレキシブル サーバーを作成するためのベスト プラクティス
DMS ではリージョン間、リソース グループ間、サブスクリプション間の移行がサポートされるため、適切なリージョン、リソース グループ、サブスクリプションをターゲット フレキシブル サーバーに自由に選択できます。 ターゲット フレキシブル サーバーを作成する前に、以下の構成ガイダンスを検討して、DMS を使用した高速データ読み込みを確実にしてください。
ソース MySQL サーバーの構成に基づいて、ターゲット フレキシブル サーバーのコンピューティング サイズとコンピューティング レベルを選択します。
1 移行の場合は、移行を高速化するために、ターゲット フレキシブル サーバーの General Purpose 16 仮想コア コンピューティング以上を選択することをお勧めします。 移行が完了したら、ターゲット サーバーの目的のコンピューティング サイズにスケール バックします。
ターゲット フレキシブル サーバーの MySQL バージョンは、ソース MySQL サーバーの MySQL バージョン以上である必要があります。
特定のゾーンにターゲット フレキシブル サーバーをデプロイする必要がない限り、可用性ゾーン パラメーターの値を "優先設定なし" に設定します。
ネットワーク接続の場合は、[ネットワーク] タブで [プライベート アクセス] を選択します。それ以外の場合は、[パブリック アクセス] を選択して、ターゲット フレキシブル サーバーへのアクセスを許可するようにファイアウォール規則を構成します。
ターゲット フレキシブル サーバーを作成して構成する
これらのベスト プラクティスを念頭に置いて、ターゲット フレキシブル サーバーを作成し、構成します。
ターゲット フレキシブル サーバーを作成します。 ガイド付きの手順については、クイック スタート「Azure portal を使用して 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" 特権が必要です。
ターゲット フレキシブル サーバーのサーバー パラメーターを次のように構成します。
- ソース サーバーの値と一致するように、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 インスタンスに提供する VNet を指定する必要があります。
[移行サービスの作成] ページで、[次へ: ネットワーク>>] を選択します。
[ネットワーク] タブで、一覧から既存の VNet を選択するか、作成する新しい VNet の名前を指定して、[確認と作成] を選択します。
詳細については、「Azure portal を使用した仮想ネットワークの作成」の記事をご覧ください。
ソース MySQL サーバーとターゲット フレキシブル サーバーの両方へのアクセス権を持つ VNet を構成する必要があるため、次のことを確認してください。
- サーバー レベルのファイアウォール規則を作成するか、ソース MySQL サーバーとターゲット Azure Database for MySQL サーバーの両方のネットワークを構成して、Azure Database Migration Service の VNet からソース データベースとターゲット データベースへのアクセスを許可します。
- VNet のネットワーク セキュリティ グループ (NSG) の規則によって、ServiceBus、Storage、Azure Monitor の ServiceTag の送信ポート 443 がブロックされていないことを確認します。 VNet 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 がソース サーバーに接続できる VNet 内にあることを確認する必要があります。 こちらでは、[ソース サーバー名]、[サーバー ポート]、[ユーザー名]、[パスワード] をソース サーバーに入力します。
[次へ: ターゲットの選択 >>] を選択し、[ターゲットの選択] 画面で、サブスクリプション、場所、およびリソース グループに基づいてサーバーを見つけます。 ユーザー名が自動入力されたら、ターゲット フレキシブル サーバーのパスワードを指定します。
[次へ: データベースの選択 >>] を選択し、[データベースの選択] タブの [サーバー移行オプション] で [該当するすべてのデータベースを移行] を選択するか、[データベースの選択] で移行するサーバー オブジェクトを選択します。
[適用可能なすべてのデータベースを移行する] オプションが表示されるようになりました。 このオプションを選択すると、ユーザーが作成したすべてのデータベースとテーブルが移行されます。 Azure Database for MySQL - フレキシブル サーバーでは、大文字と小文字が混在するデータベースはサポートされていないため、ソース上の大文字と小文字が混在するデータベースは、オンライン移行の対象にはなりません。
[データベースの選択] セクションの [ソース データベース] で、移行するデータベースを 1 つ以上選択します。
指定したデータベース内のテーブル以外のオブジェクトは移行されますが、選択しなかった項目はスキップされます。 ソースとターゲットのサーバーでデータベースの名前が一致する場合にのみ、ソースとターゲットのデータベースを選択できます。
ソース サーバー上のデータベースで、ターゲット サーバーに存在しないものを選択した場合、そのデータベースはターゲット サーバー上に作成されます。
[次へ: テーブルの選択]>> を選択して、[テーブルの選択] タブに移動します。
タブが設定される前に、DMS はソースとターゲットで選択したデータベースからテーブルをフェッチし、テーブルが存在し、データが含まれているかどうかを判断します。
移行するテーブルを選択します。
選択したソース テーブルがターゲット サーバーに存在しない場合、オンライン移行プロセスにより、テーブル スキーマとデータがターゲット サーバーに移行されます。
DMS によって入力が検証され、検証に合格した場合は、移行を開始できます。
スキーマの移行を構成した後、[移行のレビューと開始] を選択します。
[移行の設定の構成] タブに移動する必要があるのは、移行に失敗してトラブルシューティングを行う場合のみです。
[概要] タブの [アクティビティ名] テキスト ボックスで、移行アクティビティの名前を指定します。概要を見直して、ソースとターゲットの詳細が先ほど指定した内容と一致していることを確認します。
[移行の開始] を選択します。
移行アクティビティ ウィンドウが表示されます。アクティビティの [状態] は [初期化中] になります。 テーブルの移行が開始されると、 [状態] が [実行中] に変わります。
移行を監視する
初期ロード アクティビティが完了したら、[初期ロード] タブに移動して、完了状態と完了したテーブルの数を表示します。
初期ロード アクティビティが完了すると、[Replicate Data Changes] (データ変更のレプリケート) タブに自動的に移動します。 画面が 30 秒ごとに自動更新されるため、移行の進行状況を監視できます。
必要に応じて [最新の情報に更新] を選んで表示を更新し、[ソースからの遅れ時間 (秒)] を確認します。
[ソースからの遅れ時間 (秒)] を監視し、これが 0 に近づいたら、移行アクティビティ画面の上部にある [カットオーバーの開始] メニュー タブに移動して、カットオーバーの開始に進みます。
カットオーバーを実行する準備が整う前に、カットオーバー ウィンドウの手順に従います。
すべての手順を完了したら、[確定] を選択し、[適用] を選択します。
移行後のアクティビティを実行する
移行が完了したら、以下の移行後のアクティビティを必ず完了してください。
ターゲット データベースに対してアプリケーションの健全性テストを実施して移行を認定します。
新しいフレキシブル サーバーを指す接続文字列を更新します。
移行を高速化するためにターゲット フレキシブル サーバーをスケールアップした場合は、ソース MySQL サーバーの構成に基づいてフレキシブル サーバーのコンピューティング サイズとコンピューティング レベルを選択してスケール バックします。
DMS リソースをクリーンアップするには、次の手順を実行します。
Azure ポータルで、 [All services](すべてのサービス) を選択し、Azure Database Migration Service を検索して、Azure Database Migration Service を選択します。
検索結果から移行サービスのインスタンスを選択し、[サービスの削除] を選択します。
確認ダイアログ ボックスで、[TYPE THE DATABASE MIGRATION SERVICE NAME] (DATABASE MIGRATION SERVICE の名前を入力してください) テキストボックスにインスタンスの名前を指定し、[削除] を選択します。
移行のベスト プラクティス
移行を実行するときは、次のベスト プラクティスを考慮してください。
検出と評価の一環として、移行に役立つ重要なデータの一部として、サーバー SKU、CPU 使用率、ストレージ、データベース サイズ、拡張機能の使用状況を取得します。
運用環境に移行する前に、テスト移行を実行します。
テスト移行は、アプリケーション テストを含むデータベース移行のすべての側面を確実にカバーするために重要です。 ベスト プラクティスとしては、テストのために移行全体の実行を始めます。 新しく開始した移行が最小限のラグでデータ変更のレプリケート フェーズに入った後、フレキシブル サーバー ターゲットはテスト ワークロードの実行にのみ使用してください。 そのターゲットをアプリケーションのテストに使用して、期待されるパフォーマンスと結果を確認します。 より高いバージョンの MySQL に移行する場合は、アプリケーションの互換性をテストします。
テストが完了したら、運用データベースを移行できます。 この時点で、運用環境への移行の日時を確定する必要があります。 この日時にはアプリケーションの使用量が少なくなることが理想的です。 関与する必要があるすべての利害関係者が参加でき、準備ができている必要があります。 運用環境への移行には、厳密な監視が必要です。 オンライン移行の場合、データ損失を防ぐため、一括移行を実行する前にレプリケーションを完了する必要があります。
依存するすべてのアプリケーションをリダイレクトして、新しいプライマリ データベースにアクセスするようにし、ソース サーバーを読み取り専用にします。 その後、運用環境で使用するアプリケーションを開きます。
ターゲット フレキシブル サーバーでのアプリケーションの実行が始まったら、データベースのパフォーマンスをよく監視して、パフォーマンスのチューニングが必要かどうかを確認します。