Data Transmission Service:PostgreSQL データベースからのデータ移行に関する使用上の注意と制限事項

PostgreSQL データベースからデータを移行するシナリオ

次のリストは、PostgreSQL データベースからデータを移行するシナリオを示しています。シナリオによって使用上の注意と制限事項が異なる場合があります。特定のシナリオの使用上の注意と制限事項を表示するには、関連セクションに移動してください。

• PostgreSQL データベース間でデータを移行する

• PostgreSQL データベースから MySQL データベースにデータを移行する

• PostgreSQL データベースから PolarDB for PostgreSQL (Oracle 互換) クラスタにデータを移行する

PostgreSQL データベース間でデータを移行する

• ApsaraDB RDS for PostgreSQL インスタンス間でデータを移行する

  カテゴリ	説明
  ソースデータベースの制限	移行対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約が必要です。また、すべてのフィールドが一意である必要があります。そうでない場合、宛先クラスタに重複データレコードが含まれる可能性があります。 説明 データの受信に使用するテーブルが DTS を使用して作成されていない場合 ([同期タイプ] パラメータで [スキーマ同期] が選択されていない場合)、テーブルとソースデータベースから移行されるテーブルが同じ PRIMARY KEY 制約または NOT NULL UNIQUE 制約を持っていることを確認してください。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。 ソースデータベースの名前には、ハイフン (-) を含めることはできません。例: dts-testdata 移行対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルや列の名前変更など、テーブルを編集する必要がある場合は、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 DTS は、ソースデータベースの一時テーブル、内部トリガー、または C プログラミング言語で記述された一部の内部プロシージャおよび関数を移行できません。DTS は、COMPOSITE、ENUM、および RANGE タイプのカスタムパラメータを移行できます。移行対象のテーブルには、PRIMARY KEY、FOREIGN KEY、UNIQUE、または CHECK 制約が必要です。 増分データを移行する必要がある場合は、次の要件が満たされていることを確認する必要があります。 wal_level パラメータの値を logical に設定する必要があります。 増分データ移行のみを実行する場合は、ソースデータベースの先行書き込みログ (WAL) ログを 24 時間以上保存する必要があります。完全データ移行と増分データ移行の両方を実行する場合は、ソースデータベースの WAL ログを 7 日以上保存する必要があります。そうでない場合、Data Transmission Service (DTS) が WAL ログを取得できず、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。完全データ移行が完了したら、保存期間を 24 時間以上に設定できます。上記の要件に基づいて WAL ログの保存期間を設定してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。 ソースデータベースで実行する操作の制限: スキーマ移行と完全データ移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。 完全データ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。そうしないと、ソースデータベースと宛先データベース間でデータの不整合が発生します。データの整合性を確保するために、移行タイプとしてスキーマ移行、完全データ移行、および増分データ移行を選択することをお勧めします。 ソースデータベースからの論理サブスクリプションには、DTS の使用に制限があります。増分データの変更時にソースデータベースから移行される単一データのサイズが 256 MB を超えると、実行中のデータ移行インスタンスは実行に失敗し、回復できません。タスクを再構成する必要があります。 ソースデータベースに 1 つ以上の長時間トランザクションがあり、データ移行タスクで増分データが移行される場合、長時間トランザクションがコミットされる前に生成された WAL ログが蓄積される可能性があります。その結果、ソースデータベースのディスク容量が不足する可能性があります。 実行中のデータ移行インスタンスのソースデータベースのメジャーバージョンアップグレードが実行されると、インスタンスは実行に失敗し、回復できません。タスクを再構成する必要があります。
  その他の制限	ソース ApsaraDB RDS for PostgreSQL インスタンスでプライマリ/セカンダリスイッチオーバーを実行する必要がある場合は、論理レプリケーションスロットフェイルオーバー機能を有効にする必要があります。これにより、論理サブスクリプションが中断されるのを防ぎ、データ移行タスクが想定どおりに実行できるようになります。詳細については、「論理レプリケーションスロットフェイルオーバー」をご参照ください。 1 つのデータ移行タスクでは、1 つのデータベースからのみデータを移行できます。複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。 スキーマ間で継承できるテーブルは移行できません。 移行対象のテーブルに SERIAL フィールドが含まれている場合、ソースデータベースにシーケンスが作成されます。[ソースオブジェクト] パラメータを構成するときに、[移行タイプ] として [スキーマ移行] を選択する場合は、シーケンスまたは完全なスキーマ移行を選択することをお勧めします。そうでない場合、移行インスタンスは実行に失敗します。 移行対象のオブジェクトとしてスキーマを選択し、増分データ移行中にスキーマにテーブルを作成するか、RENAME 文を実行してスキーマ内のテーブルの名前を変更する場合は、テーブルにデータを書き込む前に、ALTER TABLE schema.table REPLICA IDENTITY FULL; 文を実行する必要があります。この文を実行するときは、テーブルをロックしないことをお勧めします。そうしないと、デッドロックが発生します。 説明 上記のサンプル文の schema と table を実際のスキーマ名とテーブル名に置き換えてください。 この操作は、オフピーク時に実行することをお勧めします。 DTS は、シーケンスなどのメタデータの有効性をチェックしません。メタデータの有効性は手動でチェックする必要があります。 ワークロードがターゲットデータベースに切り替えられた後、新しいシーケンスはソースデータベースのシーケンスの最大値から増加しません。そのため、ワークロードをターゲットデータベースに切り替える前に、ターゲットデータベースのシーケンスの開始値を更新する必要があります。 DTS は、ソースデータベースに次のテンポラリテーブルを作成して、増分データの DDL 文、増分テーブルのスキーマ、およびハートビート情報を取得します。データ移行中は、ソースデータベースの一時テーブルを削除しないでください。そうしないと、例外が発生します。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。 完全データ移行タスクまたは増分データ移行タスクを実行する場合、ソースデータベースから移行されるテーブルに外部キー、トリガー、またはイベントトリガーが含まれており、宛先データベースのアカウントが特権アカウントまたはスーパーユーザーロールの権限を持つアカウントである場合、DTS は完全データ移行または増分データ移行中に session_replication_role パラメータをセッションレベルで一時的に replica に設定します。宛先データベースのアカウントに権限がない場合は、宛先データベースで session_replication_role パラメータを手動で replica に設定する必要があります。完全データ移行または増分データ移行中に session_replication_role パラメータが replica に設定された後、ソースデータベースでカスケード更新または削除操作が実行されると、データの不整合が発生する可能性があります。データ移行タスクが解放された後、session_replication_role パラメータの値を origin に変更できます。 増分データ移行のレイテンシが正確であることを確認するために、DTS はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを作成します。 増分データ移行中に、DTS はソースデータベースにレプリケーションスロットを作成してデータをレプリケートします。レプリケーションスロットには、dts_sync_ というプレフィックスが付きます。このレプリケーションスロットを使用することにより、DTS は過去 15 分以内のソースデータベースの増分ログを取得できます。 説明 DTS インスタンスが解放されると、レプリケーションスロットは自動的に削除されます。ソースデータベースのパスワードを変更するか、IP アドレスホワイトリストから DTS の IP アドレスを削除すると、レプリケーションスロットは自動的に削除されません。その場合は、レプリケーションスロットが蓄積されないように、ソースデータベースからレプリケーションスロットを手動で削除する必要があります。 データ移行タスクが解放された場合、または失敗した場合、DTS はレプリケーションスロットを自動的に削除します。ソース ApsaraDB for PostgreSQL インスタンスでプライマリ/セカンダリスイッチオーバーが実行された場合は、セカンダリインスタンスにログインしてレプリケーションスロットを削除する必要があります。 データを移行する前に、データ移行がソースデータベースと宛先データベースのパフォーマンスに及ぼす影響を評価してください。オフピーク時にデータを移行することをお勧めします。完全データ移行中に、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 完全データ移行中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。完全データ移行が完了すると、宛先データベースの表領域はソースデータベースの表領域よりも大きくなります。 FLOAT データ型または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT データ型または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の精度を 38 桁に設定し、DOUBLE データ型の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードを宛先クラスタに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE 文を実行して、DTS が宛先データベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータが宛先データベースのデータを上書きします。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。 説明 タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
  特別なケース	データ移行中は、ソース ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。そうしないと、データ移行タスクが失敗します。

