Data Transmission Service:ApsaraDB RDS for PostgreSQL から ApsaraDB for SelectDB へのデータ移行

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

• 帯域幅：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでないと、データ移行速度に影響が出ます。

• プライマリキーまたは一意制約を持つテーブル：テーブルのフィールドが一意であることを確認してください。そうでないと、宛先データベースに重複データが存在する可能性があります。

  宛先テーブルが DTS によって作成されない場合（つまり、スキーマ移行が選択されていない場合）、宛先テーブルには、ソーステーブルと同一のプライマリキーまたは非 NULL の一意制約を設定してください。これを満たさないと、宛先データベースに重複データが発生する可能性があります。

• プライマリキーまたは一意制約を持たないテーブル：タスクの構成時に スキーマ移行 を選択し、テーブルエンジンを duplicate に設定します。

• データベース名：データベース名にハイフン（-）を含めることはできません。たとえば、dts-testdata はサポートされていません。

• テーブル数：列名マッピングを伴うテーブル単位での移行の場合、1 つのタスクで最大 1,000 テーブルまでサポートされます。それ以上のテーブルを移行する場合は、テーブルを複数のタスクに分割するか、データベース全体を移行してください。

• DDL 操作：完全なデータ移行中に、ソースデータベースで DDL 操作を実行しないでください。

• データサイズ：増分変更データの 1 行が 256 MB を超えると、移行インスタンスが失敗し、回復できなくなります。その場合は、移行インスタンスを再構成する必要があります。

• Write-Ahead Logging (WAL)：

  • wal_level を logical に設定します。

  • 増分のみの移行の場合：WAL ログを 24 時間以上保持します。

  • 完全 ＋ 増分移行の場合：WAL ログを最低 7 日間保持します。完全移行完了後、ログ保持期間を 24 時間以上に変更できます。

  重要

  WAL ログの保持期間が DTS の要件より短く、不足したログによりタスクが失敗した場合、これは Data Transmission Service (DTS) のサービスレベルアグリーメント (SLA) の対象外となります。

• 論理レプリケーションスロットのフェールオーバー: RDS PostgreSQL インスタンスは、論理レプリケーションスロットのフェールオーバーに対応しており、有効にする必要があります。詳しくは、「論理レプリケーションスロットのフェールオーバー」をご参照ください。

• 長時間トランザクション：ソースデータベースに長時間トランザクションが存在し、タスクに増分移行が含まれている場合、トランザクションがコミットされるまで WAL データが蓄積されます。ディスク領域が不足しないよう、ソースのディスク領域を監視してください。

• メジャーバージョンのアップグレード：移行インスタンスが実行中の間に、ソースデータベースのメジャーバージョンをアップグレードしないでください。これを行うと、インスタンスが永久に失敗します。

宛先 SelectDB の要件

• テーブルは Unique または Duplicate エンジンを使用する必要があります。「データモデル」をご参照ください。

• 宛先テーブルが Unique エンジンを使用する場合、宛先テーブルのすべての一意キーは、ソーステーブルにも存在し、移行対象オブジェクトに含まれている必要があります。

• データベース名およびテーブル名は、英字で始める必要があります。この要件を満たさないオブジェクト名は、オブジェクト名マッピング機能を使用して名前を変更してください。

• 中国語文字を含むオブジェクト名は、オブジェクト名マッピング機能を使用して ASCII 文字相当に名前を変更する必要があります。これを満たさないと、タスクが失敗する可能性があります。

• 1 つの移行インスタンスでは、1 つのデータベースのみを移行できます。複数のデータベースを移行する場合は、それぞれのデータベースに対して個別の移行インスタンスを構成してください。

• 移行中に、SelectDB データベースのバックエンド（BE）ノードを追加しないでください。これによりタスクが失敗した場合、移行インスタンスを再起動して再開してください。

• 移行中に、宛先の SelectDB インスタンスでクラスターを作成しないでください。これによりタスクが失敗した場合、移行インスタンスを再起動して再開してください。

• DTS はデータ内容を検証しますが、Sequences などのメタデータは検証しません。これらのメタデータは手動で検証してください。

増分移行の要件

