すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:PostgreSQL ソースデータベースに関する注意事項と制限事項

    ドキュメントセンター

    Data Transmission Service:PostgreSQL ソースデータベースに関する注意事項と制限事項

    最終更新日:Jan 31, 2026

    データ同期のソースデータベースが PostgreSQL データベース（ApsaraDB RDS for PostgreSQL インスタンスまたは自主管理 PostgreSQL データベースなど）の場合、データ同期タスクを設定する前に、本トピックの注意事項と制限事項をご確認ください。これにより、データ同期タスクが期待通りに実行されます。

    PostgreSQL ソースデータベース向け同期ソリューションの概要

    以下のソリューションに基づき、同期タスクの注意事項と制限事項をご参照ください。

    説明

    デフォルトでは、DTS はデータを宛先データベースに同期する際に外部キー制約を無効にします。そのため、ソースデータベースで実行されるカスケード操作や削除操作は、以下の宛先データベースには同期されません。

    • ApsaraDB RDS for PostgreSQL

    • AnalyticDB for PostgreSQL

    • PolarDB for PostgreSQL (Oracle 互換)

    • ApsaraDB RDS for MySQL

    • PolarDB for PostgreSQL

    PostgreSQL データベース間の同期

    • ApsaraDB RDS for PostgreSQL インスタンス間の単方向同期

      Type

      Description

      ソースデータベースの制限事項

      • 同期対象のテーブルにはプライマリキーまたは一意制約が存在し、フィールド値が一意である必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

        説明

        宛先テーブルが DTS によって作成されていない場合（つまり、同期タイプがスキーマ同期に設定されていない場合）、ソースデータベースから同期されるテーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

      • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

      • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

      • DTS は、ソースデータベースからの一時テーブル、内部システムトリガー、および一部の関数（C 言語関数および PROCEDURE と FUNCTION の内部関数）の同期をサポートしていません。一方で、一部のカスタムデータ型（COMPOSITE、ENUM、RANGE）および以下の制約（プライマリキー、外部キー、一意、CHECK）の同期はサポートしています。

      • 先行書き込みログ (WAL)：

        • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

        • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

      • ソースデータベースの操作に関する制限事項

        • 同期タスクが期待通りに実行され、フェールオーバーによる論理サブスクリプションの中断を防ぐため、ApsaraDB RDS for PostgreSQL インスタンスで Logical Replication Slot Failover を有効化する必要があります。詳細については、「Logical Replication Slot Failover」をご参照ください。

        • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

        • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

          説明

          完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

      • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

      • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      その他の制限事項

      • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

      • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

      • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

      • 同期対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、ソースオブジェクト を設定する際、同期タイプ に スキーマ同期 を選択する場合は、シーケンス を選択するか、スキーマ全体を同期することを推奨します。そうしないと、同期インスタンスが正常に実行されない可能性があります。

      • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

        • インスタンスを初めて実行するとき。

        • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

        • 同期オブジェクトを変更する機能を使用する場合。

        説明

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

        • この操作はオフピーク時間帯に実行することを推奨します。

      • DTS はデータ内容の検証を行いますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータの検証はご自身で行ってください。

      • 業務を宛先インスタンスに切り替えた後、新しいシーケンスはソースシーケンスの最大値から増分されません。業務切り替え前に、宛先データベースのシーケンス値を更新する必要があります。詳細については、「宛先データベースのシーケンス値の更新」をご参照ください。

      • DTS は、増分データの DDL 文、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

      • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

        説明

        • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

        • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

        Amazon slot查询信息

      • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

      • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

      • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

      • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

      • 完全同期または増分同期タスクにおいて、ソースデータベースの同期対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、宛先データベースアカウントが特権アカウントまたはスーパーユーザ権限を持つ場合、DTS はセッションレベルで一時的に `session_replication_role` パラメーターを `replica` に設定します。宛先データベースアカウントにこれらの権限がない場合は、宛先データベースで手動で `session_replication_role` パラメーターを `replica` に設定する必要があります。この期間中（`session_replication_role` が `replica` に設定されている間）、ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS タスクのリリース後は、`session_replication_role` パラメーターを `origin` に戻すことができます。

      • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

        説明

        パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

      • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

        説明

        PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

      特殊ケース

      • ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合

        同期中は、ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。そうしないと、同期が失敗します。

      • ソースインスタンスが自主管理 PostgreSQL データベースの場合

        `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

      • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

        説明

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

    • 自主管理 PostgreSQL データベースから ApsaraDB RDS for PostgreSQL インスタンスへの同期

      Type

      Description

      ソースデータベースの制限事項

      • 同期対象のテーブルにはプライマリキーまたは一意制約が存在し、フィールド値が一意である必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

        説明

        宛先テーブルが DTS によって作成されていない場合（つまり、同期タイプがスキーマ同期に設定されていない場合）、ソースデータベースから同期されるテーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

      • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

      • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

      • DTS は、ソースデータベースからの一時テーブル、内部システムトリガー、および一部の関数（C 言語関数および PROCEDURE と FUNCTION の内部関数）の同期をサポートしていません。一方で、一部のカスタムデータ型（COMPOSITE、ENUM、RANGE）および以下の制約（プライマリキー、外部キー、一意、CHECK）の同期はサポートしています。

      • 先行書き込みログ (WAL)：

        • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

        • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

      • 自主管理 PostgreSQL データベースでフェールオーバーが発生した場合、同期は失敗します。

      • `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

      • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

      • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

        説明

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

      • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

        説明

        完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

      • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      その他の制限事項

      • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

      • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

      • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

      • 同期対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、ソースオブジェクト を設定する際、同期タイプ に スキーマ同期 を選択する場合は、シーケンス を選択するか、スキーマ全体を同期することを推奨します。そうしないと、同期インスタンスが正常に実行されない可能性があります。

      • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

        • インスタンスを初めて実行するとき。

        • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

        • 同期オブジェクトを変更する機能を使用する場合。

        説明

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

        • この操作はオフピーク時間帯に実行することを推奨します。

      • DTS はデータ内容の検証を行いますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータの検証はご自身で行ってください。

      • 業務を宛先インスタンスに切り替えた後、新しいシーケンスはソースシーケンスの最大値から増分されません。業務切り替え前に、宛先データベースのシーケンス値を更新する必要があります。詳細については、「宛先データベースのシーケンス値の更新」をご参照ください。

      • DTS は、増分データの DDL 文、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

      • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

        説明

        • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

        • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

        Amazon slot查询信息

      • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

      • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

      • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

      • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

      • 完全同期または増分同期タスクにおいて、ソースデータベースの同期対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、宛先データベースアカウントが特権アカウントまたはスーパーユーザ権限を持つ場合、DTS はセッションレベルで一時的に `session_replication_role` パラメーターを `replica` に設定します。宛先データベースアカウントにこれらの権限がない場合は、宛先データベースで手動で `session_replication_role` パラメーターを `replica` に設定する必要があります。この期間中（`session_replication_role` が `replica` に設定されている間）、ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS タスクのリリース後は、`session_replication_role` パラメーターを `origin` に戻すことができます。

      • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

        説明

        パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

      • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

        説明

        PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

    • ApsaraDB RDS for PostgreSQL インスタンス間の双方向同期

      Type

      Description

      ソースおよび宛先データベースの制限事項

      • 同期対象のテーブルにプライマリキーまたは一意制約がない場合、タスク設定時に Exactly-Once 書き込み機能を有効化する必要があります。そうしないと、宛先データベースに重複データが発生する可能性があります。詳細については、「プライマリキーまたは一意制約のないテーブルの同期」をご参照ください。

      • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

      • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

      • DTS は、ソースデータベースからの一時テーブル、内部システムトリガー、および一部の関数（C 言語関数および PROCEDURE と FUNCTION の内部関数）の同期をサポートしていません。一方で、一部のカスタムデータ型（COMPOSITE、ENUM、RANGE）および以下の制約（プライマリキー、外部キー、一意、CHECK）の同期はサポートしています。

      • 先行書き込みログ (WAL)：

        • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

        • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

      • ソースデータベースの操作に関する制限事項

        • 同期タスクが期待通りに実行され、フェールオーバーによる論理サブスクリプションの中断を防ぐため、ApsaraDB RDS for PostgreSQL インスタンスで Logical Replication Slot Failover を有効化する必要があります。詳細については、「Logical Replication Slot Failover」をご参照ください。

        • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

        • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

          説明

          完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

      • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

      • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      その他の制限事項

      • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

      • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

      • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

      • 同期対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、ソースオブジェクト を設定する際、同期タイプ に スキーマ同期 を選択する場合は、シーケンス を選択するか、スキーマ全体を同期することを推奨します。そうしないと、同期インスタンスが正常に実行されない可能性があります。

      • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

        • インスタンスを初めて実行するとき。

        • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

        • 同期オブジェクトを変更する機能を使用する場合。

        説明

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

        • この操作はオフピーク時間帯に実行することを推奨します。

      • DTS はデータ内容の検証を行いますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータの検証はご自身で行ってください。

      • 業務を宛先インスタンスに切り替えた後、新しいシーケンスはソースシーケンスの最大値から増分されません。業務切り替え前に、ソースデータベースの対応するシーケンスの最大値をクエリし、それを宛先データベースの対応するシーケンスの初期値として設定する必要があります。ソースデータベースのシーケンス値をクエリするコマンドは次のとおりです。

        do language plpgsql $$
