Data Transmission Service:自己管理 MySQL データベースから ApsaraDB RDS for MySQL インスタンスへのデータ移行

外部キーの動作

ソースデータベースの制限

• ソースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行が遅くなります。

• 移行対象のテーブルには PRIMARY KEY または UNIQUE 制約が必要であり、すべてのフィールドが一意である必要があります。そうしないと、ターゲットデータベースに重複レコードが含まれる可能性があります。

• 単一の移行タスクでは、移行オブジェクトとしてテーブルを選択し、宛先で変更（例：テーブル名または列名の変更）を行う場合、最大 1,000 テーブルまでサポートされます。1,000 テーブルを超える場合は、タスクを分割するか、データベース全体を移行してください。

• 増分データ移行のためのバイナリログは、次の要件を満たす必要があります。

  • binlog_format が row に設定され、binlog_row_image が full に設定された状態でバイナリログが有効になっている必要があります。そうでない場合、事前チェック中にエラーが発生し、移行を開始できません。> 重要： デュアルプライマリクラスター内の自己管理 MySQL データベースの場合、DTS がすべてのバイナリログを取得できるように、log_slave_updates を ON に設定してください。

  • バイナリログは少なくとも 7 日間保持されている必要があります。そうでない場合、DTS がログを取得できず、タスクが失敗する可能性があります。例外的なケースでは、データ不整合または損失が発生する可能性があります。この要件を満たさない場合、DTS サービスレベル契約 (SLA) に記載されたサービスの信頼性またはパフォーマンスが無効になる可能性があります。

• 移行中のソースデータベースに対する操作：

  • スキーマ移行および完全なデータ移行中は、データベースまたはテーブルのスキーマを変更する DDL 文を実行しないでください。そうしないと、タスクが失敗します。

  • 完全データのみの移行の場合、移行中にソースデータベースにデータを書き込まないでください。そうしないと、データ不整合が発生します。整合性を確保するには、3 つの移行タイプすべてを選択してください。

• 物理バックアップからの復元やカスケード操作など、バイナリログ変更操作によって生成されたデータは、移行インスタンスの実行中には記録または移行されません。

  説明

  このデータが移行されない場合、ビジネスが許容するのであれば、再度完全なデータ移行を実行できます。

• ソース MySQL 8.0.23 以降の場合、非表示カラムは読み取ることができず、データ損失が発生します。

  説明

  - カラムを表示するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。 - プライマリキーを持たないテーブルは、自動的に非表示のプライマリキーを生成します。これらを表示状態にしてください。詳細については、「Generated Invisible Primary Keys」をご参照ください。

その他の制限

• 互換性のため、ソースおよびターゲットの MySQL データベースバージョンは同一である必要があります。

• DTS は、コメントで定義されたパーサを使用するデータを移行しません。

• ターゲット MySQL 8.0.23 以降の場合、非表示カラムはデータを受信できず、DTS インスタンスが失敗してデータ損失が発生します。

  説明

  - カラムを表示するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。 - プライマリキーを持たないテーブルは、自動的に非表示のプライマリキーを生成します。これらを表示状態にしてください。詳細については、「Generated Invisible Primary Keys」をご参照ください。

• スキーマ移行をスキップする場合、ソースとターゲットのフィールドタイプの互換性を確認してください。たとえば、ソースの text フィールドは、ターゲットの varchar(255) フィールドに書き込まれる際に切り捨てられる可能性があります。

• 移行されるデータに 4 バイト文字（希少文字または絵文字）が含まれる場合、ターゲットデータベースおよびテーブルは UTF8mb4 文字セットを使用する必要があります。

  説明

  スキーマ移行を使用する場合、ターゲットデータベースの character_set_server パラメーターを UTF8mb4 に設定してください。

• 開始前に、両方のデータベースへのパフォーマンス影響を評価してください。オフピーク時間帯に移行を実行することを推奨します。完全なデータ移行中、DTS は両方のデータベースの読み取りおよび書き込みリソースを消費し、サーバー負荷が増加する可能性があります。

• 同時 INSERT を伴う完全なデータ移行は、テーブルの断片化を引き起こします。移行後、ターゲットの表領域はソースの表領域よりも大きくなります。

