次の方法で共有

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

Note

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

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

"トランザクション整合性を有効にする" を使用したオフライン シナリオで変更のレプリケート移行を実行すると、企業はデータベースの運用中にデータベースを Azure に移行できます。 つまり、重要なアプリケーションを最小限のダウンタイムで移行でき、サービス レベルの可用性への影響と、エンド カスタマーが被る不便を抑えることができます。

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

  • DMS で MySQL Replicate Changes 移行プロジェクトを作成する。
  • 変更のレプリケート移行を実行します。
  • 移行を監視する。
  • 移行後の手順を実行する。

前提条件

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

  • 任意の MySQL コマンド ライン ツールを使用して、ソース サーバーで log_bin が有効になっているかどうかを確認します。 Binlog は既定で常に有効になっているわけではないため、移行を開始する前に有効になっていることを確認してください。 ソース サーバーで log_bin が有効になっているかどうかを確認するには、コマンド SHOW VARIABLES LIKE 'log_bin' を実行します。

  • bin ログを適用するためのターゲット サーバーに対して、ユーザーが "REPLICATION_APPLIER" または "BINLOG_ADMIN" アクセス許可を持っていることを確認します。

  • ユーザーがターゲット サーバーに対して "REPLICATION SLAVE" アクセス許可を持っていることを確認します。

  • bin ログを読み取って適用するために、ユーザーがソース サーバーで “REPLICATION CLIENT” と “REPLICATION SLAVE” のアクセス許可を持っていることを確認します。

  • "トランザクション整合性を有効にする" を使用してオフライン移行シナリオを実行し、bin ログ ファイルと位置を取得します。

    Azure Database Migration Service のオフライン移行の binlog 位置のスクリーンショット。

  • 変更のレプリケートの移行をターゲットにしている場合は、ソース サーバーで binlog_expire_logs_seconds パラメーターを構成して、レプリカが変更をコミットする前に binlog ファイルが消去されないようにします。 開始するには少なくとも 2 日間確保することをお勧めします。 カットオーバーが成功すると、値をリセットできます。

制限事項

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

  • レプリケート変更の移行を実行する場合、ターゲット サーバー上のデータベースの名前は、ソース サーバー上の名前と同じである必要があります。

  • サポートは ROW binlog 形式に制限されます。

  • DDL 変更レプリケーションは、DMS UI で 選択したオブジェクトのデータ定義と管理ステートメントをレプリケートするオプションを選択した場合にのみサポートされます。 レプリケーション機能は、初期読み込み後に発生し、バイナリ ログに記録されるデータ定義および管理ステートメントをターゲットにレプリケートすることをサポートします。

  • 変更をレプリケートする場合、データベースまたはテーブルの名前の変更はサポートされません。

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

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

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

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

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

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

  3. [新しい移行プロジェクト] ページでプロジェクトの名前を指定し、[ソース サーバーの種類] 選択ボックスで [MySQL] を選び、[ターゲット サーバーの種類] 選択ボックスで [Azure Database for MySQL - フレキシブル サーバー] を選び、[移行アクティビティの種類] 選択ボックスで [変更のレプリケート] を選んでから [アクティビティの作成と実行] を選びます。

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

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

  1. [ソースの選択] 画面で、ソース サーバー名、サーバー ポート、ユーザー名、パスワードをソース サーバーに入力します。

    ソースの詳細の追加画面のスクリーンショット。

  2. [次へ: ターゲットの選択 >>] を選択し、[ターゲットの選択] 画面で、サブスクリプション、場所、およびリソース グループに基づいてターゲット サーバーを見つけます。 ユーザー名が自動入力されたら、ターゲット フレキシブル サーバーのパスワードを指定します。

    ターゲットの選択のスクリーンショット。

  3. [次へ: binlog の選択]>> を選択し、[binlogの選択] 画面でオフライン移行シナリオ以前の実行でキャプチャした binlog ファイル名と binlog の位置を入力します。

    [binlog の選択] のスクリーンショット。

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

    データベースの選択のスクリーンショット。

  5. [次へ: テーブルの選択]>> を選択して、[テーブルの選択] タブに移動します。移行するテーブルをすべて選択する。 [テーブルの選択] のスクリーンショット。

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

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

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

    [概要] のスクリーンショット。

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

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

    実行中の状態のスクリーンショット。

移行を監視する

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

    カットオーバーの実行のスクリーンショット。

  2. カットオーバーを実行する準備が整う前に、カットオーバー ウィンドウの手順に従います。 すべての手順を完了したら、[確定] を選択し、[適用] を選択します。

    [カットオーバーの実行] の確認のスクリーンショット。

一括移行が完了すると、移行後の検証と手順をすべて実行するように設定されます。

[カットオーバーの実行] の完了のスクリーンショット。

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

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

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

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

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

  • 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 に移行する場合は、アプリケーションの互換性をテストします。
    • テストが完了したら、運用データベースを移行できます。 この時点で、運用環境への移行の日時を確定する必要があります。 この日時にはアプリケーションの使用量が少なくなることが理想的です。 関与する必要があるすべての利害関係者が参加でき、準備ができている必要があります。 運用環境への移行には、厳密な監視が必要です。 オンライン移行の場合、データ損失を防ぐため、一括移行を実行する前にレプリケーションを完了する必要があります。

  • 依存するすべてのアプリケーションをリダイレクトして、新しいプライマリ データベースにアクセスするようにし、ソース サーバーを読み取り専用にします。 その後、運用環境で使用するアプリケーションを開きます。

  • ターゲット フレキシブル サーバーでのアプリケーションの実行が始まったら、データベースのパフォーマンスをよく監視して、パフォーマンスのチューニングが必要かどうかを確認します。

関連するコンテンツ