Database Migration Service を使用して特定の MySQL データベースを移行する

※この投稿は米国時間 2024 年 7 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

MySQL、PostgreSQL、SQL Server 用のフルマネージド リレーショナル データベース サービスである Cloud SQL への移行をお考えの場合、ソース インスタンスからすべてのデータまたはデータのサブセットを移行する方法があります。Google Cloud の Database Migration Service（DMS）では、すべてのデータベースとスキーマからすべてのテーブルを簡単に移行できます。しかし、このツールを使用して、選択したデータベースまたはテーブルだけを移行する方法を見分けるのは難しいかもしれません。

このブログ記事では、オンプレミスの MySQL、Cloud SQL for MySQL、Amazon RDS for MySQL など、考えられる複数の種類のソースからデータベースとテーブルのサブセットを移行するソリューションについて説明します。この例のすべての MySQL インスタンスでは、ソース MySQL インスタンスに複数のデータベースが構成されています。このプロセスでは、ソース インスタンスでバイナリログをあらかじめ有効にしておく必要があります。以下のすべてを移行する方法を紹介します。

1. GTID が有効または無効になっているインスタンスを含む、オンプレミスで稼働している MySQL。

2. GTID が有効になっている Cloud SQL for MySQL。

3. GTID が有効になっている AWS RDS for MySQL。

ターゲットは Cloud SQL for MySQL インスタンスとなります。各種の移行について詳しく見ていきましょう。

オンプレミスで稼働している MySQL

ソース MySQL インスタンスに以下のように 2 つのデータベース（test と test1）があり、DMS を使用して「test」データベースのみを Cloud SQL for MySQL に移行したいとします。

オンプレミスの MySQL インスタンスから 1 つ以上の特定のデータベースを移行するには、以下の 4 つのステップを完了する必要があります。

1. mysqldump を使用して、整合性のある最初のスナップショットを取得する。

2. 手動ダンプファイルを Google Cloud Storage バケットに転送する。

3. 新規または既存の Cloud SQL for MySQL インスタンスに移行する場合は、replicate_do_db レプリケーション フィルタフラグを設定する。

4. Database Migration Service の連続移行ジョブを構成し、Cloud Storage バケットから初期読み込みを実行する。

上述のシナリオに沿って、それぞれのステップを見てみましょう。

1. mysqldump を使用して、整合性のある最初のスナップショットを取得する

まず mysqldump を使用して、整合性のあるスナップショットで初期ダンプを取得し、レプリケーションの設定に使用するバイナリログ座標を取得します。以下の 3 つのオプションを使用する必要があります。

• single-transaction - 繰り返し可能な読み取りトランザクションで整合性のあるスナップショットを取得します

• master-data=1 - 「CHANGE MASTER TO」ステートメントをダンプファイルに書き込みます

• set-gtid-purged=AUTO - ソース インスタンスの gtid_mode に基づいて GTID 情報を書き込みます

レプリケーション ユーザーまたは mysqldump を実行するユーザーに必要な権限は、以下のとおりです。

• RELOAD（グローバル読み取りロックを取得するための FLUSH テーブル用）

• REPLICATION_CLIENT（SHOW MASTER STATUS 用）

• SELECT

• SHOW VIEW

これらのオプションを指定した場合、mysqldump が実行するステートメントは以下のようになります。

1. FLUSH LOCAL TABLES

2. FLUSH TABLES WITH READ LOCK

3. SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ

4. START TRANSACTION

5. SHOW VARIABLES LIKE 'gtid_mode'

6. SELECT @@GLOBAL.GTID_EXECUTED

7. SHOW MASTER STATUS

8. UNLOCK TABLES

9. トランザクションはすべてのテーブルとビューをダンプし続けます

さらに、同じユーザーが Database Migration Service からレプリケーションを設定する場合、REPLICATION_SLAVE も必要となります。

ソース MySQL インスタンスのバージョンが 8.0.26 以降の場合、master-data=1 の代わりに source-data=1 を使用します。上記の mysqldump オプションは整合性のあるデータダンプを取得し、バックアップの最初の GTID の状態（GTID が有効なインスタンスの場合）をキャプチャして、レプリケーションの開始点となるバイナリログ座標を記録します。

2. 手動ダンプファイルを Google Cloud Storage バケットに転送する

以下の mysqldump コマンドを実行すると、「test」データベースの手動ダンプが取得され、Cloud Storage の「mysqldumpsom」バケットに転送されます。

ソースで GTID が構成されている場合、ダンプファイルがステートメント SET @@GLOBAL.gtid_purged=<gtid executed>（SELECT @@GLOBAL.GTID_EXECUTED）を使用して GTID ベースのレプリケーションを設定するための GTID 情報を書き込みます。

バイナリログ ベースのレプリケーションでは、以下の情報がダンプファイルに書き込まれます（mysqldump で master-data=1 が指定されているため）。

3. Cloud SQL インスタンスにレプリケーション フィルタを設定する

Database Migration Service を使用して Cloud SQL に移行する場合、プロセスを開始するときに新しいインスタンスを作成するか、既存の空の Cloud SQL インスタンスを選択するかの 2 つのオプションがあります。  

