Data Transmission Service:PolarDB for PostgreSQL (Oracleと互換) クラスターからデータを移行するための注意事項と制限事項

カテゴリ

説明

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

• ソースデータベースが属するサーバーには、十分なアウトバウンド帯域幅が必要です。 そうしないと、データ移行速度が低下します。

• 移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

• 移行するオブジェクトとしてテーブルを選択し、ターゲットデータベースのテーブルまたは列の名前を変更するなど、テーブルを編集する必要がある場合、1つのデータ移行タスクで最大1,000のテーブルを移行できます。 タスクを実行して1,000を超えるテーブルを移行すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルを移行するか、タスクを構成してデータベース全体を移行することをお勧めします。

• 増分データを移行する必要がある場合は、次の要件が満たされていることを確認してください。

  • 先行書き込みロギング (WAL) 機能を有効にする必要があります。

  • 増分データ移行の場合、ソースデータベースのWALログを24時間以上保存する必要があります。 完全データおよび増分データ移行の場合、ソースデータベースのWALログを少なくとも7日間保存する必要があります。 そうしないと、DTSはWALログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ移行が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、WALログの保持期間を設定してください。 そうしないと、DTSのサービスレベル契約 (SLA) に記載されているサービスの信頼性とパフォーマンスが保証されない場合があります。

• ソースデータベースで実行する操作の制限:

  • スキーマ移行中および完全データ移行中は、DDL操作を実行してデータベースまたはテーブルのスキーマを変更しないでください。 それ以外の場合、データ移行タスクは失敗します。

  • フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。 それ以外の場合、ソースデータベースとターゲットデータベース間でデータの不一致が発生します。 データの一貫性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、および増分データ移行を選択することを推奨します。

  • ソースPolarDB for PostgreSQL(Compatible with Oracle) クラスターでプライマリ /セカンダリの切り替えを実行する場合は、Logical Replication Slot Failover機能を有効にする必要があります。 これにより、論理サブスクリプションの中断を防ぎ、データ同期タスクを期待どおりに実行できます。 詳細については、「論理レプリケーションスロットフェールオーバー」をご参照ください。

• 1つまたは複数の長期トランザクションがソースデータベースに存在し、増分データがデータ移行タスクで移行される場合、ソースデータベースの長期トランザクションがコミットされる前に生成されたWALログが蓄積される可能性があります。 その結果、ソースデータベースのディスク容量が不足する可能性があります。

その他の制限

• データ移行タスクは、単一のデータベースからのみデータを移行できます。 複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。

• スキーマにテーブルを作成するか、RENAMEコマンドを実行してテーブルの名前を変更する場合は、テーブルにデータを書き込む前にALTER table schema.table REPLICA IDENTITY FULL; ステートメントを実行する必要があります。

  説明

  上記のサンプルステートメントのスキーマとテーブルを、実際のスキーマ名とテーブル名に置き換えます。

• 増分データ移行中に表示されるレイテンシの正確性を確保するために、DTSはソースデータベースにdts_postgres_heartbeatという名前のテーブルを作成します。 次の図は、テーブルの構造と内容を示しています。

• 増分データ移行中、DTSはソースデータベースのレプリケーションスロットを作成します。 レプリケーションスロットの先頭にdts_sync_ があります。 DTSは、このレプリケーションスロットを使用して、過去15分以内にソースデータベースの増分ログを取得できます。

  説明

  • DTSインスタンスがリリースされると、レプリケーションスロットは自動的に削除されます。 ソースデータベースのパスワードを変更したり、DTSのIPアドレスホワイトリストを削除した場合、レプリケーションスロットは自動的に削除できません。 その場合、複製スロットが積み重ならないように、複製スロットをソースデータベースから手動で削除する必要があります。

  • データ移行タスクがリリースされたか失敗した場合、DTSは自動的にレプリケーションスロットをクリアします。 ソースクラスターでプライマリ /セカンダリの切り替えが実行される場合、セカンダリインスタンスにログインしてレプリケーションスロットをクリアする必要があります。

• データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 完全データ移行中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

• 完全データ移行中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 完全なデータ移行が完了すると、移行先データベースのテーブルスペースは移行元データベースのテーブルスペースよりも大きくなります。

• FLOATまたはDOUBLEデータ型の列の精度設定がビジネス要件を満たしていることを確認します。 DTSはROUND(COLUMN,PRECISION) 関数を使用して、FLOATまたはDOUBLEデータ型の列から値を取得します。 精度を指定しない場合、DTSはFLOATデータ型の精度を38桁に設定し、DOUBLEデータ型の精度を308桁に設定します。

• DTSは、過去7日以内に失敗したデータ移行タスクを再開しようとします。 ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止またはリリースする必要があります。 REVOKEステートメントを実行して、DTSがターゲットデータベースにアクセスするために使用するアカウントの書き込み権限を取り消すこともできます。 それ以外の場合、失敗したタスクが再開された後、ソースデータベースのデータがターゲットデータベースのデータを上書きします。

• 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;
  $$;

カテゴリ

説明

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

• ソースデータベースが属するサーバーには、十分なアウトバウンド帯域幅が必要です。 そうしないと、データ移行速度が低下します。

• 移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

