Data Transmission Service:自己管理型PostgreSQLデータベース (バージョン10.1から13.0) からApsaraDB RDS for PostgreSQLインスタンスへの増分データの移行

使用上の注意

• DTSは、完全データ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これは、データベースサーバの負荷を増加させる可能性がある。 データベースのパフォーマンスが悪い場合、仕様が低い場合、またはデータ量が多い場合、データベースサービスが利用できなくなる可能性があります。 たとえば、ソースデータベースで多数の低速SQLクエリが実行されている場合、テーブルにプライマリキーがない場合、またはターゲットデータベースでデッドロックが発生する場合、DTSは大量の読み取りおよび書き込みリソースを占有します。 データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 たとえば、ソースデータベースとターゲットデータベースのCPU使用率が30% 未満の場合にデータを移行できます。

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

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

  説明

  上記のステートメントのschema変数とtable変数を、スキーマ名とテーブル名に置き換えます。

• 増分データ移行のレイテンシを正確にするために、DTSはソースデータベースにハートビートテーブルを追加します。 ハートビートテーブルの名前はdts_postgres_heartbeatです。

• 増分データ移行中、DTSはソースデータベースのレプリケーションスロットを作成します。 レプリケーションスロットの先頭にdts_sync_ があります。 DTSは、ストレージ使用量を減らすために、90分ごとに履歴レプリケーションスロットを自動的にクリアします。

  説明

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

  

• データ移行タスクが期待どおりに実行されるようにするには、ApsaraDB RDS for PostgreSQL 11インスタンスでのみプライマリ /セカンダリの切り替えを実行できます。 この場合、rds_failover_slot_modeパラメーターをsyncに設定する必要があります。 詳細については、「Logical Replication Slot Failover」をご参照ください。

  警告

  自己管理型PostgreSQLデータベースまたは11以外のバージョンのApsaraDB RDS for PostgreSQLインスタンスでプライマリ /セカンダリの切り替えを実行すると、データ移行タスクは停止します。

• データ移行タスクが失敗した場合、DTSは自動的にタスクを再開します。 ワークロードをターゲットインスタンスに切り替える前に、データ移行タスクを停止またはリリースします。 それ以外の場合、タスクの再開後、ソースデータベースのデータがターゲットインスタンスのデータを上書きします。

• ソースデータベースに実行時間の長いトランザクションがあり、タスクに増分データ移行が含まれている場合、実行時間の長いトランザクションが送信される前に生成されたライトアヘッドロギング (WAL) ログはクリアされないため、蓄積され、ソースデータベースのストレージ領域が不十分になります。

制限事項

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

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

• 増分データ移行中にソースデータベースでプライマリ /セカンダリの切り替えが実行された場合、送信を再開できません。

• 同期遅延により、ソースデータベースのプライマリノードとセカンダリノードの間でデータが一致しない場合があります。 したがって、データを移行するときは、プライマリノードをデータソースとして使用する必要があります。

  説明

  オフピーク時にデータを移行することを推奨します。 ソースデータベースの読み取りおよび書き込みパフォーマンスに基づいて、フルデータ移行の転送速度を変更できます。 詳細については、「フルデータ移行の転送速度の変更」をご参照ください。

• 増分データ移行は、BITタイプのデータをサポートしていません。

• 増分データ移行中、DTSはINSERT、DELETE、UPDATEなどのDML操作のみを移行します。

  説明

  DDL操作を移行できるのは、10月1日2020以降に作成されたデータ移行タスクのみです。 タスクを構成する前に、DDL情報を取得するには、ソースデータベースでトリガーと関数を作成する必要があります。 詳細については、「トリガーと関数を使用してPostgreSQLデータベースの増分DDL移行を実装する」をご参照ください。

• ワークロードがターゲットデータベースに切り替えられた後、新しく書き込まれたシーケンスは、ソースデータベースのシーケンスの最大値から増加しません。 したがって、ワークロードをターゲットデータベースに切り替える前に、ソースデータベース内のシーケンスの最大値を照会する必要があります。 次に、クエリされた最大値をターゲットデータベースのシーケンスの開始値として指定する必要があります。

• DTSは、シーケンスなどのメタデータの有効性をチェックしません。 メタデータの有効性を手動で確認する必要があります。

課金ルール

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

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

• 自己管理型PostgreSQLデータベース: CREATE USERおよびGRANT

• ApsaraDB RDS for PostgreSQLインスタンス: アカウントを作成

データ移行プロセス

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

準備

1. 自己管理型PostgreSQLデータベースが存在するサーバーにログオンします。

2. postgresql.conf設定ファイルのwal_levelパラメーターの値をlogicalに設定します。

   

   説明

   増分データ移行を実行する必要がない場合は、この手順をスキップしてください。

3. DTSサーバーのCIDRブロックを、自己管理型PostgreSQLデータベースのpg_hba.conf構成ファイルに追加します。 ターゲットデータベースと同じリージョンにあるDTSサーバーのCIDRブロックのみを追加します。 詳細については、「DTSサーバーのCIDRブロックの追加」をご参照ください。

   説明

   詳細については、「pg_hba.confファイル」をご参照ください。 pg_hba.confファイルのIPアドレスを0.0.0.0/0に設定している場合は、この手順をスキップします。

   

4. オプション: ソースデータベースにトリガーと関数を作成して、DDL情報を取得します。 詳細については、「トリガーと関数を使用してPostgreSQLデータベースの増分DDL移行を実装する」をご参照ください。

   説明

   DDL操作を移行する必要がない場合は、この手順をスキップしてください。

手順

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

   説明

   データ管理 (DMS) コンソールにリダイレクトされている場合は、のアイコンをクリックして、以前のバージョンのDTSコンソールに移動します。

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

3. [移行タスク] ページの上部で、移行先クラスターが存在するリージョンを選択します。

4. ページの右上隅にある [移行タスクの作成] をクリックします。

5. ソースデータベースとターゲットデータベースを設定します。

   

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

6. ページの右下隅にある [ホワイトリストと次への設定] をクリックします。

   警告

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

7. 移行タイプと移行するオブジェクトを選択します。

   

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

8. ページの右下隅にある [事前チェック] をクリックします。

   説明

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

   • タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にあるアイコンをクリックして詳細を表示できます。

     • 原因に基づいて問題をトラブルシューティングし、事前チェックを再度実行できます。

     • 問題をトラブルシューティングする必要がない場合は、失敗した項目を無視して、再度事前チェックを実行できます。

9. タスクが事前チェックに合格したら、[次へ] をクリックします。

10. [設定の確認] ダイアログボックスで、[チャネル仕様] パラメーターを指定し、[データ送信サービス (従量課金) サービス規約] を選択します。

11. [購入と開始] をクリックして、データ移行タスクを開始します。

データ移行タスクの停止

• フルデータ移行

  フルデータ移行中にタスクを手動で停止しないでください。 そうしないと、システムはすべてのデータを移行できません。 移行タスクが自動的に終了するまで待ちます。

• 増分データ移行

  増分データ移行中、タスクは自動的に終了しません。 移行タスクを手動で停止する必要があります。

  1. タスクの進行状況バーに [増分データ移行] と [移行タスクは遅延しません] が表示されるまで待ちます。 その後、ソースデータベースへのデータの書き込みを数分間停止します。 場合によっては、進行状況バーに増分データ移行の遅延時間が表示されます。

  2. 増分データ移行のステータスが移行タスクが遅延なしに変更された後、移行タスクを手動で停止します。