自己管理 MySQL データベースから ApsaraDB RDS for MySQL への移行 - ApsaraDB RDS

Data Transmission Service (DTS) を使用して、オンプレミス、Elastic Compute Service (ECS) インスタンス、または他のクラウド上にある自己管理 MySQL データベースを、ダウンタイムを最小限に抑えるか、ゼロダウンタイムで ApsaraDB RDS for MySQL に移行します。

このガイドでは、以下の内容について説明します。

移行ソリューションの選択
ソースデータベースとターゲット RDS インスタンスの準備
移行タスクの設定と実行
データの検証とアプリケーションの切り替え

移行ソリューションの選択

DTS は、ソリューションを構築するために組み合わせることができる 3 種類の移行タイプをサポートしています。

移行タイプ	機能
スキーマ移行	データベース、テーブル、ビュー、トリガー、ストアドプロシージャ、および関数の構造をコピーします。DTS は、ビューとストアドプロシージャの `DEFINER` を `INVOKER` に変換します。
完全なデータ移行	ソースデータベースからターゲット RDS インスタンスに既存のすべてのデータをコピーします。
増分データ移行	完全なデータ移行が開始された後、ソースデータベースからの新しい変更を継続的にコピーし、ほぼゼロダウンタイムでの移行を可能にします。

ダウンタイムの許容度に基づいて、これらのタイプを組み合わせてください。

ソリューション	ダウンタイム	データ整合性	制限事項	コスト	最適な用途
スキーマ + 完全 + 増分 (推奨)	ゼロ	移行中に書き込みが継続されても、移行完了後に整合性が保たれます	手動で停止するまで増分移行が実行されます	有料 (増分)	本番環境、ゼロダウンタイム要件
スキーマ + 完全	完全移行の期間	移行中にソースが読み取り専用の場合のみ整合性が保たれます。書き込みが発生すると不整合になります	データ整合性を保つためにソースを静止させる必要があります	無料	テスト環境、許容可能なダウンタイム

課金

スキーマ移行、完全なデータ移行、およびパブリックネットワークのトラフィックは無料です。以下の項目は課金対象です。

増分データ移行：実行中に課金されます。一時停止中または失敗した場合は課金されません。
データ検証：検証されたデータ量に基づいて課金されます。詳細については、「データ検証料金」をご参照ください。

前提条件

開始する前に、以下を確認してください。

ソース MySQL データベースがバージョン 5.1、5.5、5.6、5.7、または 8.0 を実行していること
ターゲット RDS for MySQL インスタンスの利用可能なストレージ容量が、ソースデータベースよりも大きいこと

制限事項

移行タスクを設定する前に、以下の制限事項を確認してください。

ソースデータベースの要件：

移行するすべてのテーブルには、プライマリキーまたは一意の値を持つ一意制約が必要です。そうでない場合、ターゲット RDS インスタンスに重複データが含まれる可能性があります。
スキーマ移行および完全なデータ移行中は、DDL 操作 (スキーマ変更) を避けてください。DDL 操作が検出されると、移行タスクは失敗します。
スキーマ + 完全移行のみ (増分なし) を実行する場合、データ整合性を維持するために移行中はソースデータベースへの書き込みを避けてください。
ソースデータベースサーバーには、十分なアウトバウンド帯域幅が必要です。帯域幅が不足すると、移行速度が低下します。
増分データ移行の場合、バイナリロギングを有効にし、正しく設定する必要があります (「バイナリロギングの設定」をご参照ください)。
ソースデータベースがデュアルプライマリクラスターの場合、移行タスクの実行中にプライマリ/セカンダリスイッチオーバーを避けてください。スイッチオーバーが発生すると、タスクは失敗します。
ソースデータベースが MySQL 8.0.23 以降を実行しており、不可視カラム (プライマリキーのないテーブルに対して自動生成された不可視プライマリキーを含む) を含んでいる場合は、移行前にそれらを可視にしてください。
```
ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;
```
詳細については、「Invisible Columns」および「Generated Invisible Primary Keys」をご参照ください。

移行できないコンテンツ：

コメント構文を使用して定義されたパーサー
物理バックアップおよび復元操作、または外部キーのカスケード操作からのデータ (バイナリログに記録されない)
インデックスとパーティション

その他の制限事項：

