データイン レプリケーションを使用して Amazon RDS for MySQL を Azure Database for MySQL に移行する

MySQL データベースを Azure Database for MySQL フレキシブル サーバーに移行するには、MySQL のダンプと復元、MySQL Workbench Export/Import、Azure Database Migration Service などの方法を使用できます。 mysqldump、mydumper、myloader などのオープンソース ツールにデータイン レプリケーションを組み合わせて使用すると、最小限のダウンタイムでワークロードを移行できます。

データイン レプリケーションは、バイナリ ログ ファイルの配置方法に基づいてソース サーバーへのデータ変更を宛先サーバーにレプリケートする技術です。 このシナリオでは、ソース (データベースの変更が行われる元の場所) として動作する MySQL インスタンスが更新と変更を "イベント" としてバイナリ ログに書き込みます。 バイナリ ログ内の情報は、記録されるデータベースの変更に応じてさまざまなログ形式で保存されます。 レプリカは、ソースからバイナリ ログを読み取り、レプリカのローカル データベース上でバイナリ ログのイベントを実行するように構成されます。

ソース MySQL サーバーからターゲット MySQL サーバーにデータを同期するように、データを Azure Database for MySQL - フレキシブル サーバーにレプリケートを設定します。 プライマリ (ソース データベース) からレプリカ (ターゲット データベース) へのアプリケーションの選択的なカットオーバーを実行できます。

このチュートリアルでは、Amazon Relational Database Service (RDS) for MySQL を実行するソース サーバーと Azure Database for MySQL フレキシブル サーバーを実行するターゲット サーバーとの間のデータイン レプリケーションを設定する方法を説明します。

パフォーマンスに関する考慮事項

このチュートリアルを開始する前に必ず、操作の実行に使用するクライアント コンピューターの場所と容量がパフォーマンスに与える影響を考慮してください。

クライアントの場所

ダンプまたは復元の操作は、データベース サーバーと同じ場所で起動したクライアント コンピューターから実行します。

• Azure Database for MySQL フレキシブル サーバー インスタンスについては、クライアント マシンがターゲット データベース サーバーと同じ仮想ネットワークと可用性ゾーンに存在する必要があります。
• ソース Amazon RDS データベース インスタンスについては、ソース データベース サーバーと同じ Amazon Virtual Private Cloud および可用性ゾーンにクライアント インスタンスが存在する必要があります。 前述のケースでは、クライアント マシン間で FTP や SFTP などのファイル転送プロトコルを使用してダンプ ファイルを移動したり、それらを Azure Blob Storage にアップロードしたりすることができます。 移行の総所要時間を短縮するために、ファイルを転送する前に圧縮できます。

クライアントの容量

クライアント コンピューターの場所に関係なく、要求された操作を実行するためには、適切なコンピューティング、I/O、ネットワーク容量が必要です。 一般的な推奨事項は次のとおりです。

• ダンプまたは復元にデータのリアルタイム処理 (圧縮、展開など) が伴う場合、ダンプまたは復元のスレッドごとに少なくとも 1 つの CPU コアを備えたインスタンス クラスを選択します。
• クライアント インスタンスに十分なネットワーク帯域幅を確保します。 高速ネットワーク機能がサポートされるインスタンス タイプを使用します。 詳細については、Azure 仮想マシン ネットワーク ガイドの高速ネットワークに関するセクションを参照してください。
• 読み取り/書き込みに期待される容量がクライアント マシンのストレージ レイヤーに備わっていることを確認します。 Premium SSD ストレージを備えた Azure 仮想マシンをお勧めします。

前提条件

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

• mysqlclient をクライアント コンピューターにインストールします。ダンプを作成して、ターゲットの Azure Database for MySQL フレキシブル サーバー インスタンス上で復元操作を実行するためです。

• データベースが大きい場合は、データベースのダンプと復元を並列処理する mydumper と myloader をインストールします。

  注意

  mydumper は、Linux ディストリビューションでのみ実行できます。 詳細については、mydumper のインストール方法に関するページを参照してください。

