PostgreSQL ソースからのデータ移行に関する注意事項と制限事項 - Data Transmission Service

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

PostgreSQL ソース向けの移行ソリューション概要

以下の移行ソリューションごとに、該当する注意事項と制限事項をご確認ください。

PostgreSQL インスタンス間の移行
PostgreSQL から MySQL への移行
PostgreSQL から PolarDB for PostgreSQL (Oracle 互換) への移行

PostgreSQL インスタンス間の移行

ApsaraDB RDS for PostgreSQL インスタンス間の移行

種別	説明
ソースデータベースの制限事項	移行対象のテーブルには、プライマリキーまたは一意制約が必要です。キーまたは制約内の列は一意である必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。説明ターゲットテーブルが DTS によって作成されていない場合（移行タイプでスキーマ移行を選択していない場合）、ソーステーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうしないと、ターゲットデータベースで重複データが発生する可能性があります。移行対象のデータベース名にはハイフン (-) を含めることはできません（例：dts-testdata）。テーブルレベルでオブジェクトを移行し、列名のマッピングなどの編集を行う場合、1 つのデータ移行タスクで最大 1,000 テーブルまでサポートされます。この制限を超えると、タスク送信後にエラーが報告されます。その場合は、テーブルを複数のタスクに分割するか、データベース全体を移行するタスクを設定してください。 DTS は、ソースデータベースからの一時テーブル、内部トリガー、一部の関数（C 言語関数および PROCEDURE と FUNCTION の内部関数）の移行をサポートしていません。DTS は、一部のカスタムデータ型（COMPOSITE、ENUM、RANGE）および以下の制約（プライマリキー、外部キー、一意、CHECK）の移行をサポートしています。増分移行に関して、先行書き込みログ (WAL) について以下の点にご注意ください。論理レプリケーションを有効にする必要があります。wal_level パラメーターを logical に設定してください。増分移行タスクの場合、DTS はソースデータベースが WAL ファイルを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースが WAL ファイルを少なくとも 7 日間保持することを要求します。完全移行完了後は、保持期間を 24 時間以上に設定できます。DTS が必要な WAL ファイルを取得できない場合、タスクが失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短いログ保持期間によって発生した問題は、DTS サービスレベルアグリーメント (SLA) の適用外となります。ソースデータベースの操作に関する制限事項：スキーマ移行および完全移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。完全なデータ移行のみを実行する場合、ソースデータベースに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間にデータ不整合が発生します。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択してください。ソースデータベースの論理レプリケーションに内在する制限により、増分変更後の移行対象データが 1 件あたり 256 MB を超える場合、移行インスタンスが失敗し、回復不能となる可能性があります。その場合は、移行インスタンスを再設定する必要があります。ソースデータベースに長時間トランザクションがあり、インスタンスに増分移行タスクが含まれている場合、トランザクションがコミットされる前に先行書き込みログ (WAL) ファイルが蓄積される可能性があります。これにより、ソースデータベースのディスク領域が不足する可能性があります。移行インスタンス実行中にソースデータベースがメジャーエンジンバージョンアップグレードを実施すると、インスタンスが失敗し、回復不能となります。その場合は、移行インスタンスを再設定する必要があります。
その他の制限事項	移行タスクを円滑に実行し、プライマリ/スタンバイ切り替え時の論理サブスクリプションの中断を防止するため、RDS PostgreSQL で Logical Replication Slot Failover を有効化する必要があります。手順については、「Logical Replication Slot Failover」をご参照ください。 1 つのデータ移行タスクでは、1 つのデータベースのみを移行できます。複数のデータベースを移行する場合は、各データベースごとに個別のデータ移行タスクを設定してください。 DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの移行をサポートしていません。拡張機能のインストールによって作成されたスキーマは移行できません。タスク設定時にコンソールでこれらのスキーマ情報を取得することはできません。移行対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、移行タイプでスキーマ移行を選択する場合、ソースオブジェクトを設定する際に、シーケンスも選択するか、スキーマ全体を移行することを推奨します。そうしないと、移行インスタンスが失敗する可能性があります。移行インスタンスに増分データ移行タスクが含まれる場合、データ書き込み前にソースデータベースの移行対象テーブルに対して `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 はセッションレベルで session_replication_role パラメーターを replica に一時的に設定します（ターゲットデータベースアカウントが特権アカウントまたはスーパーユーザ権限を持っている場合）。ターゲットデータベースアカウントがこれらの権限を持っていない場合、ターゲットデータベースで手動で session_replication_role パラメーターを replica に設定する必要があります。この期間中（session_replication_role が replica の状態）、ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS 移行タスクがリリースされた後は、session_replication_role パラメーターを origin に戻すことができます。増分データの表示される移行遅延の精度を確保するため、DTS はソースデータベースに `dts_postgres_heartbeat` という名前のハートビートテーブルを追加します。増分データ移行中、DTS はデータをレプリケートするためにソースデータベースにプレフィックス `dts_sync_` を持つレプリケーションスロットを作成します。DTS はこのレプリケーションスロットを使用して、過去 15 分間のソースデータベースからの増分ログを取得します。データ移行が失敗した場合や移行インスタンスがリリースされた場合、DTS はこのレプリケーションスロットを自動的にクリーンアップしようと試みます。説明データ移行中にソースデータベースアカウントのパスワードを変更したり、ソースデータベースの IP アドレスホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップされません。その場合は、ソースデータベースで手動でレプリケーションスロットをクリーンアップする必要があります。これにより、スロットが継続的に蓄積・ディスク領域を消費し、ソースデータベースが使用不可になることを防げます。ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリーンアップする必要があります。データ移行前に、ソースおよびターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時間帯に実行することを推奨します。完全なデータ移行中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費するため、データベース負荷が増加する可能性があります。完全なデータ移行では同時 INSERT 操作が行われるため、ターゲットデータベースでテーブルの断片化が発生する可能性があります。その結果、完全移行完了後、ターゲットデータベースのテーブルストレージ領域がソースデータベースよりも大きくなります。 FLOAT 型または DOUBLE 型の列の移行精度がビジネス要件を満たしているか確認してください。DTS はこれらの列の値を `ROUND(COLUMN,PRECISION)` を使用して読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は失敗した移行タスクを 7 日以内に回復しようと試みます。ビジネスを宛先インスタンスに切り替える前に、タスクを停止またはリリースするか、`revoke` コマンドを使用して、DTS が宛先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消してください。これにより、タスクが自動的に回復した場合にソースデータが宛先インスタンスのデータを上書きすることを防止できます。タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に回復を試みます。回復プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。説明パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれますが、これらに限定されません。パーティションテーブルを移行する場合、親テーブルとその子テーブルの両方を同期オブジェクトとして含めてください。そうしないと、パーティションテーブルのデータ不整合が発生する可能性があります。説明 PostgreSQL では、パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子テーブルに格納されます。同期タスクには親テーブルとすべての子テーブルを含める必要があります。そうしないと、子テーブルのデータが同期されず、ソースとターゲットの間にデータ不整合が発生する可能性があります。
特殊ケース	ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合、移行中にエンドポイントまたはゾーンを変更しないでください。そうしないと、移行が失敗します。

自主管理 PostgreSQL データベースから ApsaraDB RDS for PostgreSQL インスタンスへの移行

種別	説明
ソースデータベースの制限事項	帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、データ移行速度に影響が出ます。移行対象のテーブルには、プライマリキーまたは一意制約が必要です。キーまたは制約内の列は一意である必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。説明ターゲットテーブルが DTS によって作成されていない場合（移行タイプでスキーマ移行を選択していない場合）、ソーステーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうしないと、ターゲットデータベースで重複データが発生する可能性があります。移行対象のデータベース名にはハイフン (-) を含めることはできません（例：dts-testdata）。テーブルレベルでオブジェクトを移行し、列名のマッピングなどの編集を行う場合、1 つのデータ移行タスクで最大 1,000 テーブルまでサポートされます。この制限を超えると、タスク送信後にエラーが報告されます。その場合は、テーブルを複数のタスクに分割するか、データベース全体を移行するタスクを設定してください。 DTS は、ソースデータベースからの一時テーブル、内部トリガー、一部の関数（C 言語関数および PROCEDURE と FUNCTION の内部関数）の移行をサポートしていません。DTS は、一部のカスタムデータ型（COMPOSITE、ENUM、RANGE）および以下の制約（プライマリキー、外部キー、一意、CHECK）の移行をサポートしています。増分移行に関して、先行書き込みログ (WAL) について以下の点にご注意ください。論理レプリケーションを有効にする必要があります。wal_level パラメーターを logical に設定してください。増分移行タスクの場合、DTS はソースデータベースが WAL ファイルを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースが WAL ファイルを少なくとも 7 日間保持することを要求します。完全移行完了後は、保持期間を 24 時間以上に設定できます。DTS が必要な WAL ファイルを取得できない場合、タスクが失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短いログ保持期間によって発生した問題は、DTS サービスレベルアグリーメント (SLA) の適用外となります。ソースデータベースの操作に関する制限事項：自主管理 PostgreSQL データベースでフェールオーバーが発生すると、移行が失敗します。スキーマ移行および完全移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。ソースデータベースの論理レプリケーションに内在する制限により、増分変更後の移行対象データが 1 件あたり 256 MB を超える場合、移行インスタンスが失敗し、回復不能となる可能性があります。その場合は、移行インスタンスを再設定する必要があります。ソースデータベースに長時間トランザクションがあり、インスタンスに増分移行タスクが含まれている場合、トランザクションがコミットされる前に先行書き込みログ (WAL) ファイルが蓄積される可能性があります。これにより、ソースデータベースのディスク領域が不足する可能性があります。移行インスタンス実行中にソースデータベースがメジャーエンジンバージョンアップグレードを実施すると、インスタンスが失敗し、回復不能となります。その場合は、移行インスタンスを再設定する必要があります。
その他の制限事項	ソースデータベースのプライマリノードとセカンダリノード間の遅延によりデータ不整合が発生する可能性があるため、移行のデータソースとしてソースデータベースのプライマリノードを使用してください。 1 つのデータ移行タスクでは、1 つのデータベースのみを移行できます。複数のデータベースを移行する場合は、各データベースごとに個別のデータ移行タスクを設定してください。 DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの移行をサポートしていません。拡張機能のインストールによって作成されたスキーマは移行できません。タスク設定時にコンソールでこれらのスキーマ情報を取得することはできません。移行対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、移行タイプでスキーマ移行を選択する場合、ソースオブジェクトを設定する際に、シーケンスも選択するか、スキーマ全体を移行することを推奨します。そうしないと、移行インスタンスが失敗する可能性があります。移行インスタンスに増分データ移行タスクが含まれる場合、データ書き込み前にソースデータベースの移行対象テーブルに対して `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 はこのレプリケーションスロットを自動的にクリーンアップしようと試みます。説明データ移行中にソースデータベースアカウントのパスワードを変更したり、ソースデータベースの IP アドレスホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップされません。その場合は、ソースデータベースで手動でレプリケーションスロットをクリーンアップする必要があります。これにより、スロットが継続的に蓄積・ディスク領域を消費し、ソースデータベースが使用不可になることを防げます。ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリーンアップする必要があります。完全移行または増分移行タスクにおいて、ソースデータベースの移行対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、DTS はセッションレベルで session_replication_role パラメーターを replica に一時的に設定します（ターゲットデータベースアカウントが特権アカウントまたはスーパーユーザ権限を持っている場合）。ターゲットデータベースアカウントがこれらの権限を持っていない場合、ターゲットデータベースで手動で session_replication_role パラメーターを replica に設定する必要があります。この期間中（session_replication_role が replica の状態）、ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS 移行タスクがリリースされた後は、session_replication_role パラメーターを origin に戻すことができます。データ移行前に、ソースおよびターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時間帯に実行することを推奨します。完全なデータ移行中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費するため、データベース負荷が増加する可能性があります。完全なデータ移行では同時 INSERT 操作が行われるため、ターゲットデータベースでテーブルの断片化が発生する可能性があります。その結果、完全移行完了後、ターゲットデータベースのテーブルストレージ領域がソースデータベースよりも大きくなります。 FLOAT 型または DOUBLE 型の列の移行精度がビジネス要件を満たしているか確認してください。DTS はこれらの列の値を `ROUND(COLUMN,PRECISION)` を使用して読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は失敗した移行タスクを 7 日以内に回復しようと試みます。ビジネスを宛先インスタンスに切り替える前に、タスクを停止またはリリースするか、`revoke` コマンドを使用して、DTS が宛先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消してください。これにより、タスクが自動的に回復した場合にソースデータが宛先インスタンスのデータを上書きすることを防止できます。タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に回復を試みます。回復プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。説明パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれますが、これらに限定されません。パーティションテーブルを移行する場合、親テーブルとその子テーブルの両方を同期オブジェクトとして含めてください。そうしないと、パーティションテーブルのデータ不整合が発生する可能性があります。説明 PostgreSQL では、パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子テーブルに格納されます。同期タスクには親テーブルとすべての子テーブルを含める必要があります。そうしないと、子テーブルのデータが同期されず、ソースとターゲットの間にデータ不整合が発生する可能性があります。
特殊ケース	ソースインスタンスが自主管理 PostgreSQL データベースの場合、max_wal_senders パラメーターおよび max_replication_slots パラメーターの値が、使用中のレプリケーションスロット数とこのデータベースをソースとする DTS インスタンス数の合計より大きいことを確認してください。ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースのデータベースアカウントとして `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。移行オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、移行対象オブジェクトのオーナー権限をこのアカウントに付与してください（例：`GRANT <owner_of_migration_object> TO <source_account_for_task>` コマンドを実行して、このアカウントが移行対象オブジェクトのオーナーとして関連操作を実行できるようにします）。説明 cloudsqlsuperuser 権限を持つアカウントは、別の cloudsqlsuperuser 権限を持つアカウントが所有するデータを管理できません。

PostgreSQL から MySQL への移行

以下の注意事項と制限事項が適用されます。

種別	説明
ソースデータベースの制限事項	帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、データ移行速度に影響が出ます。移行対象のテーブルには、プライマリキーまたは一意制約が必要です。キーまたは制約内の列は一意である必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。説明ターゲットテーブルが DTS によって作成されていない場合（移行タイプでスキーマ移行を選択していない場合）、ソーステーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうしないと、ターゲットデータベースで重複データが発生する可能性があります。移行対象のデータベース名にはハイフン (-) を含めることはできません（例：dts-testdata）。テーブルレベルでオブジェクトを移行し、列名のマッピングなどの編集を行う場合、1 つのデータ移行タスクで最大 1,000 テーブルまでサポートされます。この制限を超えると、タスク送信後にエラーが報告されます。その場合は、テーブルを複数のタスクに分割するか、データベース全体を移行するタスクを設定してください。増分移行に関して、先行書き込みログ (WAL) について以下の点にご注意ください。論理レプリケーションを有効にする必要があります。wal_level パラメーターを logical に設定してください。増分移行タスクの場合、DTS はソースデータベースが WAL ファイルを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースが WAL ファイルを少なくとも 7 日間保持することを要求します。完全移行完了後は、保持期間を 24 時間以上に設定できます。DTS が必要な WAL ファイルを取得できない場合、タスクが失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短いログ保持期間によって発生した問題は、DTS サービスレベルアグリーメント (SLA) の適用外となります。ソースデータベースの操作に関する制限事項：自主管理 PostgreSQL データベースでフェールオーバーが発生すると、移行が失敗します。移行タスクを円滑に実行し、プライマリ/スタンバイ切り替え時の論理サブスクリプションの中断を防止するため、RDS PostgreSQL で Logical Replication Slot Failover を有効化する必要があります。手順については、「Logical Replication Slot Failover」をご参照ください。完全移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。ソースデータベースの論理レプリケーションに内在する制限により、増分変更後の移行対象データが 1 件あたり 256 MB を超える場合、移行インスタンスが失敗し、回復不能となる可能性があります。その場合は、移行インスタンスを再設定する必要があります。完全なデータ移行のみを実行する場合、ソースデータベースに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間にデータ不整合が発生します。リアルタイムのデータ整合性を維持するには、完全なデータ移行および増分データ移行を選択してください。ソースデータベースに長時間トランザクションがあり、インスタンスに増分移行タスクが含まれている場合、トランザクションがコミットされる前に先行書き込みログ (WAL) ファイルが蓄積される可能性があります。これにより、ソースデータベースのディスク領域が不足する可能性があります。移行インスタンス実行中にソースデータベースがメジャーエンジンバージョンアップグレードを実施すると、インスタンスが失敗し、回復不能となります。その場合は、移行インスタンスを再設定する必要があります。
その他の制限事項	DATATYPE、VIEW、PROCEDURE、FUNCTION、SEQUENCE、EXTENSION、OPERATOR、RULE、DEFAULT_CONSTRAINT、TRIGGER の移行はサポートされていません。移行対象データに絵文字や特殊文字など、4 バイトのストレージを必要とするコンテンツが含まれる場合、データを受信するターゲットデータベースおよびテーブルは utf8mb4 文字セットを使用する必要があります。説明 DTS を使用してスキーマ移行を行う場合、ターゲットデータベースのインスタンスレベルパラメーター `character_set_server` を utf8mb4 に設定する必要があります。 DDL 文がターゲットデータベースに書き込めなかった場合でも、DTS タスクは継続して実行されます。失敗した DDL 文はタスクリログで確認する必要があります。タスクリログの確認方法については、「タスクリログの照会」をご参照ください。宛先 MySQL データベースの同じテーブルに、列名の違いが大文字小文字のみであるフィールドを書き込む場合、移行結果が期待通りにならない可能性があります。これは、MySQL データベースの列名が大文字小文字を区別しないためです。データ移行が完了した後（インスタンスのステータスが完了になった後）、`analyze table <table_name>` コマンドを実行して、すべてのデータがターゲットテーブルに書き込まれていることを確認することを推奨します。たとえば、宛先 MySQL データベースで HA スイッチオーバーがトリガーされた場合、データがメモリにのみ書き込まれ、データ損失が発生する可能性があります。 1 つのデータ移行タスクでは、1 つのデータベースのみを移行できます。複数のデータベースを移行する場合は、各データベースごとに個別のデータ移行タスクを設定してください。 DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの移行をサポートしていません。拡張機能のインストールによって作成されたスキーマは移行できません。タスク設定時にコンソールでこれらのスキーマ情報を取得することはできません。移行インスタンスに増分データ移行タスクが含まれる場合、データ書き込み前にソースデータベースの移行対象テーブルに対して `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 はこのレプリケーションスロットを自動的にクリーンアップしようと試みます。説明データ移行中にソースデータベースアカウントのパスワードを変更したり、ソースデータベースの IP アドレスホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップされません。その場合は、ソースデータベースで手動でレプリケーションスロットをクリーンアップする必要があります。これにより、スロットが継続的に蓄積・ディスク領域を消費し、ソースデータベースが使用不可になることを防げます。ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリーンアップする必要があります。データ移行前に、ソースおよびターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時間帯に実行することを推奨します。完全なデータ移行中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費するため、データベース負荷が増加する可能性があります。完全なデータ移行では同時 INSERT 操作が行われるため、ターゲットデータベースでテーブルの断片化が発生する可能性があります。その結果、完全移行完了後、ターゲットデータベースのテーブルストレージ領域がソースデータベースよりも大きくなります。 FLOAT 型または DOUBLE 型の列の移行精度がビジネス要件を満たしているか確認してください。DTS はこれらの列の値を `ROUND(COLUMN,PRECISION)` を使用して読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は失敗した移行タスクを 7 日以内に回復しようと試みます。ビジネスを宛先インスタンスに切り替える前に、タスクを停止またはリリースするか、`revoke` コマンドを使用して、DTS が宛先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消してください。これにより、タスクが自動的に回復した場合にソースデータが宛先インスタンスのデータを上書きすることを防止できます。タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に回復を試みます。回復プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。説明パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれますが、これらに限定されません。パーティションテーブルを移行する場合、親テーブルとその子テーブルの両方を同期オブジェクトとして含めてください。そうしないと、パーティションテーブルのデータ不整合が発生する可能性があります。説明 PostgreSQL では、パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子テーブルに格納されます。同期タスクには親テーブルとすべての子テーブルを含める必要があります。そうしないと、子テーブルのデータが同期されず、ソースとターゲットの間にデータ不整合が発生する可能性があります。
特殊ケース	ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合、移行中にエンドポイントまたはゾーンを変更しないでください。そうしないと、移行が失敗します。ソースインスタンスが自主管理 PostgreSQL データベースの場合、max_wal_senders パラメーターおよび max_replication_slots パラメーターの値が、使用中のレプリケーションスロット数とこのデータベースをソースとする DTS インスタンス数の合計より大きいことを確認してください。ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースのデータベースアカウントとして `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。移行オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、移行対象オブジェクトのオーナー権限をこのアカウントに付与してください（例：`GRANT <owner_of_migration_object> TO <source_account_for_task>` コマンドを実行して、このアカウントが移行対象オブジェクトのオーナーとして関連操作を実行できるようにします）。説明 cloudsqlsuperuser 権限を持つアカウントは、別の cloudsqlsuperuser 権限を持つアカウントが所有するデータを管理できません。宛先インスタンスが ApsaraDB RDS for MySQL インスタンスの場合、DTS は自動的にインスタンス内にデータベースを作成します。移行対象のデータベース名が ApsaraDB RDS for MySQL の命名規則に準拠していない場合、移行タスクを設定する前に ApsaraDB RDS for MySQL インスタンス内にデータベースを作成しておく必要があります。詳細については、「データベースの管理」をご参照ください。

PostgreSQL から PolarDB for PostgreSQL (Oracle 互換) への移行

以下の注意事項と制限事項が適用されます。

種別	説明
ソースデータベースの制限事項	帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、データ移行速度に影響が出ます。移行対象のテーブルには、プライマリキーまたは一意制約が必要です。キーまたは制約内の列は一意である必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。説明ターゲットテーブルが DTS によって作成されていない場合（移行タイプでスキーマ移行を選択していない場合）、ソーステーブルと同じプライマリキーまたは NULL でない一意制約を持つことを保証する必要があります。そうしないと、ターゲットデータベースで重複データが発生する可能性があります。移行対象のデータベース名にはハイフン (-) を含めることはできません（例：dts-testdata）。テーブルレベルでオブジェクトを移行し、列名のマッピングなどの編集を行う場合、1 つのデータ移行タスクで最大 1,000 テーブルまでサポートされます。この制限を超えると、タスク送信後にエラーが報告されます。その場合は、テーブルを複数のタスクに分割するか、データベース全体を移行するタスクを設定してください。増分移行に関して、先行書き込みログ (WAL) について以下の点にご注意ください。論理レプリケーションを有効にする必要があります。wal_level パラメーターを logical に設定してください。増分移行タスクの場合、DTS はソースデータベースが WAL ファイルを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースが WAL ファイルを少なくとも 7 日間保持することを要求します。完全移行完了後は、保持期間を 24 時間以上に設定できます。DTS が必要な WAL ファイルを取得できない場合、タスクが失敗する可能性があります。最悪の場合、データ不整合やデータ損失が発生する可能性があります。必要な保持期間よりも短いログ保持期間によって発生した問題は、DTS サービスレベルアグリーメント (SLA) の適用外となります。ソースデータベースの操作に関する制限事項：自主管理 PostgreSQL データベースでフェールオーバーが発生すると、移行が失敗します。ソースデータベースの論理レプリケーションに内在する制限により、増分変更後の移行対象データが 1 件あたり 256 MB を超える場合、移行インスタンスが失敗し、回復不能となる可能性があります。その場合は、移行インスタンスを再設定する必要があります。完全移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。完全なデータ移行のみを実行する場合、ソースデータベースに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間にデータ不整合が発生します。リアルタイムのデータ整合性を維持するには、完全なデータ移行および増分データ移行を選択してください。ソースデータベースに長時間トランザクションがあり、インスタンスに増分移行タスクが含まれている場合、トランザクションがコミットされる前に先行書き込みログ (WAL) ファイルが蓄積される可能性があります。これにより、ソースデータベースのディスク領域が不足する可能性があります。移行インスタンス実行中にソースデータベースがメジャーエンジンバージョンアップグレードを実施すると、インスタンスが失敗し、回復不能となります。その場合は、移行インスタンスを再設定する必要があります。
その他の制限事項	完全移行または増分移行タスクにおいて、ソースデータベースの移行対象テーブルに外部キー、トリガー、イベントトリガーが含まれる場合、DTS はセッションレベルで session_replication_role パラメーターを replica に一時的に設定します（ターゲットデータベースアカウントが特権アカウントの場合）。ターゲットデータベースアカウントがこの権限を持っていない場合、ターゲットデータベースで手動で session_replication_role パラメーターを replica に設定する必要があります。この期間中（session_replication_role が replica の状態）、ソースデータベースでカスケード更新または削除操作が発生すると、データ不整合が発生する可能性があります。DTS 移行タスクがリリースされた後は、session_replication_role パラメーターを origin に戻すことができます。移行対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用のシーケンスを作成します。そのため、移行タイプでスキーマ移行を選択する場合、ソースオブジェクトを設定する際に、シーケンスも選択するか、スキーマ全体を移行することを推奨します。そうしないと、移行インスタンスが失敗する可能性があります。移行インスタンスに増分データ移行タスクが含まれる場合、データ書き込み前にソースデータベースの移行対象テーブルに対して `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 はこのレプリケーションスロットを自動的にクリーンアップしようと試みます。説明データ移行中にソースデータベースアカウントのパスワードを変更したり、ソースデータベースの IP アドレスホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップされません。その場合は、ソースデータベースで手動でレプリケーションスロットをクリーンアップする必要があります。これにより、スロットが継続的に蓄積・ディスク領域を消費し、ソースデータベースが使用不可になることを防げます。ソースデータベースでフェールオーバーが発生した場合、セカンダリデータベースにログインしてスロットを手動でクリーンアップする必要があります。 1 つのデータ移行タスクでは、1 つのデータベースのみを移行できます。複数のデータベースを移行する場合は、各データベースごとに個別のデータ移行タスクを設定してください。 DTS は、TimescaleDB 拡張テーブル、スキーマをまたいだ継承を持つテーブル、式に基づく一意なインデックスを持つテーブルの移行をサポートしていません。拡張機能のインストールによって作成されたスキーマは移行できません。タスク設定時にコンソールでこれらのスキーマ情報を取得することはできません。データ移行前に、ソースおよびターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時間帯に実行することを推奨します。完全なデータ移行中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費するため、データベース負荷が増加する可能性があります。完全なデータ移行では同時 INSERT 操作が行われるため、ターゲットデータベースでテーブルの断片化が発生する可能性があります。その結果、完全移行完了後、ターゲットデータベースのテーブルストレージ領域がソースデータベースよりも大きくなります。 FLOAT 型または DOUBLE 型の列の移行精度がビジネス要件を満たしているか確認してください。DTS はこれらの列の値を `ROUND(COLUMN,PRECISION)` を使用して読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は失敗した移行タスクを 7 日以内に回復しようと試みます。ビジネスを宛先インスタンスに切り替える前に、タスクを停止またはリリースするか、`revoke` コマンドを使用して、DTS が宛先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消してください。これにより、タスクが自動的に回復した場合にソースデータが宛先インスタンスのデータを上書きすることを防止できます。 DTS はデータ内容の検証を行いますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータの検証はご自身で行ってください。ターゲットデータベースへのサービススイッチオーバー後、新しいシーケンスはソースデータベースの最大シーケンス値から増分を開始しません。スイッチオーバー前に、ターゲットデータベースのシーケンス値を更新する必要があります。詳細については、「ターゲットデータベースのシーケンス値の更新」をご参照ください。タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に回復を試みます。回復プロセス中、タスクの再起動やパラメーター調整などの操作が実行される可能性があります。説明パラメーターが調整される場合、DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれますが、これらに限定されません。パーティションテーブルを移行する場合、親テーブルとその子テーブルの両方を同期オブジェクトとして含めてください。そうしないと、パーティションテーブルのデータ不整合が発生する可能性があります。説明 PostgreSQL では、パーティションテーブルの親テーブルは直接データを格納しません。すべてのデータは子テーブルに格納されます。同期タスクには親テーブルとすべての子テーブルを含める必要があります。そうしないと、子テーブルのデータが同期されず、ソースとターゲットの間にデータ不整合が発生する可能性があります。
特殊ケース	ソースインスタンスが ApsaraDB RDS for PostgreSQL インスタンスの場合、移行中にエンドポイントまたはゾーンを変更しないでください。そうしないと、移行が失敗します。ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースのデータベースアカウントとして `cloudsqlsuperuser` 権限を持つアカウントを指定する必要があります。移行オブジェクトを選択する際は、このアカウントが管理権限を持つオブジェクトを選択するか、移行対象オブジェクトのオーナー権限をこのアカウントに付与してください（例：`GRANT <owner_of_migration_object> TO <source_account_for_task>` コマンドを実行して、このアカウントが移行対象オブジェクトのオーナーとして関連操作を実行できるようにします）。説明 cloudsqlsuperuser 権限を持つアカウントは、別の cloudsqlsuperuser 権限を持つアカウントが所有するデータを管理できません。ソースインスタンスが自主管理 PostgreSQL データベースの場合、max_wal_senders パラメーターおよび max_replication_slots パラメーターの値が、使用中のレプリケーションスロット数とこのデータベースをソースとする DTS インスタンス数の合計より大きいことを確認してください。