• DTS は、FLOAT および DOUBLE カラムに対して ROUND(COLUMN,PRECISION) 関数を使用します。デフォルトの精度：FLOAT は 38 桁、DOUBLE は 308 桁です。精度設定が要件を満たしているか確認してください。

• DTS は、失敗したタスクを 7 日以内に再開しようと試みます。ワークロードをターゲットに切り替える前に、失敗したタスクを停止または解放するか、REVOKE を使用してターゲットデータベース上の DTS アカウントの書き込み権限を削除してください。そうしないと、再開されたタスクがターゲットデータを上書きする可能性があります。

• ターゲットで失敗した DDL 文は、DTS タスクを停止しません。失敗した DDL 文は、タスクログで確認できます。詳細については、「タスクログの表示」をご参照ください。

• 同じテーブル内で大文字と小文字のみが異なるカラム名は、MySQL のカラム名が大文字と小文字を区別しないため、予期しない結果をもたらす可能性があります。

• 移行が完了した後（ステータス が Completed に変化した後）、analyze table <table name> を実行して、データがターゲットテーブルに書き込まれていることを確認してください。ターゲットで高可用性 (HA) スイッチオーバーが発生した場合、データがメモリ内にのみ残り、データ損失が発生する可能性があります。

• EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、完全なデータ移行をサポートしていません。

  説明

  TDE (透過的データ暗号化) が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、完全なデータ移行、および増分データ移行をサポートしています。

• アカウントを移行するには、「データベースアカウントの移行」の前提条件および注意事項を確認してください。

• DTS タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。タスクが再起動され、復旧中にタスクパラメーターが変更される可能性があります。

  説明

  変更できるのはタスクパラメーターのみであり、データベースパラメーターは変更されません。変更されるパラメーターには、「インスタンスパラメーターの変更」 セクションに記載されているものなどがあります（「DTS インスタンスのパラメーターを変更する」トピック内）。

特殊なケース

• ソースとしての自己管理 MySQL データベース：

  • 移行中にソースデータベースでプライマリ／セカンダリスイッチオーバーが発生すると、タスクは失敗します。

  • DTS は、最新の移行済みデータのタイムスタンプと現在のソースタイムスタンプとの差から移行遅延を計算します。ソースで長時間 DML 操作が発生しない場合、遅延が正確でなくなる可能性があります。遅延を更新するには、ソースデータベースで DML 操作を実行してください。> 注： データベース全体を移行オブジェクトとして選択する場合、毎秒更新されるハートビートテーブルを作成できます。

  • DTS は、バイナリログファイルの位置を進めるために、ソースデータベース上で定期的に `CREATE DATABASE IF NOT EXISTS test ` を実行します。

• ソースとしての ApsaraDB RDS for MySQL インスタンス：

  • 読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンス（またはトランザクションログを記録しないインスタンス）は、増分データ移行のソースとして使用できません。

  • DTS は、バイナリログファイルの位置を進めるために、ソースデータベース上で定期的に `CREATE DATABASE IF NOT EXISTS test ` を実行します。

• 宛先が ApsaraDB RDS for MySQL インスタンスの場合: DTS は宛先インスタンスにデータベースを自動作成します。ただし、ソースデータベース名が ApsaraDB RDS for MySQL の命名規則に準拠していない場合は、タスクを設定する前に手動でデータベースを作成する必要があります。詳細については、「データベースの管理」をご参照ください。

ステップ 1：データ移行ページを開く

データ移行 ページを開き、以下のいずれかの方法でデータ移行インスタンスのリージョンを選択します。

ステップ 2：ソースおよびターゲットデータベースの設定

1. タスクの作成 をクリックします。

2. （任意）右上隅で 新しい設定ページ をクリックします。

   説明

   - 右上隅に 以前のバージョンに戻す が表示されている場合は、この手順をスキップしてください。 - 新しい設定ページの使用を推奨します。バージョン間で一部のパラメーターが異なります。

