専用クラスターでのデータ移行タスクの構成 - Data Transmission Service

Data Transmission Service (DTS) を使用すると、異なるデータソース間でデータを移行できます。これには、Alibaba Cloud への移行、Alibaba Cloud 内のインスタンス間での移行、およびデータベースの分割やスケールアウトのシナリオが含まれます。本トピックでは、ApsaraDB RDS for MySQL インスタンスをソースおよびターゲットとして使用し、DTS 専用クラスターでデータ移行タスクを構成する方法について説明します。

前提条件

開始前に、以下の要件を満たしていることを確認してください。

DTS 専用クラスター。詳細については、「DTS 専用クラスターの作成」をご参照ください。
ソースおよびターゲットの ApsaraDB RDS for MySQL インスタンス。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。
ターゲットインスタンスの利用可能ストレージが、ソースインスタンスの合計データサイズよりも大きいこと
（ソースまたはターゲットと DTS 専用クラスターが異なるリージョンにある場合）ソースまたはターゲットインスタンスでインターネットアクセスが有効になっていること

課金

DTS 専用クラスターのリソースに対してのみ課金されます。専用クラスター内で移行タスクを作成しても、追加料金は発生しません。Alibaba Cloud データベースから他のクラウドへデータを移行する場合、発生したインターネットトラフィックに対して課金されます。詳細については、「DTS 専用クラスターの課金」をご参照ください。

移行タイプ

DTS は、目的に応じて組み合わせて使用できる 3 種類の移行タイプをサポートしています。

移行タイプ	機能	使用タイミング
スキーマ移行	テーブル、ビュー、トリガー、ストアドプロシージャ、関数などのオブジェクトスキーマをソースからターゲットにコピーします。ビュー、ストアドプロシージャ、関数の SECURITY 属性を DEFINER から INVOKER に変更します。ユーザーアカウントは移行されません。INVOKER に必要な読み取りおよび書き込み権限を別途付与してください。	送信先スキーマがすでに存在する場合を除き、常にこれを含めます。
完全なデータ移行	ソースからターゲットに既存のすべてのデータをコピーします。	初期データのシード投入に使用します。完全移行のみを実行する場合は、移行中にソースに書き込まないでください。
増分データ移行	完全移行完了後、バイナリログを使用してソースからの変更を継続的にターゲットに適用します。サービス中断なくソースとターゲットを同期状態に保ちます。	これを含めることで、移行中にダウンタイムを最小限に抑え、サービスを実行中のまま維持できます。

推奨される組み合わせ：アプリケーションを中断せずにデータを移行するには、3 つのタイプすべて（スキーマ移行＋完全なデータ移行＋増分データ移行）を選択してください。ダウンタイムが許容される一時的な移行の場合のみ、完全移行のみ（スキーマ移行＋完全なデータ移行）を使用してください。

増分データ移行でサポートされる 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

必要な権限

タスクを開始する前に、DTS が使用するデータベースアカウントに以下の権限を付与してください。

データベース	スキーマ移行	完全なデータ移行	増分データ移行
ソース ApsaraDB RDS for MySQL	SELECT	SELECT	読み取りおよび書き込み権限
ターゲット ApsaraDB RDS for MySQL	読み取りおよび書き込み権限	読み取りおよび書き込み権限	読み取りおよび書き込み権限

アカウントを移行する場合は、ソースアカウントに mysql.user、mysql.db、mysql.columns_priv、および mysql.tables_priv に対する SELECT 権限も必要です。ターゲットアカウントには CREATE USER および GRANT OPTION 権限が必要です。システムアカウント（root、mysql.infoschema、mysql.session、mysql.sys）およびターゲットにすでに存在するアカウントは移行できません。

アカウントの作成および権限付与の手順については、「ApsaraDB RDS for MySQL インスタンスでのアカウントの作成」および「ApsaraDB RDS for MySQL インスタンスでの標準アカウントの権限の変更」をご参照ください。

制限事項

スキーマ移行中、DTS は外部キーをソースデータベースからターゲットデータベースに移行します。完全なデータ移行および増分データ移行中、DTS はセッションレベルで外部キー制約チェックおよびカスケード操作を一時的に無効にします。移行中にソースデータベースでカスケード操作または削除操作を実行すると、データの不整合が発生する可能性があります。

