Data Transmission Service:PolarDB-X 2.0 から AnalyticDB for PostgreSQL へのデータ移行

ソースデータベース

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

• Enterprise Edition PolarDB-X 2.0 の読み取り専用インスタンスは、ソースとして使用できません。

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

• TABLEGROUP および Locality 属性を持つデータベースまたはスキーマはサポートされません。

• 予約語（例：select）をテーブル名として使用しているテーブルは移行できません。

増分移行

増分データ移行を含める場合、ソースデータベースは以下の要件を満たす必要があります。

• バイナリログが有効化されており、binlog_row_image パラメーターが full に設定されていること。いずれかの条件を満たしていない場合、事前チェックでエラーが返され、タスクを開始できません。

• 増分移行のみの場合：バイナリログは 24 時間以上保持されていること。

• 完全 + 増分移行の場合：バイナリログは少なくとも 7 日間保持されていること。完全移行完了後は、保持期間を 24 時間以上に短縮できます。

移行中の操作

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

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

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

• 完全なデータ移行のみ（増分なし）の場合：移行中はソースデータベースへの書き込みを行わないでください。データ整合性を確保するには、スキーマ移行、完全なデータ移行、および増分データ移行を同時に選択してください。

ターゲットデータベース

• テーブルレベルの移行のみサポートされます。Append-optimized (AO) テーブルは宛先テーブルとして使用できません。

• 部分テーブル移行のためにカラムマッピングを使用する場合、またはソースとターゲットのテーブルスキーマが異なる場合、ソースに存在しターゲットに存在しないカラムのデータは失われます。

• ソーステーブルにプライマリキーがある場合、ターゲットのプライマリキーカラムは一致している必要があります。

• ソーステーブルにプライマリキーがない場合、ターゲットのプライマリキーカラムと分散キーは同一である必要があります。

• ターゲットの一意キー（プライマリキーカラムを含む）には、その分散キーのすべてのカラムが含まれている必要があります。

運用上の注意事項

• 移行前にソースおよびターゲットデータベースのパフォーマンスを評価してください。完全なデータ移行中、DTS はソースからの読み取りとターゲットへの書き込みを同時に行うため、両方のデータベースの負荷が増加します。影響を軽減するために、オフピーク時間帯に移行を実行してください。

• DTS は失敗したタスクを最大 7 日間、自動再開可能な状態に保ちます。ワークロードをターゲットに切り替える前に、失敗したタスクを停止またはリリースしてください。あるいは、タスクが自動的に再開された場合にデータが上書きされないようにするため、revoke コマンドを実行して、DTS アカウントのターゲットへの書き込み権限を取り消してください。

• DTS インスタンスで障害が発生した場合、DTS は 8 時間以内に回復を試みます。回復中に、DTS はインスタンスを再起動するか、インスタンスパラメーターを調整する可能性があります。データベースパラメーターは変更されません。調整される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれます。

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

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

以下のいずれかの方法を使用します。

DTS コンソール

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

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

3. 左上隅で、移行インスタンスが配置されているリージョンを選択します。

Data Management (DMS) コンソール

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

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

2. 上部のナビゲーションバーで、Data + AI > DTS (DTS) > データ移行 を選択します。

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

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

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

2. 次に進む前に、ページ上部の 使用制限 セクションの説明を確認してください。

