Data Transmission Service:自主管理 PostgreSQL データベースから AnalyticDB for PostgreSQL へのデータ移行

ソースデータベースの要件

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

• テーブルにはプライマリキーまたは一意制約が必要であり、すべてのフィールドは一意である必要があります。これらの制約がないテーブルでは、宛先に重複レコードが生成される可能性があります。

• ソースデータベース名にハイフン (-) を含めることはできません。たとえば、dts-testdata は有効な名前ではありません。

• テーブルを移行オブジェクトとして選択し、宛先でテーブルまたはカラムの名前を変更する必要がある場合、1 つの移行タスクでサポートされるテーブルは最大 1,000 です。大規模な移行の場合は、複数のタスクに分割するか、データベースレベルで移行してください。

• 増分移行には、ソースデータベースで wal_level パラメーターを logical に設定する必要があります。

• Write-ahead log (WAL) 保持:

  • 増分データ移行のみ: WAL ログを 24 時間以上保持します。

  • 完全なデータ移行 + 増分データ移行: WAL ログを 少なくとも 7 日間保持します。

  • 完全移行が完了した後、保持期間を 24 時間以上に短縮できます。保持期間が不十分な場合、DTS が WAL ログを読み取れず、タスクの失敗やデータ損失につながる可能性があります。

• 移行中、ソースデータベースで次の操作を避けてください。

  • プライマリ/セカンダリ スイッチオーバー — これにより移行タスクが失敗します。

  • 完全なデータ移行中の DDL 操作 — これにより移行タスクが失敗します。

  • 完全移行のみの移行中にソースにデータを書き込む — これによりデータの不整合が発生します。このリスクを回避するには、増分データ移行をタスクに含めます。

• 増分移行の実行中に、オープンな write-ahead ログを持つ長時間実行されるトランザクションが蓄積され、ソースのディスク領域を使い果たす可能性があります。

ターゲットデータベースの要件

• 完全なデータ移行および増分データ移行中、DTS はセッションレベルで外部キーの制約チェックとカスケード操作を一時的に無効にします。移行中にソースデータベースでカスケード更新または削除操作を実行すると、データの不整合が発生する可能性があります。

• 宛先テーブルは追加最適化 (AO) テーブルにできません。

• DTS は、DATATYPE、SEQUENCE、INDEX、PROCEDURE、FUNCTION、VIEW、OPERATOR、DEFAULT_CONSTRAINT、UK、PK、RULE、DOMAIN、AGGREGATE、EXTENSION、FK、および TRIGGER などのオブジェクトタイプを移行しません。

• 部分テーブル移行にカラムマッピングを使用する場合、一致する宛先カラムがないソースカラムのデータは失われます。

• プライマリキーを持つテーブルの場合: 宛先のプライマリキー列はソースのプライマリキー列と一致する必要があります。

• プライマリキーを持たないテーブルの場合: 宛先のプライマリキー列と分散キーは同じである必要があります。

• 宛先の一意キーには、その分散キーのすべてのカラム (プライマリキー列を含む) が含まれている必要があります。

• DTS は、TimescaleDB 拡張テーブルまたはクロススキーマ継承関係を持つテーブルの移行をサポートしていません。

• DTS は、親テーブルとすべての子テーブルの両方を移行オブジェクトとして含めない限り、パーティションテーブルの移行をサポートしていません。親テーブルにはデータがなく、すべてのデータは子テーブルにあります。

増分移行の動作

REPLICA IDENTITY と UPDATE/DELETE レプリケーション

PostgreSQL は REPLICA IDENTITY を使用して、UPDATE および DELETE イベントの WAL レコードに書き込まれるカラムデータの量を制御します。デフォルト設定 (DEFAULT) では、これらのレコードにプライマリキー列のみが含まれます。DTS が UPDATE または DELETE 操作をレプリケートする場合、宛先で変更を正しく識別して適用するには、すべてのカラムの以前の値が必要です。FULL ID がないと、DTS は UPDATE または DELETE イベントを確実にレプリケートできず、データの不整合につながる可能性があります。

移行タスクに増分データ移行が含まれている場合、データを書き込む前に、移行する各テーブルで次のコマンドを実行してください。これにより、REPLICA IDENTITY が FULL に設定され、UPDATE および DELETE イベントのすべてのカラム値が記録されます。

ALTER TABLE schema.table REPLICA IDENTITY FULL;

schema と table を実際のスキーマ名とテーブル名に置き換えてください。このコマンドはオフピーク時間に実行し、実行中のテーブルロックを避けてください。

