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

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

ハード制約 — 満たされない場合、移行は失敗します：

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

• 読み取り専用の PolarDB-X 1.0 インスタンスからの移行はサポートされていません。

• 移行オブジェクトとしてテーブルを選択し、テーブル名または列名を変更する必要がある場合、1 つのタスクでサポートされるテーブルは最大 1,000 です。1,000 を超えるテーブルの場合は、移行を複数のタスクに分割するか、データベース全体を移行してください。

増分データ移行に必要な設定：

• バイナリログが有効になっており、binlog_row_image が full に設定されている必要があります。これが設定されていない場合、事前チェックが失敗し、タスクを開始できません。

• バイナリログの保持期間：保持期間が不十分な場合、DTS がバイナリログを読み取れず、タスクの失敗やデータの不整合を引き起こす可能性があります。完全移行が完了した後、保持期間を 24 時間以上に短縮できます。

  • 増分移行のみ：バイナリログを 24 時間以上保持します。

  • 完全 + 増分移行：バイナリログを少なくとも 7 日間保持します。

移行中の操作制限：

• ソースインスタンスのアップグレードやダウングレード、頻繁に更新されるテーブルの変更、シャードキーの変更、ソースオブジェクトに対する DDL 操作を実行しないでください。これらの操作はタスクの失敗を引き起こします。

• 完全および増分移行中、DTS はセッションレベルで外部キー制約チェックとカスケード操作を一時的に無効にします。この期間中のカスケード更新または削除は、データの不整合を引き起こす可能性があります。

• 移行中に PolarDB-X 1.0 インスタンスのネットワークタイプが変更された場合は、DTS 移行タスクのネットワーク接続設定を適宜更新してください。

• 完全移行のみ（増分移行なし）の場合：移行中にソースにデータを書き込まないでください。これにより不整合が発生します。データの一貫性を保つには、[スキーマ移行]、[完全データ移行]、および[増分データ移行]を同時に選択してください。

その他の制限事項

• 移行前に、ソースおよびターゲットデータベースのパフォーマンスへの影響を評価してください。移行タスクはオフピーク時に実行してください。完全データ移行は両方のデータベースの読み取りおよび書き込みリソースを使用するため、サーバーの負荷が増加する可能性があります。

• 完全データ移行では同時 INSERT 操作が使用されるため、移行先でテーブルの断片化が発生します。完全移行後、移行先のテーブルスペースはソースよりも大きくなります。

• DTS は失敗したタスクを最大 7 日間再開しようとします。ワークロードを移行先に切り替える前に、失敗したタスクを停止またはリリースしてください。または、REVOKE 文を実行して、移行先にアクセスする DTS アカウントから書き込み権限を取り消してください。ワークロードを切り替えた後に失敗したタスクが再開されると、ソースデータが移行先データを上書きする可能性があります。

注意事項

• DTS は、バイナリログの位置を進めるために、ソースデータベースの ` dts_health_check.ha_health_check ` テーブルを定期的に更新します。

• 移行中に移行先の ApsaraMQ for Kafka インスタンスがアップグレードまたはダウングレードされた場合は、インスタンスを再起動して移行を再開してください。

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

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

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

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

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

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

ステップ 3：ソースデータベースとターゲットデータベースの設定

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

ソースデータベース (PolarDB-X 1.0)

ターゲットデータベース (ApsaraMQ for Kafka)

ステップ 4：接続テスト

ページ下部の [接続テストと次へ] をクリックします。

Alibaba Cloud データベースインスタンス (ApsaraDB RDS for MySQL や ApsaraDB for MongoDB など) の場合、DTS は自動的にそのサーバー CIDR ブロックをインスタンスの IP アドレスホワイトリストに追加します。 Elastic Compute Service (ECS) インスタンス上の自己管理データベースの場合、DTS は自動的にその CIDR ブロックを ECS セキュリティグループルールに追加します。 自己管理データベースが複数の ECS インスタンスにまたがる場合は、各インスタンスのセキュリティグループルールに CIDR ブロックを手動で追加してください。 データセンター内、またはサードパーティプロバイダーによってホストされている自己管理データベースの場合、DTS サーバーの CIDR ブロックをデータベースの IP アドレスホワイトリストに手動で追加してください。 詳細については、「DTS サーバーの CIDR ブロックをオンプレミスデータベースのセキュリティ設定に追加する」をご参照ください。

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

以下のパラメーターを設定します：

ステップ 6：詳細設定

[次へ：詳細設定] をクリックし、以下を設定します：

ステップ 7：事前チェックの実行

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

DTS はタスク開始前に事前チェックを実行します。タスクは事前チェックに合格した後にのみ続行できます。

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

• 事前チェック中にアラートが表示された場合：

  • 無視できないアラートの場合：[詳細の表示] をクリックし、問題を修正して再度事前チェックを実行します。

  • 無視できるアラートの場合：[アラート詳細の確認] をクリックし、[無視] > [OK] > [再度事前チェック] をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

ステップ 8：移行インスタンスの購入

成功率が 100% に達するまで待ってから、[次へ：インスタンスの購入] をクリックします。

[インスタンスの購入] ページで、以下を設定します：

ステップ 9：移行の開始

[Data Transmission Service (従量課金) 利用規約] を読み、同意してから、[購入して開始] をクリックします。

移行タスクが開始されます。タスクリストで進捗を監視します。