• Azure Database for MySQL フレキシブル サーバーのインスタンスを作成します。実行するバージョンは 5.7 または 8.0 とします。

  重要

  ゾーン冗長による高可用性 (HA) を備えた Azure Database for MySQL フレキシブル サーバーがターゲットである場合、この構成では、データイン レプリケーションがサポートされないことに注意してください。 回避策として、サーバーの作成中、ゾーン冗長 HA を設定してください。

  1. ゾーン冗長 HA が有効なサーバーを作成します。
  2. HA を無効にします。
  3. 記事に従ってデータイン レプリケーションを設定します。
  4. カットオーバー後に、データイン レプリケーション構成を削除します。
  5. HA を有効にします。

また、いくつかのパラメーターと機能が、以下の記述のとおりに適切に構成、設定されていることを確認します。

• 互換性に関する理由から、ソースとターゲットのデータベース サーバーを同じ MySQL バージョンに揃えます。
• それぞれのテーブルにプライマリ キーを設定します。 テーブルにプライマリ キーがないと、レプリケーション プロセスの速度が低下する場合があります。
• ソースとターゲットのデータベースの文字セットが同じであることを確認します。
• wait_timeout パラメーターを適切な時間に設定します。 時間は、インポートまたは移行するデータまたはワークロードの量によって異なります。
• すべてのテーブルで InnoDB が使用されていることを確認します。 Azure Database for MySQL フレキシブル サーバーでは、InnoDB ストレージ エンジンのみがサポートされています。
• 多数のセカンダリ インデックスがあるテーブルまたは大きいテーブルの場合、パフォーマンスのオーバーヘッドの影響が復元中に表示されます。 CREATE TABLE ステートメントにセカンダリ キーの定義が含まれないように、ダンプ ファイルを変更します。 データをインポートした後、セカンダリ インデックスを再作成して、復元処理中のパフォーマンスの低下を回避します。

最後に、データイン レプリケーションの準備を行います。

• ターゲットの Azure Database for MySQL フレキシブル サーバー インスタンスがソースの Amazon RDS for MySQL サーバーにポート 3306 経由で接続できることを確認します。
• ソース Amazon RDS for MySQL サーバーのポート 3306 で受信と送信の両方のトラフィックが許可されていることを確認します。
• Azure ExpressRoute または Azure VPN Gateway のどちらかを使用して、ソース サーバーへのサイト間接続が提供されていることを確認します。 仮想ネットワークの作成の詳細については、Azure Virtual Network のドキュメントを参照してください。 詳細な手順については、クイックスタートの記事も参照してください。
• ターゲットの Azure Database for MySQL フレキシブル サーバーの IP アドレスを許可するようにソース データベース サーバーのネットワーク セキュリティ グループを構成します。

Azure Database for MySQL のターゲット インスタンスを構成する

Azure Database for MySQL フレキシブル サーバーのターゲット インスタンス (データイン レプリケーションのターゲット) を構成するには、次の手順を実行します。

1. max_allowed_packet パラメーター値を最大値の 1073741824 (1 GB) に設定します。 この値を指定すると、長い行に関連するオーバーフローの問題を回避できます。

2. 移行中は、クエリのログに関連したオーバーヘッドをなくすために、slow_query_log、general_log、audit_log_enabled、query_store_capture_mode の各パラメーターを OFF に設定します。

3. ターゲットの Azure Database for MySQL フレキシブル サーバー インスタンスのコンピューティング サイズを最大の 64 仮想コアにスケールアップします。 このサイズにより、ソース サーバーのデータベース ダンプを復元する際のコンピューティング リソースが補強されます。

   移行の完了後はいつでも、アプリケーションの需要を満たすようにコンピューティングをスケールバックしてかまいません。

4. 移行中の IOPS (移行の最大 IOPS) を高めるために、ストレージ サイズをスケールアップします。

   Note

   使用できる最大 IOPS はコンピューティング サイズによって決まります。 詳細については、Azure Database for MySQL フレキシブル サーバーのコンピューティングとストレージのオプションの記事で、IOPS に関するセクションを参照してください。

ソース Amazon RDS for MySQL サーバーを構成する

Amazon RDS をホストとする MySQL サーバー (データイン レプリケーションの "ソース") を準備、構成するには、次の手順を実行します。

