セルフ管理の PostgreSQL から RDS for PostgreSQL への増分データ移行 - DTS

このトピックでは、data Transmission Service (DTS) を使用して、自己管理型PostgreSQLデータベースからApsaraDB RDS for PostgreSQLインスタンスに増分データを移行する方法について説明します。 DTS はフルデータ移行と増分データ移行に対応しています。セルフマネージドPostgreSQLデータベースからAlibaba Cloudにデータを移行する場合、サポートされているすべての移行タイプを選択して、サービスの継続性を確保できます。

このトピックでは、増分データ移行タスクを設定する方法について説明します。この例では、パブリックIPアドレスを持つユーザー作成データベースが選択されています。フルデータ移行を実行する方法については、「セルフマネージド型PostgreSQLデータベースからApsaraDB RDS For PostgreSQLインスタンスへのフルデータ移行」をご参照ください。

前提条件

自己管理型PostgreSQLデータベースはバージョン9.4.8以降で、PostgreSQL 9.5、PostgreSQL 9.6、またはPostgreSQL10.0が含まれます。
ApsaraDB RDS for PostgreSQLインスタンスの使用可能なストレージ容量が、自己管理型PostgreSQLデータベースのデータの合計サイズよりも大きいこと。
自己管理型PostgreSQLデータベースのサービスポートには、インターネット経由でアクセスできます。

使用上の注意

DTSは、完全データ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。これは、データベースサーバの負荷を増加させる可能性がある。データベースのパフォーマンスが悪い場合、仕様が低い場合、またはデータ量が多い場合、データベースサービスが利用できなくなる可能性があります。たとえば、ソースデータベースで多数の低速SQLクエリが実行されている場合、テーブルにプライマリキーがない場合、またはターゲットデータベースでデッドロックが発生する場合、DTSは大量の読み取りおよび書き込みリソースを占有します。データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。オフピーク時にデータを移行することを推奨します。たとえば、ソースデータベースとターゲットデータベースのCPU使用率が30% 未満の場合にデータを移行できます。
移行するオブジェクトとしてスキーマを選択し、スキーマにテーブルを作成するか、RENAMEステートメントを実行して増分データ移行中にテーブルの名前を変更する場合は、テーブルにデータを書き込む前にALTER table schema.table REPLICA IDENTITY FULL; ステートメントを実行する必要があります。
説明
上記のステートメントのschema変数とtable変数を、スキーマ名とテーブル名に置き換えます。
移行元データベースで移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースは重複するデータレコードを含み得る。
データ移行タスクが失敗して停止すると、DTSは自動的にタスクを再開します。ワークロードをターゲットインスタンスに切り替える前に、データ移行タスクを停止またはリリースします。それ以外の場合、タスクの再開後、ソースデータベースのデータがターゲットインスタンスのデータを上書きします。
1つまたは複数の長期トランザクションがソースデータベースに存在し、増分データがデータ移行タスクで移行される場合、ソースデータベースの長期トランザクションがコミットされる前に生成されたライトアヘッドロギング (WAL) ログが蓄積されてもよい。その結果、ソースデータベースのディスク容量が不足する可能性があります。

制限事項