• データをソースに書き込む前に、移行対象の各テーブルで次のコマンドを実行します。

  ALTER TABLE schema.table REPLICA IDENTITY FULL;

  schema および table を実際のスキーマ名およびテーブル名に置き換えてください。このコマンドは、トラフィックが少ない時間帯に実行し、デッドロックを回避するためにテーブルをロックしないでください。

  関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化時に自動的にこのコマンドを実行します。これは、インスタンスが初めて実行される場合、または移行対象オブジェクトの粒度がスキーマ単位に設定されており、新しいテーブルが作成された場合、または既存のテーブルが RENAME コマンドで再構築された場合に適用されます。

• 増分移行でサポートされる SQL 操作は以下のとおりです。

  操作タイプ	SQL ステートメント
  DML	INSERT、UPDATE、DELETE
  DDL	ADD COLUMN、DROP COLUMN

• Duplicate エンジンを使用するテーブルに対しては、DTS が UPDATE および DELETE ステートメントを INSERT ステートメントに変換します。

• DTS は、TimescaleDB 拡張テーブルや、クロススキーマ継承を持つテーブルを移行できません。

• パーティションテーブルを移行する場合、親テーブルとすべての子テーブルを移行対象オブジェクトに含めてください。親テーブル自体はデータを格納しませんが、これを除外するとデータの不整合が発生します。

• マルチテーブルマージのシナリオ（複数のソーステーブルから 1 つの宛先テーブルへ）では、すべてのソーステーブルのスキーマが同一である必要があります。

特殊なケース

DTS の内部動作

移行中、DTS はソースデータベースに以下のオブジェクトを作成します。これらは DTS インスタンスがリリースされた際に自動的に削除されるため、削除しないでください。

• 一時テーブル：public.dts_pg_class、public.dts_pg_attribute、public.dts_pg_type、public.dts_pg_enum、public.dts_postgres_heartbeat、public.dts_ddl_command、public.dts_args_session、public.aliyun_dts_instance

• レプリケーションスロット（プレフィックス：dts_sync_）：直近 15 分間の増分ログを取得するために使用されます。移行が失敗した場合、またはインスタンスがリリースされた場合、DTS がこのスロットをクリーンアップします。

  移行中に、ソースデータベースアカウントのパスワードを変更したり、DTS の IP アドレスをホワイトリストから削除したりすると、レプリケーションスロットが自動的にクリーンアップされません。ディスク領域の過剰消費を防ぐため、手動でクリーンアップしてください。プライマリ/セカンダリ フェールオーバーが発生した場合は、セカンダリデータベースにログインしてクリーンアップを行ってください。

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

以下のいずれかのコンソールを使用して、データ移行ページにアクセスします。

ステップ 2：ソースおよび宛先データベースの構成

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

タスク名

ソースデータベース

宛先データベース

ステップ 3：接続性のテストとオブジェクトの構成

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

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