1. ソース Amazon RDS for MySQL サーバーで、バイナリ ログが有効になっていることを確認します。 自動化されたバックアップが有効になっていることを確認します。また、ソース Amazon RDS for MySQL サーバーの読み取りレプリカが存在することを確認します。

2. ソース サーバーのバイナリ ログ ファイルは、ターゲットの Azure Database for MySQL フレキシブル サーバーのインスタンスに変更が適用されるまで確実に保持する必要があります。

   データイン レプリケーションでは、Azure Database for MySQL フレキシブル サーバーがレプリケーション プロセスを管理することはありません。

3. ソース Amazon RDS サーバーでバイナリ ログの保有期間を確認して、バイナリ ログが保有される時間数を調べるには、mysql.rds_show_configuration ストアド プロシージャを呼び出します。

   call mysql.rds_show_configuration;
   +------------------------+-------+-----------------------------------------------------------------------------------------------------------+
   | name | value | description |
   | +------------------------+-------+-----------------------------------------------------------------------------------------------------------+ |
   | binlog retention hours | 24 | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
   | source delay | 0 | source delay specifies replication delay in seconds between current instance and its master. |
   | target delay | 0 | target delay specifies replication delay in seconds between current instance and its future read-replica. |
   | +------------------------+------- +-----------------------------------------------------------------------------------------------------------+ |
   | 3 rows in set (0.00 sec) |
   

4. バイナリ ログの保有期間を構成するために、rds_set_configuration ストアド プロシージャを実行して、必要な期間、ソース サーバーにバイナリ ログが保有されるようにします。 次に例を示します。

   Call mysql.rds_set_configuration('binlog retention hours', 96);
   

   前述のコマンドは、ダンプを作成して復元する際、変更の差分をすぐに反映するのに役立ちます。

   注意

   定義した保有期間に基づいて、バイナリ ログを格納できるだけの十分なディスク領域がソース サーバーに存在することを確認してください。

ソース Amazon RDS for MySQL サーバーからデータのダンプをキャプチャする方法は 2 つあります。 1 つはデータのダンプをソース サーバーから直接キャプチャする方法です。 もう 1 つは Amazon RDS for MySQL の読み取りレプリカからダンプをキャプチャする方法です。

• データのダンプをソース サーバーから直接キャプチャするには、次の手順に従います。

  1. データのダンプにトランザクション整合性を確保するため、数分間、アプリケーションからの書き込みを停止してください。

     データのダンプをキャプチャしているときに書き込みが処理されないよう、一時的に、read_only パラメーターの値を 1 に設定してもかまいません。

  2. ソース サーバーへの書き込みを停止したら、Mysql> Show master status; コマンドを実行して、バイナリ ログのファイル名とオフセットを収集します。

  3. Azure Database for MySQL フレキシブル サーバー インスタンスからのレプリケーションを開始するために、これらの値を保存します。

  4. データのダンプを作成するには、次のコマンドを実行して、mysqldump を実行します。

     $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql
     

• ソース サーバーへの書き込みを停止できない場合や、ソース サーバーでのデータ ダンプのパフォーマンスを許容できない場合は、レプリカ サーバーでダンプをキャプチャします。

  1. ソース サーバーと同じ構成で Amazon MySQL 読み取りレプリカを作成します。 次に、そこでダンプを作成します。

  2. Amazon RDS for MySQL の読み取りレプリカをソース Amazon RDS for MySQL サーバーと同期した状態にします。

  3. 読み取りレプリカのレプリカ ラグが 0 に達したら、mysql.rds_stop_replication ストアド プロシージャを呼び出してレプリケーションを停止します。

     call mysql.rds_stop_replication;
     

  4. レプリケーションが停止したら、レプリカに接続します。 次に、SHOW SLAVE STATUS コマンドを実行して、Relay_Master_Log_File フィールドから最新のバイナリ ログ ファイル名を、Exec_Master_Log_Pos フィールドからログ ファイル位置を取得します。

  5. Azure Database for MySQL フレキシブル サーバー インスタンスからのレプリケーションを開始するために、これらの値を保存します。

  6. Amazon RDS for MySQL の読み取りレプリカからデータのダンプを作成するために、次のコマンドで mysqldump を実行します。

     $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql
     

  Note

  mydumper を使用して、ソース Amazon RDS for MySQL データベースからデータのダンプを並列処理でキャプチャすることもできます。 詳細については、mydumper/myloader を使用して大規模なデータベースを Azure Database for MySQL フレキシブル サーバーに移行することに関するページを参照してください。