• 移行するオブジェクトとしてテーブルを選択し、ターゲットデータベースのテーブルまたは列の名前を変更するなど、テーブルを編集する必要がある場合、1つのデータ移行タスクで最大1,000のテーブルを移行できます。 タスクを実行して1,000を超えるテーブルを移行すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルを移行するか、タスクを構成してデータベース全体を移行することをお勧めします。

• 増分データを移行する必要がある場合は、次の要件が満たされていることを確認してください。

  • 先行書き込みロギング (WAL) 機能を有効にする必要があります。

  • 増分データ移行の場合、ソースデータベースのWALログを24時間以上保存する必要があります。 完全データおよび増分データ移行の場合、ソースデータベースのWALログを少なくとも7日間保存する必要があります。 そうしないと、DTSはWALログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ移行が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、WALログの保持期間を設定してください。 そうしないと、DTSのサービスレベル契約 (SLA) に記載されているサービスの信頼性とパフォーマンスが保証されない場合があります。

• ソースデータベースで実行する操作の制限:

  • フルデータ移行中は、DDL操作を実行してデータベースまたはテーブルのスキーマを変更しないでください。 それ以外の場合、データ移行タスクは失敗します。

  • フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。 それ以外の場合、ソースデータベースとターゲットデータベース間でデータの不一致が発生します。 データの一貫性を確保するために、移行タイプとしてフルデータ移行と増分データ移行を選択することを推奨します。

  • ソースPolarDB for PostgreSQL(Compatible with Oracle) クラスターでプライマリ /セカンダリの切り替えを実行する場合は、Logical Replication Slot Failover機能を有効にする必要があります。 これにより、論理サブスクリプションの中断を防ぎ、データ同期タスクを期待どおりに実行できます。 詳細については、「論理レプリケーションスロットフェールオーバー」をご参照ください。

• 1つまたは複数の長期トランザクションがソースデータベースに存在し、増分データがデータ移行タスクで移行される場合、ソースデータベースの長期トランザクションがコミットされる前に生成されたWALログが蓄積される可能性があります。 その結果、ソースデータベースのディスク容量が不足する可能性があります。

その他の制限

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

• データ移行タスクは、単一のデータベースからのみデータを移行できます。 複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。

• スキーマにテーブルを作成するか、RENAMEコマンドを実行してテーブルの名前を変更する場合は、テーブルにデータを書き込む前にALTER table schema.table REPLICA IDENTITY FULL; ステートメントを実行する必要があります。

  説明

  上記のサンプルステートメントのスキーマとテーブルを、実際のスキーマ名とテーブル名に置き換えます。

• 増分データ移行中に表示されるレイテンシの正確性を確保するために、DTSはソースデータベースにdts_postgres_heartbeatという名前のテーブルを作成します。 次の図は、テーブルの構造と内容を示しています。

• 増分データ移行中、DTSはソースデータベースのレプリケーションスロットを作成します。 レプリケーションスロットの先頭にdts_sync_ があります。 DTSは、このレプリケーションスロットを使用して、過去15分以内にソースデータベースの増分ログを取得できます。

  説明

  • DTSインスタンスがリリースされると、レプリケーションスロットは自動的に削除されます。 ソースデータベースのパスワードを変更したり、DTSのIPアドレスホワイトリストを削除した場合、レプリケーションスロットは自動的に削除できません。 その場合、複製スロットが積み重ならないように、複製スロットをソースデータベースから手動で削除する必要があります。

  • データ移行タスクがリリースされたか失敗した場合、DTSは自動的にレプリケーションスロットをクリアします。 ソースクラスターでプライマリ /セカンダリの切り替えが実行される場合、セカンダリインスタンスにログインしてレプリケーションスロットをクリアする必要があります。

• 完全データ移行中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 完全なデータ移行が完了すると、移行先データベースのテーブルスペースは移行元データベースのテーブルスペースよりも大きくなります。

• FLOATまたはDOUBLEデータ型の列の精度設定がビジネス要件を満たしていることを確認します。 DTSはROUND(COLUMN,PRECISION) 関数を使用して、FLOATまたはDOUBLEデータ型の列から値を取得します。 精度を指定しない場合、DTSはFLOATデータ型の精度を38桁に設定し、DOUBLEデータ型の精度を308桁に設定します。

• DTSは、過去7日以内に失敗したデータ移行タスクを再開しようとします。 ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止またはリリースする必要があります。 REVOKEステートメントを実行して、DTSがターゲットデータベースにアクセスするために使用するアカウントの書き込み権限を取り消すこともできます。 それ以外の場合、失敗したタスクが再開された後、ソースデータベースのデータがターゲットデータベースのデータを上書きします。

特別なケース

自己管理型OracleデータベースがReal Application Cluster (RAC) アーキテクチャでデプロイされ、Alibaba Cloud仮想プライベートクラウド (VPC) を介してDTSに接続されている場合、Oracle RACのSingle Client Access Name (SCAN) IPアドレスと各ノードの仮想IPアドレス (VIP) をVPCに接続し、ルートを設定する必要があります。 この設定により、DTSタスクが期待どおりに実行できるようになります。 詳細については、「オンプレミスデータベースをAlibaba Cloudに接続する」および「VPN Gatewayを使用してデータセンターをDTSに接続する」をご参照ください。