Data Transmission Service:ApsaraDB RDS for PostgreSQL インスタンスから AnalyticDB for PostgreSQL インスタンスへのデータ同期

テーブルおよびスキーマの要件

• テーブルには PRIMARY KEY またはすべてのフィールドが一意である UNIQUE 制約が必要です。これを満たさないと、宛先データベースに重複レコードが発生する可能性があります。

  説明

  DTS 外部で宛先テーブルを作成する場合（同期タイプで スキーマ同期 を選択しない場合）、宛先テーブルにはソーステーブルと同一の PRIMARY KEY または NOT NULL UNIQUE 制約を設定してください。

• 同期対象として選択できるのはテーブルのみであり、ビュー、関数、その他のオブジェクトタイプは選択できません。

• 1 つのタスクでは 1 つのデータベースからのみデータを同期できます。複数のデータベースを同期する場合は、それぞれのデータベースに対して個別のタスクを作成してください。

• スキーマ間の継承関係を持つテーブルは同期できません。

• 宛先テーブルは append-optimized（AO）テーブルであってはなりません。

• DTS は以下のデータ型を同期しません：VARBIT、GEOMETRY、UUID、TSQUERY、TSVECTOR、TXID_SNAPSHOT。

列マッピングおよびスキーマの差異

• 非完全テーブル同期で列マッピングを使用する場合、またはソースと宛先のテーブルスキーマが異なる場合、ソースに存在し宛先に存在しない列のデータは失われます。

• オブジェクト名マッピング機能を用いて宛先データベースでテーブルまたは列の名前を変更する場合、1 つのタスクで 5,000 を超えるテーブルを同期するとリクエストエラーが発生します。5,000 を超えるテーブルを同期する場合は、複数のタスクを設定するか、代わりにデータベース全体を同期してください。

WAL ログの要件

ソースデータベースは、以下の先行書き込みログ（WAL）要件を満たす必要があります。

• wal_level を logical に設定します。

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

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

これらの要件を満たさない場合、DTS が WAL ログを取得できず、タスクが失敗するほか、例外的なケースではデータの不整合や損失が発生する可能性があります。

実行時の制約

• スキーマ同期または完全データ同期中に DDL ステートメントを実行しないでください。実行するとタスクが失敗します。

• 同期対象のスキーマにテーブルを追加したり、RENAME を用いてテーブル名を変更したりする場合、そのテーブルにデータを書き込む前に、ALTER TABLE schema.table REPLICA IDENTITY FULL; を実行してください。これによりデータの不整合を防止できます。デッドロックを回避するため、この操作は非ピーク時間帯に実行してください。

  説明

  schema および table は、実際のスキーマ名およびテーブル名に置き換えてください。

• ソースデータベース内に 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 はインスタンスのリリース時にこれらのテーブルを自動的に削除します。

• ソースデータベース内の長時間実行トランザクションは、WAL ログの蓄積を引き起こし、ディスク領域を枯渇させる可能性があります。

• タスク実行中にソースデータベースでメジャーバージョンアップが行われると、タスクは失敗し、復旧できません。タスクを再構成してください。

• 単一の増分データ変更が 256 MB を超えてはなりません。超えた場合、タスクは失敗し、復旧できません。タスクを再構成してください。

レプリケーションスロット

DTS はソースデータベース内に、プレフィックス dts_sync_ を付与したレプリケーションスロットを作成します。このスロットは直近 15 分間の増分ログを保持します。

DTS はまた、同期遅延を追跡するために、ソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルも追加します。

ソース固有の制約

ApsaraDB RDS for PostgreSQL：

• タスク実行中にソースの ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。変更するとタスクが失敗します。

• ソースインスタンスでプライマリ/セカンダリ スイッチオーバーを実行するには、まず論理レプリケーションスロットフェールオーバー機能を有効化します。「論理レプリケーションスロットフェールオーバー」を参照してください。

自主管理 PostgreSQL：

• max_wal_senders および max_replication_slots を、既存のレプリケーションスロット数と今後作成する DTS インスタンス数の合計より大きい値に設定してください。

• 自主管理 PostgreSQL データベースでのプライマリ／セカンダリスイッチオーバーはタスクを失敗させます。

Google Cloud SQL for PostgreSQL：

• データベースアカウント パラメーターを、cloudsqlsuperuser 権限を持つアカウントに設定してください。同期対象オブジェクトを選択する際は、そのアカウントが管理権限を持つオブジェクトのみを選択するか、該当オブジェクトに対して OWNER 権限をアカウントに付与してください。

  説明

  cloudsqlsuperuser 権限を持つアカウントは、同じ権限を持つ他のアカウントが所有するデータを管理できません。