データ移行タスクは、1つのデータベースからのみデータを移行できます。複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。
ソースデータベースの名前にハイフン (-) を含めることはできません。たとえば、dts-testdataは使用できません。
増分データ移行中にソースデータベースでプライマリ /セカンダリの切り替えが実行された場合、送信を再開できません。
同期遅延により、ソースデータベースのプライマリノードとセカンダリノードの間でデータが一致しない場合があります。したがって、データを移行するときは、プライマリノードをデータソースとして使用する必要があります。
説明
オフピーク時にデータを移行することを推奨します。ソースデータベースの読み取りおよび書き込みパフォーマンスに基づいて、フルデータ移行の転送速度を変更できます。詳細については、「フルデータ移行の転送速度の変更」をご参照ください。
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;
$$;
```
データ移行タスクが期待どおりに実行されるようにするには、ApsaraDB RDS for PostgreSQL 11インスタンスでのみプライマリ /セカンダリの切り替えを実行できます。この場合、rds_failover_slot_modeパラメーターをsyncに設定する必要があります。詳細については、「Logical Replication Slot Failover」をご参照ください。
警告
自己管理型PostgreSQLデータベースまたは11以外のバージョンのApsaraDB RDS for PostgreSQLインスタンスでプライマリ /セカンダリの切り替えを実行すると、データ移行タスクは停止します。
増分データ移行中、DTSはINSERT、DELETE、UPDATEなどのDML操作のみを移行します。
説明
DDL操作を移行できるのは、10月1日2020以降に作成されたデータ移行タスクのみです。タスクを構成する前に、DDL情報を取得するには、ソースデータベースでトリガーと関数を作成する必要があります。詳細については、「トリガーと関数を使用してPostgreSQLデータベースの増分DDL移行を実装する」をご参照ください。

課金ルール

移行タイプ	タスク設定料金	インターネットトラフィック料金
スキーマ移行とフルデータ移行	無料です。	インターネット経由でAlibaba Cloudからデータが移行された場合にのみ課金されます。詳細については、「課金の概要」をご参照ください。
増分データ移行	有料。詳細については、「課金の概要」をご参照ください。

データベースアカウントに必要な権限

データベース	スキーマ移行	完全なデータ移行	増分データ移行
自己管理型 PostgreSQL データベース	pg_catalogの使用権限	移行するオブジェクトに対するSELECT権限	スーパーユーザーの権限
ApsaraDB RDS for PostgreSQL インスタンス	移行するオブジェクトに対するCREATEおよびUSAGE権限	スキーマ所有者の権限	スキーマ所有者の権限

データベースアカウントを作成し、アカウントに権限を付与する方法の詳細については、以下のトピックを参照してください。

自己管理型PostgreSQLデータベース: CREATE USERおよびGRANT
ApsaraDB RDS for PostgreSQLインスタンス: アカウントの作成

データ移行プロセス

次の表に、DTSがソースPostgreSQLデータベースのスキーマとデータを移行する方法を示します。このプロセスは、オブジェクト間の依存関係によって引き起こされるデータ移行の失敗を防ぎます。

説明

スキーマ移行、完全データ移行、および増分データ移行の詳細については、「用語」をご参照ください。

ステップ	説明
1. スキーマの移行	DTSは、テーブル、ビュー、シーケンス、関数、ユーザー定義型、ルール、ドメイン、操作、および集計のスキーマをターゲットデータベースに移行します。説明 DTSはプラグインを移行しません。さらに、DTSは、Cプログラミング言語で記述された関数を移行しません。
2. フルデータ移行	DTSは、オブジェクトのすべての履歴データをターゲットデータベースに移行します。
3. スキーマの移行	DTSは、トリガーと外部キーのスキーマをターゲットデータベースに移行します。
4. 増分データ移行	DTSは、オブジェクトの増分データをターゲットデータベースに移行します。増分データ移行により、自己管理型アプリケーションのサービス継続性が保証されます。説明増分データ移行中、DTSはINSERT、DELETE、UPDATEなどのDML操作のみを移行します。増分データ移行は、BITタイプのデータをサポートしていません。

準備

説明

このセクションでは、Linuxでの操作について説明します。

オプション: 公式WebサイトからPostgreSQLソースコードをダウンロードし、ソースコードをコンパイルしてインストールします。
説明
ソースコードを使用して自己管理型PostgreSQLデータベースをインストールする場合は、この手順をスキップします。
1. 自己管理型PostgreSQLデータベースのバージョンに基づいて、PostgreSQL公式Webサイトからソースコードをダウンロードします。
2. 次のコマンドを順番に実行して、ソースコードを構成、コンパイル、およびインストールします。
```
sudo ./configure --prefix=/usr/local/postgresql

sudo make