この例では、「test」データベースだけを移行したい場合、「replicate_do_db」フラグを設定して、移行したいデータベースを指定する必要があります。このフラグは、Cloud SQL レプリカに対しリレーログから指定されたデータベースのステートメントだけを読み込むように指示するレプリケーション フィルタです。DMS でインスタンスを作成している場合、「移行先の定義」のステップでこのフラグを設定できます。

既存のインスタンスを使用している場合、DMS が Cloud SQL インスタンスを降格させてリードレプリカに変換すると、このフラグを設定できます。インスタンスがスタンドアロン モードのときはこのフラグを設定できません。複数のデータベースを一度に複製する場合は、このフラグの値を移行対象のすべてのデータベースのカンマ区切りのリストに設定します。

4. Database Migration Service の継続移行ジョブを構成する

Database Migration Service のジョブを作成するときは、[移行ジョブの説明] のセクションで、移行ジョブのタイプとして [継続的] を選択します。Database Migration Service の次の画面の [ソースの定義] セクションで手動ダンプの場所を以下のように指定します。

Database Migration Service は、「移行先の定義」で指定した Cloud SQL インスタンスにデータをインポートし、昇格の実行を決定するまでオンプレミスの MySQL データベースから継続的レプリケーション（CDC）を実行します。

移行先 Cloud SQL for MySQL インスタンスには、以下のように選択したデータベースのみが複製されます。

GTID を基にレプリケーションを行う Cloud SQL for MySQL

既存の Cloud SQL for MySQL インスタンスから特定のデータベースを移行したい場合があります。または、ワークロードの分離を目的として、複数データベースの Cloud SQL インスタンスから新しい Cloud SQL for MySQL インスタンスにデータベースを移行したい場合もあります。実行する手順は、オンプレミスの MySQL サーバーから mysqldump を取得するのと似ています。「root」ユーザーとして mysqldump を実行する場合、Cloud SQL for MySQL の「root」ユーザーは必要な権限を持っているため、追加の権限を付与する必要はありません。これは、以下のコマンドで確認できます。

Cloud SQL for MySQL は GTID を使用するため、ダンプファイルには前述のとおり「SET @@GLOBAL.gtid_purged=<gtid executed>」エントリがあります。

DMS ジョブが設定され、レプリケーション中状態になると、ターゲット Cloud SQL インスタンスの GTID パージ済み情報は、mysqldump ファイルにキャプチャされた GLOBAL.GTID_PURGED 値と同じになります。

これは、以下のコマンドで確認できます。

GTID を基にレプリケーションを行う AWS RDS for MySQL

この投稿で述べているとおり、AWS RDS ユーザーは、整合性のあるバイナリログの位置を取得するために --single-transaction とともに使用するよう Google が提案している --master-data=1 および --set-gtid-purged=AUTO で実行しているときに mysqldump が必要とする「FLUSH TABLES WITH READ LOCK」を実行できません。ここでは、AWS RDS リードレプリカから移行するための回避策を提示します。

AWS RDS リードレプリカからの移行

AWS RDS リードレプリカからの移行の手順は、オンプレミスまたは Cloud SQL からの移行と同様ですが、ソースのレプリケーションを停止するステップがいくつか追加されます。

1. 自動バックアップを有効にして、RDS リードレプリカのバイナリ ロギングを有効にします。また、binlog_format を「ROW」に設定することもおすすめします。これは、プライマリ インスタンスの DB パラメータ グループを更新することで有効にできます。

2. バイナリログの保持の構成を更新して、レプリケーションが行われるのに十分な期間を指定します。

3. これで、データダンプを開始できるようになりました。まず、データの整合性が保たれるよう、RDS リードレプリカのレプリケーションを停止します。

4. 以下の mysqldump を使用して、初期スナップショットを取得し、ローカルファイルに保存します。

5. RDS リードレプリカで「SHOW MASTER STATUS」コマンドを実行して、現在の Executed_Gtid_Set を取得します。

6. ダンプファイルが生成されると、RDS リードレプリカのレプリケーションを再開できます。

7. ローカルのダンプファイルを手動で更新し、以下のステートメントを含めます。

8. ローカルの手動ダンプファイルを Google Cloud Storage バケットに転送し、移行します。

残りの手順は、オンプレミスまたは Cloud SQL からの移行と同じです。

結論と次のステップ

このブログ記事では、mysqldump と DMS を使用して、選択型 MySQL データベースを空の Cloud SQL インスタンスに移行する方法を説明しました。mysqldump はシングル スレッド プロセスであるため、移行時間は mysqldump によって制限されます。今後のブログ記事では、選択型 MySQL データベースの移行を行いながら初期ダンププロセスを同時処理する方法とともに、空でない Cloud SQL インスタンスにデータベースを移行する方法を紹介します。Cloud SQL の利用を開始するには、クイックスタート: Cloud Shell から Cloud SQL for MySQL に接続する | Google Cloud をご覧ください。データベース移行の詳細についてもご確認ください。

-Cloud SQL データ移行担当ソフトウェア エンジニア Holly Xu

-データ マネジメント スペシャリスト Somdyuti Paul