このコマンドは次の状況で実行します。

• DTS インスタンスが初めて起動するとき。

• 移行オブジェクトの粒度がスキーマであり、移行中のスキーマで新しいテーブルを作成するか、RENAME コマンドを使用してテーブルを再構築する場合。

関連する事前チェック項目をスキップした場合、DTS はインスタンスの初期化中にこのコマンドを自動的に実行します。

一時テーブルとレプリケーションスロット

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_postgres_heartbeat テーブルは、DTS が増分移行のレイテンシーの精度を確保するために使用するハートビートテーブルです。

DTS は、dts_sync_ プレフィックスを持つレプリケーションスロットも作成し、ストレージ使用量を削減するために 90 分ごとにその既存データをクリアします。移行タスクがリリースされるか失敗した場合、DTS はレプリケーションスロットを自動的にクリアします。ApsaraDB RDS for PostgreSQL インスタンスでプライマリ/セカンダリ スイッチオーバーが実行された場合、セカンダリデータベースにログインしてレプリケーションスロットを手動でクリアしてください。

その他の増分移行に関する注意事項

• 2023 年 5 月 12 日より前に作成されたデータ移行タスクを使用して DDL 操作を移行するには、データ移行タスクを設定する前に、ソースデータベースにトリガーおよび関数を作成して DDL 情報をキャプチャする必要があります。詳細については、「PostgreSQL データベース向けの増分 DDL 移行を実装するためのトリガーおよび関数の使用」をご参照ください。

• 増分データ移行は、BIT データ型のカラムをサポートしていません。

• DTS が UPDATE ステートメントを宛先 AnalyticDB for PostgreSQL インスタンスに書き込む際、自動的に REPLACE INTO に変換します。UPDATE がプライマリキー列をターゲットとする場合、DTS はそれを DELETE + INSERT に変換します。

• DTS は、2020 年 10 月 1 日以降に作成されたタスクに対してのみ、DDL レプリケーションをサポートしています。2023 年 5 月 12 日以前に作成されたタスクの場合、タスクの設定を行う前に、ソースデータベースでトリガーおよび関数を作成して DDL をキャプチャする必要があります。詳細については、「PostgreSQL データベース向けの増分 DDL 移行を実装するためのトリガーおよび関数の使用方法」をご参照ください。

• 増分移行に使用されるデータベースアカウントには、DDL をレプリケートするためのスーパーユーザー権限が必要です。サポートされる 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

• DTS は、CASCADE または RESTRICT を伴う DDL、SET session_replication_role = replica を実行しているセッションからの DDL、関数呼び出しを介して実行される DDL、CREATE SEQUENCE、または DML と DDL が混在するバッチをレプリケートしません。

その他の注意事項

• 1 つの移行タスクは 1 つのデータベースをカバーします。追加のデータベースごとに個別のタスクを作成してください。

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

• 完全なデータ移行では同時 INSERT 操作が使用されるため、宛先テーブルで断片化が発生します。移行後、宛先の表領域はソースよりも大きくなります。

• DTS は ROUND(COLUMN, PRECISION) を使用して FLOAT および DOUBLE カラムを読み取ります。デフォルト精度: 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;
  $$;

  出力には、ソース内のすべてのシーケンスに対する setval ステートメントが含まれています。宛先で移行オブジェクトに適用されるステートメントのみを実行してください。

• DTS インスタンスが失敗した場合、ヘルプデスクは 8 時間以内に回復を試みます。回復には、インスタンスの再起動や DTS インスタンスパラメーター (データベースパラメーターではない) の調整が含まれる場合があります。調整可能なパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。

PostgreSQL 10.1 以降

1. 自主管理 PostgreSQL データベースを実行しているサーバーにログインします。

2. postgresql.conf を開き、次のパラメーターを更新します。設定例:

   • wal_level を logical に設定します。

   • max_wal_senders と max_replication_slots を、現在ソースで使用中のレプリケーションスロットの数と、このソースデータベースを使用する DTS インスタンスの数の合計よりも大きい値に設定します。

   # - Settings -
   
   wal_level = logical			# minimal, replica, or logical
   					# (change requires restart)
   
   ......
   
   # - Sending Server(s) -
   
   # Set these on the master and on any standby that will send replication data.
   
   max_wal_senders = 10		# max number of walsender processes
   				# (change requires restart)
   #wal_keep_segments = 0		# in logfile segments, 16MB each; 0 disables
   #wal_sender_timeout = 60s	# in milliseconds; 0 disables
   
   max_replication_slots = 10	# max number of replication slots
   				# (change requires restart)

   変更を適用するためにデータベースを再起動します。

