Data Transmission Service:PolarDB for MySQL クラスターから ApsaraDB RDS for MySQL インスタンスへのデータ移行

ソースデータベース

• テーブルには PRIMARY KEY または一意制約（すべてのフィールドが一意）が必要です。該当しない場合、ターゲットデータベースに重複レコードが生成される可能性があります。

• テーブルを移行対象として選択し、ターゲットでテーブル名またはカラム名を変更する必要がある場合、1 つのタスクでサポートされる最大テーブル数は 1,000 です。1,000 を超える場合は、複数のタスクを構成するか、代わりにデータベース単位での移行を実施してください。

• スキーマ移行または完全なデータ移行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。

• 増分移行を含まない完全なデータ移行（フルオンリー）中は、ソースデータベースへの書き込みを行わないでください。データの不整合を回避するため、タスクには必ず増分データ移行を含めてください。

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

• ソースクラスターの読み取り専用ノードは移行できません。

増分移行におけるバイナリログの保持期間

移行タイプに応じて、バイナリログの保存期間を設定してください。

DTS がバイナリログを取得できない場合（保持期間が短すぎるなど）、タスクは失敗します。例外的なケースでは、データの不整合や損失が発生する可能性があります。完全なデータ移行完了後は、保持期間を 24 時間を超えるように短縮できます。

外部キーの動作

• DTS は、スキーマ移行時に外部キーを移行します。

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

データ型の精度

DTS は、FLOAT および DOUBLE カラムの値を ROUND(COLUMN,PRECISION) を使用して取得します。精度が指定されていない場合、FLOAT には 38 桁、DOUBLE には 308 桁がデフォルトで使用されます。移行を開始する前に、これらのデフォルト値が要件を満たすことを確認してください。

ターゲットデータベースの作成

DTS は、ApsaraDB RDS for MySQL インスタンス内にターゲットデータベースを自動的に作成します。ソースデータベース名が無効な場合は、タスクの構成前に手動でデータベースを作成してください。詳細については、「データベースの管理」をご参照ください。

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

ステップ 1：データ移行タスクページへ移動

1. Data Management (DMS) コンソール にログインします。

2. トップナビゲーションバーで、DTS をクリックします。

3. 左側ナビゲーションウィンドウで、DTS (DTS) ＞ データ移行 を選択します。

ステップ 2：タスクの作成

1. データ移行タスク の横にあるドロップダウンリストから、データ移行インスタンスが配置されているリージョンを選択します。

   説明

   新しい DTS コンソールでは、左上隅からリージョンを選択します。

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

3. （任意）右上隅で、新規構成ページ をクリックして、新しい構成ページに切り替えます。

   説明

   前のバージョンに戻る が表示されている場合は、このステップをスキップしてください。新しい構成ページの使用を推奨します。

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

以下のパラメーターを構成します。

タスク情報

ソースデータベース

宛先データベース

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

接続性のテストと続行 をクリックします。

DTS は、DTS サーバーの CIDR ブロックを、Alibaba Cloud データベースインスタンスの IP アドレスホワイトリストと、ECS でホストされているデータベースのセキュリティグループルールに自動的に追加します。 ソースデータベースまたはターゲットデータベースが複数の ECS インスタンスでホストされている場合、各 ECS インスタンスのセキュリティグループルールに DTS サーバーの CIDR ブロックを手動で追加する必要があります。 データセンターまたはサードパーティのクラウドサービス内の自己管理データベースの場合、DTS サーバーの CIDR ブロックをデータベースの IP アドレスホワイトリストに手動で追加してください。 詳細については、「DTS サーバーの CIDR ブロック」をご参照ください。

ステップ 5：オブジェクトの選択と移行設定の構成

オブジェクトの選択 ページで、以下のパラメーターを構成します。

パラメーター	説明
移行タイプ	ワンタイム移行の場合は、スキーマ移行 および 完全なデータ移行 を選択します。移行中にソースを稼働させ続ける場合は、3 つのタイプすべて（増分データ移行 を含む）を選択します。
ソースデータベース内のトリガーの移行方法	これは、スキーマ移行 および 増分データ移行 の両方が選択されている場合にのみ利用可能です。詳細については、「ソースデータベースからのトリガーの同期または移行」をご参照ください。
競合するテーブルの処理モード	事前チェックおよびエラー報告（デフォルト）：両方のデータベースに同一名称のテーブルが存在する場合、事前チェックが失敗します。エラーを無視して続行：このチェックをスキップします。注意：ソースとターゲットのスキーマが異なる場合、データの不整合が発生する可能性があります。
ターゲットインスタンスにおけるオブジェクト名の大文字小文字	デフォルト: [DTS デフォルトポリシー]。詳細については、「宛先インスタンスでのオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクト	オブジェクトを選択し、 アイコンをクリックして 選択済みオブジェクト に移動します。カラム、テーブル、またはデータベースを選択できます。テーブルまたはカラムを選択すると、ビュー、トリガー、ストアドプロシージャは除外されます。
選択済みオブジェクト	オブジェクトを右クリックして、名前を変更するかフィルター条件を設定します。[一括編集] をクリックして、複数のオブジェクトを一度に名前を変更します。「オブジェクト名のマップ」をご参照ください。注意：オブジェクトの名前を変更すると、依存オブジェクトが移行に失敗する場合があります。

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

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

ステップ 6：設定の保存と事前チェックの実行

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

DTS は、移行を開始する前に事前チェックを実行します。事前チェックが成功した場合にのみ、タスクが開始されます。

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

• アラートが生成された場合：アラート詳細の確認 をクリックします。ダイアログで 無視 をクリックし、確認後、再度事前チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

ステップ 7：インスタンスの購入

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

インスタンスの購入 ページで、以下の項目を構成します。

Data Transmission Service（従量課金）利用規約 をお読みになり、同意した上で、購入して開始 をクリックします。

タスクがタスクリストに表示されます。そこから進行状況を監視できます。

ステップ 8：移行の完了

タスクのステータスが「完全なデータ移行完了」となり、増分移行の遅延がほぼゼロになった時点で、ターゲットデータベースはトラフィックを受け入れる準備が整います。

移行を完了するには、以下の手順を実行してください。

1. ソースおよびターゲットデータベース間のデータ整合性を検証します。

2. DTS 移行タスクを停止またはリリースします。あるいは、ターゲットデータベース上の DTS アカウントに付与された書き込み権限を REVOKE で取り消します。

3. アプリケーションのトラフィックをターゲット ApsaraDB RDS for MySQL インスタンスに切り替えます。

4. アプリケーションがターゲットデータベースに対して正しく機能することを検証します。