Data Transmission Service:PolarDB for PostgreSQL (Oracle 互換) をソースとする移行の注意事項と制限

タイプ

説明

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

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

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

• テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。

• 増分移行を実行する場合、先行書き込みログ (WAL) に関する以下の点にご注意ください。

  • WAL を有効にする必要があります。

  • 増分移行タスクの場合、DTS ではソースデータベースの WAL を 24 時間以上保持する必要があります。完全移行と増分移行の両方を含むタスクの場合、DTS では WAL を少なくとも 7 日間保持する必要があります。完全移行が完了した後、ログの保持期間を 24 時間以上に設定できます。WAL が必要な期間保持されない場合、DTS が WAL を取得できないため、DTS タスクが失敗する可能性があります。極端なケースでは、データの不整合やデータ損失が発生する可能性があります。必要な期間より短い WAL 保持期間に起因する問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。

• ソースデータベース操作の制限：

  • スキーマ移行および完全なデータ移行中は、データベースまたはテーブルの構造を変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。

  • 完全なデータ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生します。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択してください。

  • 移行タスクが期待どおりに実行され、フェールオーバーによって論理レプリケーションが中断されるのを防ぐために、PolarDB for PostgreSQL (Compatible with Oracle) は論理レプリケーションスロットのフェールオーバーをサポートし、有効にする必要があります。

    説明

    ソースの PolarDB for PostgreSQL (Compatible with Oracle) クラスターが論理レプリケーションスロットのフェールオーバーをサポートしていない場合 (たとえば、[データベースエンジン] が [Oracle 構文互換 2.0] の場合)、ソースデータベースでのフェールオーバーにより、移行インスタンスが失敗し、回復不能になる可能性があります。

  • ソースデータベースの論理レプリケーションに固有の制限により、増分変更後に移行される単一のデータが 256 MB を超える場合、移行インスタンスが失敗し、回復不能になる可能性があります。移行インスタンスを再設定する必要があります。

• ソースデータベースに長時間トランザクションがあり、インスタンスが増分移行を実行する場合、トランザクションコミット前の WAL が蓄積され、クリアできなくなることがあります。これにより、ソースデータベースのディスク領域が不足する可能性があります。

その他の制限

• 1 つのデータ移行タスクで移行できるデータベースは 1 つだけです。複数のデータベースを移行するには、データベースごとに個別のデータ移行タスクを設定してください。

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

• 拡張機能をインストールして作成されたスキーマは、移行の対象外です。タスクを設定する際に、コンソールでこれらのスキーマに関する情報を取得することはできません。

• 移行対象のテーブルに 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 アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップされません。この場合、ソースデータベースでレプリケーションスロットを手動でクリーンアップする必要があります。これにより、スロットが継続的に蓄積されてディスク領域を消費し、ソースデータベースが利用できなくなるのを防ぎます。

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

• ソースデータベースとターゲットデータベースのパフォーマンスをデータ移行前に評価してください。オフピーク時にデータ移行を実行してください。そうしないと、完全なデータ移行中に DTS がソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースの一部を消費し、データベースの負荷が増加する可能性があります。

• 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。完全移行が完了すると、ターゲットデータベースのテーブルストレージ領域は、ソースインスタンスよりも大きくなります。

• DTS が FLOAT または DOUBLE データ型の列に使用する移行精度がビジネス要件を満たしているかどうかを確認してください。DTS は ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT を 38 桁の精度で、DOUBLE を 308 桁の精度で移行します。

• DTS は、失敗した移行タスクを 7 日以内に回復しようとします。ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用して DTS が宛先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消してください。これにより、タスクが自動的に回復された後、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。

• DTS はデータ内容を検証しますが、シーケンスなどのメタデータの検証はサポートしていません。メタデータはご自身で検証する必要があります。

• ターゲットデータベースへのサービススイッチオーバー後、新しいシーケンスはソースデータベースの最大シーケンス値から増分を開始しません。スイッチオーバーの前に、ターゲットデータベースのシーケンス値を更新する必要があります。詳細については、「ターゲットデータベースのシーケンス値を更新する」をご参照ください。

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

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

  説明

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

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

  説明

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

タイプ

