このトピックでは、data Transmission Service (DTS) を使用して、自己管理型PostgreSQLデータベースからApsaraDB RDS for PostgreSQLインスタンスに完全データを移行する方法について説明します。 DTS はフルデータ移行と増分データ移行に対応しています。 自己管理型PostgreSQLデータベースからフルデータを移行するには、タスクの設定時にスキーマ移行とフルデータ移行を選択します。
背景情報
このトピックでは、パブリックIPアドレスを持つユーザー作成データベースを例として、フルデータ移行タスクを設定する方法について説明します。 データの一貫性を確保するために、フルデータ移行中は自己管理型PostgreSQLデータベースにデータを書き込まないことを推奨します。 最小限のダウンタイムでデータを移行する方法については、「自己管理型PostgreSQLデータベース (バージョン10.1から13.0) からApsaraDB RDS For PostgreSQLインスタンスへの増分データの移行」および「自己管理型PostgreSQLデータベース (バージョン10.0以前) からApsaraDB RDS for PostgreSQLインスタンスへの増分データの移行」をご参照ください。
自己管理型PostgreSQLデータベースからApsaraDB RDS for PostgreSQLインスタンスに完全なデータを移行するには、論理バックアップファイルを使用してデータを復元することもできます。 詳細については、「pg_restoreを使用して論理バックアップファイルからデータを復元する」をご参照ください。
前提条件
自己管理型PostgreSQLデータベースのバージョンは、9.2、9.3、9.4、9.5、9.6、10.x、11、12、または13です。
ApsaraDB RDS for PostgreSQLインスタンスの使用可能なストレージ容量が、自己管理型PostgreSQLデータベースのデータの合計サイズよりも大きいこと。
自己管理型PostgreSQLデータベースのサービスポートには、インターネット経由でアクセスできます。
制限事項
DTSは、完全データ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これは、データベースサーバの負荷を増加させる可能性がある。 データベースのパフォーマンスが悪い場合、仕様が低い場合、またはデータ量が多い場合、データベースサービスが利用できなくなる可能性があります。 たとえば、ソースデータベースで多数の低速SQLクエリが実行されている場合、テーブルにプライマリキーがない場合、またはターゲットデータベースでデッドロックが発生する場合、DTSは大量の読み取りおよび書き込みリソースを占有します。 データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 たとえば、ソースデータベースとターゲットデータベースのCPU使用率が30% 未満の場合にデータを移行できます。
ソースデータベースの名前にハイフン (-) を含めることはできません。 たとえば、dts-testdataは使用できません。
移行元データベースで移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。
データ移行タスクは、単一のデータベースからのみデータを移行できます。 複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。
データ移行タスクが期待どおりに実行されるようにするには、ApsaraDB RDS for PostgreSQL 11インスタンスでのみプライマリ /セカンダリの切り替えを実行できます。 この場合、
rds_failover_slot_modeパラメーターをsyncに設定する必要があります。 詳細については、「Logical Replication Slot Failover」をご参照ください。警告自己管理型PostgreSQLデータベースまたは11以外のバージョンのApsaraDB RDS for PostgreSQLインスタンスでプライマリ /セカンダリの切り替えを実行すると、データ移行タスクは停止します。
データ移行タスクが失敗した場合、DTSは自動的にタスクを再開します。 ワークロードをターゲットインスタンスに切り替える前に、データ移行タスクを停止またはリリースします。 それ以外の場合、タスクの再開後、ソースデータベースのデータがターゲットインスタンスのデータを上書きします。
ソースデータベースに実行時間の長いトランザクションがあり、タスクに増分データ移行が含まれている場合、実行時間の長いトランザクションが送信される前に生成されたライトアヘッドロギング (WAL) ログはクリアされないため、蓄積され、ソースデータベースのストレージ領域が不十分になります。
移行タイプ
スキーマの移行
DTSは、オブジェクトのスキーマをターゲットデータベースに移行します。 DTSは、テーブル、トリガー、ビュー、シーケンス、関数、ユーザー定義型、ルール、ドメイン、操作、および集計のオブジェクトのスキーマ移行をサポートしています。
フルデータ移行
DTSは、オブジェクトの履歴データを自己管理型PostgreSQLデータベースからApsaraDB RDS for PostgreSQLインスタンスのターゲットデータベースに移行します。
課金
移行タイプ | タスク設定料金 | インターネットトラフィック料金 |
フルデータ移行 | 無料です。 | インターネット経由でAlibaba Cloudからデータが移行された場合にのみ課金されます。 詳細については、「課金の概要」をご参照ください。 |
データベースアカウントに必要な権限
データベース | スキーマ移行 | 完全なデータ移行 |
自己管理型 PostgreSQL データベース | pg_catalogの使用権限 | 移行するオブジェクトに対するSELECT権限 |
ApsaraDB RDS for PostgreSQL インスタンス | 移行するオブジェクトに対するCREATEおよびUSAGE権限 | スキーマ所有者の権限 |
アカウントを作成し、アカウントに権限を付与する方法の詳細については、以下のトピックを参照してください。
自己管理型PostgreSQLデータベース: CREATE USERおよびGRANT
ApsaraDB RDS for PostgreSQLインスタンス:ApsaraDB RDS for PostgreSQLインスタンスにアカウントを作成します
完全データ移行のプロセス
オブジェクト間の依存関係によるデータ移行の失敗を防ぐために、DTSはソースPostgreSQLデータベースのスキーマとデータを次の順序で移行します。
テーブル、ビュー、シーケンス、関数、ユーザー定義型、ルール、ドメイン、操作、および集計のスキーマを移行します。
説明Cプログラミング言語で記述された関数は移行できません。
完全なデータを移行します。
トリガーと外部キーのスキーマを移行します。
準備
移行するオブジェクトのデータベースとスキーマ情報に基づいて、移行先のApsaraDB RDS for PostgreSQLインスタンスにデータベースとスキーマを作成します。 ソースデータベースとターゲットデータベースのスキーマ名は同じである必要があります。 詳細については、以下をご参照ください。 ApsaraDB RDS for PostgreSQLインスタンスにデータベースを作成、 付録: ユーザーとスキーマの管理をご参照ください。
手順
最初にDTSコンソールにログインします。
説明Data Management (DMS) コンソールにリダイレクトされている場合は、右下隅にある
アイコンをクリックして、以前のバージョンのDTSコンソールに移動します。左側のナビゲーションウィンドウで、データ移行 をクリックします。
[移行タスク] ページの上部で、RDSインスタンスが存在するリージョンを選択します。
ページの右上隅にある [移行タスクの作成] をクリックします。
ソースデータベースとターゲットデータベースを設定します。
セクション
パラメーター
説明
N/A
タスク名
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。
移行タイプと移行するオブジェクトを選択します。
設定
説明
移行タイプの選択
フルデータ移行のみを実行するには、[スキーマ移行] と [フルデータ移行] を選択します。
データ移行中のサービスの継続性を確保するには、[スキーマ移行] 、[フルデータ移行] 、および [増分データ移行] を選択します。
この例では、[スキーマ移行] および [フルデータ移行] を選択する必要があります。
説明データの一貫性を確保するために、フルデータ移行中は自己管理型PostgreSQLデータベースにデータを書き込まないことを推奨します。
移行するオブジェクトを選択します。
[使用可能] セクションから1つ以上のオブジェクトを選択し、
アイコンをクリックして、オブジェクトを [選択済み] セクションに追加します。 説明移行するオブジェクトとして、列、テーブル、またはスキーマを選択できます。
既定では、オブジェクトがターゲットデータベースに移行された後、オブジェクトの名前は変更されません。 オブジェクト名マッピング機能を使用して、移行先データベースに移行するオブジェクトの名前を変更できます。 詳細は、オブジェクト名のマッピングをご参照ください。
オブジェクト名マッピング機能を使用してオブジェクトの名前を変更すると、そのオブジェクトに依存する他のオブジェクトの移行に失敗する可能性があります。
オブジェクトの名前を変更するかどうかを指定する
オブジェクト名マッピング機能を使用して、移行先クラスターに移行するオブジェクトの名前を変更できます。 詳細は、オブジェクト名のマッピングをご参照ください。
ソースデータベースまたはターゲットデータベースへの接続が失敗した場合のリトライ時間範囲の指定
デフォルトでは、DTSがソースデータベースとターゲットデータベースへの接続に失敗した場合、DTSは次の12時間以内に再試行します。 業務要件に基づいて再試行時間範囲を指定できます。 指定された時間範囲内にDTSがソースデータベースとターゲットデータベースに再接続された場合、DTSはデータ移行タスクを再開します。 それ以外の場合、データ移行タスクは失敗します。
説明DTSがソースデータベースとターゲットデータベースへの再接続を試みる時間範囲内で、DTSインスタンスに対して課金されます。 業務要件に基づいて再試行時間範囲を指定することを推奨します。 ソースデータベースとターゲットデータベースがリリースされた後、できるだけ早くDTSインスタンスをリリースすることもできます。
[事前チェック] をクリックします。
説明移行タスクが開始される前にプリチェックが実行されます。 移行タスクは、事前チェックが成功した後にのみ開始されます。
事前チェックが失敗した場合は、失敗した各チェック項目の横にある
アイコンをクリックして、関連する詳細を表示します。 指示に従って問題を修正し、事前チェックを再度実行します。
[次へ] をクリックします。
[設定の確認] ダイアログボックスで、[チャネル仕様] パラメーターを設定します。 次に、[データ送信サービス (従量課金) サービス規約] を読み、選択します。
[今すぐ購入してスタート] をクリックして、移行タスクを開始します。
説明フルデータ移行中は、手動でタスクを停止しないことをお勧めします。 そうしないと、ターゲットデータベースに移行されたデータが不完全になる可能性があります。 データ移行タスクが自動的に停止するまで待つことができます。
ワークロードを移行先 RDS インスタンスに切り替えます。
次のステップ
データ移行に使用されるデータベースアカウントには、読み取りおよび書き込み権限があります。 データ移行が完了したら、セキュリティを確保するために、自己管理型PostgreSQLデータベースとApsaraDB RDS for PostgreSQLインスタンスの両方のアカウントを削除する必要があります。