• 自主管理 PostgreSQL データベースから ApsaraDB RDS for PostgreSQL インスタンスにデータを移行する

  カテゴリ	説明
  ソースデータベースの制限	ソースデータベースが存在するサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度に影響します。 移行対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約が必要です。また、すべてのフィールドが一意である必要があります。そうでない場合、宛先クラスタに重複データレコードが含まれる可能性があります。 説明 データの受信に使用するテーブルが DTS を使用して作成されていない場合 ([同期タイプ] パラメータで [スキーマ同期] が選択されていない場合)、テーブルとソースデータベースから移行されるテーブルが同じ PRIMARY KEY 制約または NOT NULL UNIQUE 制約を持っていることを確認してください。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。 ソースデータベースの名前には、ハイフン (-) を含めることはできません。例: dts-testdata 移行対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルや列の名前変更など、テーブルを編集する必要がある場合は、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 DTS は、ソースデータベースの一時テーブル、内部トリガー、または C プログラミング言語で記述された一部の内部プロシージャおよび関数を移行できません。DTS は、COMPOSITE、ENUM、および RANGE タイプのカスタムパラメータを移行できます。移行対象のテーブルには、PRIMARY KEY、FOREIGN KEY、UNIQUE、または CHECK 制約が必要です。 増分データを移行する必要がある場合は、次の要件が満たされていることを確認する必要があります。 wal_level パラメータの値を logical に設定する必要があります。 増分データ移行のみを実行する場合は、ソースデータベースの先行書き込みログ (WAL) ログを 24 時間以上保存する必要があります。完全データ移行と増分データ移行の両方を実行する場合は、ソースデータベースの WAL ログを 7 日以上保存する必要があります。そうでない場合、Data Transmission Service (DTS) が WAL ログを取得できず、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。完全データ移行が完了したら、保存期間を 24 時間以上に設定できます。上記の要件に基づいて WAL ログの保存期間を設定してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。 ソースデータベースで実行する操作の制限: ソースの自主管理 PostgreSQL データベースでプライマリ/セカンダリスイッチオーバーを実行すると、データ移行タスクは失敗します。 スキーマ移行と完全データ移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。 ソースデータベースからの論理サブスクリプションには、DTS の使用に制限があります。増分データの変更時にソースデータベースから移行される単一データのサイズが 256 MB を超えると、実行中のデータ移行インスタンスは実行に失敗し、回復できません。タスクを再構成する必要があります。 ソースデータベースに 1 つ以上の長時間トランザクションがあり、データ移行タスクで増分データが移行される場合、長時間トランザクションがコミットされる前に生成された WAL ログが蓄積される可能性があります。その結果、ソースデータベースのディスク容量が不足する可能性があります。 実行中のデータ移行インスタンスのソースデータベースのメジャーバージョンアップグレードが実行されると、インスタンスは実行に失敗し、回復できません。タスクを再構成する必要があります。
  その他の制限	移行レイテンシにより、ソースデータベースのプライマリノードとセカンダリノード間でデータの不整合が発生する可能性があります。したがって、データを移行するときは、プライマリノードをデータソースとして使用する必要があります。 1 つのデータ移行タスクでは、1 つのデータベースからのみデータを移行できます。複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。 スキーマ間で継承できるテーブルは移行できません。 移行対象のテーブルに SERIAL フィールドが含まれている場合、ソースデータベースにシーケンスが作成されます。[ソースオブジェクト] パラメータを構成するときに、[移行タイプ] として [スキーマ移行] を選択する場合は、シーケンスまたは完全なスキーマ移行を選択することをお勧めします。そうでない場合、移行インスタンスは実行に失敗します。 移行対象のオブジェクトとしてスキーマを選択し、増分データ移行中にスキーマにテーブルを作成するか、RENAME 文を実行してスキーマ内のテーブルの名前を変更する場合は、テーブルにデータを書き込む前に、ALTER TABLE schema.table REPLICA IDENTITY FULL; 文を実行する必要があります。この文を実行するときは、テーブルをロックしないことをお勧めします。そうしないと、デッドロックが発生します。 説明 上記のサンプル文の schema と table を実際のスキーマ名とテーブル名に置き換えてください。 この操作は、オフピーク時に実行することをお勧めします。 DTS は、シーケンスなどのメタデータの有効性をチェックしません。メタデータの有効性は手動でチェックする必要があります。 ワークロードがターゲットデータベースに切り替えられた後、新しいシーケンスはソースデータベースのシーケンスの最大値から増加しません。そのため、ワークロードをターゲットデータベースに切り替える前に、ターゲットデータベースのシーケンスの開始値を更新する必要があります。 DTS は、ソースデータベースに次のテンポラリテーブルを作成して、増分データの DDL 文、増分テーブルのスキーマ、およびハートビート情報を取得します。データ移行中は、ソースデータベースの一時テーブルを削除しないでください。そうしないと、例外が発生します。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。 増分データ移行のレイテンシが正確であることを確認するために、DTS はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを作成します。 増分データ移行中に、DTS はソースデータベースにレプリケーションスロットを作成してデータをレプリケートします。レプリケーションスロットには、dts_sync_ というプレフィックスが付きます。このレプリケーションスロットを使用することにより、DTS は過去 15 分以内のソースデータベースの増分ログを取得できます。 説明 データ移行タスクが解放された場合、または失敗した場合、DTS はレプリケーションスロットを自動的に削除します。ソースの自主管理 PostgreSQL データベースでプライマリ/セカンダリスイッチオーバーが実行された場合は、セカンダリデータベースにログインしてレプリケーションスロットを削除する必要があります。 完全データ移行タスクまたは増分データ移行タスクを実行する場合、ソースデータベースから移行されるテーブルに外部キー、トリガー、またはイベントトリガーが含まれており、宛先データベースのアカウントが特権アカウントまたはスーパーユーザーロールの権限を持つアカウントである場合、DTS は完全データ移行または増分データ移行中に session_replication_role パラメータをセッションレベルで一時的に replica に設定します。宛先データベースのアカウントに権限がない場合は、宛先データベースで session_replication_role パラメータを手動で replica に設定する必要があります。完全データ移行または増分データ移行中に session_replication_role パラメータが replica に設定された後、ソースデータベースでカスケード更新または削除操作が実行されると、データの不整合が発生する可能性があります。データ移行タスクが解放された後、session_replication_role パラメータの値を origin に変更できます。 データを移行する前に、データ移行がソースデータベースと宛先データベースのパフォーマンスに及ぼす影響を評価してください。オフピーク時にデータを移行することをお勧めします。完全データ移行中に、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 完全データ移行中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。完全データ移行が完了すると、宛先データベースの表領域はソースデータベースの表領域よりも大きくなります。 FLOAT データ型または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT データ型または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の精度を 38 桁に設定し、DOUBLE データ型の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードを宛先クラスタに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE 文を実行して、DTS が宛先データベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータが宛先データベースのデータを上書きします。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。 説明 タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
  特別なケース	ソースデータベースが自主管理 PostgreSQL データベースの場合、max_wal_senders パラメータと max_replication_slots パラメータの値は、自主管理 PostgreSQL データベースで使用されているレプリケーションスロットの数と、このデータベースからデータを移行するために作成する必要がある DTS インスタンスの数の合計よりも大きくなければなりません。 ソースデータベースが Google Cloud Platform によって提供される Cloud SQL for PostgreSQL インスタンスの場合、データベースアカウント パラメーターを、ソースデータベースに対する cloudsqlsuperuser 権限を持つデータベースアカウントに設定する必要があります。移行するオブジェクトを選択する場合は、指定したアカウントが管理することを承認されているオブジェクトを選択する必要があります。そうでない場合は、選択したオブジェクトに対する OWNER 権限を指定したアカウントに付与する必要があります。 説明 cloudsqlsuperuser 権限を持つアカウントは、cloudsqlsuperuser 権限を持つ他のアカウントが所有するデータを管理することはできません。

PostgreSQL データベースから MySQL データベースにデータを移行する

次の表に、PostgreSQL データベースから MySQL データベースにデータを移行する際に注意する必要がある使用上の注意と制限事項を示します。

PostgreSQL データベースから PolarDB for PostgreSQL (Oracle 互換) クラスタにデータを移行する

次の表に、PostgreSQL データベースから PolarDB for PostgreSQL (Oracle 互換) クラスタにデータを移行する際に注意する必要がある使用上の注意と制限事項を示します。