3. ソースおよびターゲットデータベースを構成します。

   セクション	パラメーター	説明
   該当なし	タスク名	DTS がタスク名を自動生成します。識別しやすいように、わかりやすい名前を指定してください。名前は一意である必要はありません。
   ソースデータベース	既存の接続を選択	リストから登録済みのデータベースインスタンスを選択するか、インスタンスが登録されていない場合は手動で接続を構成します。詳細については、「データベース接続の管理」をご参照ください。 説明 DMS コンソールでは、DMS データベースインスタンスの選択 ドロップダウンリストからデータベースインスタンスを選択できます。
   	データベースタイプ	PolarDB-X 2.0 を選択します。
   	アクセス方法	Alibaba Cloud インスタンス を選択します。
   	インスタンスリージョン	ソースの PolarDB-X 2.0 インスタンスが配置されているリージョンを選択します。
   	クロスアカウント	同じ Alibaba Cloud アカウント内でデータを移行する場合は、いいえ を選択します。
   	インスタンス ID	ソースの PolarDB-X 2.0 インスタンスの ID を選択します。
   	データベースアカウント	データベースアカウントを入力します。必要な権限については、「必要な権限」をご参照ください。
   	データベースパスワード	データベースアカウントのパスワードを入力します。
   ターゲットデータベース	既存の接続を選択	リストから登録済みのデータベースインスタンスを選択するか、インスタンスが登録されていない場合は手動で接続を構成します。詳細については、「データベース接続の管理」をご参照ください。 説明 DMS コンソールでは、DMS データベースインスタンスの選択 ドロップダウンリストからデータベースインスタンスを選択できます。
   	データベースタイプ	AnalyticDB For PostgreSQL を選択します。
   	アクセス方法	Alibaba Cloud インスタンス を選択します。
   	インスタンスリージョン	ターゲットの AnalyticDB for PostgreSQL インスタンスが配置されているリージョンを選択します。
   	インスタンス ID	ターゲットの AnalyticDB for PostgreSQL インスタンスの ID を選択します。
   	データベース名	移行オブジェクトを受信するターゲットデータベースの名前を入力します。
   	データベースアカウント	ターゲットインスタンスのデータベースアカウントを入力します。
   	データベースパスワード	データベースアカウントのパスワードを入力します。

4. 接続テストして次へ をクリックします。

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

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

1. オブジェクトの構成 ページで、以下の設定を構成します。

   パラメーター	説明
   移行タイプ	要件に基づいて移行タイプを選択します。<br>- スキーマ移行 および 完全移行 のみ：継続的なレプリケーションを行わない一回限りの移行。移行中はソースへの書き込みを行わないでください。<br>- スキーマ移行、完全移行、および 増分移行：移行中のサービス継続性を確保するため（推奨）。
   競合テーブルの処理モード	[事前チェックとエラーの報告]: ソーステーブルと同じ名前の送信先テーブルをチェックします。衝突が検出された場合、事前チェックは失敗します。送信先テーブルを削除せずに名前衝突を解決するには、オブジェクト名マッピングを使用します。詳細については、「オブジェクト名のマップ」をご参照ください。<br><br>[エラーを無視して続行]: 名前衝突のチェックをスキップします。注意して使用してください。この操作により、データの不整合が発生する可能性があります。完全移行中は、送信先の衝突レコードが保持され、増分移行中は、送信先の衝突レコードが上書きされます。ソースと送信先のスキーマが異なる場合、タスクが失敗するか、一部の列のみが移行されることがあります。
   ストレージエンジンタイプ	ターゲットテーブルのストレージエンジン。デフォルト：Beam。このパラメーターは、ターゲットの AnalyticDB for PostgreSQL インスタンスのマイナーバージョンが v7.0.6.6 以降であり、かつ スキーマ移行 が選択されている場合にのみ利用可能です。
   宛先インスタンスにおけるオブジェクト名の大文字・小文字の扱い	宛先のデータベース、テーブル、およびカラム名の大文字・小文字ポリシーを構成します。デフォルトでは、DTS ポリシーが適用されます。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字・小文字の指定」をご参照ください。
   ソースオブジェクト	ソースオブジェクト セクションからオブジェクトを選択し、矢印アイコンをクリックして 選択済みオブジェクト に追加します。テーブルのみサポートされます。ビュー、トリガー、ストアドプロシージャは移行されません。
   選択済みオブジェクト	単一のオブジェクトの名前を変更するには、そのオブジェクトを右クリックします。複数のオブジェクトの名前を一度に変更するには、右上隅の 一括編集 をクリックします。詳細については、「オブジェクト名のマッピング」をご参照ください。<br><br> 説明 オブジェクトの名前を変更すると、それに依存する他のオブジェクトの移行が失敗する可能性があります。SQL 条件を使用して行をフィルターするには、選択済みオブジェクト のテーブルを右クリックしてフィルターを構成します。詳細については、「SQL 条件を使用したデータのフィルター」をご参照ください。特定のテーブルに対して移行する DML 操作を選択するには、テーブルを右クリックして操作を構成します。