カテゴリ	制限事項
ソースデータベース	ソースサーバーに十分なアウトバウンド帯域幅がないと、移行速度が低下します。
	テーブルにはプライマリキーまたはすべてのフィールドが一意となる UNIQUE 制約が必要です。これらの制約がないと、ターゲットデータベースに重複レコードが含まれる可能性があります。
	テーブルを移行オブジェクトとして選択し、ターゲットでテーブル名または列名を変更する必要がある場合、1 つのタスクでサポートされるテーブル数は最大 1,000 です。この上限を超えるとリクエストエラーが発生します。テーブルを複数のタスクに分割するか、データベース全体を移行してください。
	増分データ移行の場合：`binlog_format` を `row` に設定し、`binlog_row_image` を `full` に設定し、バイナリロギングを有効にしてください。自己管理 MySQL データベースがデュアルプライマリクラスターで動作している場合は、DTS がすべてのバイナリログを読み取れるように、`log_slave_updates` を `ON` に設定してください。
	増分移行のみの場合：バイナリログを 24 時間以上保持してください。完全なデータ移行＋増分データ移行の場合：バイナリログを少なくとも 7 日間保持してください。完全移行完了後は、保持期間を 24 時間以上に短縮できます。保持期間が不十分だと、DTS がバイナリログを取得できず、タスクが失敗したりデータが損失したりする可能性があります。
	スキーマ移行または完全なデータ移行中に DDL 操作を実行しないでください。完全移行のみを実行する場合は、ソースデータベースに書き込まないでください。そうしないと、データの不整合が発生します。
その他	ソースおよびターゲットの MySQL データベースで同じエンジンバージョンを使用してください。
	オフピーク時間帯に移行を実行してください。完全なデータ移行では、両方のインスタンスの読み取りおよび書き込みリソースを使用し、サーバーロードが増加します。
	完全なデータ移行では、同時 INSERT 操作によりターゲットテーブルに断片化が発生します。移行後、ターゲットの表領域はソースの表領域よりも大きくなります。
	DTS は `ROUND(COLUMN,PRECISION)` を使用して FLOAT および DOUBLE 列を読み取ります。デフォルトの精度は、FLOAT の場合は 38 桁、DOUBLE の場合は 308 桁です。これらの精度設定が要件を満たしているか確認してください。
	DTS は失敗したタスクを最大 7 日間自動的に再試行します。ワークロードをターゲットデータベースに切り替える前に、移行タスクを停止またはリリースするか、`REVOKE` を実行してターゲットに対する DTS の書き込み権限を削除してください。そうしないと、再開されたタスクがターゲットデータをソースデータで上書きしてしまいます。
特殊ケース	自己管理 MySQL の場合：アクティブな移行タスク中にプライマリ／セカンダリのフェールオーバーが発生すると、タスクが失敗します。
	自己管理 MySQL の場合：ソースで長時間 DML 操作が実行されないと、移行遅延のレポートが不正確になる可能性があります。遅延情報を更新するには、DML 操作を実行してください。データベース全体を移行する場合は、毎秒データを書き込むハートビートテーブルを作成してください。
	DTS は、バイナリログの位置を進めるために、ソースデータベース上で定期的に `CREATE DATABASE IF NOT EXISTS \`test\`` を実行します。
	ApsaraDB RDS for MySQL をターゲットとする場合：DTS は自動的にターゲットデータベースを作成しますが、ソースデータベース名が無効な場合は例外です。名前が無効な場合は、タスク構成前に手動でデータベースを作成してください。

移行タスクの構成

構成は、ソースおよびターゲットデータベースの接続、移行オブジェクトの選択、高度な設定の構成、タスクの開始の 4 つのステージで行われます。

ステップ 1：ソースおよびターゲットデータベースの接続

専用クラスターページに移動します。
上部ナビゲーションバーで、ご利用の DTS 専用クラスターが配置されているリージョンを選択します。
クラスターを見つけ、[操作] 列で [タスクの構成] ＞ [データ移行タスクの構成] を選択します。
構成ページで、次に進む前に上部の [制限事項] 通知を確認します。

[ソースデータベース] パラメーターを設定します。

パラメーター	説明
タスク名	自動生成されます。タスクを識別するためのわかりやすい名前を指定してください。一意である必要はありません。
既存のデータベース接続を選択（オプション）	既存の接続を選択すると、ソースパラメーターが自動的に入力されます。手動で構成する場合は、この手順をスキップしてください。
データベースタイプ	MySQL を選択します。
アクセス方法	Alibaba Cloud インスタンスを選択します。
インスタンスリージョン	DTS 専用クラスターによって設定されます。変更できません。
Alibaba Cloud アカウント間でデータを複製	同一アカウント内での移行の場合は、いいえを選択します。
RDS インスタンス ID	ソース ApsaraDB RDS for MySQL インスタンスの ID です。ソースとターゲットは同じインスタンスでも構いません。
データベースアカウント	必要な権限に記載されている権限を持つアカウントです。
データベースパスワード	データベースアカウントのパスワードです。
暗号化	[暗号化なし] または [SSL 暗号化] を選択します。SSL 暗号化の場合、このタスクを開始する前に、インスタンスで SSL を構成する必要があります。