sudo make install
```
  重要
  - prefixパラメーターの値は、自己管理型PostgreSQLデータベースのインストールパスと同じにすることはできません。
  - PostgreSQLをコンパイルしてインストールする場合、PostgreSQLのOSバージョンはGNUコンパイラコレクション (GCC) のバージョンと一致している必要があります。
  - を実行したときにエラーが発生した場合、スド /configureコマンドを変更すると、エラーメッセージに基づいてコマンドを変更できます。たとえば、エラーメッセージがreadlineライブラリが見つかりません。 -- without-readlineを使用して、readlineサポートを無効にします。に変更することができます。スド /configure -- without-readline.
  - 他の方法でPostgreSQLをインストールする場合は、同じOSバージョンとGCCバージョンのテスト環境でali_decodingプラグインをコンパイルする必要があります。
PostgreSQLのソースコードをコンパイルして新しいali_decodingファイルを生成し、そのファイルを使用してソースの自己管理型PostgreSQLデータベースのali_decodingファイルを置き換えます。
1. DTSが提供するali_decodingプラグインをダウンロードします。
  説明
  Linuxで次のコマンドを実行して、ali_decodingプラグインをダウンロードして解凍することもできます。
```
sudo wget https://github.com/aliyun/rds_dbsync/archive/refs/heads/master.zip
unzip master.zip
```
2. 次のコマンドを実行し、ali_decodingのディレクトリ全体を、コンパイルおよびインストールされているPostgreSQLのcontribディレクトリにコピーします。
```
sudo cp rds_dbsync-master/ali_decoding /tmp/postgresql-9.4.26/contrib/ -r
```
  説明
  上記のコマンドの /tmp/postgresql-9.4.26/contrib/ をPostgreSQLソースコードのディレクトリに置き換えます。
3. 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 source code:
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
```
4. オプション: 自己管理型PostgreSQLデータベースのバージョンが9.4.8〜9.4.26の場合、ali_decoding.cファイルのset_config_option関数からfalseパラメーターを削除する必要があります。次のコードは、変更された関数を示しています。
```
    if (extra_float_digits < 3)
        (void) set_config_option("extra_float_digits", "3",
                PGC_USERSET, PGC_S_SESSION,
                GUC_ACTION_SAVE, true, 0);
```
5. ali_decodingディレクトリに移動し、sudo makeコマンドとsudo make installコマンドを順番に実行して、ali_decodingをコンパイルし、ali_decodingプラグインのインストールに必要なファイルを生成します。
6. 生成されたali_decodingファイルをソースの自己管理型PostgreSQLデータベースにコピーし、次のパスで元のali_decodingファイルを置き換えます。
  説明
  次のパスの /usr/local/postgresqlを、ソースの自己管理型PostgreSQLデータベースのインストールパスに置き換えます。
```
/usr/local/postgresql/lib/ali_decoding.so
/usr/local/postgresql/share/extension/ali_decoding.control 
/usr/local/postgresql/share/extension/ali_decoding--0.0.1.sql 
/usr/local/postgresql/share/extension/ali_decoding--unpackaged--0.0.1.sql
```
移行するオブジェクトに関するデータベースとスキーマ情報に基づいて、移行先ApsaraDB RDS for PostgreSQLインスタンスにデータベースとスキーマを作成します。ソースデータベースとターゲットデータベースのスキーマの名前は同じである必要があります。詳細については、「データベースの作成」および「スキーマを使用したアカウントの管理」をご参照ください。

手順

最初にDTSコンソールにログインします。
説明
データ管理 (DMS) コンソールにリダイレクトされている場合は、のアイコンをクリックして、以前のバージョンのDTSコンソールに移動します。
左側のナビゲーションウィンドウで、データ移行 をクリックします。
[移行タスク] ページの上部で、RDSインスタンスが存在するリージョンを選択します。
ページの右上隅にある [移行タスクの作成] をクリックします。

データ移行タスクのソースデータベースとターゲットデータベースを設定します。 Configure the source and destination databases