ソースとターゲットの MySQL バージョンは一致している必要があります。
移行するデータに 4 バイト文字 (珍しい文字や絵文字) が含まれている場合、ターゲット RDS インスタンスとそのテーブルは utf8mb4 文字セットを使用する必要があります。スキーマ移行の場合、ターゲット RDS インスタンスで character_set_server を utf8mb4 に設定してください。
列名マッピングが設定されている場合、1 つの移行タスクでサポートされるテーブルは最大 1,000 です。より大規模な移行の場合は、複数のタスクを作成してください。
DTS は ROUND(COLUMN, PRECISION) を使用して FLOAT および DOUBLE 列から値を取得します。精度が指定されていない場合、FLOAT は 38 桁、DOUBLE は 308 桁にデフォルト設定されます。これらの精度設定が要件を満たしていることを確認してください。
DTS は失敗したタスクを最大 7 日間再試行します。ワークロードをターゲットに切り替える前に、失敗したタスクを停止またはリリースするか、ターゲットに対する DTS の書き込み権限を取り消して、古いデータが新しいデータを上書きするのを防いでください。
DTS タスクの実行に失敗した場合、DTS のテクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動されたり、そのパラメーターが変更されたりすることがあります。
ソースデータベース名が ApsaraDB RDS for MySQL の命名規則に従っている場合、DTS は自動的にターゲットデータベースを作成します。従っていない場合は、手動でデータベースを作成してから移行タスクを設定してください。
pt-online-schema-change を使用したソースデータベースでのオンライン DDL 操作はサポートされておらず、タスクの失敗を引き起こします。代わりに DMS または gh-ost を使用してください。
DTS は、バイナリログの位置を進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS を実行します (test データベースを作成)。
ターゲット RDS インスタンスで HA スイッチオーバーが発生した後、ANALYZE TABLE <table_name> を実行して、データがメモリだけでなくディスクに書き込まれていることを確認してください。
ソースデータベースで TDE (透過的データ暗号化) が有効になっている場合、3 つすべての移行タイプがサポートされます。EncDB 機能が有効になっている場合、完全なデータ移行はサポートされません。
増分データ移行では、読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンスはトランザクションログを記録しないため、ソースデータベースとして使用できません。

フェーズ 1：移行の準備

ステップ 1：DTS へのクラウドリソースへのアクセス権限の付与

Alibaba Cloud アカウントでクイック承認ページを開き、[Authorize] をクリックします。
EntityAlreadyExists.Role および EntityAlreadyExists.Role.Policy メッセージが表示された場合、権限付与はすでに完了しています。

ステップ 2：データベースアカウントの作成

ソースデータベース用のアカウント

ソースデータベースで以下のステートメントを実行します。

-- dts_user と Your_Password123 を実際の値に置き換えてください。
CREATE USER 'dts_user'@'%' IDENTIFIED BY 'Your_Password123';

-- スキーマ移行と完全なデータ移行に必要です。
GRANT SELECT ON *.* TO 'dts_user'@'%';

-- 増分データ移行に必要です。
GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW ON *.* TO 'dts_user'@'%';

-- DTS がバイナリログの位置を進めるためのハートビートテーブルを作成するために必要です。
GRANT CREATE ON *.* TO 'dts_user'@'%';

FLUSH PRIVILEGES;

以下の表は、各移行タイプに必要な最小権限をまとめたものです。

移行タイプ	必要な権限
スキーマ移行	SELECT
完全なデータ移行	SELECT
増分データ移行	SELECT; REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW; CREATE (ハートビートテーブル用)

ターゲット RDS インスタンス用のアカウント

RDS コンソールで、リージョンを選択し、ターゲット RDS インスタンスの ID をクリックします。
左側のナビゲーションウィンドウで [アカウント] をクリックし、次に [アカウントの作成] をクリックします。
[アカウントタイプ] を [特権アカウント] に設定し、残りのパラメーターを入力します。

ターゲットアカウントには、ターゲット RDS インスタンスに対する読み取りおよび書き込み権限が必要です。

ステップ 3：ソースデータベースへのアクセス設定

ソースデータベースのデプロイメントに一致するアクセス方法を選択します。

ソースデータベース	アクセス方法	構成
パブリック IP アドレスを持つオンプレミス	パブリック IP	ソースデータベースの IP ホワイトリストに DTS サーバーの CIDR ブロックを追加する
パブリック IP アドレスを持たないオンプレミス	Cloud Enterprise Network (CEN)、データベースゲートウェイ、または VPN Gateway/Express Connect/Smart Access Gateway (SAG)	IP ホワイトリストに DTS サーバーの CIDR ブロックを追加し、選択した方法のネットワークアクセス構成を完了します
ECS インスタンス上のデータベース	[ECS インスタンス]	設定は不要です

