Data Transmission Service:PolarDB-X 1.0 インスタンスから PolarDB-X 2.0 インスタンスへのデータ移行

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

テーブルの要件

• 移行するテーブルには、すべてのフィールドが一意である PRIMARY KEY または UNIQUE 制約が必要です。これがない場合、送信先に重複レコードが含まれる可能性があります。

• DTS は、UNIQUE 制約のみを持つテーブルのスキーマ移行をサポートしていません。移行を開始する前に、これらのテーブルに主キー制約を作成してください。

• 個々のテーブルを移行オブジェクトとして選択し、テーブルまたはカラムの名前を変更する場合、1 つのタスクで最大 1,000 個のテーブルを移行できます。1,000 個を超えるテーブルを移行するには、複数のタスクに分割するか、データベース全体を移行してください。

バイナリロギングの要件

ソース PolarDB-X 1.0 インスタンスに接続されている ApsaraDB RDS for MySQL インスタンスでバイナリロギングを有効にする必要があります。以下のパラメーターを確認してください。詳細については、「インスタンスのパラメーターの表示」をご参照ください。

移行中の制限事項

移行タスクの実行中は、以下の操作を避けてください。

• ソースインスタンスの容量のスケーリング

• 頻繁にアクセスされるテーブルの移行またはシャードの変更

• DDL 操作の実行 (これらは移行タスクの失敗やデータの不整合を引き起こす可能性があります)

• ソース PolarDB-X 1.0 インスタンスのネットワークタイプの切り替え (切り替える必要がある場合は、後で移行接続設定を更新してください)

• 完全移行のみ中のソースデータベースへのデータ書き込み (データ整合性を維持するために、スキーマ移行 + 完全なデータ移行 + 増分データ移行を使用してください)

考慮事項

• データ分散: DTS が PolarDB-X 1.0 インスタンスからデータを移行する際、データはアタッチされた ApsaraDB RDS for MySQL インスタンス全体に分散されます。DTS は各インスタンスに対してサブタスクを実行します。サブタスクのステータスは、パフォーマンス監視 ページで監視できます。

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

• XA トランザクション: DTS は、PolarDB-X 1.0 の XA トランザクションの継続性に基づいて、増分移行のデータ整合性を保証します。XA トランザクションの継続性が中断された場合 (例えば、ディザスタリカバリシナリオなど)、未コミットの XA トランザクションが失われ、データの不整合が発生する可能性があります。

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

• 表領域の断片化: 完全移行中の同時 INSERT 操作は、送信先でテーブルの断片化を引き起こします。完全移行後、送信先の使用済み表領域はソースのそれよりも大きくなります。

• パフォーマンスへの影響: 完全なデータ移行は、ソースデータベースとターゲットデータベースの両方で読み書きリソースを使用します。データベースサーバーへの負荷を軽減するために、オフピーク時間中に移行を実行してください。

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

• タスク障害からの回復: DTS タスクが失敗した場合、DTS サポートは 8 時間以内に回復を試みます。タスクは再起動され、回復中にタスクパラメーター (データベースパラメーターではない) が変更される場合があります。

ステップ 1: データ移行ページへの移動

DTS コンソールまたは DMS コンソールのいずれかを使用します。

DTS コンソール

1. DTS コンソールにログインします。DTS コンソール

2. 左側のナビゲーションウィンドウで、[データ移行] をクリックします。

3. 左上隅で、データ移行インスタンスが存在するリージョンを選択します。

DMS コンソール

手順は、ご利用の DMS コンソールモードとレイアウトによって異なる場合があります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズ」をご参照ください。

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

2. トップナビゲーションバーで、ポインターを [Data + AI] > [DTS (DTS)] > [データ移行] に合わせます。

3. **[データ移行タスク]** の右側にあるドロップダウンリストから、データ移行インスタンスが存在するリージョンを選択します。

ステップ 2: ソースデータベースとターゲットデータベースの構成

[タスクの作成] をクリックし、以下のパラメーターを設定します。

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

DTS サーバーの CIDR ブロックが、ソースデータベースとターゲットデータベースの両方のセキュリティ設定に追加されていることを確認してください。詳細については、「DTS サーバーの CIDR ブロックを追加」をご参照ください。

ステップ 3: 移行するオブジェクトの選択

「[Configure Objects]」ページで、以下のパラメーターを設定します。

ステップ 4: 詳細設定の構成

「[次へ: 詳細設定]」をクリックし、その後、以下のパラメーターを設定します。

ステップ 5: 事前チェックの実行

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

この構成の API パラメーターをプレビューするには、続行する前に、ボタンにマウスを合わせて、[OpenAPI パラメーターのプレビュー] をクリックしてください。

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

• いずれかの事前チェック項目が失敗した場合は、その項目の横にある[詳細の表示]をクリックします。問題を修正してから、[再度事前チェック]をクリックします。

• 事前チェック項目で無視できるアラートがトリガーされた場合は、[アラート詳細を確認] をクリックします。ダイアログで [無視] > [OK] の順にクリックし、次に [再事前チェック] をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

ステップ 6: インスタンスの購入と移行の開始

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

2. [Purchase Instance] ページで、以下のパラメーターを設定します。

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

3. Data Transmission Service (従量課金) サービス規約を読み、同意します。

4. [購入して開始] をクリックし、次に [OK] をクリックします。