セクション	パラメーター	説明
非該当	タスク名	DTSが自動的に生成するタスク名。簡単に識別できるように、ビジネス要件を示す名前を指定することを推奨します。一意の名前を使用する必要はありません。
移行元データベース	インスタンスタイプ	ソースデータベースのアクセス方法。この例では、パブリックIPアドレスを持つユーザー作成データベースが選択されています。説明ソースの自己管理データベースが別のタイプの場合は、自己管理データベースに必要な環境を設定する必要があります。詳細については、「準備の概要」をご参照ください。
	インスタンスリージョン	インスタンスタイプとして [パブリックIPアドレスを持つユーザー作成データベース] を選択した場合、[インスタンスリージョン] パラメーターを設定する必要はありません。説明自己管理型PostgreSQLデータベースにホワイトリストが設定されている場合は、DTSサーバーのCIDRブロックをデータベースのホワイトリストに追加する必要があります。 [インスタンスリージョン] の横にある [DTS IP を取得する] をクリックして、DTS サーバーの CIDR ブロックを取得します。
	データベースエンジン	移行元ディスクのタイプを設定します。 [PostgreSQL] を選択します。
	Hostname or IP Address	自己管理型PostgreSQLデータベースへの接続に使用されるエンドポイント。この例では、パブリック IP アドレスを入力します。
	ポート番号	自己管理型PostgreSQLデータベースのサービスポート番号。デフォルトのポート番号は5432です。
	データベース名	自己管理型PostgreSQLデータベースの名前。
	データベースアカウント	自己管理型PostgreSQLデータベースへのログインに使用されるアカウント。アカウントに必要な権限については、「データベースアカウントに必要な権限」をご参照ください。
	データベースパスワード	データベースアカウントのパスワードを設定します。説明ソースデータベースに関する情報を指定した後、[データベースパスワード] の横にある [接続のテスト] をクリックして、情報が有効かどうかを確認できます。情報が有効な場合は、[合格] メッセージが表示されます。 [失敗] メッセージが表示されたら、[失敗] の横にある [チェック] をクリックします。次に、チェック結果に基づいて情報を変更します。
ターゲットデータベース	インスタンスタイプ	ターゲットデータベースのインスタンスタイプ。 RDS インスタンスを選択します。
	インスタンスリージョン	ターゲットApsaraDB RDS for PostgreSQLインスタンスが存在するリージョン。
	RDS インスタンス ID	ターゲットApsaraDB RDS for PostgreSQLインスタンスのID。
	データベース名	ApsaraDB RDS for PostgreSQLインスタンス内のデータの移行先データベースの名前。名前は、自己管理型PostgreSQLデータベースの名前とは異なる場合があります。説明データ移行タスクを設定する前に、ターゲットApsaraDB RDS for PostgreSQLインスタンスにデータベースとスキーマを作成する必要があります。詳細については、「準備」をご参照ください。
	データベースアカウント	ターゲットApsaraDB RDS for PostgreSQLインスタンスのデータベースアカウント。アカウントに必要な権限については、「データベースアカウントに必要な権限」をご参照ください。
	データベースパスワード	データベースアカウントのパスワードを設定します。説明 RDSインスタンスに関する情報を指定した後、[データベースパスワード] の横にある [接続のテスト] をクリックして、情報が有効かどうかを確認できます。情報が有効な場合は、[合格] メッセージが表示されます。 [失敗] メッセージが表示されたら、[失敗] の横にある [チェック] をクリックします。次に、チェック結果に基づいて情報を変更します。

ページの右下隅にある [ホワイトリストの設定] および [次へ] をクリックします。
警告
DTSサーバーのCIDRブロックがデータベースまたはインスタンスのホワイトリスト、またはECSセキュリティグループルールに自動的または手動で追加されると、セキュリティリスクが発生する可能性があります。したがって、DTSを使用してデータを移行する前に、潜在的なリスクを理解して認識し、次の対策を含む予防策を講じる必要があります。VPNゲートウェイ、またはSmart Access Gateway。

移行タイプと移行するオブジェクトを選択します。 Select the migration types and the objects that you want to migrate