増分データ移行のためのバイナリロギングの設定

増分データ移行を実行しない場合は、このステップをスキップしてください。

増分データ移行のためには、ソースデータベースでバイナリロギングを有効にする必要があります。以下のパラメーターを設定し、変更を有効にするために MySQL を再起動してください。

バイナリロギングのパラメーター

パラメーター	必須の値	注意
`log_bin`	`mysql_bin` (または任意のパス)	バイナリロギングを有効にします
`binlog_format`	`row`	DTS が行レベルの変更をキャプチャするために必要です
`binlog_row_image`	`full`	MySQL 5.6 以降で必要です
`server_id`	1 より大きい任意の整数	レプリケーショントポロジー内で一意である必要があります
`expire_logs_days`	7 以上	MySQL 8.0 より前のバージョン。デフォルト：0 (有効期限なし)
`binlog_expire_logs_seconds`	604800 以上 (7 日間)	MySQL 8.0 以降。デフォルト：2592000 (30 日間)
`log_slave_updates`	`ON`	デュアルプライマリクラスターのみ

バイナリログは少なくとも 7 日間保持してください。保持期間が短すぎると、DTS が必要なバイナリログを取得できず、データの不整合や損失が発生する可能性があります。

Linux での設定

/etc/my.cnf を編集します。

log_bin=mysql_bin
binlog_format=row

# MySQL 8.0 より前：
# expire_logs_days=7

# MySQL 8.0 以降：
# binlog_expire_logs_seconds=604800

server_id=2
binlog_row_image=full

# デュアルプライマリクラスターのみ：
# log_slave_updates=ON

MySQL を再起動します。
```
/etc/init.d/mysqld restart
```

Windows での設定

my.ini を編集します。

log_bin=mysql_bin
binlog_format=row

# MySQL 8.0 より前：
# expire_logs_days=7

# MySQL 8.0 以降：
# binlog_expire_logs_seconds=604800

server_id=2
binlog_row_image=full

# デュアルプライマリクラスターのみ：
# log_slave_updates=ON

MySQL を再起動します。
```
net stop mysql
net start mysql
```

フェーズ 2：移行タスクの設定

DTS コンソールにログインし、左側のナビゲーションウィンドウで [データ移行] をクリックし、次に [タスクの作成] をクリックします。

ソースデータベースとターゲット RDS インスタンスを設定します。

ソースデータベース

パラメーター	値
データベースタイプ	MySQL
アクセス方法	ステップ 3 で設定した方法を選択します (例：[パブリック IP])
インスタンスリージョン	ソースデータベースが配置されているリージョン
[ドメイン名または IP]	ソースデータベースのパブリックエンドポイントまたは IP アドレス
ポート	ソースデータベースのサービスポート。デフォルト：3306
[データベースアカウント]	ステップ 2
データベースパスワード	アカウントのパスワード
暗号化	[非暗号化]、SSL が有効な場合は [SSL 暗号化] (CA 証明書をアップロードし、[CA キー] を設定)

ターゲット RDS インスタンス

パラメーター	値
データベースタイプ	MySQL
アクセス方法	Alibaba Cloud インスタンス
インスタンスリージョン	ターゲット RDS インスタンスのリージョン
Alibaba Cloud アカウント間のデータレプリケーション	いいえ
RDS インスタンス ID	ターゲット RDS インスタンスの ID
データベースアカウント	ステップ 2
データベースパスワード	アカウントのパスワード
暗号化	暗号化なしまたは SSL 暗号化。SSL 暗号化の場合、まず送信先の RDS インスタンスでSSL 暗号化を有効にしてください

[接続をテストして続行] をクリックします。ダイアログボックスで [接続をテスト] をクリックします。テストが失敗した場合は、続行する前にエラーメッセージに基づいて問題を修正してください。

移行するオブジェクトを設定します。

オブジェクトの設定

[オブジェクトの設定] タブで、移行タイプを設定し、移行するオブジェクトを選択します。[次へ：詳細設定] をクリックします。

