Data Transmission Service:Db2 for LUW データベースから PolarDB for MySQL クラスターへのデータ移行

スキーマ移行

• DTS は、ソースデータベースから送信先データベースへ外部キーを移行します。

完全なデータ移行および増分データ移行

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

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

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

• 移行対象のテーブルには、PRIMARY KEY または一意制約（UNIQUE constraint）が設定されており、すべてのフィールド値が一意である必要があります。これらの制約が設定されていないテーブルは、送信先データベースで重複レコードを生成する可能性があります。

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

増分データ移行の要件

• ソースデータベースでデータログ機能が有効化されている必要があります。無効な場合、事前チェックに失敗し、移行タスクを開始できません。

• ログ保持期間の要件：DTS が保持期間不足によりデータログを取得できない場合、タスクは失敗し、データ損失または不整合が発生する可能性があります。ログ保持期間がこれらの要件を満たさない場合、サービスレベルアグリーメント（SLA）による信頼性およびパフォーマンスの保証は行われません。

  • 増分移行のみの場合：ログは 24 時間以上保持する必要があります。

  • 完全なデータ移行と増分データ移行を併用する場合：ログは最低 7 日間保持する必要があります。

  • 完全なデータ移行完了後は、ログ保持期間を 24 時間以上に設定してください。

• DTS は、Db2 for LUW の Change Data Capture（CDC）レプリケーション技術を用いて増分データを移行します。CDC 固有の制限事項については、「SQL レプリケーションの一般的なデータ制限」をご参照ください。

移行中のソースデータベースでの操作

• 完全なデータ移行中：データベースまたはテーブルのスキーマを変更する DDL 操作は実行しないでください。このような操作は、移行タスクの失敗を引き起こします。

• 完全なデータ移行（増分なし）中：ソースデータベースへのデータ書き込みは行わないでください。データ整合性を確保するためには、完全なデータ移行と増分データ移行の両方を選択することを推奨します。

その他の制限事項

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

• 完全なデータ移行完了後、送信先データベースの使用済み表領域（tablespace）は、ソースデータベースよりも大きくなります。移行中の同時 INSERT 操作により、テーブルの断片化が発生する可能性があります。

• 移行中は、ソースデータベース以外からのデータを送信先データベースに書き込まないでください。他のソースからのデータは、データの不整合を引き起こします。移行後の DDL 操作には、Data Management（DMS） をご使用ください。

• 送信先データベースで DDL ステートメントの実行に失敗した場合でも、DTS はタスクの実行を継続します。失敗した DDL ステートメントは、タスクログで確認できます。「タスクログの表示」をご参照ください。

自己管理型 Db2 for LUW データベースの特殊ケース

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

• DTS は、送信先データベースで最新に移行されたデータのタイムスタンプと、ソースデータベースの現在時刻を比較することで、移行遅延を算出します。ソースデータベースで長期間 DML 操作が実行されない場合、遅延の測定値が不正確になる可能性があります。遅延を更新するには、ソースデータベースで任意の DML 操作を実行してください。

  説明

  データベース全体を移行対象として選択する場合、ハートビートテーブルを作成してください。DTS はこのテーブルを 1 秒ごとに更新し、遅延の測定値を正確に保ちます。

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

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

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

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

ステップ 2：リージョンの選択

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

ステップ 3：ソースおよび送信先データベースの構成

タスクの作成 をクリックします。タスクの作成 ページで、以下のパラメーターを構成します。

ソースデータベース（Db2 for LUW）

送信先データベース（PolarDB for MySQL）

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

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

DTS は、Alibaba Cloud のデータベースインスタンスおよび ECS 上でホストされるデータベースに対して、自動的に自社サーバーの CIDR ブロックを IP アドレスホワイトリストまたはセキュリティグループルールに追加します。複数の ECS インスタンス上で動作する自己管理型データベースの場合は、各インスタンスのセキュリティグループルールに DTS の CIDR ブロックを手動で追加してください。オンプレミスデータベースまたは第三者プロバイダーがホストするデータベースの場合は、データベースのホワイトリストに DTS の CIDR ブロックを手動で追加してください。

DTS サーバーの CIDR ブロックの完全な一覧については、「オンプレミスデータベースのセキュリティ設定への DTS サーバー CIDR ブロックの追加」の「DTS サーバーの CIDR ブロック」セクションをご参照ください。

ステップ 5：移行対象の構成

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

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

次へ：高度な設定 をクリックし、以下のパラメーターを構成します。

データ検証

データ検証を構成するには、「データ検証の有効化」をご参照ください。

高度な設定

ステップ 7：設定の保存および事前チェックの実行

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

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

• チェック項目のいずれかが失敗した場合、失敗した項目の横にある 詳細の表示 をクリックし、エラーメッセージに基づいて問題を修正した後、再チェック をクリックしてください。

• チェック項目でアラートが発生した場合：

  • アラートを無視できない場合は、失敗した項目の横にある 詳細の表示 をクリックしてトラブルシューティングを行い、その後 再チェック をクリックしてください。

  • アラートを安全に無視できる場合は、アラートの詳細の確認 をクリックします。詳細の表示 ダイアログボックスで 無視 をクリックし、次に OK、そして 再チェック をクリックしてください。アラートを無視すると、データの不整合が発生する可能性があります。

ステップ 8：事前チェックの完了を待機

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

ステップ 9：インスタンスクラスの構成

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

ステップ 10：サービス利用規約の承諾

Data Transmission Service（従量課金）サービス利用規約 を確認し、チェックボックスをオンにして承諾してください。

ステップ 11：移行タスクの開始

購入および開始 をクリックします。移行タスクが開始されます。タスクリストで進行状況を確認できます。