設定	説明
移行タイプの選択	フルデータ移行のみを実行するには、[スキーマ移行] と [フルデータ移行] を選択します。データ移行中のサービスの継続性を確保するには、[スキーマ移行] 、[フルデータ移行] 、および [増分データ移行] を選択します。この例では、3つの移行タイプを選択します。説明増分データ移行が選択されていない場合、フルデータ移行中に自己管理型PostgreSQLデータベースにデータを書き込まないでください。これにより、自己管理型データベースとApsaraDB RDS for PostgreSQLインスタンス間のデータの整合性が確保されます。
移行するオブジェクトの選択	[使用可能] セクションから1つ以上のオブジェクトを選択し、アイコンをクリックして、オブジェクトを [選択済み] セクションに移動します。説明移行するオブジェクトとして、列、テーブル、またはスキーマを選択できます。デフォルトでは、オブジェクトがApsaraDB RDS for PostgreSQLインスタンスに移行された後も、オブジェクトの名前は自己管理型PostgreSQLデータベースの名前と同じままです。オブジェクト名マッピング機能を使用して、移行先のApsaraDB RDS for PostgreSQLインスタンスに移行されるオブジェクトの名前を変更できます。詳細は、オブジェクト名のマッピングをご参照ください。オブジェクト名マッピング機能を使用してオブジェクトの名前を変更すると、そのオブジェクトに依存する他のオブジェクトの移行に失敗する可能性があります。
オブジェクトの名前を変更するかどうかを指定する	オブジェクト名マッピング機能を使用して、移行先インスタンスに移行されるオブジェクトの名前を変更できます。詳細は、オブジェクト名のマッピングをご参照ください。
ソースデータベースまたはターゲットデータベースへの接続が失敗した場合のリトライ時間範囲の指定	デフォルトでは、DTSがソースデータベースまたはターゲットデータベースへの接続に失敗した場合、DTSは次の12時間以内に再試行します。業務要件に基づいて再試行時間範囲を指定できます。 DTSが指定された期間内にソースデータベースとターゲットデータベースに再接続すると、DTSはデータ移行タスクを再開します。それ以外の場合、データ移行タスクは失敗します。説明 DTSが接続を再試行すると、DTSインスタンスに対して課金されます。業務要件に基づいて再試行時間範囲を指定することを推奨します。ソースインスタンスとターゲットインスタンスがリリースされた後、できるだけ早くDTSインスタンスをリリースすることもできます。

[事前チェック] をクリックします。
説明
- 移行タスクが開始される前にプリチェックが実行されます。移行タスクは、事前チェックが成功した後にのみ開始されます。
- 事前チェックが失敗した場合は、失敗した各チェック項目の横にあるアイコンをクリックして、関連する詳細を表示します。指示に従って問題を修正し、事前チェックを再度実行します。
[次へ] をクリックします。
[設定の確認] ダイアログボックスで、[チャネル仕様] パラメーターを設定します。次に、[データ送信サービス (従量課金) サービス規約] を読み、選択します。
[今すぐ購入してスタート] をクリックして、移行タスクを開始します。
- フルデータ移行
  フルデータ移行タスクを手動で停止しないでください。フルデータ移行タスクを手動で停止すると、RDSインスタンスに移行されたデータが不完全になる可能性があります。データ移行タスクが自動的に停止するまで待つことができます。
- 増分データ移行
  増分データ移行タスクは自動的に停止しません。タスクを手動で停止する必要があります。
  説明
  増分データ移行タスクを適切な時点で手動で停止することを推奨します。たとえば、オフピーク時やワークロードをApsaraDB RDS For MySQLインスタンスに切り替える前にタスクを停止できます。
  1. 増分データ移行とデータ移行タスクが遅延しませんがデータ移行タスクのプログレスバーに表示されるまで待ちます。その後、ソースデータベースへのデータの書き込みを数分間停止します。 増分データ移行のレイテンシは、プログレスバーに表示され得る。
  2. 増分データ移行のステータスが [データ移行タスクは遅延なし] に変わるまで待ちます。次に、移行タスクを手動で停止します。
ワークロードをApsaraDB RDS for PostgreSQLインスタンスに切り替えます。

次のステップ

データ移行に使用されるデータベースアカウントには、読み取りおよび書き込み権限があります。データ移行が完了したら、セキュリティを確保するために、自己管理型PostgreSQLデータベースとApsaraDB RDS for PostgreSQLインスタンスの両方のアカウントを削除する必要があります。