パラメータ	説明
移行タイプ	完全移行の場合は、[スキーマ移行] と [完全データ移行] を選択します。ダウンタイムを最小限に抑えるには、[増分データ移行] を追加します。
ソースオブジェクト	移行するデータベース、テーブル、またはカラムを選択し、をクリックして [選択したオブジェクト] に追加します。
選択したオブジェクト	オブジェクトを右クリックして名前を変更するか、WHERE フィルターを設定します。複数のオブジェクトの名前を一度に変更するには、[一括編集] をクリックします。
競合するテーブルの処理モード	[事前チェックしてエラーを報告] (デフォルト)：移行先に同じ名前のテーブルが既に存在する場合、事前チェックは失敗します。[エラーを無視して続行]：このチェックをスキップします。完全移行中は既存のレコードが保持され、増分移行中は既存のレコードが上書きされます。
ソースデータベースのトリガーを移行する方法	[スキーマ移行] と [増分データ移行]トリガーの同期または移行の両方が選択されている場合に使用できます。詳細については、「」をご参照ください。
イベントを移行するかどうか	ソースデータベースからイベントを移行するかどうかを指定します。[はい]ソースデータベースからのイベントの同期または移行を選択した場合は、後続の操作を完了する必要があります。詳細については、「」をご参照ください。
移行評価を有効にする	[スキーマ移行] が選択されている場合に使用できます。ソースと移行先のスキーマ (インデックス長、ストアドプロシージャ、依存テーブル) の互換性をチェックします。結果は事前チェック中に表示されますが、事前チェックの結果には影響しません。
移行先インスタンスのオブジェクト名の大文字/小文字	移行先のデータベース、テーブル、カラム名の大文字/小文字をコントロールします。デフォルトは [DTS のデフォルトポリシー]オブジェクト名の大文字/小文字の指定です。詳細については、「」をご参照ください。

(オプション) 詳細設定

(オプション) [詳細設定] タブで、必要に応じて設定を調整します。[次へ：データ検証] をクリックします。

パラメーター	説明
タスクスケジューリング用の専用クラスター	デフォルトでは、タスクは共有クラスターで実行されます。安定性を向上させるには、専用クラスターをご購入ください。
オンライン DDL ツールの一時テーブルをコピー	ソースで DMS または gh-ost を使用してオンライン DDL を実行する場合： [はい] を選択すると、一時テーブルのデータが移行されます (遅延が増加する可能性があります)。[いいえ、DMS オンライン DDL に適応] を選択すると、元の DDL 操作のみが移行されます。[いいえ、gh-ost に適応] を選択すると、gh-ost からの元の DDL のみが移行されます。
アカウントを移行するかどうか	ソースからアカウント情報を移行します。この機能を有効にした場合は、移行するアカウントを選択し、アカウント権限を確認してください。
接続失敗時の再試行時間	接続失敗後、DTS が再試行する時間です。範囲：10～1,440 分。デフォルト：720 分。少なくとも 30 分以上に設定してください。
その他の問題での再試行時間	DDL または DML の失敗後、DTS が再試行する時間です。範囲：1～1,440 分。デフォルト：10 分。[接続失敗時の再試行時間] よりも短くする必要があります。
完全データ移行のスロットリングを有効化	ソースデータベースへの QPS、完全移行の RPS、および移行速度 (MB/s) を制限します。データベースサーバーの負荷を軽減するために使用します。
増分データ移行のスロットリングを有効化	増分移行の RPS と移行速度 (MB/s) を制限します。
ETL の設定	抽出・変換・書き出し (ETL) 処理を有効にします。詳細については、「ETL の設定」をご参照ください。
モニタリングとアラート	タスクが失敗した場合、または遅延がしきい値を超えた場合にアラートを送信します。詳細については、「モニタリングとアラートの設定」をご参照ください。
ハートビートテーブルに対する SQL 操作を削除するかどうか	[はい]：ハートビート SQL をソースに書き込みません (移行遅延が表示される場合があります)。[いいえ]：ハートビート SQL をソースに書き込みます (物理バックアップとクローニングに影響する可能性があります)。

(オプション) データ検証

(オプション) [データ検証] タブで、データ検証を設定します。完全データ検証を設定する場合は、次のパラメーターを設定します。増分データ検証を設定する場合は、[増分検証ベンチマーク] を設定して、検証する DML 操作をフィルターします。データ検証のアラートを設定するには、[完全データ検証アラート] または [増分データ検証アラート] を [はい] に設定し、アラートルールを選択して設定します。アラート通知を受信するには、CloudMonitor でアラートメッセージをサブスクライブします。「DTS タスクのアラートルールを設定する」をご参照ください。

