すべてのプロダクト
Search

このプロダクト

    ApsaraDB RDS:DTS を使用したインスタンスの移行

    ドキュメントセンター

    ApsaraDB RDS:DTS を使用したインスタンスの移行

    最終更新日:Mar 29, 2026

    Data Transmission Service (DTS) を使用して、ApsaraDB RDS for PostgreSQL インスタンス間でデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしています。これら 3 種類の移行を組み合わせて実行することで、移行中のアプリケーションをオンライン状態に保ち、ダウンタイムを最小限に抑えることができます。

    前提条件

    開始する前に、以下の点を確認してください。

    • 送信元および送信先の ApsaraDB RDS for PostgreSQL インスタンスが作成されています。詳細については、「インスタンスの作成」をご参照ください。

    • 宛先データベースのバージョンが、ソースデータベースのバージョンと同一か、それより新しいこと。宛先のバージョンが低い場合、互換性の問題が発生する可能性があります。

    • 宛先インスタンスの利用可能なストレージ領域が、ソースインスタンス内の全データサイズよりも大きいこと。

    サポートされているソースデータベースとターゲットデータベースのバージョンについては、「データ移行シナリオの概要」をご参照ください。

    移行タイプ

    DTS では、要件に応じて組み合わせ可能な 3 種類の移行タイプをサポートしています。

    移行タイプ機能
    スキーマ移行選択したオブジェクト（テーブル、ビュー、インデックスなど）のスキーマをソースから宛先へコピーします。
    完全なデータ移行既存のすべてのデータをソースから宛先へコピーします。
    増分データ移行完全なデータ移行完了後、ソースから宛先へデータ変更を継続的にレプリケーションし、アプリケーションの稼働中に宛先を同期状態に保ちます。

    移行戦略の選択：

    • 完全移行のみ（ダウンタイムあり）： スキーマ移行 および 完全なデータ移行 を選択します。データ整合性を確保するため、移行開始前にソースへの書き込みを停止します。

    • オンライン移行（最小限のダウンタイム）： スキーマ移行、完全なデータ移行、および 増分データ移行 を選択します。移行中もアプリケーションはオンライン状態を維持できます。カットオーバー時のみ、ソースへの書き込みを停止します。

    対応するオブジェクト

    以下のオブジェクトタイプを移行できます。

    • SCHEMA および TABLE — PRIMARY KEY、UNIQUE KEY、FOREIGN KEY、組み込みデータ型、DEFAULT 制約を含む

    • VIEW

    • PROCEDURE — PostgreSQL V11 以降のみ

    • FUNCTION、RULE、SEQUENCE、EXTENSION、TRIGGER、AGGREGATE、INDEX、OPERATOR、DOMAIN

    増分移行でサポートされる SQL 操作

    操作タイプサポートされる文
    DMLINSERT、UPDATE、DELETE
    DDL以下に詳細を記載

    DDL 移行の詳細：

    DDL 移行は、2020 年 10 月 1 日以降に作成されたタスクでのみ利用可能です。

    2023 年 5 月 12 日より前に作成されたタスクで DDL 操作を移行するには、まずソースデータベースにトリガーと関数を作成します。詳細については、「PostgreSQL データベース向けの増分 DDL 移行をトリガーおよび関数を使用して実装する」をご参照ください。

    ソースデータベースで特権アカウントを使用し、マイナーエンジンバージョンが 20210228 以降の場合、以下の DDL 文がサポートされます。

    • CREATE TABLE、DROP TABLE

    • ALTER TABLE（RENAME TABLE、ADD COLUMN、ADD COLUMN DEFAULT、ALTER COLUMN TYPE、DROP COLUMN、ADD CONSTRAINT、ADD CONSTRAINT CHECK、ALTER COLUMN DROP DEFAULT）

    • TRUNCATE TABLE — ソースは PostgreSQL V11 以降であること

    • CREATE INDEX ON TABLE

    DDL 移行の制限事項：

    • 増分移行中は BIT 型のデータを移行できません。

    • DDL 文内の CASCADE および RESTRICT 修飾子は移行できません。

    • SET session_replication_role = replica を実行したセッション内で実行された DDL 文は移行できません。

    • 関数経由で呼び出された DDL 文は移行できません。

    • バッチ送信に DML 文と DDL 文が混在している場合、DDL 文はスキップされます。

    • バッチ送信に移行がサポートされていない DDL 文が含まれている場合、その DDL 文はスキップされます。

    必要な権限

    DTS で使用するデータベースアカウントに、以下の権限を付与します。最小権限の原則に従い、必要な権限を個別に付与できない場合を除き、スーパーユーザアカウントの使用は避けてください。

    データベーススキーマ移行完全なデータ移行増分データ移行
    ソース ApsaraDB RDS for PostgreSQLpg_catalog スキーマに対する USAGE 権限移行対象のオブジェクトに対する SELECTデータベースの所有者である特権アカウント。DML のみの移行で PostgreSQL 9.4 を使用する場合は、REPLICATION 権限のみが必要です。
    宛先 ApsaraDB RDS for PostgreSQL移行対象のオブジェクトに対する CREATE および USAGE 権限スキーマ所有者の権限—

    アカウントを作成し、権限を付与するには、「アカウントを作成する」および「データベースを作成する」をご参照ください。

    制限事項

    移行タスクの設定前に、これらの制限事項を確認してください。無視すると、タスクの失敗やデータの不整合が発生する可能性があります。

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

    制限事項詳細違反時の影響
    主キーまたは一意制約の必須要件テーブルには PRIMARY KEY または一意制約（すべてのフィールドが一意）が必要です。宛先で DTS スキーマ移行を経ずにテーブルが作成されている場合、そのテーブルの PRIMARY KEY または NOT NULL UNIQUE 制約がソーステーブルと一致していることを確認してください。移行対象のテーブルには、PRIMARY KEY、FOREIGN KEY、UNIQUE、または CHECK 制約のいずれかが必要です。宛先に重複レコードが存在する可能性があります。
    データベース名にハイフンを含めないことソースデータベース名にはハイフン (-) を含めることはできません。たとえば、dts-testdata は無効です。移行前にデータベース名を変更してください。移行タスクが開始できません。
    テーブル名の編集時に 1 タスクあたり 1,000 テーブルの制限移行対象としてテーブルを選択し、宛先でテーブル名またはカラム名を変更する必要がある場合、1 タスクで移行できるテーブル数は最大 1,000 です。1,000 を超えるテーブルを移行する場合は、複数のタスクを作成するか、データベース全体を移行してください。要求エラーが発生します。
    一時テーブルおよび内部 C 言語プロシージャの非対応DTS は一時テーブル、内部トリガー、および C 言語で記述された内部プロシージャおよび関数を移行できません。これらのオブジェクトは自動的にスキップされます。
    カスタム型のサポートDTS は COMPOSITE、ENUM、RANGE 型のカスタムパラメーターを移行できます。その他のカスタム型は移行されません。
    wal_level は増分移行で logical である必要あり増分移行を設定する前に、ソースインスタンスで wal_level = logical を設定します。増分移行を開始できません。
    WAL ログ保持期間増分移行のみの場合：先行書き込みログ (WAL) を 24 時間以上保持します。完全移行＋増分移行の場合：WAL ログを少なくとも 7 日間保持します。完全移行完了後は、保持期間を 24 時間以上に短縮できます。保持期間が不足すると、タスクの失敗、データの不整合、またはデータ損失が発生します。
    スキーマ移行または完全移行中の DDL 実行禁止スキーマ移行または完全なデータ移行の実行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。移行タスクが失敗します。
    完全移行のみの際のソースへの書き込み禁止完全なデータ移行のみ（増分移行なし）を実行する場合、移行中にソースデータベースへの書き込みを行わないでください。この制限を回避するには、完全移行＋増分移行を選択してください。同時書き込みによりデータの不整合が発生します。
    増分移行における単一レコードの 256 MB 制限単一の増分変更が 256 MB を超えると、タスクは失敗し、回復できません。タスクを再構成する必要があります。回復不能なタスク失敗が発生します。
    長時間トランザクションによる WAL ログの蓄積ソースデータベース内の長時間トランザクションは、WAL ログのクリーンアップを妨げます。移行前に、長時間トランザクションをコミットまたは終了してください。増分移行中にソースのディスク領域が枯渇する可能性があります。
    メジャーバージョンアップによる実行中タスクの中断移行タスク実行中にソースデータベースでメジャーバージョンアップを実施すると、タスクは失敗し、回復できません。アップグレード後にタスクを再構成してください。回復不能なタスク失敗が発生します。

    その他の制限事項

    制限事項詳細
    プライマリ/セカンダリ スイッチオーバーには論理レプリケーションスロットのフェールオーバーが必要ソースインスタンスでプライマリ/セカンダリ スイッチオーバーを実行する前に、論理レプリケーションスロットフェールオーバー機能を有効化する必要があります。これにより、論理サブスクリプションが中断されるのを防ぎます。「論理レプリケーションスロットフェールオーバー」をご参照ください。
    1 タスクあたり 1 データベース1 タスクでは 1 つのデータベースからのみデータを移行できます。各データベースごとに個別のタスクを作成してください。
    スキーマ継承テーブルなしスキーマ間で継承されたテーブルは移行できません。
    SERIAL フィールドにはシーケンス移行が必要テーブルに SERIAL フィールドがあり、スキーマ移行を選択している場合、シーケンス も選択するか、スキーマ全体を移行してください。これを実行しないと、タスクが失敗します。
    増分移行中の新規テーブル作成増分移行中にスキーマに新規テーブルを追加したり、RENAME を使用してテーブル名を変更したりする場合、そのテーブルにデータを書き込む前に、ALTER TABLE schema.table REPLICA IDENTITY FULL; を実行してください。デッドロックを回避するため、このステートメント実行中にテーブルをロックしないでください。ピーク時を避けて実行してください。
    メタデータの妥当性チェックなしDTS はシーケンスなどのメタデータの妥当性を検証しません。移行後に手動でメタデータを検証してください。
    宛先のシーケンスがソースの最大値から開始されないワークロードを宛先に切り替えた後、新規シーケンスはソースの最大値ではなく初期値から開始されます。カットオーバー前に、宛先のシーケンスの開始値を更新してください。
    DTS が作成する一時テーブルDTS は増分移行をサポートするために、ソースデータベースに以下の 1 時的テーブルを作成します。移行中は削除しないでください。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
    session_replication_role が移行中に replica に設定される宛先アカウントが特権アカウントまたはスーパーユーザロールを持っている場合、DTS は完全移行および増分移行中にセッションレベルで session_replication_role を replica に設定します。アカウントがこれらの権限を持っていない場合、session_replication_role = replica を手動で設定してください。この期間中にソースで実行される Cascade UPDATE または DELETE 操作により、データの不整合が発生する可能性があります。タスクがリリースされた後は、値を origin に戻してください。
    ソースに作成されるハートビートテーブルDTS は、増分移行の遅延を追跡するために、ソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを作成します。
    ソースに作成されるレプリケーションスロットDTS は、ソースに dts_sync_ で始まるプレフィックスを持つレプリケーションスロットを作成します。このスロットは直近 15 分間の増分ログを保持します。DTS インスタンスがリリースされたとき、またはタスクが失敗したときに、スロットは自動的に削除されます。ソースデータベースのパスワードを変更したり、IP ホワイトリストから DTS の IP アドレスを削除したりした場合は、スロットの蓄積を防ぐために手動でスロットを削除してください。プライマリ/セカンダリ スイッチオーバー後は、セカンダリインスタンスにログインしてスロットを削除してください。
    完全移行によるテーブルの断片化完全移行中の同時 INSERT 操作により、宛先のテーブルが断片化します。完全移行完了後、宛先の表領域はソースよりも大きくなります。
    FLOAT および DOUBLE の精度DTS は FLOAT および DOUBLE 値の取得に ROUND(COLUMN, PRECISION) を使用します。精度が指定されていない場合、FLOAT はデフォルトで 38 桁、DOUBLE はデフォルトで 308 桁になります。これらの精度設定が要件を満たすことを確認してください。
    失敗したタスクが再開され、宛先データを上書きする可能性DTS は失敗したタスクを最大 7 日間再試行します。ワークロードを宛先に切り替える前に、失敗したタスクを停止またはリリースするか、REVOKE を実行して、宛先データベース上の DTS アカウントの書き込み権限を削除してください。
    DTS サポートがタスクパラメーターを変更する可能性タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。タスクは再起動され、タスクパラメーター（データベースパラメーターではない）が変更される可能性があります。

    特殊ケース

    移行タスク実行中に、ソース ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントまたはゾーンを変更しないでください。これによりタスクが失敗します。

    移行タスクの設定

    ステップ 1：データ移行ページへ移動

    DTS コンソールまたは DMS コンソールのいずれかを使用します。

    DTS コンソール：

    1. DTS コンソール にログインします。

    2. 左側のナビゲーションウィンドウで、データ移行 をクリックします。

    3. 左上隅で、移行インスタンスを配置するリージョンを選択します。

    DMS コンソール：

    実際の手順は、お客様の DMS コンソールのモードおよびレイアウトによって異なる場合があります。レイアウトの参考として、「シンプルモード」をご参照ください。また、「DMS コンソールのレイアウトをカスタマイズする」方法についてもご確認ください。

    1. DMS コンソール にログインします。

    2. 上部のナビゲーションバーで、Data + AI > DTS (DTS) > データ移行 の順にポインターを移動します。

    3. データ移行タスク の右側にあるドロップダウンリストから、移行インスタンスを配置するリージョンを選択します。

    ステップ 2：タスクの作成

    タスクの作成 をクリックして、タスク設定ページを開きます。

    ステップ 3：ソースおよび宛先データベースの設定

    警告

    ソースおよび宛先データベースを設定した後、ページ上部に表示される 制限事項 を必ず確認してください。このステップをスキップすると、タスクの失敗やデータの不整合が発生する可能性があります。

    ソースおよび宛先データベースの両方について、以下のパラメーターを設定します。

    セクションパラメーター説明
    該当なしタスク名DTS タスクの名前です。DTS が自動的に名前を生成します。タスクを容易に識別できるように、説明的な名前を指定してください。名前は一意である必要はありません。
    ソースデータベース既存の接続を選択インスタンスがすでに DTS に登録されている場合は、ドロップダウンリストから選択してください。DTS が残りのパラメーターを自動入力します。そうでない場合は、以下のパラメーターを設定してください。DMS コンソールでは、DMS データベースインスタンスの選択 ドロップダウンリストからインスタンスを選択してください。
    データベースタイプPostgreSQL を選択します。
    アクセス方法Alibaba Cloud インスタンス を選択します。
    インスタンスリージョンソースインスタンスのリージョンです。
    インスタンス IDソースインスタンスの ID です。
    データベース名移行対象のオブジェクトを含むデータベースの名前です。
    データベースアカウントソースインスタンスのアカウントです。「必要な権限」をご参照ください。
    データベースパスワードデータベースアカウントのパスワードです。
    暗号化[非暗号化]（デフォルト）または [SSL 暗号化] を選択します。SSL 暗号化の場合は、CA 証明書をアップロードし、必要に応じて クライアント証明書、クライアント証明書の秘密鍵、および クライアント証明書の秘密鍵のパスワード もアップロードします。「SSL 暗号化」を参照して、設定手順をご確認ください。
    宛先データベース既存の接続を選択ソースと同様です。
    データベースタイプPostgreSQL を選択します。
    アクセス方法Alibaba Cloud インスタンス を選択します。
    インスタンスリージョン宛先インスタンスのリージョンです。
    インスタンス ID宛先インスタンスの ID です。
    データベース名宛先データベースの名前です。
    データベースアカウント宛先インスタンスのアカウントです。「必要な権限」をご参照ください。
    データベースパスワードデータベースアカウントのパスワードです。
    暗号化ソースと同じオプションです。

    ステップ 4：接続性のテスト

    ページ下部の 接続性のテストと続行 をクリックします。

    DTS サーバーの CIDR ブロックを、ソースデータベースと送信先データベースの両方のセキュリティ設定に追加する必要があります。 詳細については、「DTS サーバーの CIDR ブロックを追加する」をご参照ください。 ソースまたは送信先が Alibaba Cloud Instance 以外のアクセス方法を使用する場合、[DTS サーバーの CIDR ブロック] ダイアログで [テスト接続] をクリックします。

    ステップ 5：移行対象の設定

    オブジェクトの設定 ページで、移行設定を構成します。

    移行タイプ：

    目的選択
    完全移行（ダウンタイムあり）スキーマ移行 および 完全なデータ移行
    オンライン移行（最小限のダウンタイム）スキーマ移行、完全なデータ移行、および 増分データ移行
    増分データ移行 を選択しない場合、データ整合性を確保するため、移行中にソースへのデータ書き込みを行わないでください。スキーマ移行では外部キーが宛先にコピーされます。

    競合するテーブルの処理モード：

    モード動作
    事前チェックとエラー報告オブジェクト名のマッピング移行前に、ソースと送信先で同名のテーブルが存在するかをチェックします。衝突が検出された場合、事前チェックは失敗し、タスクは開始されません。送信先テーブルを削除せずに衝突を解決するには、オブジェクト名マッピングを使用して移行対象のテーブル名を変更してください。詳細については、「」をご参照ください。
    エラーを無視して続行衝突チェックをスキップします。完全移行では、衝突するレコードは移行されず（既存の送信先レコードが保持されます）。増分移行では、衝突するレコードが既存の送信先レコードを上書きします。このモードは注意して使用してください。データの一貫性リスクを引き起こす可能性があります。

    ソースオブジェクト：

    ソースオブジェクト から 1 つ以上のスキーマまたはテーブルを選択し、向右小箭头 をクリックして 選択済みオブジェクト に追加します。

    テーブル（スキーマではなく）を選択した場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトは移行されません。テーブルに SERIAL データ型があり、スキーマ移行が選択されている場合、シーケンス も選択するか、スキーマ全体を移行してください。

    選択済みオブジェクト：

    オブジェクト名マッピングを使用してオブジェクトの名前を変更すると、依存オブジェクトの移行が失敗する可能性があります。

    次へ：高度な設定 をクリックします。

    高度な設定：

    パラメーター説明
    タスクスケジューリング用専用クラスターデフォルトでは、DTS は共有クラスターを使用します。より高い安定性を実現するには、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。
    接続失敗時の再試行時間接続失敗後の DTS の再試行時間です。範囲：10～1,440 分。デフォルト：720。最低でも 30 に設定してください。再試行期間内に DTS が再接続できた場合、タスクは再開します。それ以外の場合は、タスクが失敗します。
    説明

    複数のタスクが同じソースまたは宛先を共有する場合、最も最近設定された再試行時間がすべてのタスクに適用されます。再試行中も DTS の課金は継続します。

    その他の問題発生時の再試行時間DDL または DML 操作失敗後の DTS の再試行時間です。範囲：1～1,440 分。デフォルト：10。10 より大きい値に設定してください。この値は 接続失敗時の再試行時間 より小さくする必要があります。
    完全なデータ移行のスロットリングを有効化ソースおよび宛先への負荷を軽減するために、移行スループットを制限します。ソースデータベースへの QPS、完全データ移行の RPS、および 完全移行のデータ移行速度 (MB/s) を設定します。完全データ移行が選択されている場合にのみ利用可能です。
    増分データ移行のスロットリングを有効化増分移行のスループットを制限します。増分データ移行の RPS および 増分移行のデータ移行速度 (MB/s) を設定します。増分データ移行が選択されている場合にのみ利用可能です。
    環境タグDTS インスタンスを環境別に識別するための任意のタグです。
    ETL の設定移行中にデータを処理するために、ETL (抽出・変換・書き出し) を有効化します。データ処理文を入力するには、[はい] を選択します。「データ移行またはデータ同期タスクでの ETL の設定」をご参照ください。
    モニタリングとアラートタスクの失敗や移行遅延が高くなる場合のアラートを設定します。[はい] を選択し、アラートのしきい値と通知設定を構成します。詳細については、「DTS タスクを作成するときにモニタリングとアラート機能を設定する」をご参照ください。

    [次へ: データ検証] をクリックして、データ検証を設定します。詳細については、「データ検証タスクを設定する」をご参照ください。

    ステップ 6：事前チェックの実行

    次へ：タスク設定の保存と事前チェック をクリックします。

    このタスク設定の API パラメーターをプレビューするには、次へ：タスク設定の保存と事前チェック にカーソルを合わせ、続行する前に OpenAPI パラメーターのプレビュー をクリックします。

    DTS はタスク開始前に事前チェックを実行します。事前チェックが成功するまで、タスクは開始できません。

    • 事前チェック項目のいずれかが失敗した場合、詳細の表示 をクリックして原因を確認し、問題を修正してから 再チェック をクリックします。

    • 項目がアラートをトリガーした場合：

      • 無視できないアラートの場合は、問題を修正して事前チェックを再実行します。

      • 無視できるアラートの場合は、アラートの詳細の確認 をクリックし、その後 無視 > OK > 再チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

    ステップ 7：インスタンスの購入とタスクの開始

    1. 成功率 が 100% になるまで待ち、その後 次へ：インスタンスの購入 をクリックします。

    2. インスタンスの購入 ページで、インスタンスを構成します。

      セクションパラメーター説明
      新規インスタンスクラスリソースグループ移行インスタンスのリソースグループです。デフォルト: デフォルト リソースグループ。Resource Management とは何か？ を参照してください。
      インスタンスクラス移行速度を制御します。データ量と時間要件に基づいて選択してください。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

    3. Data Transmission Service (従量課金) サービス利用規約 を読み、チェックボックスをオンにして同意します。

    4. 購入して開始 をクリックし、確認ダイアログで OK をクリックします。

    タスクは データ移行 ページに表示されます。

    • タスクに増分移行が含まれていない場合、完了時に自動的に停止します。ステータスは 完了 と表示されます。

    • タスクに増分移行が含まれている場合、継続して実行されます。ステータスは 実行中 と表示されます。

    宛先データベースへのカットオーバー

    増分データ移行を使用したオンライン移行では、データ損失を最小限に抑えるために、以下の手順でカットオーバーを行ってください。

    1. 移行遅延の監視。 データ移行 ページで、増分移行タスクの遅延を確認します。遅延が 0 またはほぼ 0 になるまで待ち、宛先がソースとほぼ完全に同期していることを確認します。

    2. ソースへの書き込みの停止。 遅延がほぼ 0 になったら、アプリケーションによるソースデータベースへの書き込みを停止します。

    3. 遅延が 0 になったことの確認。 書き込みを停止した後、増分移行の遅延が 0 になったことを確認します。これにより、すべての変更が宛先にレプリケーションされたことが保証されます。

    4. 宛先のシーケンスの更新。 宛先の新規シーケンスは、ソースのシーケンスの最大値からではなく初期値から開始されます。トラフィックを切り替える前に、ID の競合を回避するために、宛先のすべてのシーケンスの開始値を更新してください。

    5. データの検証。 データ検証を設定している場合、検証結果を確認して、ソースと宛先のデータ整合性を確認します。

    6. アプリケーションの切り替え。 アプリケーションの接続文字列を、宛先インスタンスを指すように更新します。

    7. DTS タスクのリリース。 アプリケーションが宛先で正常に実行されていることを確認した後、DTS 移行タスクを停止およびリリースします。タスクがリリースされると、DTS はソースから一時テーブルおよびレプリケーションスロットを自動的に削除します。

    重要

    DTS は失敗したタスクを最大 7 日間再試行します。ワークロードを宛先に切り替える前に、失敗したタスクを停止またはリリースするか、REVOKE を実行して、宛先データベース上の DTS アカウントの書き込み権限を削除してください。そうしないと、再開された失敗タスクが宛先のデータを上書きする可能性があります。

    次のステップ