3. ソースおよびターゲットデータベースを設定します。

   警告

   設定後、ページ上部の 制限事項 を必ずお読みください。そうしないと、タスクが失敗したり、データ不整合が発生したりする可能性があります。

   セクション	パラメーター	説明
   該当なし	タスク名	DTS は自動的にタスク名を生成します。識別しやすいように、わかりやすい名前を指定してください。一意の名前である必要はありません。
   ソースデータベース	既存の接続を選択	この例では、既存の接続は選択しません。以下にデータベース情報を設定します。
   	データベースタイプ	MySQL を選択します。
   	アクセス方法	ソースデータベースのデプロイメントに基づいてアクセス方法を選択します。この例では、パブリック IP アドレス を選択します。
   		重要 自己管理データベースの場合、移行前に必要な環境を整えてください。詳細については、「準備の概要」をご参照ください。
   	インスタンスリージョン	ソース MySQL データベースのリージョン。
   	ドメイン名または IP	ソース MySQL データベースのエンドポイント。この例では、パブリック IP アドレスを入力します。
   	ポート番号	ソースデータベースのサービスポート。インターネット経由でアクセス可能である必要があります。デフォルト：3306。
   	データベースアカウント	ソースデータベースアカウント。必要な権限については、「データベースアカウントに必要な権限」セクションをご参照ください。
   	データベースパスワード	ソースデータベースアカウントのパスワード。
   	暗号化	要件に基づいて、暗号化なし または SSL 暗号化 を選択します。
   		- ソースで SSL が有効になっていない場合は、暗号化なし を選択します。
   		- SSL が有効になっている場合は、SSL 暗号化 を選択し、CA 証明書 をアップロードして、CA キー を設定します。
   宛先データベース	既存の接続を選択	この例では、既存の接続は選択しません。以下にデータベース情報を設定します。
   	データベースタイプ	MySQL を選択します。
   	アクセス方法	Alibaba Cloud インスタンス を選択します。
   	インスタンスリージョン	宛先 ApsaraDB RDS for MySQL インスタンスのリージョン。
   	Alibaba Cloud アカウント間でデータを複製	いいえ を選択します。
   	RDS インスタンス ID	宛先 ApsaraDB RDS for MySQL インスタンスの ID。
   	データベースアカウント	ターゲットデータベースアカウント。必要な権限については、「データベースアカウントに必要な権限」セクションをご参照ください。
   	データベースパスワード	ターゲットデータベースアカウントのパスワード。
   	暗号化	暗号化なし または SSL 暗号化 を選択します。SSL 暗号化クラウド証明書を使用した SSL 暗号化の有効化 を使用するには、事前に RDS インスタンスで SSL を有効にしてください。詳細については、「」をご参照ください。

4. 接続テストして次へ をクリックし、DTS サーバーの CIDR ブロック ダイアログボックスで 権限付与を確認してリンクをテスト をクリックします。

   説明

   DTS サーバーの CIDR ブロックを、両方のデータベースのセキュリティ設定に（自動的または手動で）追加できることを確認してください。詳細については、「DTS サーバーの CIDR ブロックをセキュリティ設定に追加する」をご参照ください。

ステップ 3：移行オブジェクトおよび詳細設定の構成