検証方法	コスト	説明
完全データ検証	有料	完全移行後にソースとターゲットのデータを比較します
増分データ検証	有料	増分移行中にデータを比較します
[スキーマ検証]	無料	ソースとターゲットのスキーマの互換性をチェックします

ビジネスニーズに応じて、1 つ以上のデータ検証方法を選択してください。

完全なデータ検証

完全なデータ検証を選択した場合は、以下のパラメーターを設定します。

パラメーター	説明
完全データ検証	[行サンプリングによる完全なフィールド検証]：行の一定割合 (10～100%) をサンプリングして、完全なフィールド比較を行います。[テーブルの行数に基づいて検証]：行数のみを比較します (無料)。
全データ検証時間ルール	[今すぐ開始] のみがサポートされています。
[完全なデータ検証のタイムアウト設定]	タイムアウト (1～72 時間) を設定して、検証タスクが長すぎる場合に自動的に終了させます。
[完全なキャリブレーションリファレンス]	[デフォルト]：ソースとターゲットの和集合をベースラインとして使用します。[ソースデータベース]：ターゲットがソースと一致することを検証します。[ターゲットデータベース]：ソースがターゲットと一致することを検証します。

増分データ検証

フェーズ 3：事前チェックの実行と移行の開始

[次へ：タスク設定を保存して事前チェック] をクリックします。DTS は設定と環境を検証します。
事前チェックが完了するのを待ちます。
- [成功率] が 100% に達した場合、環境は準備完了です。警告を確認してリスクがないことを確認し、無視して続行します。
- 事前チェックが失敗した場合は、[詳細を表示] をクリックして問題を修正し、再度事前チェックを実行します。
[次へ：インスタンスの購入] をクリックします。
[リソースグループ] (デフォルト：[デフォルトリソースグループ]) と適切な DTS インスタンス仕様を選択します。
[Data Transmission Service (従量課金) 利用規約] に同意し、[購入して開始] をクリックし、次に [確認] をクリックします。移行タスクが自動的に開始されます。

フェーズ 4：データ検証と切り替え

移行タスクのステータスを監視します。
- 増分データ移行のないタスクは、完了すると [ステータス：完了] と表示されます。
- 増分データ移行のあるタスクは、[ステータス：実行中] と表示され、自動的には終了しません。
完全移行が完了し、増分移行の遅延がほぼゼロになった後、データ整合性を検証します。オプション 1 — 自動検証：DTS でデータ検証タスクを設定します。オプション 2 — 手動検証：ソースデータベースとターゲット RDS インスタンスの両方で以下のクエリを実行し、結果を比較します。
```
-- 行数を比較
SELECT COUNT(*) FROM <your_table>;

-- 主要なビジネスメトリクスを比較
SELECT SUM(amount) FROM orders WHERE create_time >= '2024-01-01';
```
オフピーク時にアプリケーションを切り替えます。
1. アプリケーションを停止します。
2. 増分移行の遅延がゼロに達したことを確認します。
3. アプリケーションのデータベース接続文字列をターゲット RDS インスタンスのエンドポイントに更新します。
4. 切り替えが完了したら、移行タスクをリリースします。

増分データ移行でサポートされる SQL 操作

操作タイプ	SQL ステートメント
DML	INSERT, UPDATE, DELETE
DDL	ALTER TABLE, ALTER VIEW, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, DROP INDEX, DROP TABLE, RENAME TABLE, TRUNCATE TABLE

重要

RENAME TABLE 操作はデータの不整合を引き起こす可能性があります。移行中にテーブルの名前を変更し、そのテーブル (親データベースではなく) を移行オブジェクトとして選択した場合、名前が変更されたテーブルのデータは移行されません。これを避けるには、データベースを移行オブジェクトとして選択し、名前変更前と名前変更後の両方のデータベース名が移行範囲に含まれていることを確認してください。

よくある質問

Q：DTS が「Host 'XXX' is not allowed to connect to this MySQL server」というエラーで接続に失敗するのはなぜですか？

これは Java Database Connectivity (JDBC) の接続エラーです。アカウントの認証情報が正しく、アカウントに必要な権限があることを確認してください。特権アカウントを使用して接続をテストすると、問題の切り分けに役立ちます。

Q：移行タスクを作成する際に、中国 (福州) リージョンの RDS インスタンスを選択できないのはなぜですか？

DTS は中国 (福州) リージョンのインスタンスをサポートしていません。代替案として、自己管理 MySQL 5.7 または 8.0 データベースをクラウドにバックアップしてください。