3. DTS サーバーの CIDR ブロックを pg_hba.conf に追加します。宛先データベースと同じリージョンにある DTS サーバーの CIDR ブロックのみを追加してください。CIDR ブロックのリストについては、「DTS サーバーの IP アドレスをホワイトリストに追加」をご参照ください。pg_hba.conf を編集した後、SELECT pg_reload_conf(); を実行するか、データベースを再起動して変更を適用します。pg_hba.conf の IP アドレスがすでに 0.0.0.0/0 に設定されている場合は、この手順をスキップしてください。

   

4. 宛先 AnalyticDB for PostgreSQL インスタンスに一致するデータベースとスキーマを作成します。

PostgreSQL 9.4.8 から 10.0

PostgreSQL 10.1 より前のバージョンでは、論理レプリケーションをサポートするために ali_decoding プラグインが必要です。これをコンパイルしてインストールするには、次の手順に従ってください。

1. 「PostgreSQL 公式ウェブサイト」から、ご利用のデータベースバージョンに一致する PostgreSQL ソースコードをダウンロードしてください。

2. 次のコマンドを順に実行して、PostgreSQL をコンパイルしてインストールします。

   重要

   - OS バージョンは GNU Compiler Collection (GCC) バージョンと互換性がある必要があります。 - sudo ./configure が readline エラーで失敗した場合は、代わりに sudo ./configure --without-readline を実行してください。 - 他の方法で PostgreSQL をインストールした場合、同じ OS バージョンと GCC バージョンのテスト環境で ali_decoding プラグインをコンパイルしてください。

   sudo ./configure
   sudo make
   sudo make install

3. 「ali_decoding」プラグインをダウンロードします。

4. ali_decoding ディレクトリを、コンパイルされた PostgreSQL インストールの contrib ディレクトリにコピーします。

   

5. ali_decoding ディレクトリ内の Makefile の内容を次のように置き換えます。

   # contrib/ali_decoding/Makefile
   MODULE_big = ali_decoding
   MODULES = ali_decoding
   OBJS    = ali_decoding.o
   
   DATA = ali_decoding--0.0.1.sql ali_decoding--unpackaged--0.0.1.sql
   
   EXTENSION = ali_decoding
   
   NAME = ali_decoding
   
   #subdir = contrib/ali_decoding
   #top_builddir = ../..
   #include $(top_builddir)/src/Makefile.global
   #include $(top_srcdir)/contrib/contrib-global.mk
   
   #PG_CONFIG = /usr/pgsql-9.6/bin/pg_config
   #pgsql_lib_dir := $(shell $(PG_CONFIG) --libdir)
   #PGXS := $(shell $(PG_CONFIG) --pgxs)
   #include $(PGXS)
   
   # Run the following commands to install the ali_decoding plug-in:
   ifdef USE_PGXS
   PG_CONFIG = pg_config
   PGXS := $(shell $(PG_CONFIG) --pgxs)
   include $(PGXS)
   else
   subdir = contrib/ali_decoding
   top_builddir = ../..
   include $(top_builddir)/src/Makefile.global
   include $(top_srcdir)/contrib/contrib-global.mk
   endif

6. ali_decoding ディレクトリから、次のコマンドを順に実行してプラグインをコンパイルしてインストールします。

   sudo make
   sudo make install

7. コンパイルされたファイルを必要なディレクトリにコピーします。

   

8. 宛先 AnalyticDB for PostgreSQL インスタンスに一致するデータベースとスキーマを作成します。

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

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

ステップ 2：ソースデータベースおよびターゲットデータベースの設定

タスクの作成 をクリックし、以下のパラメーターを設定します。

ソースデータベース

ターゲットデータベース

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

接続性のテストと続行 をクリックします。

DTS は両方のデータベースへのアクセスが必要です。DTS サーバーの CIDR ブロックが、ソースおよびターゲットデータベースのセキュリティ設定に追加されていることを確認してください。詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。

ソースまたはターゲットが、Alibaba Cloud インスタンスとしてアクセスされない自己管理データベースである場合、接続性のテスト をクリックし、表示された DTS サーバーの CIDR ブロック ダイアログボックスで操作を完了してください。

ステップ 4：移行オブジェクトの設定

移行タイプと移行対象