1. オブジェクトの設定 ページで、以下のパラメーターを設定します。

   パラメーター	説明
   移行タイプ	- 完全なデータ移行のみを行う場合、スキーマ移行 および 完全なデータ移行 を選択します。
   	- ダウンタイムゼロの移行を行う場合、スキーマ移行、完全なデータ移行、および 増分データ移行 を選択します。
   	> 注：
   	> - スキーマ移行 をスキップする場合、事前にターゲットにデータベースおよびテーブルを作成し、選択済みオブジェクト でオブジェクト名マッピングを有効にしてください。
   	> - 増分データ移行 をスキップする場合、移行中にソースにデータを書き込まないでください。
   ソースデータベースのトリガーを移行する方法	要件に基づいてトリガー移行方法を選択します。トリガーが存在しない場合はスキップしてください。詳細については、「ソースデータベースからのトリガーの同期または移行」をご参照ください。
   	説明 スキーマ移行 および 増分データ移行 の両方が選択されている場合にのみ利用可能です。
   移行評価の有効化	ソースおよびターゲットのスキーマの互換性（インデックス長、ストアドプロシージャ、依存テーブル）をチェックします。はい または いいえ を選択します。
   	> 注：
   	> - スキーマ移行 が選択されている場合にのみ利用可能です。
   	> - はい を選択すると、事前チェック時間が長くなります。事前チェック中に 評価結果 を確認できます。評価結果は事前チェック結果に影響しません。
   競合テーブルの処理モード	- 事前チェックしてエラーを報告：重複するテーブル名をチェックします。重複が存在する場合、事前チェックは失敗し、移行を開始できません。
   	説明 重複するテーブルを削除または名前変更できない場合は、オブジェクト名マッピングを使用して、移行されたテーブルの名前を変更します。詳細については、「オブジェクト名をマップする」をご参照ください。
   	- エラーを無視して続行：重複テーブル名のチェックをスキップします。
   	警告 エラーを無視して続行 を選択すると、データ不整合が発生する可能性があります。
   	> - 同じスキーマ、同じプライマリキー：完全移行中は既存レコードが保持され、増分移行中は既存レコードが上書きされます。
   	> - 異なるスキーマ：特定のカラムのみが移行されるか、タスクが失敗します。
   イベントを移行するかどうか	イベントを移行するには、はい を選択します。詳細については、「イベントの同期または移行」をご参照ください。
   宛先インスタンスにおけるオブジェクト名の大文字・小文字の扱い	データベース、テーブル、および列の名前の大文字/小文字の扱いを制御します。デフォルト: [DTS デフォルトポリシー]。詳細については、「宛先インスタンスのオブジェクト名の大文字/小文字を指定する」をご参照ください。
   ソースオブジェクト	ソースオブジェクト からオブジェクトを選択し、右向き矢印をクリックして 選択済みオブジェクト に追加します。
   	説明 カラム、テーブル、またはデータベースを選択できます。テーブルまたはカラムを選択すると、ビュー、トリガー、およびストアドプロシージャは除外されます。
   選択済みオブジェクト	・単一のオブジェクトの名前を変更するには、そのオブジェクトを[右クリック]します。詳細については、「単一のオブジェクトの名前をマップする」をご参照ください。
   	- 複数のオブジェクトの名前を変更するには、一括編集複数のオブジェクト名を一括でマッピング をクリックします。詳細については、「」をご参照ください。
   	> 注：
   	> - オブジェクトの名前を変更すると、依存オブジェクトの移行が失敗する可能性があります。
   	> - WHERE 条件でデータをフィルタリングするには、テーブルを右クリックしてフィルターを設定します。詳細については、「移行するデータのフィルタリング」をご参照ください。
   	> - 増分移行で特定の SQL 操作を選択するには、オブジェクトを右クリックして操作を選択します。サポートされる操作については、「増分データ移行でサポートされる SQL 操作」セクションをご参照ください。