データ整合性

• タスク開始前に、ソースおよび宛先データベースのパフォーマンスへの影響を評価してください。タスクは非ピーク時間帯に実行することを推奨します。

• 完全データ同期中、同時実行の INSERT 操作により宛先データベースでテーブルの断片化が発生するため、完全同期完了後の宛先表領域はソースよりも大きくなる可能性があります。

• 同期中に DTS 以外のソースから宛先データベースへデータが書き込まれると、データの不整合が発生します。他のソースが宛先へ書き込みを行う状態で Data Management（DMS）を用いてオンライン DDL 操作を実行した場合、データ損失が発生する可能性があります。

• DTS のみを使用して送信先にデータを書き込む場合、同期中にソーステーブルでオンライン DDL 操作を実行するために DMS を使用します。詳細については、「テーブルのロックを解除せずにスキーマを変更する」をご参照ください。

タスクの復旧

DTS タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に回復を試みます。 回復中、タスクが再起動されたり、タスクパラメーター (データベースパラメーターではない) が変更されたりする場合があります。 変更される可能性のあるパラメーターの詳細については、「DTS インスタンスのパラメーターを変更する」の インスタンスパラメーターの変更 セクションをご参照ください。

ステップ 1：データ同期タスクに移動

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

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

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

   説明

   • ナビゲーションは、DMS コンソールのモードおよびレイアウトによって異なる場合があります。『シンプルモード』および『DMS コンソールのレイアウトとスタイルをカスタマイズする』をご参照ください。

   • 直接、新しい DTS コンソールのデータ同期タスクページ にアクセスすることもできます。

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

1. データ同期タスク の右側で、同期インスタンスを配置するリージョンを選択します。

   説明

   新しい DTS コンソールでは、上部のナビゲーションバーでリージョンを選択します。

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

3. （任意）右上隅の 新規構成ページ をクリックします。

   説明

   • 前のバージョンに戻る が表示されている場合は、このステップをスキップしてください。

   • 新規構成ページを使用してください。バージョン間で一部のパラメーターが異なります。

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

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

タスク名

ソースデータベース

宛先データベース

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

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

DTS は、自動的にそのサーバーの CIDR ブロックを Alibaba Cloud データベースインスタンスのホワイトリストおよび ECS でホストされるデータベースのセキュリティグループルールに追加します。データセンター内またはサードパーティのクラウドプラットフォーム上の自己管理データベースの場合、DTS サーバーの CIDR ブロックを手動でデータベースのホワイトリストに追加します。詳細については、「DTS サーバーの CIDR ブロック」をご参照ください。

ステップ 5：同期対象の構成

オブジェクトおよび競合処理の構成

パラメーター	説明
同期対象の DDL および DML 操作	同期する SQL 操作。テーブルごとに構成する場合は、選択済みオブジェクト 内のオブジェクトを右クリックし、操作を選択します。詳細については、「増分同期でサポートされる SQL 操作」をご参照ください。
競合テーブルの処理モード	事前チェックとエラー報告オブジェクト名マッピング：宛先テーブルとソーステーブルの名前が一致する場合、事前チェックが失敗します。競合を解決するには、 を使用してください。エラーを無視して続行：名前競合のチェックをスキップします。完全同期中は、主キーまたは一意キーが一致する既存の宛先レコードが保持され、増分同期中は上書きされます。スキーマが異なる場合、初期化が部分的に失敗する可能性があります。
宛先インスタンスにおけるオブジェクト名の大文字小文字	DTS が宛先におけるデータベース名、テーブル名、および列名をどのように処理するか。デフォルトは DTS デフォルトポリシー です。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクト	このセクションからオブジェクトを選択し、 をクリックして 選択済みオブジェクト に追加します。選択可能な粒度：列、テーブル、またはスキーマ。
選択済みオブジェクト	テーブルを右クリックして、その名前を変更したり、データフィルターを設定したり、テーブルごとの SQL 操作を構成したりできます。複数のオブジェクトの名前を一度に変更するには、[バッチ編集] をクリックします。詳細については、「オブジェクト名のマッピング」および「フィルター条件の設定」をご参照ください。

説明

オブジェクト名マッピングを用いたオブジェクト名の変更により、依存オブジェクトの同期が失敗する場合があります。

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

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

ステップ 7：インスタンスの購入および開始

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

購入ページで、以下の項目を構成します。

Data Transmission Service（従量課金）サービス利用規約 を読み、同意した上で、購入および開始 をクリックします。確認ダイアログで OK をクリックします。

タスクはタスクリストに表示されます。そこから進捗をモニターできます。