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

[アーティクル]
08/15/2024

適用対象: Azure Database for MySQL - 単一サーバー Azure Database for MySQL - フレキシブルサーバー

重要

Azure Database for MySQL シングルサーバーは廃止パスにあります。 Azure Database for MySQL フレキシブルサーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブルサーバーへの移行の詳細については、Azure Database for MySQL シングルサーバーの現状に関するページを参照してください

Note

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

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

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

ソース MySQL サーバーからターゲット 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 とします。
重要

ターゲットの Azure Database for MySQL フレキシブルサーバーがゾーン冗長高可用性 (HA) 構成の場合は、この構成ではデータインレプリケーションがサポートされないことに注意してください。回避策として、サーバーの作成中、ゾーン冗長 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 アドレスを許可するようにソースデータベースサーバーのネットワークセキュリティグループを構成します。

重要

ソースの Amazon RDS for MySQL インスタンスの GTID_mode がオンに設定されている場合は、ターゲットの Azure Database for MySQL フレキシブルサーバーのインスタンスでも GTID_mode がオンに設定されている必要があります。

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

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

max_allowed_packet パラメーター値を最大値の 1073741824 (1 GB) に設定します。この値を指定すると、長い行に関連するオーバーフローの問題を回避できます。
移行中は、クエリのログに関連したオーバーヘッドをなくすために、slow_query_log、general_log、audit_log_enabled、query_store_capture_mode の各パラメーターを OFF に設定します。
ターゲットの Azure Database for MySQL フレキシブルサーバーインスタンスのコンピューティングサイズを最大の 64 仮想コアにスケールアップします。このサイズにより、ソースサーバーのデータベースダンプを復元する際のコンピューティングリソースが補強されます。

移行の完了後はいつでも、アプリケーションの需要を満たすようにコンピューティングをスケールバックしてかまいません。
移行中の IOPS (移行の最大 IOPS) を高めるために、ストレージサイズをスケールアップします。

Note

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

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

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

ソース Amazon RDS for MySQL サーバーで、バイナリログが有効になっていることを確認します。自動化されたバックアップが有効になっていることを確認します。また、ソース Amazon RDS for MySQL サーバーの読み取りレプリカが存在することを確認します。
ソースサーバーのバイナリログファイルは、ターゲットの Azure Database for MySQL フレキシブルサーバーのインスタンスに変更が適用されるまで確実に保持する必要があります。

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

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

mysql> 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)

バイナリログの保有期間を構成するために、rds_set_configuration ストアドプロシージャを実行して、必要な期間、ソースサーバーにバイナリログが保有されるようにします。次に例を示します。
```
Mysql> 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 ストアドプロシージャを呼び出してレプリケーションを停止します。
```
Mysql> 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 フレキシブルサーバーに移行することに関するページを参照してください。

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

mysql のネイティブの復元を使用してデータベースを復元するには、次のコマンドを実行します。
```
$ mysql -h <target_server> -u <targetuser> -p < dumpname.sql
```
Note

代わりに myloader を使用する場合は、mydumper/myloader を使用して大規模なデータベースを Azure Database for MySQL フレキシブルサーバーに移行することに関するページを参照してください。
ソース Amazon RDS for MySQL サーバーにサインインし、レプリケーションユーザーを設定します。次に、必要な権限をこのユーザーに付与します。
- SSL を使用している場合は、次のコマンドを実行します。
```
Mysql> CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
Mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%' REQUIRE SSL;
Mysql> SHOW GRANTS FOR syncuser@'%';
```
- SSL を使用していない場合は、次のコマンドを実行します。
```
Mysql> CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
Mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%';
Mysql> SHOW GRANTS FOR syncuser@'%';
```
データインレプリケーションの機能は、すべてストアドプロシージャによって実現されています。すべてのプロシージャについての情報は、「データインレプリケーションストアドプロシージャ」を参照してください。これらのストアドプロシージャは、MySQL シェルまたは MySQL Workbench で実行できます。
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>');
```
ソースの Amazon RDS for MySQL サーバーとターゲットの Azure Database for MySQL フレキシブルサーバーインスタンスとの間のレプリケーションを開始するために、次のコマンドを実行します。
```
Mysql> CALL mysql.az_replication_start;
```
レプリカサーバーでのレプリケーションの状態をチェックするには、次のコマンドを実行します。
```
Mysql> show slave status\G
```
Slave_IO_Running および Slave_SQL_Running パラメーターの状態が Yes の場合、レプリケーションは開始されており、実行中の状態です。
Seconds_Behind_Master パラメーターの値を調べて、ターゲットサーバーの時間差を確認します。

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

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

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

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

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

次のステップ

Azure Database for MySQL フレキシブルサーバーへのデータベース移行に関するさらに詳しい情報については、データベース移行ガイドを参照してください。
MySQL/PostgreSQL アプリを Azure マネージドサービスに簡単に移行する方法のビデオをご覧ください。 MySQL アプリを Azure Database for MySQL フレキシブルサーバーに移行する方法を示すデモが含まれています。

次の方法で共有

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

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

クライアントの場所

クライアントの容量

前提条件

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

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

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

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

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

クライアントの場所

クライアントの容量

前提条件

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

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

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

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

次のステップ

フィードバック

その他のリソース

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

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

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