2. 次へ：詳細設定 をクリックし、以下のオプションパラメーターを構成します。

   パラメーター	説明
   タスクスケジューリング用専用クラスター	デフォルトでは、DTS はタスクを共有クラスターにスケジュールします。タスクの安定性を向上させるには、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。
   接続失敗時のリトライ時間	接続が失敗した後、ソースまたは送信先に再接続するためのリトライウィンドウです。有効な値：10～1,440 分。デフォルト値：720。少なくとも 30 分に設定してください。DTS はこのウィンドウ内で再接続されるとタスクを再開します。それ以外の場合はタスクが失敗します。 説明 DTS がリトライ中は、DTS インスタンスに対して課金されます。
   その他の問題発生時のリトライ時間	DDL または DML 操作の失敗に対するリトライウィンドウです。有効な値：1～1,440 分。デフォルト値：10。少なくとも 10 分に設定してください。接続失敗時のリトライ時間より小さく設定する必要があります。
   完全データ移行時のスループット制限の有効化	完全移行中に読み取り/書き込みスループットを制限し、データベースへの負荷を軽減します。ソースデータベースへのクエリ数 (QPS)、完全データ移行の RPS、および完全移行時のデータ移行速度 (MB/s) を設定します。このオプションは、完全データ移行が選択されている場合のみ利用可能です。
   増分データ移行時のスループット制限の有効化	増分移行中のスループットを制限します。増分データ移行の RPS および 増分移行時のデータ移行速度 (MB/s) を設定します。このオプションは、増分データ移行が選択されている場合のみ利用可能です。
   双方向タスクのハートビートテーブルに対する SQL 操作の削除設定	DTS インスタンス実行中に、DTS がソースデータベースにハートビート SQL 操作を書き込むかどうかを制御します。はい：ハートビート操作を書き込みません。ただし、DTS インスタンスに遅延が表示される可能性があります。いいえ：ハートビート操作を書き込みます。ただし、ソースデータベースの物理バックアップやクローンなどの機能に影響を与える可能性があります。
   環境タグ	任意で設定できます。インスタンスを環境（例：本番環境またはテスト環境）で識別するためにタグを選択します。
   ETL の設定	移行中のデータ変換を行うための抽出・変換・書き出し (ETL) 機能を有効にします。詳細については、「ETL とは」および「データ移行またはデータ同期タスクでの ETL の設定」をご参照ください。
   モニタリングとアラート	タスクの失敗や移行遅延がしきい値を超えた場合のアラートを設定します。有効にした場合は、アラートのしきい値および通知設定を構成します。詳細については、「DTS タスク作成時のモニタリングとアラートの設定」をご参照ください。

3. （任意）次へ：データベースおよびテーブルフィールドの構成 をクリックして、ターゲットテーブルのプライマリキーカラムおよび分散キーを設定します。

   スキーマ移行 を選択した場合、各ターゲットテーブルの タイプ、プライマリキーカラム、および 分散キー を定義します。複合プライマリキーの場合は、複数のカラムを選択します。プライマリキーカラム リストの少なくとも 1 つのカラムが 分散キー である必要があります。詳細については、「CREATE TABLE」をご参照ください。

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

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

   このタスクの API パラメーターをプレビューするには、次へ：タスク設定の保存と事前チェック の上にカーソルを合わせて、OpenAPI パラメーターのプレビュー をクリックしてください。

2. 事前チェック結果を確認し、必要に応じて問題を解決します。

   結果	アクション
   失敗	タスクがブロックされます。詳細を表示 をクリックして問題をトラブルシューティングし、その後 再度事前チェック をクリックします。
   アラート（解決必須）	詳細を表示 をクリックして問題をトラブルシューティングし、その後 再度事前チェック をクリックします。
   アラート（無視可能）	アラートの詳細を確認 をクリックします。ダイアログボックスで 無視 をクリックし、その後 OK をクリックしてから 再度事前チェック をクリックします。アラートを無視すると、データの不整合が発生するか、ワークロードがリスクにさらされる可能性があります。

ステップ 5：インスタンスの購入とタスクの開始

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

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

   セクション	パラメーター	説明
   新しいインスタンスクラス	リソースグループ	移行インスタンスのリソースグループです。デフォルト値： デフォルトのリソースグループResource Management とは
   	インスタンスクラス	データ移行インスタンスのインスタンスクラス必要な移行速度に応じて、適切なインスタンスクラスを選択します。詳細については、「」をご参照ください。

3. Data Transmission Service (従量課金) サービス利用規約 チェックボックスを読み、選択します。

4. 購入して開始 をクリックし、確認メッセージで OK をクリックします。