Data Transmission Service:PolarDB-X 1.0 インスタンスから DataHub プロジェクトへのデータ移行

ソースデータベース

• テーブル数の制限： テーブルを移行対象として選択し、宛先テーブルまたはカラムの名前を変更する場合、1 つのタスクで最大 1,000 テーブルまでサポートされます。この上限を超えるとリクエストエラーが発生します。移行タスクを複数に分割するか、データベース全体を単一のオブジェクトとして移行してください。

• 読み取り専用インスタンス： 読み取り専用の PolarDB-X 1.0 インスタンスからのデータ移行はできません。

• バイナリログの保持期間： バイナリログを 24 時間以上保持してください。DTS がバイナリログを読み取れない場合、タスクは失敗し、データ損失またはデータの不整合が発生する可能性があります。上記の要件に基づき、バイナリログの保持期間を適切に設定してください。設定が不適切な場合、Data Transmission Service (DTS) のサービスレベル合意 (SLA) では、サービスの信頼性およびパフォーマンスを保証しません。

• 移行中の禁止操作： 移行中にソースインスタンスの設定の変更、頻繁に更新されるテーブルの移行、シャードキーの変更、ソースオブジェクトに対する DDL 操作を実行しないでください。これらの操作により、移行タスクが失敗する可能性があります。

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

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

• スキーマのみの移行中の書き込み操作： 増分データ移行を伴わないスキーマ移行を実行する場合、データの不整合を防ぐため、移行中にソースデータベースへの書き込みを停止してください。

その他の制限事項

• ソースおよびターゲットデータベースのパフォーマンスへの影響を軽減するため、非ピーク時間帯に移行を実行してください。

• DTS は失敗したタスクを最大 7 日間自動的に再試行します。ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止または解放するか、REVOKE を実行して、ターゲットデータベースにおける DTS の書き込み権限を削除してください。これを実行しない場合、失敗したタスクが再開され、ターゲットデータがソースデータで上書きされる可能性があります。

注意事項

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

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

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

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

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

コンソールの操作は、DMS コンソールのモードおよびレイアウトによって異なる場合があります。「シンプルモード」および「DMS コンソールのレイアウトおよびスタイルのカスタマイズ」をご参照ください。また、直接「新しい DTS コンソールのデータ移行タスクページ」にアクセスすることもできます。

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

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

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

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

[タスクの作成] をクリックし、ソースおよびターゲットデータベースを構成します。

ソースデータベースの設定

宛先データベース

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

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

DTS は、Alibaba Cloud データベースインスタンスまたは Elastic Compute Service (ECS) のセキュリティグループの IP アドレスホワイトリストに、自社サーバーの CIDR ブロックを自動的に追加します。

ステップ 5：移行オブジェクトの構成

パラメーター	説明
[移行タイプ]	[スキーマ移行]、[増分データ移行]、または両方を選択します。
[競合テーブルの処理モード]	[事前チェックとエラー報告]：宛先テーブルの名前がソーステーブルと同じ場合、事前チェックが失敗します。オブジェクト名マッピング を使用して、移行前に競合するテーブルの名前を変更してください。[エラーを無視して続行]：名前の競合チェックをスキップします。スキーマが一致する場合、DTS は重複するプライマリキーを持つレコードをスキップします。スキーマが異なる場合、特定のカラムのみが移行されるか、タスクが失敗します。慎重にご使用ください。
[追加カラムの命名規則]	DTS は移行後に宛先テーブルに追加カラムを追加します。これらのカラム名が宛先の既存カラム名と競合する場合、移行は失敗します。競合を回避するため、[新規ルール] または [従来のルール] を選択して命名を制御してください。選択前に競合がないか確認してください。「追加カラムの命名規則」をご参照ください。
[宛先インスタンスにおけるオブジェクト名の大文字小文字]	宛先におけるデータベース、テーブル、カラム名の大文字小文字を制御します。デフォルトでは DTS のポリシーが適用されます。「宛先インスタンスにおけるオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクト	1 つ以上のオブジェクトを選択し、 をクリックして [選択済みオブジェクト] に移動します。テーブルまたはデータベース全体を選択できます。テーブルを選択した場合、DTS はビュー、トリガー、ストアドプロシージャは移行しません。
[選択済みオブジェクト]	オブジェクトを右クリックして名前を変更したり、SQL フィルター条件を追加したり、移行対象の特定の SQL 操作を選択したりできます。複数のオブジェクトを一度に名前変更するには、[一括編集] をクリックします。「オブジェクト名のマッピング」および「SQL 条件を使用したデータのフィルター処理」をご参照ください。

データベースを移行オブジェクトとして選択し、ソーステーブルにプライマリキー（単一カラムまたは複合）がある場合、そのプライマリキーが宛先における分散キーとして使用されます。ソーステーブルにプライマリキーがない場合、DTS は宛先に自動採番主キー列を生成しますが、これはデータの不整合を引き起こす可能性があります。

オブジェクト名マッピングを使用してオブジェクトの名前を変更すると、依存オブジェクトの移行が失敗する可能性があります。

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

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

DTS は再試行の試行回数に対して課金されます。ソースおよびターゲットインスタンスがリリースされた後は、速やかに DTS インスタンスをリリースしてください。

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

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

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

DTS は、移行を開始する前にタスク構成を検証します。事前チェックでは、接続性、アカウント権限、バイナリログ設定、オブジェクト互換性が確認されます。

• 事前チェック項目のいずれかが失敗した場合、[詳細の表示] をクリックしてエラー内容を確認し、問題を修正した後、[再チェック] をクリックしてください。

• 事前チェック項目が安全に無視できるアラートをトリガーした場合、[アラート詳細の確認] をクリックし、「詳細の表示」ダイアログで [無視] をクリックし、[OK] をクリックした後、[再チェック] をクリックしてください。

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

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

[インスタンスの購入] ページで、インスタンスクラスを構成します。

ステップ 9：移行の開始

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

移行タスクが開始され、タスク一覧に表示されます。そこからタスクの進行状況を監視できます。