Data Transmission Service:セルフマネージド MySQL データベースから PolarDB for MySQL への移行

ソースデータベース

• サーバーのアウトバウンド帯域幅が十分である必要があります。そうでないと、移行速度が低下します。

• テーブルには、すべてのフィールドが一意となるプライマリキーまたは一意制約が必要です。該当しない場合、ターゲットに重複レコードが生成される可能性があります。

• ターゲットでテーブルまたはカラムの名前を変更する場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。1,000 個を超える場合は、複数のタスクを構成するか、データベース全体を移行してください。

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

• 増分移行を伴わない完全移行（完全移行のみ）の場合、ソースデータベースへの書き込みは行わないでください。これによりデータの不整合が発生します。整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を同時に選択してください。

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

• ソースが MySQL 8.0.23 以降であり、データに不可視カラムが含まれる場合、それらのカラムは読み取れず、データ損失が発生します。カラムを可視にするには、次のコマンドを実行します。ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;

プライマリキーがないテーブルでは、不可視のプライマリキーが自動生成されます。移行前に、これらの不可視のプライマリキーを可視にしてください。「生成された不可視のプライマリキー」をご参照ください。

増分移行のためのバイナリログ要件：

セルフマネージド MySQL ソース：特殊ケース

• タスク実行中にソースでプライマリ/セカンダリ スイッチオーバーが発生した場合、タスクは失敗します。

• 移行遅延は、ターゲットで最新に移行されたデータのタイムスタンプとソースの現在時刻を比較して算出されます。ソースで長期間 DML 操作が行われていない場合、報告される遅延値が不正確になることがあります。遅延値を更新するには、ソースで DML 操作を実行してください。データベース全体を移行する場合は、1 秒ごとに更新されるハートビートテーブルを作成してください。

