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

ソースデータベースが PostgreSQL データベース (自主管理 PostgreSQL データベースや RDS for PostgreSQL インスタンスなど) の場合、データ移行タスクを設定する前に、このトピックの注意点と制限を確認してください。これにより、データ移行タスクが期待どおりに実行されるようになります。

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

移行ソリューションに基づいて、移行タスクの注意点と制限を確認してください。

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

PostgreSQL から PostgreSQL への移行

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

タイプ	説明
ソースデータベースの制限	移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。説明ターゲットテーブルが DTS によって作成されていない場合 (つまり、移行タイプでスキーマ移行を選択しなかった場合)、テーブルにソーステーブルと同じプライマリキーまたは空でない一意制約があることを確認する必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。移行するデータベースの名前にハイフン (-) を含めることはできません (例: dts-testdata)。テーブルレベルでオブジェクトを移行し、列名のマッピングなどで編集する必要がある場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 DTS は、ソースデータベースからの一時テーブル、内部トリガー、または一部の関数 (C 言語関数および PROCEDURE と FUNCTION の内部関数) の移行をサポートしていません。DTS は、一部のカスタムデータ (TYPE が COMPOSITE、ENUM、または RANGE) の移行をサポートしています。DTS は、プライマリキー、外部キー、および UNIQUE 制約と CHECK 制約の移行をサポートしています。増分移行の場合、先行書き込みログ (wal): 有効にする必要があります。wal_level パラメーターを logical に設定します。増分移行タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持する必要があります。完全移行と増分移行の両方を含むタスクの場合、DTS は WAL ログを少なくとも 7 日間保持する必要があります。完全移行が完了した後、ログの保持期間を 24 時間以上に変更できます。そうしないと、DTS が WAL ログを取得できないため、タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。DTS が要求するよりも短いログ保持期間に起因する問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。ソースデータベースの操作制限: スキーマ移行および完全移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。完全なデータ移行のみを実行する場合は、ソースデータベースに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生します。リアルタイムのデータ整合性を確保するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。ソースデータベースの論理レプリケーションの制限により、移行中に移行される増分データの単一部分が 256 MB を超えると、DTS インスタンスが失敗し、回復できなくなる可能性があります。DTS インスタンスを再設定する必要があります。ソースデータベースに長時間トランザクションがあり、インスタンスが増分移行を実行する場合、トランザクションコミット前の先行書き込みログ (WAL) がクリアされないことがあります。これにより、ログが蓄積され、ソースデータベースのディスク領域が不足する可能性があります。 DTS インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスは失敗し、回復できなくなります。DTS インスタンスを再設定する必要があります。
その他の制限	移行タスクが期待どおりに実行され、フェールオーバーによる論理レプリケーションの中断を防ぐために、RDS for PostgreSQL は論理レプリケーションスロットのフェールオーバーをサポートし、有効にする必要があります。設定方法の詳細については、「論理レプリケーションスロットのフェールオーバー」をご参照ください。 1 つのデータ移行タスクで移行できるデータベースは 1 つだけです。複数のデータベースを移行するには、データベースごとにデータ移行タスクを設定する必要があります。 DTS は、TimescaleDB 拡張テーブルまたはスキーマ間継承を持つテーブルの移行をサポートしていません。移行対象のテーブルに SERIAL 型のフィールドが含まれている場合、ソースデータベースはそのフィールドのシーケンスを自動的に作成します。したがって、ソースオブジェクトを設定するときに、移行タイプでスキーマ移行を選択した場合は、[シーケンス] を選択するか、完全なスキーマ移行を実行することをお勧めします。そうしないと、移行インスタンスが失敗する可能性があります。 DTS インスタンスが増分データ移行タスクを実行する場合、データを書き込む前に、ソースデータベースの移行対象テーブルで `ALTER TABLE schema.table REPLICA IDENTITY FULL;` コマンドを実行する必要があります。これは、次の 2 つのシナリオに適用され、データ整合性を確保します。このコマンドの実行中は、テーブルロック操作を実行しないことをお勧めします。そうしないと、テーブルがロックされる可能性があります。事前チェックで関連するチェックをスキップした場合、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 はこのレプリケーションスロットを自動的にクリアしようとします。説明データ移行中にタスクで使用されるソースデータベースアカウントのパスワードを変更したり、ソースデータベースのホワイトリストから DTS IP アドレスを削除したりすると、レプリケーションスロットを自動的にクリアできません。この場合、ソースデータベースでレプリケーションスロットを手動でクリアして、それが蓄積されてディスク領域を占有し、ソースデータベースが利用できなくなるのを防ぐ必要があります。ソースデータベースでフェールオーバーが発生した場合は、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースのテーブルで断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルが使用するストレージ領域は、ソースデータベースよりも大きくなります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしていることを確認してください。DTS は、`ROUND(COLUMN,PRECISION)` を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 列を 38 桁の精度で、DOUBLE 列を 308 桁の精度で移行します。 DTS は 7 日以内に失敗した移行タスクを再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、`revoke` コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。パーティションテーブルを移行する場合、親テーブルとその子パーティションの両方を同期オブジェクトとして含める必要があります。そうしないと、パーティションテーブルでデータの不整合が発生する可能性があります。説明 PostgreSQL パーティションテーブルの親テーブルはデータを直接保存しません。すべてのデータは子パーティションに保存されます。同期タスクには、親テーブルとそのすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータの不整合が発生する可能性があります。
特殊なケース	ソースインスタンスが RDS for PostgreSQL インスタンスの場合、移行中にそのエンドポイントまたはゾーンを変更しないでください。そうしないと、移行は失敗します。

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

