オープンソース ツールで Azure Database for MySQL - 単一サーバーを Azure Database for MySQL - フレキシブル サーバーに移行する
mydumper や myloader などのオープンソース ツールとデータイン レプリケーションを組み合わせて使用することで、アプリケーションのダウンタイムを最小限に抑えながら、Azure Database for MySQL - 単一サーバーのインスタンスを Azure Database for MySQL - フレキシブル サーバーに移行できます。
注意
この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。 ソフトウェアからこの用語が削除された時点で、この記事から削除します。
データイン レプリケーションは、バイナリ ログ ファイルの配置方法に基づいてソース サーバーへのデータ変更を宛先サーバーにレプリケートする技術です。 このシナリオでは、ソース (データベースの変更が行われる元の場所) として動作する MySQL インスタンスが更新と変更を "イベント" としてバイナリ ログに書き込みます。 バイナリ ログ内の情報は、記録されるデータベースの変更に応じてさまざまなログ形式で保存されます。 レプリカは、ソースからバイナリ ログを読み取り、レプリカのローカル データベース上でバイナリ サインのイベントを実行するように構成されます。
Azure Database for MySQL のあるインスタンスから別のインスタンスにデータを同期するようにデータイン レプリケーションを設定する場合、プライマリ (ソース データベース) からレプリカ (ターゲット データベース) へのアプリケーションの選択的なカットオーバーを実行できます。
このチュートリアルでは、mydumper および myloader とデータイン レプリケーションを使用して、サンプル データベース (classicmodels) を Azure Database for MySQL - 単一サーバーのインスタンスから Azure Database for MySQL - フレキシブル サーバーのインスタンスに移行し、データを同期します。
このチュートリアルでは、以下の内容を学習します。
- さまざまなシナリオでデータイン レプリケーションのネットワーク設定を構成する。
- プライマリとレプリカの間でデータイン レプリケーションを構成する。
- レプリケーションをテストする。
- カットオーバーして移行を完了する。
前提条件
このチュートリアルを完了するには、次のものが必要です。
バージョン 5.7 または 8.0 を実行している Azure Database for MySQL 単一サーバーのインスタンス。
注意
Azure Database for MySQL 単一サーバー バージョン 5.6 を実行している場合、インスタンスを 5.7 にアップグレードしてからデータイン レプリケーションを構成してください。 詳細については、「Azure Database for MySQL 単一サーバーでのメジャー バージョンのアップグレード」を参照してください。
Azure Database for MySQL フレキシブル サーバーのインスタンス。 詳細については、Azure Database for MySQL フレキシブル サーバーでのインスタンスの作成に関する記事を参照してください。
注意
ゾーン冗長高可用性サーバーでのデータイン レプリケーションの構成は、サポートされていません。 ターゲット サーバーでゾーン冗長 HA を使用したい場合は、これらの手順を実行してください。
- ゾーン冗長 HA が有効なサーバーを作成します
- HA を無効にします
- 記事に従ってデータイン レプリケーションを設定します
- カットオーバー後に、データイン レプリケーション構成を削除します
- HA を有効にします
"ソースとターゲットのサーバーで GTID_Mode の設定が同じになるようにしてください。 "
MySQL Workbench を使用して接続し、データベースを作成する。 詳細については、MySQL Workbench を使用した接続とデータ クエリに関する記事を参照してください。
Linux を実行し、自分のソースおよびターゲット データベースをホストする Azure VM を、同じリージョン (またはプライベート アクセスを使用する同じ VNet 上) に配置するようにする。
mysql クライアントまたは MySQL Workbench (クライアント ツール) を自分の Azure VM にインストールする。 プライマリとレプリカの両方のサーバーに接続できるようにしてください。 この記事では、mysql クライアントがインストールされています。
mydumper または myloader を自分の Azure VM にインストールする。 詳細については、mydumper および myloader に関する記事を参照してください。
classicmodels データベースのサンプル データベース スクリプトをダウンロードして、ソース サーバーで実行する。
ソース サービスで binlog_expire_logs_seconds を構成し、確実にレプリカでのコミットの変更前に binlog が消去されないようにします。 カットオーバーが成功したら、この値をリセットできます。
ネットワーク要件の構成
データイン レプリケーションを構成するには、ターゲットがポート 3306 経由でソースに接続できるようにする必要があります。 ソースのエンドポイント設定の種類に応じて、次の手順のうち適切な方を実行してください。
- ソースでパブリック エンドポイントが有効な場合は、ファイアウォール規則で [Azure サービスへのアクセスを許可] を有効にして、確実にターゲットがソースに接続できるようにします。 詳細については、Azure Database for MySQL のファイアウォール規則に関する記事を参照してください。
- ソースでプライベート エンドポイントと パブリック アクセスの拒否 が有効な場合は、ターゲットをホストする同じ VNet にプライベート リンクをインストールします。 詳細については、Azure Database for MySQL の Private Link に関する記事を参照してください。
データイン レプリケーションの構成
データイン レプリケーションを構成するには、次の手順を実行します。
mysql クライアント ツールをインストールした Azure VM にサインインします。
mysql クライアント ツールを使用してソースとターゲットに接続します。
mysql クライアント ツールを使用し、次のコマンドを実行して、log_bin がソースで有効かどうかを判定します。
SHOW VARIABLES LIKE 'log_bin';注意
これは、最大 16 TB をサポートする大容量ストレージを備えた Azure Database for MySQL 単一サーバーでは既定で有効です。
ヒント
これは、最大 4 TB をサポートする Azure Database for MySQL 単一サーバーでは既定で有効になっていません。 ただし、ソース サーバーの読み取りレプリカを昇格してから読み取りレプリカを削除すると、パラメーターが ON に設定されます。
ソース サーバーの SSL 強制に基づいて、適切なコマンドを実行してレプリケーション アクセス許可付きでソース サーバーにユーザーを作成します。
SSL を使用している場合は、次のコマンドを実行します。
CREATE USER 'syncuser'@'%' IDENTIFIED BY '<password>'; GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;SSL を使用していない場合は、次のコマンドを実行します。
CREATE USER 'syncuser'@'%' IDENTIFIED BY '<password>'; GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';mydumper を使用してデータベースをバックアップするには、mydumper または myloader をインストールした Azure VM で次のコマンドを実行します。
mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl --regex '^(classicmodels\.)' -L mydumper-logs.txtヒント
オプション --trx-consistency-only は、バックアップを作成する際にトランザクションの一貫性を確保するために必要です。
- mydumper において、mysqldump の --single-transaction に相当します。
- すべてのテーブルが InnoDB のときに役立ちます。
- "main" スレッドでは、"dump" スレッドがトランザクションを開始するまでの間だけ、グローバル ロックを保持する必要があります。
- 最短期間のグローバル ロックを提供します
"main" スレッドでは、"dump" スレッドがトランザクションを開始するまでの間だけ、グローバル ロックを保持する必要があります。
このコマンドの変数は以下で説明します。
HOW-TO-MANAGE-FIREWALL-PORTAL --host: プライマリ サーバーの名前
- --user: ユーザーの名前 (プライマリ サーバーが Azure Database for MySQL - 単一サーバーを実行しているため、username@servername の形式)。 サーバー管理者、または SELECT と RELOAD のアクセス許可を持っているユーザーを使用できます。
- --Password: 上記のユーザーのパスワード
mydumper の使用について詳しくは、mydumper および myloader に関する記事を参照してください
次のコマンドを実行して、メタデータ ファイルを読み取り、バイナリ ログ ファイル名とオフセットを特定します。
cat ./backup/metadataこのコマンドの ./backup は、前の手順のコマンドで使用された出力ディレクトリを参照します。
次の画像に示すような結果が表示されるはずです。
バイナリ ファイルの名前はこの後の手順で使用するため、必ずメモしておいてください。
次のコマンドを実行し、myloader を使用してデータベースを復元します。
myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txtこのコマンドの変数は以下で説明します。
- --host: レプリカ サーバーの名前
- --user: ユーザーの名前。 サーバー管理者、またはスキーマとデータをデータベースに復元できる読み取り/書き込みアクセス許可を持つユーザーを使用できます
- --Password: 上記のユーザーのパスワード
プライマリ サーバーの SSL 強制に応じて、mysql クライアント ツールを使用してレプリカ サーバーに接続し、次の手順を実行します。
SSL 強制が有効な場合は、次のようになります。
i. SSL 経由で Azure Database for MySQL サーバーと通信するために必要な証明書をこちらからダウンロードします。
ii. メモ帳でファイルを開いて、内容を "PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE" セクションに貼り付けます。
SET @cert = '-----BEGIN CERTIFICATE----- PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE -----END CERTIFICATE-----'iii. データイン レプリケーションを構成するために、次のコマンドを実行します。
CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<password>', 3306, '<File_Name>', <Position>, @cert);注意
手順 6 で取得した情報から位置とファイル名を特定してください。
SSL 強制が有効でない場合は、次のコマンドを実行します。
CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<password>', 3306, '<File_Name>', <Position>, '');
レプリカ サーバーからレプリケーションを開始するには、下のストアド プロシージャを呼び出します。
call mysql.az_replication_start;レプリケーションの状態をチェックするには、レプリカ サーバーで次のコマンドを実行します。
show slave status \G;注意
MySQL Workbench を使用している場合は、\G 修飾子は不要です。
Slave_IO_Running と Slave_SQL_Running の状態が Yes で、Seconds_Behind_Master の値が 0 だと、レプリケーションは正常に機能しています。 Seconds_Behind_Master は、レプリカの遅延を示します。 0 を超える値の場合は、レプリカが更新を処理しています。
レプリケーションをテストする (省略可能)
データイン レプリケーションが適切に動作していることを確かめるために、プライマリのテーブルに対する変更がレプリカにレプリケートされたことを確認できます。
テストに使用するテーブル (たとえば customers テーブル) を特定します。次に、そこに含まれているエントリの数がプライマリとレプリカのサーバーで同じであることを確認するために、各サーバーで次のコマンドを実行します。
select count(*) from customers;後で比較するために、エントリの数をメモします。
レプリケーションをテストするために、プライマリ サーバーの customers テーブルへのデータの追加を試行して、新しいデータがレプリケートされたことを確認します。 この場合、プライマリ サーバーのテーブルに 2 つの行を追加してから、それらがレプリカ サーバーにレプリケートされたことを確認します。
次のコマンドを実行して、プライマリ サーバー上の customers テーブルに行を挿入します。
insert into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values (<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');レプリケーションの状態をチェックするには、show slave status \G を呼び出して、レプリケーションが想定どおりに動作していることを確認します。
数が同じあることを確認するには、レプリカ サーバーで次のコマンドを実行します。
select count(*) from customers;
カットオーバーを確実に成功させる
カットオーバーを確実に成功させるために、次のタスクを実行します。
- サーバーレベルの適切なファイアウォールと仮想ネットワーク規則を構成して、ターゲット サーバーに接続します。 ポータルからソースとターゲットのファイアウォール規則を比較できます。
- ターゲット サーバーで適切なログインとデータベース レベルのアクセス許可を構成します。 比較対象のソースおよびターゲット サーバーで SELECT FROM mysql.user; を実行できます。
- Azure Database for MySQL 単一サーバーへの受信接続がすべて停止されるようにします。
ヒント
Azure Database for MySQL 単一サーバーを読み取りのみに設定できます。
- show slave status \G を実行し、Seconds_Behind_Master パラメーターの値が 0 であることを確認して、レプリカがプライマリに同期されたのを確かめます。
- クライアントとクライアント アプリケーションを Azure Database for MySQL フレキシブル サーバーのターゲット インスタンスにリダイレクトします。
- mysql.az_replication_stop ストアド プロシージャを実行して最終的なカットオーバーを実行します。これで、レプリカ サーバーからのレプリケーションが停止します。
- "mysql.az_replication_remove_master を呼び出して" データイン レプリケーション構成を削除します。
この時点で、アプリケーションが新しい Azure Database for MySQL フレキシブル サーバーに接続されて、ソースの変更がターゲットにレプリケートされなくなります。 Azure Portal を使用した Azure Database for MySQL ファイアウォール規則の作成と管理