説明

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

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

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

• テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。

• 増分移行を実行する場合、先行書き込みログ (WAL) に関する以下の点にご注意ください。

  • WAL を有効にする必要があります。

  • 増分移行タスクの場合、DTS ではソースデータベースの WAL を 24 時間以上保持する必要があります。完全移行と増分移行の両方を含むタスクの場合、DTS では WAL を少なくとも 7 日間保持する必要があります。完全移行が完了した後、ログの保持期間を 24 時間以上に設定できます。WAL が必要な期間保持されない場合、DTS が WAL を取得できないため、DTS タスクが失敗する可能性があります。極端なケースでは、データの不整合やデータ損失が発生する可能性があります。必要な期間より短い WAL 保持期間に起因する問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。

• ソースデータベース操作の制限：

  • 完全なデータ移行中は、データベースまたはテーブルの構造を変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。

  • 完全なデータ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生します。リアルタイムのデータ整合性を維持するには、完全なデータ移行と増分データ移行を選択してください。

  • 移行タスクが期待どおりに実行され、フェールオーバーによって論理レプリケーションが中断されるのを防ぐために、PolarDB for PostgreSQL (Compatible with Oracle) は論理レプリケーションスロットのフェールオーバーをサポートし、有効にする必要があります。

    説明

    ソースの PolarDB for PostgreSQL (Compatible with Oracle) クラスターが論理レプリケーションスロットのフェールオーバーをサポートしていない場合 (たとえば、[データベースエンジン] が [Oracle 構文互換 2.0] の場合)、ソースデータベースでのフェールオーバーにより、移行インスタンスが失敗し、回復不能になる可能性があります。

  • ソースデータベースの論理レプリケーションに固有の制限により、増分変更後に移行される単一のデータが 256 MB を超える場合、移行インスタンスが失敗し、回復不能になる可能性があります。移行インスタンスを再設定する必要があります。

• ソースデータベースに長時間トランザクションがあり、インスタンスが増分移行を実行する場合、トランザクションコミット前の WAL が蓄積され、クリアできなくなることがあります。これにより、ソースデータベースのディスク領域が不足する可能性があります。

その他の制限

• スキーマ移行はサポートされていません。移行タスクを設定する前に、宛先インスタンスに対応するデータベースとテーブルを作成する必要があります。

• 1 つのデータ移行タスクで移行できるデータベースは 1 つだけです。複数のデータベースを移行するには、データベースごとに個別のデータ移行タスクを設定してください。

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

• 拡張機能をインストールして作成されたスキーマは、移行の対象外です。タスクを設定する際に、コンソールでこれらのスキーマに関する情報を取得することはできません。

• 移行インスタンスに増分データ移行タスクが含まれている場合、データを書き込む前に、ソースデータベースの移行対象テーブルで 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 アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップされません。この場合、ソースデータベースでレプリケーションスロットを手動でクリーンアップする必要があります。これにより、スロットが継続的に蓄積されてディスク領域を消費し、ソースデータベースが利用できなくなるのを防ぎます。

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

• 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。完全移行が完了すると、ターゲットデータベースのテーブルストレージ領域は、ソースインスタンスよりも大きくなります。

• DTS が FLOAT または DOUBLE データ型の列に使用する移行精度がビジネス要件を満たしているかどうかを確認してください。DTS は ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT を 38 桁の精度で、DOUBLE を 308 桁の精度で移行します。

• DTS は、失敗した移行タスクを 7 日以内に回復しようとします。ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用して DTS が宛先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消してください。これにより、タスクが自動的に回復された後、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。

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

  説明

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

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

  説明

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

特殊なケース

自己管理 Oracle データベースが Real Application Clusters (RAC) アーキテクチャであり、Alibaba Cloud VPC に接続する必要がある場合、各ノードの SCAN IP と仮想 IP アドレス (VIP) の両方を VPC に接続し、ルーティングを設定する必要があります。これにより、DTS タスクが正常に実行されるようになります。詳細については、「オンプレミスデータセンターを Alibaba Cloud に接続するためのソリューションの概要」および「VPN Gateway を使用してオンプレミスデータセンターを Alibaba Cloud サービスに接続する」をご参照ください。