2. 次へ：詳細設定 をクリックします。

   パラメーター	説明
   タスクスケジューリング用の専用クラスター	デフォルトでは、DTS は共有クラスターを使用します。より高い安定性を得るには、専用クラスターをご購入ください。詳細については、「DTS 専用クラスターとは」をご参照ください。
   ソーステーブルで生成されたオンライン DDL ツールの一時テーブルをターゲットデータベースにコピーする。	DMS または gh-ost を使用したオンライン DDL 操作による一時テーブルの処理を制御します。
   	重要 オンライン DDL 操作に pt-online-schema-change を使用しないでください。DTS タスクが失敗します。
   	- はい：一時テーブルのデータを移行します。
   	説明 大量のオンライン DDL データは、移行遅延を増加させる可能性があります。
   	- いいえ、DMS オンライン DDL に適応: 一時テーブルをスキップします。 DMS からのオリジナルの DDL 操作のみが移行されます。
   	説明 このオプションはターゲットテーブルをロックする可能性があります。
   	- いいえ、gh-ost に適応：一時テーブルをスキップします。gh-ost からの元の DDL のみを移行します。シャドウテーブルをフィルタリングするために、デフォルトまたはカスタムの正規表現を使用します。
   	説明 このオプションはターゲットテーブルをロックする可能性があります。
   アカウントを移行するかどうか	ソースデータベースアカウントを移行するには、はい を選択します。タスクで使用されるソースおよびターゲットアカウントの権限を確認してください。
   接続失敗時の再試行時間	ソースまたはターゲットの接続が失敗した場合の再試行期間。範囲：10～1,440 分。デフォルト：720。推奨：30 分以上。この時間内に再接続が成功すると、タスクは再開されます。そうでない場合、タスクは失敗します。
   	> 注：
   	> - 複数のタスクがデータベースを共有している場合、最新に設定された値が優先されます。
   	> - DTS 料金は再試行中にも適用されます。データベースを解放した後は、速やかにインスタンスを解放してください。
   その他の問題発生時の再試行時間	DDL/DML 失敗時の再試行期間。範囲：1～1,440 分。デフォルト：10。推奨：10 分以上。
   	重要 この値は、接続失敗時の再試行時間 より小さくなければなりません。
   完全なデータ移行のスロットリングを有効化	完全移行中のリソース消費を制限します。ソースデータベースへのクエリ数 (QPS)、完全なデータ移行の RPS、および 完全移行のデータ移行速度 (MB/s) を設定します。
   	説明 完全なデータ移行 が選択されている場合にのみ利用可能です。
   増分データ移行のスロットリングを有効化	増分移行中のリソース消費を制限します。増分データ移行の RPS および 増分移行のデータ移行速度 (MB/s) を設定します。
   	説明 増分データ移行 が選択されている場合にのみ利用可能です。
   環境タグ	DTS インスタンスを識別するためのタグ。この例では不要です。
   フォワードおよびリバースタスクのハートビートテーブルに対する SQL 操作を削除するかどうか	ハートビート SQL 操作をソースデータベースに書き込むかどうかを制御します。
   	- はい：ハートビート SQL を書き込みません。遅延情報に影響を与える可能性があります。
   	- いいえ：ハートビート SQL を書き込みます。ソースの物理バックアップおよびクローンに影響を与える可能性があります。
   ETL の設定	ETL とは
   	- [はい]: コードエディタにデータ処理文を入力します。詳細については、「データ移行またはデータ同期タスクで ETL を設定する」をご参照ください。
   	- いいえ：ETL 設定をスキップします。
   モニタリングとアラート	タスクの失敗または移行遅延が過剰になった場合のアラートを設定します。
   	- いいえ：アラートをスキップします。
   	- はい: アラートしきい値と 通知受信者 を設定します。詳細については、「DTS タスクの作成時にモニタリングとアラートを設定する」をご参照ください。

3. [次のステップ: データ検証] をクリックして、データ検証の設定を行います。詳細については、「データ検証タスクの設定」をご参照ください。

ステップ 4：事前チェックの実行およびインスタンスの購入

1. タスク設定を保存し、事前チェックを開始します。

   • API パラメーターを表示するには、次へ：タスク設定の保存と事前チェック にポインターを合わせて、OpenAPI パラメーターのプレビュー をクリックします。

   • それ以外の場合は、次へ：タスク設定の保存と事前チェック をクリックします。

   説明

   - DTS はタスク開始前に事前チェックを実行します。事前チェックが合格した後にのみ、タスクが開始されます。 - 事前チェックが失敗した場合は、各失敗項目の横にある 詳細を表示 をクリックします。問題を修正して、再度事前チェックを実行してください。 - 事前チェック中にアラートがトリガーされた場合： - アラートを無視できない場合は、詳細を表示 をクリックして問題を修正し、再度事前チェックを実行します。 - アラートを無視できる場合は、アラートの詳細を確認 をクリックし、ダイアログボックスで 無視 をクリックしてから OK をクリックします。その後、再度事前チェック をクリックします。アラートを無視すると、データ不整合が発生する可能性があります。

2. 成功率 が 100% に達するまで待ち、次へ：インスタンスの購入 をクリックします。

3. インスタンスの購入 ページで、インスタンスクラスを設定します。

   セクション	パラメーター	説明
   新しいインスタンスクラス	リソースグループ	インスタンスのリソースグループ。デフォルト：デフォルトリソースグループResource Management とは
   	インスタンスクラス	必要な移行速度に基づいてインスタンスクラスを選択します。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

4. Data Transmission Service (従量課金) サービス利用規約 チェックボックスをオンにします。

5. 購入して開始 をクリックし、確認ダイアログボックスで OK をクリックします。

移行後

データ移行 ページでタスクの進捗状況を確認します。