[送信先データベース] パラメーターを設定します。

パラメーター	説明
既存の DMS データベースインスタンスを選択（オプション）	既存の接続を選択すると、ターゲットパラメーターが自動的に入力されます。手動で構成する場合は、この手順をスキップしてください。
データベースタイプ	MySQL を選択します。
アクセス方法	Alibaba Cloud インスタンスを選択します。
インスタンスリージョン	DTS 専用クラスターによって設定されます。変更できません。
RDS インスタンス ID	ターゲット ApsaraDB RDS for MySQL インスタンスの ID です。
データベースアカウント	必要な権限に記載されている権限を持つアカウントです。
データベースパスワード	データベースアカウントのパスワードです。
暗号化	[暗号化なし] または [SSL 暗号化] を選択します。SSL 暗号化の場合、このタスクを開始する前に、インスタンスで SSL を設定する必要があります。

［接続テストと次へ進む］をクリックします。DTS は、自動的に自サーバーの CIDR ブロックを Alibaba Cloud データベースインスタンスの IP ホワイトリスト、または自己管理データベースをホストする Elastic Compute Service (ECS) インスタンスのセキュリティグループルールに追加します。オンプレミスデータセンターやサードパーティクラウド内の自己管理データベースの場合は、手動で DTS サーバーの CIDR ブロックをデータベースの IP ホワイトリストに追加してください。詳細については、「オンプレミスデータベースのセキュリティ設定に DTS サーバーの CIDR ブロックを追加する」をご参照ください。

警告
IP ホワイトリストまたはセキュリティグループルールに DTS サーバーの CIDR ブロックを追加すると、セキュリティリスクが生じます。次に進む前に、予防措置を講じてください。具体的には、アカウントおよびパスワードのセキュリティを強化し、公開ポートを制限し、API 呼び出しを認証し、IP ホワイトリストおよびセキュリティグループルールを定期的に監査して不正な CIDR ブロックを削除することです。また、Express Connect、VPN Gateway、Smart Access Gateway を使用してデータベースを DTS に接続することを検討してください。

ステップ 2：移行オブジェクトの選択

移行タイプ、競合処理方法、および移行するオブジェクトを構成します。

パラメーター	説明
移行タイプ	目的に合った組み合わせを選択します。完全移行のみを行う場合は、スキーマ移行とフルデータ移行を選択します。移行中にサービスを継続して実行する場合は、スキーマ移行、フルデータ移行、および増分データ移行を選択します。
競合テーブルの処理モード	事前チェックしてエラーを報告：宛先にソースと同じ名前のテーブルが存在するかどうかをチェックします。名前の競合が存在しない場合にのみ、事前チェックは合格となります。競合するテーブルを宛先でリネームするには、オブジェクト名マッピングをご利用ください。エラーを無視して続行：名前の競合チェックをスキップします。スキーマが一致する場合、DTS は重複するプライマリキーを持つレコードをスキップします。スキーマが異なる場合、特定の列のみが移行されるか、タスクが失敗します。データの不整合が発生する可能性があるため、慎重にご利用ください。
ソースデータベースのトリガー移行方法	スキーマ移行を選択した場合にのみ適用されます。要件に基づいて方法を選択します。詳細については、「ソースデータベースからトリガーを同期または移行する」をご参照ください。
移行アセスメントの有効化	スキーマ移行を選択した場合にのみ適用されます。はいを選択すると、ソースと宛先のスキーマ（インデックス長、ストアドプロシージャ、依存テーブル）が移行要件を満たしているかどうかをチェックします。アセスメント結果は事前チェック中に確認可能であり、事前チェックの合格／不合格には影響しません。
宛先インスタンスにおけるオブジェクト名の大文字・小文字の扱い	宛先のデータベース、テーブル、および列名の大文字・小文字の扱いを制御します。デフォルトは DTS デフォルトポリシーです。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字・小文字の扱いを指定する」をご参照ください。
ソースオブジェクト	ソースオブジェクトリストからオブジェクトを選択し、アイコンをクリックして選択済みオブジェクトに追加します。選択可能な粒度は、列、テーブル、またはデータベースです。テーブルまたは列を選択した場合、ビュー、トリガー、およびストアドプロシージャは移行対象外となります。
選択済みオブジェクト	オブジェクトを右クリックしてリネームしたり、WHERE 条件を設定して行をフィルターしたりできます。右上隅の一括編集をクリックすると、複数のオブジェクトを一度にリネームできます。詳細については、「オブジェクト名マッピング」および「SQL 条件を使用してデータをフィルターする」をご参照ください。オブジェクトのリネームにより、依存オブジェクトの移行が失敗する可能性があります。