• DTS は定期的にソースで CREATE DATABASE IF NOT EXISTS \`test\` を実行し、バイナリログ位置を進めます。

ApsaraDB RDS for MySQL ソース：特殊ケース

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

• DTS は定期的にソースで CREATE DATABASE IF NOT EXISTS \`test\` を実行し、バイナリログ位置を進めます。

ターゲットデータベース（PolarDB for MySQL）

• DTS はターゲットクラスター内にデータベースを自動的に作成します。ソースデータベース名が PolarDB for MySQL の命名規則に準拠していない場合、タスクの構成前に手動でデータベースを作成してください。「データベースの管理」をご参照ください。

• PolarDB for MySQL への完全なデータ移行では、速度制限は利用できません。

その他の制限事項

• ソースおよびターゲットの MySQL バージョンは一致している必要があります。

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

• 非ピーク時間帯に移行をスケジュールしてください。完全なデータ移行では、両方のデータベースの読み取りおよび書き込みリソースが使用され、サーバー負荷が増加します。

• 完全なデータ移行の後、同時実行の INSERT 操作により、ターゲットのテーブルで断片化が発生し、表領域がソースよりも大きくなる場合があります。

• データに 4 バイト文字（稀な文字、絵文字など）が含まれる場合、ターゲットデータベースおよびテーブルは UTF8mb4 文字セットを使用する必要があります。DTS のスキーマ移行を使用する場合は、ターゲットデータベースで character_set_server を UTF8mb4 に設定してください。

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

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

• DATETIME 値は VARCHAR に変換できません。

• 送信先で DDL 文が失敗した場合でも、DTS タスクは実行を続けます。失敗した DDL 文は、タスクログ で確認できます。

• EncDB が有効化された ApsaraDB RDS for MySQL インスタンスをソースとする場合、完全なデータ移行はサポートされていません。透過的データ暗号化（TDE）は、すべての 3 種類の移行タイプでサポートされています。

• アカウントの移行については、「データベースアカウントの移行」をご参照ください。

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

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

以下のいずれかのコンソールから開始します。

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

タスクの作成 をクリックして、タスク構成ページを開きます。

タスク名

ソースデータベース

宛先データベース

ステップ 3：接続性のテスト

ページ下部の 接続性のテストと続行 をクリックし、DTS サーバーの CIDR ブロック ダイアログで 接続性のテスト をクリックします。

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

ステップ 4：移行対象オブジェクトおよび移行タイプの選択

オブジェクトの構成 ページで、以下の項目を構成します。

パラメーター	説明
移行タイプ	一度限りの移行には、スキーマ移行 および 完全なデータ移行 を選択します。サービス継続性を維持するには、増分データ移行 も選択してください。もし スキーマ移行 を省略する場合は、ターゲットデータベースおよびテーブルを手動で作成し、選択したオブジェクト でオブジェクト名マッピングを有効化してください。
ソースデータベース内のトリガーの移行方法	要件に応じてトリガーの移行方法を選択します。移行タイプ に スキーマ移行 が含まれている場合にのみ利用可能です。「トリガーの同期または移行方法の設定」をご参照ください。
競合するテーブルの処理モード	事前チェックとエラー報告：ソースおよびターゲットに同一のテーブル名が存在する場合、事前チェックが失敗します（競合するテーブル名を変更するには、オブジェクト名マッピングを使用してください）。エラーを無視して続行：同一のテーブル名に対する事前チェックをスキップします。ただし、データの不整合が発生する可能性があります：完全なデータ移行中は、DTS が競合するレコードを移行せず、既存のターゲットレコードが保持されます。増分データ移行中は、DTS がレコードを移行し、既存のターゲットレコードが上書きされます。
イベントの移行有無	はいアラート通知設定 を選択してイベントを移行し、その後の手順を完了してください。「イベントの同期または移行」をご参照ください。
ターゲットインスタンスにおけるオブジェクト名の大文字小文字	ターゲットにおけるデータベース名、テーブル名、カラム名の大文字小文字を制御します。デフォルト値：DTS のデフォルトポリシー送信先インスタンスにおけるオブジェクト名の大文字小文字の指定。「」をご参照ください。
ソースオブジェクト	オブジェクトを選択し、 をクリックして 選択したオブジェクト に移動します。カラム、テーブル、またはスキーマを選択できます。テーブルまたはカラムを選択すると、ビュー、トリガー、およびストアドプロシージャは除外されます。
選択したオブジェクト	個々のオブジェクトを右クリックして名前を変更するか、一括編集 をクリックして一括で名前を変更します。行をフィルターするには、テーブルを右クリックして WHERE 条件を設定します。データベースまたはテーブルレベルで SQL 操作を制限するには、右クリックして含める操作を選択します。

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

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

ステップ 6：データ検証の構成（任意）

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

ステップ 7：事前チェックの実行とインスタンスの購入

1. 次へ：タスク設定の保存と事前チェック をクリックします。

   このタスク構成の API パラメーターをプレビューするには、次へ：タスク設定の保存と事前チェック 上にカーソルを合わせ、OpenAPI パラメーターのプレビュー をクリックしてください。

2. 事前チェックの完了を待ちます。

   • 項目が失敗した場合、詳細の表示 をクリックして問題を修正し、再度事前チェック をクリックします。

   • 無視可能な項目でアラートがトリガーされた場合、アラート詳細の確認 > 無視 > OK の順にクリックし、再度事前チェック をクリックします。

3. 成功率 が 100% になったら、次へ：インスタンスの購入 をクリックします。

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

   パラメーター	説明
   リソースグループ	移行インスタンスのリソースグループです。デフォルト値：デフォルトのリソースグループ。
   インスタンスクラス	インスタンスクラスは移行速度を決定します。要件に応じて選択してください。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

5. Data Transmission Service（従量課金）サービス利用規約 のチェックボックスをオンにし、購入して開始 > OK をクリックします。

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

• スキーマ移行または完全移行のみ：タスクは自動的に停止します。ステータスは 完了 と表示されます。

• 増分データ移行：タスクは継続して実行され、自動的に停止しません。ステータスは 実行中 と表示されます。