タイプ	説明
ソースデータベースの制限	帯域幅要件: ソースデータベースが存在するサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。説明ターゲットテーブルが DTS によって作成されていない場合 (つまり、移行タイプでスキーマ移行を選択しなかった場合)、テーブルにソーステーブルと同じプライマリキーまたは空でない一意制約があることを確認する必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。移行するデータベースの名前にハイフン (-) を含めることはできません (例: dts-testdata)。テーブルレベルでオブジェクトを移行し、列名のマッピングなどで編集する必要がある場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 DTS は、ソースデータベースからの一時テーブル、内部トリガー、または一部の関数 (C 言語関数および PROCEDURE と FUNCTION の内部関数) の移行をサポートしていません。DTS は、一部のカスタムデータ (TYPE が COMPOSITE、ENUM、または RANGE) の移行をサポートしています。DTS は、プライマリキー、外部キー、および UNIQUE 制約と CHECK 制約の移行をサポートしています。増分移行の場合、先行書き込みログ (wal): 有効にする必要があります。wal_level パラメーターを logical に設定します。増分移行タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持する必要があります。完全移行と増分移行の両方を含むタスクの場合、DTS は WAL ログを少なくとも 7 日間保持する必要があります。完全移行が完了した後、ログの保持期間を 24 時間以上に変更できます。そうしないと、DTS が WAL ログを取得できないため、タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。DTS が要求するよりも短いログ保持期間に起因する問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。ソースデータベースの操作制限: 自主管理 PostgreSQL データベースでフェールオーバーが発生した場合、移行は失敗します。スキーマ移行および完全移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。ソースデータベースの論理レプリケーションの制限により、移行中に移行される増分データの単一部分が 256 MB を超えると、DTS インスタンスが失敗し、回復できなくなる可能性があります。DTS インスタンスを再設定する必要があります。ソースデータベースに長時間トランザクションがあり、インスタンスが増分移行を実行する場合、トランザクションコミット前の先行書き込みログ (WAL) がクリアされないことがあります。これにより、ログが蓄積され、ソースデータベースのディスク領域が不足する可能性があります。 DTS インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスは失敗し、回復できなくなります。DTS インスタンスを再設定する必要があります。
その他の制限	ソースデータベースのプライマリノードとセカンダリノード間の潜在的なレイテンシーにより、データの不整合が発生する可能性があるため、移行のデータソースとしてソースデータベースのプライマリノードを使用してください。 1 つのデータ移行タスクで移行できるデータベースは 1 つだけです。複数のデータベースを移行するには、データベースごとにデータ移行タスクを設定する必要があります。 DTS は、TimescaleDB 拡張テーブルまたはスキーマ間継承を持つテーブルの移行をサポートしていません。移行対象のテーブルに SERIAL 型のフィールドが含まれている場合、ソースデータベースはそのフィールドのシーケンスを自動的に作成します。したがって、ソースオブジェクトを設定するときに、移行タイプでスキーマ移行を選択した場合は、[シーケンス] を選択するか、完全なスキーマ移行を実行することをお勧めします。そうしないと、移行インスタンスが失敗する可能性があります。 DTS インスタンスが増分データ移行タスクを実行する場合、データを書き込む前に、ソースデータベースの移行対象テーブルで `ALTER TABLE schema.table REPLICA IDENTITY FULL;` コマンドを実行する必要があります。これは、次の 2 つのシナリオに適用され、データ整合性を確保します。このコマンドの実行中は、テーブルロック操作を実行しないことをお勧めします。そうしないと、テーブルがロックされる可能性があります。事前チェックで関連するチェックをスキップした場合、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 アドレスを削除したりすると、レプリケーションスロットを自動的にクリアできません。この場合、ソースデータベースでレプリケーションスロットを手動でクリアして、それが蓄積されてディスク領域を占有し、ソースデータベースが利用できなくなるのを防ぐ必要があります。ソースデータベースでフェールオーバーが発生した場合は、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。完全移行または増分移行タスクの場合、ソースデータベースの移行対象テーブルに外部キー、トリガー、またはイベントトリガーが含まれている場合、ターゲットデータベースアカウントが特権アカウントであるか、スーパーユーザー権限を持っている場合、DTS はセッションレベルで `session_replication_role` パラメーターを一時的に `replica` に設定します。ターゲットデータベースアカウントにこれらの権限がない場合は、ターゲットデータベースで `session_replication_role` パラメーターを手動で `replica` に設定する必要があります。この期間中、`session_replication_role` が `replica` のときに、ソースデータベースでカスケード更新または削除操作が発生すると、データの不整合が発生する可能性があります。DTS 移行タスクがリリースされた後、`session_replication_role` パラメーターを `origin` に戻すことができます。データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースのテーブルで断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルが使用するストレージ領域は、ソースデータベースよりも大きくなります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしていることを確認してください。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_objects_to_migrate> TO <source_db_account_for_task>` コマンドを実行して、このアカウントがオブジェクトのオーナーとして関連操作を実行できるようにします)。説明 `cloudsqlsuperuser` 権限を持つアカウントは、`cloudsqlsuperuser` 権限を持つ別のアカウントが所有するデータを管理できません。

PostgreSQL から MySQL への移行

以下に注意点と制限を示します。

タイプ	説明
ソースデータベースの制限	帯域幅要件: ソースデータベースが存在するサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。説明ターゲットテーブルが DTS によって作成されていない場合 (つまり、移行タイプでスキーマ移行を選択しなかった場合)、テーブルにソーステーブルと同じプライマリキーまたは空でない一意制約があることを確認する必要があります。そうでない場合、ターゲットデータベースでデータが重複する可能性があります。移行するデータベースの名前にハイフン (-) を含めることはできません (例: dts-testdata)。テーブルレベルでオブジェクトを移行し、列名のマッピングなどで編集する必要がある場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。増分移行の場合、先行書き込みログ (wal): 有効にする必要があります。wal_level パラメーターを logical に設定します。増分移行タスクの場合、DTS はソースデータベースの WAL ログを 24 時間以上保持する必要があります。完全移行と増分移行の両方を含むタスクの場合、DTS は WAL ログを少なくとも 7 日間保持する必要があります。完全移行が完了した後、ログの保持期間を 24 時間以上に変更できます。そうしないと、DTS が WAL ログを取得できないため、タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。DTS が要求するよりも短いログ保持期間に起因する問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。ソースデータベースの操作制限: 自主管理 PostgreSQL データベースでフェールオーバーが発生した場合、移行は失敗します。移行タスクが期待どおりに実行され、フェールオーバーによる論理レプリケーションの中断を防ぐために、RDS for PostgreSQL は論理レプリケーションスロットのフェールオーバーをサポートし、有効にする必要があります。設定方法の詳細については、「論理レプリケーションスロットのフェールオーバー」をご参照ください。完全移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。ソースデータベースの論理レプリケーションの制限により、移行中に移行される増分データの単一部分が 256 MB を超えると、DTS インスタンスが失敗し、回復できなくなる可能性があります。DTS インスタンスを再設定する必要があります。完全なデータ移行のみを実行する場合は、ソースデータベースに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生します。リアルタイムのデータ整合性を確保するには、完全なデータ移行と増分データ移行を選択します。ソースデータベースに長時間トランザクションがあり、インスタンスが増分移行を実行する場合、トランザクションコミット前の先行書き込みログ (WAL) がクリアされないことがあります。これにより、ログが蓄積され、ソースデータベースのディスク領域が不足する可能性があります。 DTS インスタンスの実行中にソースデータベースでメジャーエンジンバージョンのアップグレードを実行すると、インスタンスは失敗し、回復できなくなります。DTS インスタンスを再設定する必要があります。
その他の制限	DTS は、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 拡張テーブルまたはスキーマ間継承を持つテーブルの移行をサポートしていません。 DTS インスタンスが増分データ移行タスクを実行する場合、データを書き込む前に、ソースデータベースの移行対象テーブルで `ALTER TABLE schema.table REPLICA IDENTITY FULL;` コマンドを実行する必要があります。これは、次の 2 つのシナリオに適用され、データ整合性を確保します。このコマンドの実行中は、テーブルロック操作を実行しないことをお勧めします。そうしないと、テーブルがロックされる可能性があります。事前チェックで関連するチェックをスキップした場合、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 アドレスを削除したりすると、レプリケーションスロットを自動的にクリアできません。この場合、ソースデータベースでレプリケーションスロットを手動でクリアして、それが蓄積されてディスク領域を占有し、ソースデータベースが利用できなくなるのを防ぐ必要があります。ソースデータベースでフェールオーバーが発生した場合は、セカンダリデータベースにログインしてスロットを手動でクリアする必要があります。データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースのテーブルで断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルが使用するストレージ領域は、ソースデータベースよりも大きくなります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしていることを確認してください。DTS は、`ROUND(COLUMN,PRECISION)` を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 列を 38 桁の精度で、DOUBLE 列を 308 桁の精度で移行します。 DTS は 7 日以内に失敗した移行タスクを再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、`revoke` コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。パーティションテーブルを移行する場合、親テーブルとその子パーティションの両方を同期オブジェクトとして含める必要があります。そうしないと、パーティションテーブルでデータの不整合が発生する可能性があります。説明 PostgreSQL パーティションテーブルの親テーブルはデータを直接保存しません。すべてのデータは子パーティションに保存されます。同期タスクには、親テーブルとそのすべての子パーティションを含める必要があります。そうしないと、子パーティションのデータが同期されず、ソースと宛先の間でデータの不整合が発生する可能性があります。
特殊なケース	ソースインスタンスが RDS for PostgreSQL インスタンスの場合、移行中にそのエンドポイントまたはゾーンを変更しないでください。そうしないと、移行は失敗します。ソースインスタンスが自主管理 PostgreSQL データベースの場合、`max_wal_senders` および `max_replication_slots` パラメーターの値が、現在使用中のレプリケーションスロットの数と、このデータベースをソースとして作成される DTS インスタンスの数の合計よりも大きいことを確認してください。ソースインスタンスが Google Cloud Platform Cloud SQL for PostgreSQL の場合、ソースデータベースのデータベースアカウントに cloudsqlsuperuser 権限を持つアカウントを指定する必要があります。移行オブジェクトを選択するときは、このアカウントが管理する権限を持つオブジェクトを選択するか、移行するオブジェクトのオーナー権限をこのアカウントに付与する必要があります (たとえば、`GRANT <owner_of_objects_to_migrate> TO <source_db_account_for_task>` コマンドを実行して、このアカウントがオブジェクトのオーナーとして関連操作を実行できるようにします)。説明 `cloudsqlsuperuser` 権限を持つアカウントは、`cloudsqlsuperuser` 権限を持つ別のアカウントが所有するデータを管理できません。宛先インスタンスが RDS for MySQL インスタンスの場合、DTS はインスタンスにデータベースを自動的に作成します。移行するデータベースの名前が RDS for MySQL の命名規則に準拠していない場合は、移行タスクを設定する前に RDS for MySQL インスタンスにデータベースを作成する必要があります。詳細については、「データベースの管理」をご参照ください。

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

以下に注意点と制限を示します。

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