ステップ 3：高度な設定の構成

[次へ：高度な設定] をクリックし、以下の項目を構成します。

データ検証

移行後のデータ整合性を検証するには、「データ検証を有効化する」をご参照ください。

高度な設定

パラメーター	説明
タスクのスケジュールに使用する専用クラスターを選択	ご利用の DTS 専用クラスターがデフォルトで選択されています。
アラートの設定	タスクが失敗した場合や移行遅延がしきい値を超えた場合に通知を受信するには、[はい] を選択します。アラートのしきい値と連絡先を指定します。「DTS タスクを作成する際にモニタリングとアラートを設定する」をご参照ください。
ソーステーブルで生成されたオンライン DDL ツールの一時テーブルをターゲットデータベースにコピーする	ソースで Data Management (DMS) または gh-ost を使用してオンライン DDL 操作を実行する場合に適用されます。はい：オンライン DDL で生成された一時テーブルのデータを移行します（大規模なデータセットの場合、移行時間が長くなる可能性があります）。いいえ、DMS オンライン DDL に適応：一時テーブルのデータをスキップし、元の DDL のみを移行します。ターゲットのテーブルがロックされる可能性があります。いいえ、gh-ost に適応：一時テーブルのデータをスキップし、元の DDL のみを移行します。gh-ost のシャドウテーブルを除外するために、デフォルトまたはカスタムの正規表現を使用します。ターゲットのテーブルがロックされる可能性があります。重要 pt-online-schema-change はサポートされていません。使用するとタスクが失敗します。
アカウントを移行するかどうか	はいを選択すると、ソースデータベースのアカウントを移行します。必要な権限の権限要件をご確認ください。
ソースデータベースのトリガーを移行する方法	トリガー移行方法を選択してください。詳細については、「ソースデータベースからトリガーを同期または移行する」をご参照ください。
接続失敗後の再試行時間	DTS が接続失敗後に再試行する時間を指定します。有効値：10～1,440 分。デフォルト：720。少なくとも 30 分に設定してください。この時間枠内で再接続が成功すると、DTS はタスクを再開します。共有のソースまたはターゲットインスタンスを複数のタスクで使用している場合、最も最近設定された値がすべてのタスクに適用されます。説明 DTS が接続を再試行している間、DTS インスタンスに対して課金されます。この値はビジネス要件に基づいて指定してください。また、ソースおよびターゲットインスタンスをリリースした後は、できるだけ早く DTS インスタンスをリリースすることも可能です。
ソースおよびターゲットデータベースでその他の問題が発生した場合の再試行前の待機時間	DDL または DML 操作の失敗後に DTS が再試行する時間を指定します。有効値：1～1,440 分。デフォルト：10。少なくとも 10 分に設定してください。この値は接続失敗後の再試行時間より小さくする必要があります。

ステップ 4：事前チェックを実行してタスクを開始

[次へ：タスク設定の保存と事前チェック] をクリックします。このタスクの構成に使用される API パラメーターをプレビューするには、ボタンにカーソルを合わせて [OpenAPI パラメーターのプレビュー] をクリックします。
事前チェックが完了するまで待ちます。事前チェックが失敗した場合は、以下のように対応します。
- 失敗した項目の場合：[詳細を表示] をクリックして問題を修正し、[再度事前チェック] をクリックします。
- 無視できないアラート項目の場合：[詳細を表示] をクリックして問題を修正し、[再度事前チェック] をクリックします。
- 無視可能なアラート項目の場合：[アラートの詳細を確認] ＞ [無視] ＞ [OK] ＞ [再度事前チェック] をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
成功率が 100% になったら、[次へ：DTS インスタンスタイプの選択] をクリックします。
[新規インスタンスクラス] セクションで、タスクの インスタンスクラス を設定します。最小値は 1 DTS ユニット（DU）、最大値はクラスター内の残りの利用可能 DU 数です。
[Data Transmission Service（従量課金）サービス利用規約] チェックボックスをオンにします。
[タスクの開始] > [OK] をクリックします。

進行状況をモニターするには、クラスター詳細ページに移動し、左側のナビゲーションウィンドウで [クラスタータスクリスト] をクリックします。

次のステップ

タスクが開始され、増分移行が実行中の場合：

[クラスタータスクリスト] で移行遅延をモニターします。ソースの非アクティブ状態により遅延が高くなっている場合は、DML 操作を実行して情報を更新してください。
アプリケーションのトラフィックをターゲットデータベースに切り替える前に、データ検証を使用してデータ整合性を確認してください。
ワークロードを切り替える前に、移行タスクを停止またはリリースするか、REVOKE を実行してターゲットに対する DTS の書き込み権限を削除してください。これにより、再開されたタスクがターゲットデータを上書きするのを防げます。