2. オブジェクトの構成 ページで、以下のパラメーターを設定します。

   パラメーター	説明
   移行タイプ	移行戦略に応じて選択します。「移行タイプの選択」をご参照ください。ゼロダウンタイム移行の場合は、スキーマ移行、完全なデータ移行、および 増分データ移行 を選択します。一括移行の場合は、スキーマ移行 および 完全なデータ移行 を選択します。
   競合テーブルの処理モード	事前チェックとエラー報告（デフォルト）：宛先に同名のテーブルが存在する場合、事前チェックでタスクが失敗します。エラーを無視して続行：DTS がチェックをスキップします。注意：スキーマが異なる場合、データの不整合が発生する可能性があります。
   宛先インスタンスにおけるオブジェクト名の大文字小文字の処理	宛先でのデータベース名、テーブル名、および列名の大文字・小文字の形式を決定します。[DTS デフォルトポリシー] がデフォルトで選択されています。詳細については、「宛先インスタンスでのオブジェクト名の大文字・小文字の形式を指定する」をご参照ください。
   ソースオブジェクト	スキーマまたはテーブル単位で移行対象オブジェクトを選択し、アイコンをクリックして 選択済みオブジェクト に追加します。
   選択済みオブジェクト	オブジェクトを右クリックして、名前の変更、フィルター条件の設定、または増分移行の SQL 操作の選択を行います。bucket_count パラメーターを設定するには、テーブルを右クリックし、「パラメーター設定」に移動して設定を有効化し、値を指定します。オブジェクトを削除するには、オブジェクトをクリックしてから削除アイコンをクリックします。

   - bucket_count パラメーターは正の整数である必要があります。デフォルト値は auto です。 - オブジェクト名マッピングを使用してオブジェクトの名前を変更すると、そのオブジェクトに依存している他のオブジェクトが移行に失敗する可能性があります。 - 行をフィルターするには、[選択されたオブジェクト] でテーブルを右クリックし、WHERE 条件を指定します。詳細については、「フィルター条件の指定」をご参照ください。

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

   パラメーター	説明
   タスクスケジューリング用の専用クラスター	デフォルトでは、タスクは共有クラスターで実行されます。より高い安定性が必要な場合は、専用クラスターを購入してください。「DTS 専用クラスターとは」をご参照ください。
   接続失敗時の再試行時間	接続問題によりタスクが失敗と判定されるまでの DTS の再試行時間です。範囲：10～1,440 分。デフォルト：720 分。少なくとも 30 分に設定してください。
   その他の問題発生時の再試行時間	DDL または DML エラーによりタスクが失敗と判定されるまでの DTS の再試行時間です。範囲：1～1,440 分。デフォルト：10 分。ただし、接続失敗時の再試行時間 よりも短くする必要があります。
   完全なデータ移行のスロットリングの有効化	完全移行中の読み取り／書き込みスループットを制限し、データベース負荷を軽減します。ソースデータベースへのクエリ毎秒数（QPS）、完全データ移行の RPS、および 完全移行のデータ移行速度（MB/s） を構成します。
   増分データ移行のスロットリングの有効化	増分移行中のスループットを制限します。増分データ移行の RPS および 増分移行のデータ移行速度（MB/s） を構成します。
   環境タグ	任意。環境識別のためのインスタンスへのタグ付け。
   ETL の構成	抽出・変換・書き出し (ETL) 機能を有効にするには、[はい]アラート通知設定を選択します。「データ移行タスクまたはデータ同期タスクで ETL を設定する」をご参照ください。
   モニタリングとアラート	タスクが失敗した場合、または移行遅延がしきい値を超えた場合にアラートを受信するには、[はい] を選択します。詳細については、「モニタリングとアラートの設定」をご参照ください。

4. （任意）次へ：データベースおよびテーブルフィールドの構成 をクリックして、宛先テーブルの プライマリキー列、分散キー、および エンジン を設定します。

   - このステップは、移行タイプ で スキーマ移行 を選択した場合にのみ利用可能です。定義ステータス を すべて に設定すると、すべてのテーブルを編集できます。 - プライマリキー列 は複合プライマリキーを指定できます。プライマリキー列 から 1 つ以上の列を選択して 分散キー として設定します。 - プライマリキーまたは一意制約を持たないテーブルの場合は、エンジン を duplicate に設定します。これを満たさないと、移行インスタンスが失敗したり、データが失われたりする可能性があります。

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

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

   このタスク構成の API パラメーターをプレビューするには、次へ：タスク設定の保存と事前チェック の上にポインターを移動し、OpenAPI パラメーターのプレビュー をクリックします。

2. 事前チェックが完了するまで待ちます。いずれかの項目が失敗した場合：

   • 各失敗項目の横にある 詳細の表示 をクリックし、問題を解決した後、再チェック をクリックします。

   • 無視可能なアラート項目については、アラート詳細の確認 をクリックし、その後 無視 > OK > 再チェック の順にクリックします。

   重要

   アラート項目を無視すると、データの不整合が発生する可能性があります。慎重に進めてください。

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

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

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

   パラメーター	説明
   リソースグループ	移行インスタンスのリソースグループ。デフォルト：デフォルトリソースグループ。「Resource Management とは
   インスタンスクラス	移行速度を制御します。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

3. Data Transmission Service（従量課金）利用規約 を読み、同意した後、購入して開始 > OK をクリックします。

移行ステータスの確認

タスクが開始された後、データ移行 ページに移動して進行状況を監視します。

• 完全移行のみ：タスクは完了時に自動的に停止します。ステータス は 完了 に変わります。

• 完全 ＋ 増分移行：増分フェーズは継続的に実行されます。ステータス は 実行中 と表示されます。宛先への切り替え準備が整ったら、タスクを手動で停止してください。