declare
  nsp name;
  rel name;
  val int8;
begin
  for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
  loop
    execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
    raise notice '%',
    format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
  end loop;
end;
$$;
        説明

        コマンド実行後に返される SQL 文には、ソースデータベースのすべてのシーケンスが含まれます。必要に応じて、これらの SQL 文を宛先データベースで実行してください。

      • DTS は、増分データの DDL 文、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

      • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

        説明

        • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

        • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

        Amazon slot查询信息

      • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

      • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

      • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

      • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

      • 完全同期または増分同期タスクにおいて、ソースデータベースの同期対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、宛先データベースアカウントが特権アカウントまたはスーパーユーザ権限を持つ場合、DTS はセッションレベルで一時的に `session_replication_role` パラメーターを `replica` に設定します。宛先データベースアカウントにこれらの権限がない場合は、宛先データベースで手動で `session_replication_role` パラメーターを `replica` に設定する必要があります。この期間中（`session_replication_role` が `replica` に設定されている間）、ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS タスクのリリース後は、`session_replication_role` パラメーターを `origin` に戻すことができます。

      • 双方向同期インスタンスには、転送タスクと逆タスクが含まれます。双方向同期インスタンスを設定またはリセットする際、あるタスクの宛先オブジェクトが別のタスクのソースオブジェクトである場合：

        • 1 つのタスクのみが完全同期と増分同期を実行できます。もう一方のタスクは増分同期のみを実行できます。

        • 現在のタスクのソースデータは、現在のタスクの宛先にのみ同期されます。同期されたデータは、別のタスクのソースデータとしては使用されません。

      • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

        説明

        パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

      • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

        説明

        PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

      特殊ケース

      • ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合

        同期中は、ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。そうしないと、同期が失敗します。

      • ソースインスタンスが自主管理 PostgreSQL データベースの場合

        `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

      • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

        説明

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

    自主管理 PostgreSQL データベースまたは ApsaraDB RDS for PostgreSQL インスタンスから AnalyticDB for PostgreSQL インスタンスへの同期

    Type

    Description

    ソースデータベースの制限事項

    • 同期対象のテーブルにはプライマリキーまたは一意制約が存在し、フィールド値が一意である必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

      説明

      宛先テーブルが DTS によって作成されていない場合（つまり、同期タイプがスキーマ同期に設定されていない場合）、ソースデータベースから同期されるテーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

    • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

    • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

    • 先行書き込みログ (WAL)：

      • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

      • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

    • 自主管理 PostgreSQL データベースでフェールオーバーが発生した場合、同期は失敗します。

    • ソースデータベースの操作に関する制限事項

      • 同期タスクが期待通りに実行され、フェールオーバーによる論理サブスクリプションの中断を防ぐため、ApsaraDB RDS for PostgreSQL インスタンスで Logical Replication Slot Failover を有効化する必要があります。詳細については、「Logical Replication Slot Failover」をご参照ください。

      • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

        説明

        完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

    • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

    • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

    その他の制限事項

    • Append-optimized (AO) テーブルは、宛先テーブルとしてサポートされていません。

    • 部分テーブル同期のためにカラムマッピングを使用する場合、またはソースおよび宛先テーブルスキーマが異なる場合、ソースに存在するが宛先に存在しないカラムのデータは失われます。

    • 同期オブジェクトの要件：

      • テーブルレベルの同期のみがサポートされています。

      • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

      • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

      • 以下のデータ型の同期はサポートされていません：BIT、VARBIT、GEOMETRY、UUID、TSQUERY、TSVECTOR、TXID_SNAPSHOT。

      • 以下のオブジェクトの同期はサポートされていません：DATATYPE、SEQUENCE、INDEX、PROCEDURE、FUNCTION、VIEW、OPERATOR、DEFAULT_CONSTRAINT、UK、PK、RULE、DOMAIN、AGGREGATE、EXTENSION、FK、TRIGGER。

    • 同期対象のテーブルにプライマリキーがある場合、宛先テーブルのプライマリキーカラムはソーステーブルと同じである必要があります。同期対象のテーブルにプライマリキーがない場合、宛先テーブルのプライマリキーカラムは分散キーと同じである必要があります。

    • 宛先テーブルの一意キー（プライマリキーカラムを含む）は、分散キーのすべてのカラムを含んでいる必要があります。

    • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

    • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

      • インスタンスを初めて実行するとき。

      • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

      • 同期オブジェクトを変更する機能を使用する場合。

      説明

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

      • この操作はオフピーク時間帯に実行することを推奨します。

    • DTS は、増分データの DDL 文、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

    • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

      説明

      • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

      • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

      Amazon slot查询信息

    • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

    • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

    • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

    • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

    • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

      説明

      パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

    • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

      説明

      PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

    特殊ケース

    • ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合

      同期中は、ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。そうしないと、同期が失敗します。

    • ソースインスタンスが自主管理 PostgreSQL データベースの場合

      `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

    • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

      説明

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

    自主管理 PostgreSQL データベースから PolarDB for PostgreSQL (Oracle 互換) インスタンスへの同期

    Type

    Description

    ソースデータベースの制限事項

    • 同期対象のテーブルにはプライマリキーまたは一意制約が存在し、フィールド値が一意である必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

      説明

      宛先テーブルが DTS によって作成されていない場合（つまり、同期タイプがスキーマ同期に設定されていない場合）、ソースデータベースから同期されるテーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

    • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

    • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

    • 先行書き込みログ (WAL)：

      • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

      • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

    • 自主管理 PostgreSQL データベースでフェールオーバーが発生した場合、同期は失敗します。

    • `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

    • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

    • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

      説明

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

    • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

    • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

      説明

      完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

    • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

    その他の制限事項

    • タスクが完全同期または増分同期であり、ソースデータベースの同期対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、宛先データベースアカウントが特権アカウントである場合、DTS は完全同期または増分同期中にセッションレベルで一時的に session_replication_role パラメーターを replica に設定します。宛先データベースアカウントにこの権限がない場合は、宛先データベースで手動で session_replication_role パラメーターを replica に設定する必要があります。この期間中—完全同期または増分同期中に session_replication_role パラメーターが replica に設定されている間—ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS 同期タスクのリリース後は、session_replication_role パラメーターを origin に戻すことができます。

    • 同期対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、ソースオブジェクト を設定する際、同期タイプ に スキーマ同期 を選択する場合は、シーケンス を選択するか、スキーマ全体を同期することを推奨します。そうしないと、同期インスタンスが正常に実行されない可能性があります。

    • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

    • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

    • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

    • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

      • インスタンスを初めて実行するとき。

      • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

      • 同期オブジェクトを変更する機能を使用する場合。

      説明

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

      • この操作はオフピーク時間帯に実行することを推奨します。

    • DTS はデータ内容の検証を行いますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータの検証はご自身で行ってください。

    • 業務を宛先インスタンスに切り替えた後、新しいシーケンスはソースシーケンスの最大値から増分されません。業務切り替え前に、宛先データベースのシーケンス値を更新する必要があります。詳細については、「宛先データベースのシーケンス値の更新」をご参照ください。

    • DTS は、増分データの DDL 文、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

    • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

      説明

      • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

      • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

      Amazon slot查询信息

    • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

    • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

    • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

    • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

    • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

      説明

      パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

    • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

      説明

      PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

    ApsaraDB RDS for PostgreSQL インスタンスから ApsaraDB RDS for MySQL インスタンスへの同期

    Type

    Description

    ソースデータベースの制限事項

    • 同期対象のテーブルにはプライマリキーまたは一意制約が存在し、フィールド値が一意である必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

      説明

      宛先テーブルが DTS によって作成されていない場合（つまり、同期タイプがスキーマ同期に設定されていない場合）、ソースデータベースから同期されるテーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

    • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

    • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

    • 先行書き込みログ (WAL)：

      • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

      • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

    • ソースデータベースの操作に関する制限事項

      • 同期タスクが期待通りに実行され、フェールオーバーによる論理サブスクリプションの中断を防ぐため、ApsaraDB RDS for PostgreSQL インスタンスで Logical Replication Slot Failover を有効化する必要があります。詳細については、「Logical Replication Slot Failover」をご参照ください。

      • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

        説明

        完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

    • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

    • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

    その他の制限事項

    • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

    • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

    • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

    • 以下のオブジェクトの同期はサポートされていません：DATATYPE、VIEW、PROCEDURE、FUNCTION、SEQUENCE、EXTENSION、OPERATOR、RULE、DEFAULT_CONSTRAINT、TRIGGER。

    • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

      • インスタンスを初めて実行するとき。

      • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

      • 同期オブジェクトを変更する機能を使用する場合。

      説明

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

      • この操作はオフピーク時間帯に実行することを推奨します。

    • DTS は、増分データの DDL 文（これらの DDL 文は宛先データベースに書き込まれません）、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

    • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

      説明

      • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

      • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

      Amazon slot查询信息

    • 同期対象データに、まれな文字や絵文字など 4 バイトのストレージを必要とするコンテンツが含まれる場合、宛先データベースおよびテーブルは utf8mb4 文字セットを使用する必要があります。

      説明

      DTS を使用してスキーマ同期を行う場合、宛先データベースでインスタンスレベルのパラメーター character_set_server を utf8mb4 に設定する必要があります。

    • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

    • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

    • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

    • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

    • DDL 文が宛先データベースに書き込めなかった場合でも、DTS タスクは継続して実行されます。失敗した DDL 文を確認するには、タスクリログをチェックしてください。タスクリログの確認方法については、「タスクリログの照会」をご参照ください。

    • 大文字小文字のみが異なるソーステーブルカラムが同じ宛先 MySQL テーブルに同期される場合、同期結果が期待通りにならない可能性があります。これは、MySQL のカラム名が大文字小文字を区別しないためです。

    • データ同期が完了した後（インスタンスの ステータス が 完了 になった後）、analyze table <table_name> を実行して、すべてのデータが宛先テーブルに書き込まれていることを確認することを推奨します。例えば、宛先 MySQL データベースで HA スイッチオーバーがトリガーされた場合、データがメモリにのみ書き込まれ、データ損失が発生する可能性があります。

    • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

      説明

      パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

    • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

      説明

      PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

    特殊ケース

    • ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合

      同期中は、ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。そうしないと、同期が失敗します。

    • ソースインスタンスが自主管理 PostgreSQL データベースの場合

      `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

    • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

      説明

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

    ApsaraDB RDS for PostgreSQL インスタンスから PolarDB for PostgreSQL インスタンスへの同期

    • 単方向同期

      Type

      Description

      ソースデータベースの制限事項

      • 同期対象のテーブルにはプライマリキーまたは一意制約が存在し、フィールド値が一意である必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

        説明

        宛先テーブルが DTS によって作成されていない場合（つまり、同期タイプがスキーマ同期に設定されていない場合）、ソースデータベースから同期されるテーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

      • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

      • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

      • 先行書き込みログ (WAL)：

        • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

        • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

      • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

      • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

        説明

        完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

      • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      その他の制限事項

      • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

      • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

      • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

      • 同期対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、ソースオブジェクト を設定する際、同期タイプ に スキーマ同期 を選択する場合は、シーケンス を選択するか、スキーマ全体を同期することを推奨します。そうしないと、同期インスタンスが正常に実行されない可能性があります。

      • タスクが完全同期または増分同期であり、ソースデータベースの同期対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、宛先データベースアカウントが特権アカウントである場合、DTS は完全同期または増分同期中にセッションレベルで一時的に session_replication_role パラメーターを replica に設定します。宛先データベースアカウントにこの権限がない場合は、宛先データベースで手動で session_replication_role パラメーターを replica に設定する必要があります。この期間中—完全同期または増分同期中に session_replication_role パラメーターが replica に設定されている間—ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS 同期タスクのリリース後は、session_replication_role パラメーターを origin に戻すことができます。

      • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

        • インスタンスを初めて実行するとき。

        • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

        • 同期オブジェクトを変更する機能を使用する場合。

        説明

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

        • この操作はオフピーク時間帯に実行することを推奨します。

      • DTS は、増分データの DDL 文、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

      • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

        説明

        • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

        • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

        Amazon slot查询信息

      • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

      • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

      • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

      • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

      • DTS はデータ内容の検証を行いますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータの検証はご自身で行ってください。

      • 業務を宛先インスタンスに切り替えた後、新しいシーケンスはソースシーケンスの最大値から増分されません。業務切り替え前に、宛先データベースのシーケンス値を更新する必要があります。詳細については、「宛先データベースのシーケンス値の更新」をご参照ください。

      • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

        説明

        パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

      • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

        説明

        PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

      特殊ケース

      • ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合

        同期中は、ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。そうしないと、同期が失敗します。

      • ソースインスタンスが自主管理 PostgreSQL データベースの場合

        `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

      • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

        説明

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

    • 双方向同期

      Type

      Description

      ソースデータベースの制限事項

      • 同期対象のテーブルにはプライマリキーまたは一意制約が存在し、フィールド値が一意である必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

        説明

        宛先テーブルが DTS によって作成されていない場合（つまり、同期タイプがスキーマ同期に設定されていない場合）、ソースデータベースから同期されるテーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうでない場合、宛先データベースに重複データが発生する可能性があります。

      • 同期対象のデータベース名にハイフン (-) を含めることはできません（例：dts-testdata）。

      • テーブルレベルでデータを同期し、テーブル名やカラム名のマッピングなどのオブジェクト編集が必要な場合、1 つのタスクで最大 5,000 テーブルまでサポートされます。それ以上のテーブルを同期する場合は、複数のタスクに分割するか、データベース全体を同期するタスクを設定してください。そうしないと、タスク送信後にリクエストエラーが発生する可能性があります。

      • 先行書き込みログ (WAL)：

        • WAL 機能を有効にする必要があります。wal_level パラメーターを logical に設定してください。

        • 増分同期タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持することを要求します。完全同期と増分同期を含むタスクの場合、WAL ログを少なくとも 7 日間保持する必要があります。完全同期完了後は、ログ保持期間を 24 時間以上に変更できます。保持期間が要件を満たさない場合、DTS タスクは WAL ログを取得できず失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短い保持期間による問題は、DTS サービスレベル契約 (SLA) の適用外となります。

      • ソースインスタンスに長時間トランザクションが存在し、タスクに増分同期が含まれる場合、長時間トランザクションがコミットされる前に発生した先行書き込みログ (WAL) はクリアできません。これにより、WAL ログが蓄積し、ソースインスタンスのディスク領域を枯渇させる可能性があります。

      • ソースデータベースの論理レプリケーションの制限により、増分変更後の同期対象データが 1 件あたり 256 MB を超える場合、同期インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      • スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

        説明

        完全同期フェーズ中、DTS はソースデータベースをクエリし、メタデータロックを取得します。これにより、ソースデータベースでの DDL 操作がブロックされる可能性があります。

      • 同期インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスが失敗し、復旧できません。同期インスタンスを再設定する必要があります。

      その他の制限事項

      • 1 つのデータ同期タスクでは、1 つのデータベースのみを同期できます。複数のデータベースを同期する場合は、各データベースごとに個別のタスクを設定する必要があります。

      • DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの同期をサポートしていません。

      • 拡張機能のインストールによって作成されたスキーマはサポートされていません。タスク設定時にコンソールでこれらのスキーマの情報を検索できません。

      • 同期対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、ソースオブジェクト を設定する際、同期タイプ に スキーマ同期 を選択する場合は、シーケンス を選択するか、スキーマ全体を同期することを推奨します。そうしないと、同期インスタンスが正常に実行されない可能性があります。

      • タスクが完全同期または増分同期であり、ソースデータベースの同期対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、宛先データベースアカウントが特権アカウントである場合、DTS は完全同期または増分同期中にセッションレベルで一時的に session_replication_role パラメーターを replica に設定します。宛先データベースアカウントにこの権限がない場合は、宛先データベースで手動で session_replication_role パラメーターを replica に設定する必要があります。この期間中—完全同期または増分同期中に session_replication_role パラメーターが replica に設定されている間—ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS 同期タスクのリリース後は、session_replication_role パラメーターを origin に戻すことができます。

      • 以下の 3 つのシナリオでは、データ書き込み前にソースデータベースの同期対象テーブルに対して ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。これにより、データ整合性が確保されます。このコマンド実行中にテーブルをロックしないでください。デッドロックを防ぐためです。関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化中に自動的にこのコマンドを実行します。

        • インスタンスを初めて実行するとき。

        • オブジェクト選択の粒度としてスキーマを選択し、スキーマ内に新しいテーブルが作成された場合、または同期対象テーブルが RENAME コマンドを使用して再構築された場合。

        • 同期オブジェクトを変更する機能を使用する場合。

        説明

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

        • この操作はオフピーク時間帯に実行することを推奨します。

      • DTS は、増分データの DDL 文、増分テーブルの構造、ハートビート情報を取得するために、ソースデータベースに以下の仮テーブルを作成します。同期中はこれらの仮テーブルを削除しないでください。そうしないと、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 はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを追加します。

      • データ同期中、DTS はソースデータベースに dts_sync_ プレフィックスを持つレプリケーションスロットを作成してデータをレプリケートします。このレプリケーションスロットにより、DTS は過去 15 分以内のソースデータベースからの増分ログを取得できます。データ同期が失敗した場合や同期インスタンスがリリースされた場合、DTS は自動的にレプリケーションスロットをクリアしようと試みます。

        説明

        • データ同期中にタスクで使用しているソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリアされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリアする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不可になることを防げます。

        • ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。

        Amazon slot查询信息

      • データ同期前に、ソースおよび宛先データベースのパフォーマンスを評価してください。オフピーク時間帯にデータを同期することを推奨します。そうしないと、初期完全同期がソースおよび宛先データベースの読み取り・書き込みリソースを消費し、データベース負荷が増加する可能性があります。

      • 初期完全同期は同時 INSERT 操作を実行します。これにより、宛先データベースでテーブルの断片化が発生します。その結果、初期完全同期完了後、宛先インスタンスの表領域がソースインスタンスよりも大きくなります。

      • テーブルレベルのデータ同期で、DTS 以外のデータが宛先データベースに書き込まれていない場合、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしでスキーマ変更を実行する」をご参照ください。

      • DTS 同期中は、他のソースから宛先データベースにデータを書き込まないでください。これにより、ソースおよび宛先データベース間でデータ不整合が発生する可能性があります。例えば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、宛先データベースでデータ損失が発生する可能性があります。

      • DTS はデータ内容の検証を行いますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータの検証はご自身で行ってください。

      • 業務を宛先インスタンスに切り替えた後、新しいシーケンスはソースシーケンスの最大値から増分されません。業務切り替え前に、ソースデータベースの対応するシーケンスの最大値をクエリし、それを宛先データベースの対応するシーケンスの初期値として設定する必要があります。ソースデータベースのシーケンス値をクエリするコマンドは次のとおりです。

        do language plpgsql $$
declare
  nsp name;
  rel name;
  val int8;
begin
  for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
  loop
    execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
    raise notice '%',
    format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
  end loop;
end;
$$;
        説明

        コマンド実行後に返される SQL 文には、ソースデータベースのすべてのシーケンスが含まれます。必要に応じて、これらの SQL 文を宛先データベースで実行してください。

      • 双方向同期インスタンスの実行中、DTS はデータループを防ぐためにソースおよび宛先データベースに dts という名前のスキーマを作成します。インスタンス実行中は、このスキーマを変更しないでください。

      • 双方向同期インスタンスには、転送タスクと逆タスクが含まれます。双方向同期インスタンスを設定またはリセットする際、あるタスクの宛先オブジェクトが別のタスクのソースオブジェクトである場合：

        • 1 つのタスクのみが完全同期と増分同期を実行できます。もう一方のタスクは増分同期のみを実行できます。

        • 現在のタスクのソースデータは、現在のタスクの宛先にのみ同期されます。同期されたデータは、別のタスクのソースデータとしては使用されません。

      • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。

        説明

        パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更 に記載されているものが含まれますが、これらに限定されません。

      • パーティションテーブルを同期する場合、親テーブルとその子パーティションの両方を同期オブジェクトに含める必要があります。そうしないと、パーティションテーブルでデータ不整合が発生する可能性があります。

        説明

        PostgreSQL パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子パーティションに格納されます。同期タスクには親テーブルとすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータ不整合が発生する可能性があります。

      特殊ケース

      • ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合

        同期中は、ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。そうしないと、同期が失敗します。

      • ソースインスタンスが自主管理 PostgreSQL データベースの場合

        `max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロット数とこの自主管理 PostgreSQL データベースをソースとする作成予定の DTS インスタンス数の合計より大きいことを確認してください。

      • ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースの データベースアカウント に `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。同期オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、同期対象オブジェクトについてこのアカウントにオーナー権限を付与してください（例：同期対象オブジェクトのオーナーとして関連操作を実行できるようにするため、GRANT <owner_of_the_object_to_be_synced> TO <source_database_account_for_the_task> コマンドを実行）。

        説明

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