チュートリアル: DMS を使用して MySQL を Azure Database for MySQL にオフラインで移行する
Azure Database Migration Service を使うと、高速データ移行機能により、外部の MySQL インスタンスから Azure Database for MySQL へのシームレスな移行を実行できます。 このチュートリアルでは、Azure Database Migration Service のオフライン移行アクティビティを使用して、サンプル データベースを MySQL 5.7 のオンプレミス インスタンスから Azure Database for MySQL (v5.7) に移行します。 この記事は、ソースとして MySQL データベース インスタンスを、ターゲットとして Azure Database for MySQL を想定していますが、ソース サーバーの名前と資格情報さえ変更すれば Azure Database for MySQL 間の移行にも使用できます。 また、MySQL サーバーの下位バージョン (v5.6 以上) から上位バージョンへの移行にも対応します。
Note
この移行エクスペリエンスを PowerShell スクリプトで実現したバージョンについては、Azure Database for MySQL へのオフライン移行のスクリプト制御に関するページを参照してください。
Note
Amazon Relational Database Service (RDS) for MySQL および Amazon Relational Database Service (RDS) for Amazon Aurora (MySQL ベース) も移行元としてサポートされます。
このチュートリアルでは、次の作業を行う方法について説明します。
- DMS インスタンスを作成する。
- DMS で MySQL 移行プロジェクトを作成する。
- DMS を使用して MySQL スキーマを移行する。
- 移行を実行する。
- 移行を監視する。
前提条件
このチュートリアルを完了するには、以下を実行する必要があります。
アクティブなサブスクリプションが含まれる Azure アカウントを用意します。 無料でアカウントを作成できます。
バージョン 5.7 の MySQL データベースをオンプレミスに用意します。 ない場合は、MySQL Community Edition 5.7 をダウンロードしてインストールしてください。
Azure Resource Manager デプロイ モデルを使用して、Azure Database Migration Service 用の Microsoft Azure 仮想ネットワークを作成します。これで、ExpressRoute または VPN を使用したオンプレミスのソース サーバーとのサイト間接続が確立されます。 仮想ネットワークの作成方法の詳細については、Virtual Network のドキュメントを参照してください。特に、詳細な手順が記載されたクイックスタートの記事を参照してください。
Note
仮想ネットワークのセットアップ中、Microsoft へのネットワーク ピアリングに ExpressRoute を使用する場合は、サービスのプロビジョニング先となるサブネットに、次のサービス エンドポイントを追加してください。
- ターゲット データベース エンドポイント (SQL エンドポイント、Azure Cosmos DB エンドポイントなど)
- ストレージ エンドポイント
- サービス バス エンドポイント
Azure Database Migration Service にはインターネット接続がないため、この構成が必要となります。
仮想ネットワークのネットワーク セキュリティ グループの規則によって、ServiceBus、Storage、AzureMonitor の ServiceTag の送信ポート 443 がブロックされていないことを確認します。 仮想ネットワークの NSG トラフィックのフィルター処理の詳細については、ネットワーク セキュリティ グループによるネットワーク トラフィックのフィルター処理に関する記事を参照してください。
Azure Database Migration Service がソース MySQL Server (既定では TCP ポート 3306) にアクセスできるよう、Windows ファイアウォールを開放して仮想ネットワークからの接続を許可します。
ソース データベースの手前でファイアウォール アプライアンスを使用する場合は、移行対象のソース データベースに Azure Database Migration Service がアクセスできるよう、その仮想ネットワークからの接続を許可するファイアウォール規則を追加することが必要となる場合があります。
Azure Database Migration Service の仮想ネットワークからターゲット データベースにアクセスできるよう、サーバーレベルのファイアウォール規則を作成するか、ターゲット Azure Database for MySQL の VNET サービス エンドポイントを構成します。
ソース MySQL は、サポートされている MySQL Community Edition で実行されている必要があります。 MySQL インスタンスのバージョンを確認するには、MySQL ユーティリティまたは MySQL Workbench で、次のコマンドを実行します。
SELECT @@version;
Azure Database for MySQL は、InnoDB テーブルのみをサポートします。 MyISAM テーブルを InnoDB に変換するには、MyISAM から InnoDB へのテーブルの変換に関する記事を参照してください。
ユーザーには、ソース データベースにあるデータの読み取り権限が必要です。
スキーマの移行を正常に完了するには、ソース サーバーで、移行を実行するユーザーに次の特権が必要です。
- ソース上のサーバー レベルでの "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" 特権。
ターゲットの Azure Database for MySQL インスタンスをサイズ設定する
Azure Database Migration Service を使用してデータ読み込みを高速化するようにターゲットの Azure Database for MySQL サーバーを準備するには、次のサーバー パラメーターと構成の変更をお勧めします。
max_allowed_packet – 1073741824 (1GB) に設定して、行が大きいために発生する接続の問題を防ぎます。
slow_query_log – OFF に設定して、低速のクエリ ログを無効にします。 これにより、データの読み込み中の低速クエリ ログによって発生するオーバーヘッドがなくなります。
query_store_capture_mode – NONE に設定し、クエリ ストアを無効にします。 これにより、クエリ ストアによるサンプリング アクティビティで発生するオーバーヘッドがなくなります。
innodb_buffer_pool_size – 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 および innodb_write_io_threads - Azure portal のサーバー パラメーターで 4 に変更し、移行の速度を向上させます。
ストレージ層のスケールアップ – Azure Database for MySQL サーバーの IOP は、ストレージ層の増加に合せて徐々に増加します。
- 単一サーバーのデプロイ オプションでは、読み込みを高速化するために、ストレージ層を増やしてプロビジョニングされる IOP を増やすことをお勧めします。
- フレキシブル サーバーのデプロイ オプションでは、ストレージ サイズに関係なく IOPS をスケーリング (増減) することができます。
- ストレージ サイズはスケールアップのみ可能で、スケールダウンはできません。
次の表の詳細を参照して、ソース単一サーバーの価格レベルと仮想コア数に基づいて、ターゲット フレキシブル サーバーのコンピューティング サイズとコンピューティング レベルを選択します。
単一サーバーの価格レベル 単一サーバーの仮想コア数 フレキシブル サーバーのコンピューティング サイズ フレキシブル サーバーのコンピューティング レベル 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 仮想コア コンピューティングを選択します。 移行が完了したら、この記事の後半にある「移行後のアクティビティの実行」に関するセクションでコンピューティング サイズに関する推奨事項に従って、ターゲット サーバーの適切なコンピューティング サイズにスケール バックします。
移行が完了したら、サーバー パラメーターと構成を、ワークロードで必要な値に戻すことができます。
DMS を設定する
ターゲット フレキシブル サーバーをデプロイして構成したら、次に、単一サーバーをフレキシブル サーバーに移行するように DMS を設定する必要があります。
リソース プロバイダーの登録
Microsoft.DataMigration リソース プロバイダーを登録するには、次の手順を実行します。
最初の DMS インスタンスを作成する前に、Azure portal にサインインし、サブスクリプションを検索して選択します。
DMS インスタンスの作成に使用するサブスクリプションを選択してから、[リソース プロバイダー] を選択します。
"移行" という語を検索し、Microsoft.DataMigration に対して [登録] を選択します。
Database Migration Service インスタンスを作成する
Azure portal で [+ リソースの作成] を選択し、Azure Database Migration Service を検索して、ドロップダウン リストから [Azure Database Migration Service] を選択します。
[Azure Database Migration Service] 画面で、 [作成] を選択します。
[移行サービスの作成] 画面で、サービスの名前、サブスクリプション、新規または既存のリソース グループを指定します。
価格レベルを選択し、ネットワーク画面に移動します。 オフライン移行機能は、Premium の価格レベルでのみ使用できます。
コストと価格レベルの詳細については、価格に関するページを参照してください。
既存の仮想ネットワークを一覧から選択するか、新しく作成する仮想ネットワークの名前を入力します。 [確認と作成] 画面に移動します。 必要に応じて、[タグ] 画面を使用してサービスにタグを追加できます。
この仮想ネットワークが Azure Database Migration Service に、ソース SQL Server とターゲット Azure SQL Database インスタンスへのアクセスを提供します。
Azure portal で仮想ネットワークを作成する方法の詳細については、「Azure portal を使用した仮想ネットワークの作成」を参照してください。
構成を確認し、 [作成] を選択してサービスを作成します。
移行プロジェクトを作成する
サービスが作成されたら、Azure portal 内でそのサービスを探して開き、新しい移行プロジェクトを作成します。
Azure ポータルで、 [All services](すべてのサービス) を選択し、Azure Database Migration Service を検索して、Azure Database Migration Service を選択します。
検索結果から移行サービスのインスタンスを選択し、 [+ 新しい移行プロジェクト] を選択します。
[新しい移行プロジェクト] 画面でプロジェクトの名前を指定し、 [ソース サーバーの種類] 選択ボックスで [MySQL] を、 [ターゲット サーバーの種類] 選択ボックスで [Azure Database for MySQL] を選択して、 [Migration activity type](移行アクティビティの種類) 選択ボックスで [Data migration](データの移行) を選択します。 [アクティビティの作成と実行] を選択します。
Note
または、 [プロジェクトのみを作成します] を選択して移行プロジェクトを作成しておき、移行は後で実行することもできます。
移行プロジェクトを構成する
[ソースの選択] 画面で、ソース MySQL インスタンスの接続情報を指定し、[次へ: ターゲットの選択>>] を選択します
[ターゲットの選択] 画面で、ターゲット Azure Database for MySQL インスタンスの接続情報を指定し、[次へ: データベースの選択>>] を選択します
[データベースの選択] 画面で、移行のソース データベースとターゲット データベースをマッピングし、[次へ: 移行の設定の構成>>] を選択します。 [Make Source Server Read Only](ソース サーバーを読み取り専用にする) オプションを選択することでソースを読み取り専用にできますが、これはサーバー レベルの設定であることに注意してください。 選択した場合、選択したデータベースだけでなく、サーバー全体が読み取り専用に設定されます。
ターゲット データベースにソース データベースと同じデータベース名が含まれている場合、Azure Database Migration Service では、既定でターゲット データベースが選択されます。
[移行の設定の構成] 画面で、移行の対象となるテーブルを選択し、[Next : Summary>>](次へ: サマリー>>) を選択します。 ターゲット テーブルにデータが含まれている場合、それらは既定では選択されませんが、明示的に選択することもできます。その場合、テーブルに格納されているデータは、移行の開始前にすべて削除されます。
[Summary](サマリー) 画面の [アクティビティ名] ボックスで、移行アクティビティの名前を指定します。サマリーを見直して、ソースとターゲットの詳細が先ほど指定した内容と一致していることを確認します。
[移行の開始] を選択します。 移行アクティビティ ウィンドウが表示されます。アクティビティの [状態] は [初期化中] になります。 テーブルの移行が開始されると、 [状態] が [実行中] に変わります。
移行を監視する
移行アクティビティ画面で [最新の情報に更新] を選択して表示を更新し、完了したテーブル数についての進行状況を確認します。
アクティビティ画面でデータベース名をクリックして、移行中の各テーブルの状態を確認します。 [最新の情報に更新] を選択して、表示を更新してください。
移行を完了する
移行アクティビティ画面で、移行の [状態] が [完了] になるまで [最新の情報に更新] を選択して表示を更新します。
移行後のアクティビティ
オフライン移行の本番環境への導入はアプリケーションに依存するプロセスであり、このドキュメントで取り扱う範囲を超えていますが、移行後のアクティビティとしては次のような指針があります。
- アプリケーションの要件に従って、ログイン、ロール、アクセス許可を作成します。
- 移行前の手順で抽出したすべてのトリガーをターゲット データベースに再作成します。
- ターゲット データベースに対してアプリケーションの健全性テストを実施して移行を認定します。
リソースをクリーンアップする
今後 Database Migration Service を使用しない場合は、次の手順に従ってサービスを削除してください。
Azure ポータルで、 [All services](すべてのサービス) を選択し、Azure Database Migration Service を検索して、Azure Database Migration Service を選択します。
検索結果から移行サービスのインスタンスを選択し、 [サービスの削除] を選択します。
確認ダイアログで [DATABASE MIGRATION SERVICE の名前を入力してください] テキストボックスにサービスの名前を入力し、[削除] を選びます。
次の手順
- DMS を使用した移行の実行時の既知の問題と制限事項については、Azure Database Migration Service の一般的な問題に関する記事を参照してください。
- DMS の使用中に発生するソース データベースの接続の問題のトラブルシューティングについては、ソース データベースへの接続時の問題に関する記事を参照してください。
- Azure Database Migration Service の詳細については、「Azure Database Migration Service とは」を参照してください。
- Azure Database for MySQL の詳細については、「Azure Database for MySQL とは」の記事を参照してください。
- PowerShell から DMS を使用するうえでのガイダンスについては、記事「PowerShell: DMS を使用して MySQL データベースから Azure Database for MySQL へのオフライン移行を実行する」を参照してください。