パラメーター	説明
移行タイプ	一括移行を行う場合は、スキーマ移行 および 完全移行 を選択します。移行中にソースをオンライン状態で維持する場合は、さらに 増分移行 も選択してください。また、スキーマ移行 をスキップする場合は、宛先データベースおよびテーブルを手動で作成し、選択済みオブジェクト でオブジェクト名マッピングを有効化します。
競合テーブルの処理モード	事前チェックとエラーの報告: 送信先テーブルのいずれかがソーステーブルと同名の場合、事前チェックは失敗します。競合を解決するには、オブジェクト名マッピング を使用します。エラーを無視して続行: 名前の競合チェックをスキップしますが、データの不整合が発生するリスクがあります — 完全移行では、競合するレコードが送信先に保持されます。増分移行では、それらは上書きされます。
同期対象の DDL および DML 操作	増分移行時にレプリケートする SQL 操作を選択します。サポートされる操作については、「増分移行の動作」をご参照ください。データベースまたはテーブルレベルで設定する場合は、選択済みオブジェクト 内の対象オブジェクトを右クリックし、必要な操作を選択します。
ストレージエンジンの種類	デフォルト： Beam。宛先 AnalyticDB for PostgreSQL のマイナーバージョンが v7.0.6.6 以降 であり、かつ スキーマ移行 が選択されている場合にのみ利用可能です。
宛先インスタンスにおけるオブジェクト名の大文字小文字	宛先におけるデータベース名、テーブル名、カラム名の大文字小文字を制御します。デフォルト： DTS デフォルトポリシー宛先インスタンスにおけるオブジェクト名の大文字小文字の指定。詳細については、「」をご参照ください。
ソースオブジェクト	移行対象のオブジェクトを選択し、 をクリックして 選択済みオブジェクト に追加します。カラム、テーブル、またはスキーマ単位で選択できます。テーブルまたはカラムを選択した場合、ビュー、トリガー、ストアドプロシージャは除外されます。
選択済みオブジェクト	単一のオブジェクトの名前を変更するには、そのオブジェクトを右クリックします。複数のオブジェクトの名前を一度に変更するには、[バッチ編集] をクリックします。詳細については、「オブジェクト名のマッピング」をご参照ください。行をフィルターするには、テーブルを右クリックして WHERE 条件を設定します。詳細については、「フィルター条件の設定」をご参照ください。

高度な設定の構成

[次へ: 高度な設定] をクリックし、以下のパラメーターを構成します。

ステップ 6: データ検証の設定 (オプション)

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

プライマリキーと分布列の設定

[次へ: データベースとテーブルフィールドの設定] をクリックして、送信先の AnalyticDB for PostgreSQL インスタンス内の移行対象テーブルについて、プライマリキーと分布列を設定します。

このページは、[スキーマ移行] が選択されている場合にのみ表示されます。プライマリキー列および分布列の詳細については、「データテーブル管理」および「テーブル分布定義」をご参照ください。

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

[次へ: タスク設定を保存して事前チェック] をクリックします。

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

DTS は、移行を開始する前に事前チェックを実行します。タスクは、事前チェックに合格した場合にのみ開始できます。

事前チェックが失敗した場合は、失敗した各項目の横にある [詳細を表示] をクリックし、問題を修正して、[再度事前チェック] をクリックします。

項目にアラートが表示された場合:

• アラートを無視できない場合は、[詳細を表示] をクリックし、問題を修正して、再度事前チェックを実行します。

• アラートを無視できる場合は、[アラート詳細の確認] > [無視] > [OK] をクリックし、その後、[再度事前チェック] をクリックします。

手順 9: インスタンスの購入と起動

1. [成功率] が 100% になるまで待機し、[次へ: インスタンスの購入] をクリックします。

2. [インスタンスの購入] ページで、以下を設定します。

   パラメーター	説明
   リソースグループ	移行インスタンスのリソースグループです。デフォルト値： デフォルトのリソースグループ。
   インスタンスクラス	データ移行インスタンスのインスタンスクラス必要な移行速度に応じて、インスタンスクラスを選択します。詳細については、「」をご参照ください。

3. [Data Transmission Service (従量課金) 利用規約] を読み、同意します。

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

[データ移行] ページで進捗状況を確認します。

スキーマ移行 + 完全なデータ移行タスクは、完了すると自動的に停止します。ステータスは [完了] と表示されます。

増分データ移行タスクは継続的に実行されます。ステータスは [実行中] と表示されます。ワークロードを送信先に切り替える準備ができたら、タスクを手動で停止してください。