ソースとレプリカのサーバーをリンクしてデータイン レプリケーションを開始する

1. mysql のネイティブの復元を使用してデータベースを復元するには、次のコマンドを実行します。

   $ mysql -h <target_server> -u <targetuser> -p < dumpname.sql
   

   Note

   代わりに myloader を使用する場合は、mydumper/myloader を使用して大規模なデータベースを Azure Database for MySQL フレキシブル サーバーに移行することに関するページを参照してください。

2. ソース Amazon RDS for MySQL サーバーにサインインし、レプリケーション ユーザーを設定します。 次に、必要な権限をこのユーザーに付与します。

   • SSL を使用している場合は、次のコマンドを実行します。

     CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
     GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%' REQUIRE SSL;
     SHOW GRANTS FOR syncuser@'%';
     

   • SSL を使用していない場合は、次のコマンドを実行します。

     CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
     GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%';
     SHOW GRANTS FOR syncuser@'%';
     

   データイン レプリケーションの機能は、すべてストアド プロシージャによって実現されています。 すべてのプロシージャについての情報は、「データイン レプリケーション ストアド プロシージャ」を参照してください。 これらのストアド プロシージャは、MySQL シェルまたは MySQL Workbench で実行できます。

3. Amazon RDS for MySQL のソース サーバーと Azure Database for MySQL フレキシブル サーバーのターゲット サーバーをリンクするために、ターゲットの Azure Database for MySQL フレキシブル サーバー インスタンスにサインインします。 次のコマンドを実行して、Amazon RDS for MySQL サーバーをソース サーバーとして設定します。

   CALL mysql.az_replication_change_master('source_server','replication_user_name','replication_user_password',3306,'<master_bin_log_file>',master_bin_log_position,'<master_ssl_ca>');
   

4. ソースの Amazon RDS for MySQL サーバーとターゲットの Azure Database for MySQL フレキシブル サーバー インスタンスとの間のレプリケーションを開始するために、次のコマンドを実行します。

   CALL mysql.az_replication_start;
   

5. レプリカ サーバーでのレプリケーションの状態をチェックするには、次のコマンドを実行します。

   show slave status\G
   

   Slave_IO_Running および Slave_SQL_Running パラメーターの状態が Yes の場合、レプリケーションは開始されており、実行中の状態です。

6. Seconds_Behind_Master パラメーターの値を調べて、ターゲット サーバーの時間差を確認します。

   この値が 0 の場合、ソース サーバーからの更新内容はすべて、ターゲット側で処理済みです。 値が 0 以外の場合、ターゲット サーバーがまだ更新内容を処理しています。

カットオーバーを確実に成功させる

カットオーバーを確実に成功させるには、次の手順に従います。

1. ターゲットの Azure Database for MySQL フレキシブル サーバー インスタンス内で、適切なログインとデータベースレベルのアクセス許可を構成します。
2. ソース Amazon RDS for MySQL サーバーへの書き込みを停止します。
3. ターゲットの Azure Database for MySQL フレキシブル サーバー インスタンスがソース サーバーにキャッチアップ済みで show slave status の Seconds_Behind_Master 値が 0 になっていることを確認します。
4. すべての変更がターゲットの Azure Database for MySQL フレキシブル サーバー インスタンスにレプリケート済みになったので、ストアド プロシージャ mysql.az_replication_stop を呼び出してレプリケーションを停止します。
5. mysql.az_replication_remove_master を呼び出してデータイン レプリケーション構成を削除します。
6. クライアントとクライアント アプリケーションを、ターゲットの Azure Database for MySQL フレキシブル サーバー インスタンスにリダイレクトします。

この時点で移行は完了です。 アプリケーションは、Azure Database for MySQL フレキシブル サーバーを実行するサーバーに接続されています。

関連するコンテンツ

• データベース移行ガイド