Data Transmission Service (DTS) を使用して、ApsaraDB RDS for PPAS インスタンスから PolarDB for PostgreSQL (Compatible with Oracle) クラスターへ、ダウンタイムを最小限に抑えながらデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしています。すべての移行タイプを選択することで、移行実行中もソースインスタンスがトラフィックを処理し続けます。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
ソースの ApsaraDB RDS for PPAS インスタンス内のデータの合計サイズよりも大きい利用可能なストレージ容量を備えた PolarDB for PostgreSQL (Compatible with Oracle) クラスター。詳細については、「PolarDB for PostgreSQL (Compatible with Oracle) クラスターの作成」をご参照ください。
必要な権限を持つソースの ApsaraDB RDS for PPAS インスタンス用データベースアカウント（「必要な権限」を参照）
送信先のPolarDB for Oracle クラスター用のスキーマ所有者権限を持つデータベースアカウント。詳細については、「データベースアカウントの作成」をご参照ください。
命名に関する考慮事項： ソースインスタンス内のデータベース名、テーブル名、またはフィールド名に大文字が含まれる場合、PolarDB for Oracle クラスターで対応するオブジェクトを作成する際に、その名前を二重引用符 (") で囲む必要があります。
移行タイプ
DTS は本シナリオ向けに 3 種類の移行タイプをサポートしています。ダウンタイムなしのライブ移行を行うには、すべてのタイプを選択してください。
| 移行タイプ | 移行対象 | 備考 |
|---|---|---|
| スキーマ移行 | テーブル、ビュー、シノニム、トリガー、ストアドプロシージャ、ストアドファンクション、パッケージ、およびユーザー定義型のスキーマ | DTS はトリガーをサポートしていません。対象オブジェクトにトリガーが含まれている場合、データの不整合が発生する可能性があります。 |
| 完全なデータ移行 | ソースデータベースからの履歴データ | スキーマ移行および完全なデータ移行中に、移行対象オブジェクトに対して DDL 操作を実行しないでください。 |
| 増分データ移行 | リドログファイルからキャプチャされる継続的な変更：INSERT、UPDATE、DELETE | DDL 操作は同期されません。移行中のサービス継続性を確保します。 |
推奨事項： スキーマ移行、完全なデータ移行、および 増分データ移行 のすべてを同時に選択してください。最初の 2 つだけを選択した場合、データの不整合を防ぐため、移行中はソースインスタンスへの書き込みを行わないでください。
課金
| 移行タイプ | タスク構成料金 | インターネットトラフィック料金 |
|---|---|---|
| スキーマ移行 ＋ 完全なデータ移行 | 無料 | 課金概要Alibaba Cloud からインターネット経由でデータを移行する場合のみ課金されます。詳細については、「」をご参照ください。 |
| 増分データ移行 | 課金済み。「課金概要」を参照してください。 | — |
必要な権限
移行に使用するデータベースアカウントに、以下の権限を付与してください。
| データベース | スキーマ移行 | 完全なデータ移行 | 増分データ移行 |
|---|---|---|---|
| ApsaraDB RDS for PPAS | 読み取り | 読み取り | Superuser ロール |
| PolarDB for Oracle クラスター | スキーマ所有者 | スキーマ所有者 | スキーマ所有者 |
開始前の準備
パフォーマンスへの影響
完全なデータ移行中は DTS がソースデータベースから読み取り、増分移行中は宛先データベースへ書き込みを行います。これにより、両方のデータベースの負荷が増加します。
遅延クエリ、メモリ不足 (OOM) エラー、またはサービス中断のリスクを低減するには、以下の手順を実施してください。
ソースおよび宛先データベースの CPU 使用率がいずれも 30 % 未満であるタイミングで移行を実行してください。
PolarDB for Oracle クラスターの仕様が、ソースの ApsaraDB RDS for PPAS インスタンスの仕様と同等以上であることを確認してください（「仕様マッピング」を参照）。
負荷を高める要因には、ソース側での遅延 SQL クエリ、プライマリキーを持たないテーブル、宛先側でのデッドロックなどがあります。
移行前の制約事項
移行タスクを開始する前に、以下の制約事項を確認してください。これらの要件を満たさない場合、移行は実行できません。
各データ移行タスクは、単一のデータベースからデータを移行します。複数のデータベースを移行する場合は、それぞれのデータベースごとに個別のタスクを作成してください。
ソーステーブルには、すべてのフィールドが一意となる PRIMARY KEY または一意制約 (UNIQUE constraint) が必要です。これらの制約がない場合、宛先データベースに重複レコードが生成される可能性があります。
DTS はスキーマ移行時に外部キーを移行します。完全なデータ移行および増分データ移行中は、DTS がセッションレベルで外部キー制約チェックおよびカスケード操作を一時的に無効化します。この期間中にソース側でカスケード操作または削除操作を実行すると、データの不整合が発生する可能性があります。
運用上の制限事項
移行タスクが実行中の間は、これらのルールに従ってください。
移行対象オブジェクトに対して DDL 操作を実行しないでください。これは、スキーマ移行、完全なデータ移行、および増分データ移行のすべてのフェーズに適用されます。
移行タスクが失敗した場合、DTS は自動的に再開します。ワークロードを宛先クラスターに切り替える前に、タスクを停止またはリリースしてください。そうしないと、再開されたタスクによる書き込みによって、宛先のデータが上書きされる可能性があります。
仕様マッピング
ApsaraDB RDS for PPAS インスタンスと同等以上の仕様を持つ PolarDB for Oracle クラスターを選択してください。移行後に CPU やメモリが不足すると、遅延クエリや OOM エラーが発生する可能性があります。
接続数または IOPS に特定の要件がある場合は、「コンピュートノードの仕様」をご参照ください。
| ApsaraDB RDS for PPAS インスタンス | 推奨される PolarDB for Oracle クラスター | ||
|---|---|---|---|
| インスタンスタイプ | CPU およびメモリ | インスタンスタイプ | CPU およびメモリ |
| rds.ppas.t1.small | 1 コア、1 GB | polar.o.x4.medium | 2 コア、8 GB |
| ppas.x4.small.2 | 1 コア、4 GB | polar.o.x4.medium | 2 コア、8 GB |
| ppas.x4.medium.2 | 2 コア、8 GB | polar.o.x4.medium | 2 コア、8 GB |
| ppas.x8.medium.2 | 2 コア、16 GB | polar.o.x4.large | 4 コア、16 GB |
| ppas.x4.large.2 | 4 コア、16 GB | polar.o.x4.large | 4 コア、16 GB |
| ppas.x8.large.2 | 4 コア、32 GB | polar.o.x4.xlarge | 8 コア、32 GB |
| ppas.x4.xlarge.2 | 8 コア、32 GB | polar.o.x4.xlarge | 8 コア、32 GB |
| ppas.x8.xlarge.2 | 8 コア、64 GB | polar.o.x8.xlarge | 8 コア、64 GB |
| ppas.x4.2xlarge.2 | 16 コア、64 GB | polar.o.x8.2xlarge | 16 コア、128 GB |
| ppas.x8.2xlarge.2 | 16 コア、128 GB | polar.o.x8.2xlarge | 16 コア、128 GB |
| ppas.x4.4xlarge.2 | 32 コア、128 GB | polar.o.x8.4xlarge | 32 コア、256 GB |
| ppas.x8.4xlarge.2 | 32 コア、256 GB | polar.o.x8.4xlarge | 32 コア、256 GB |
| rds.ppas.st.h43 | 60 コア、470 GB | polar.o.x8.8xlarge | 64 コア、512 GB |
移行タスクの作成
ステップ 1：データ移行タスクページを開く
Data Management (DMS) コンソール にログインします。
トップナビゲーションバーで、DTS をクリックします。
左側のナビゲーションウィンドウで、DTS (DTS) > データ移行 を選択します。
新しい DTS コンソールのデータ移行タスクページに直接アクセスすることもできます。コンソールのレイアウトは異なる場合があります。シンプルモードおよびビジネス要件に基づいて DMS コンソールを設定するをご参照ください。
ステップ 2：リージョンの選択
データ移行タスク の横にあるドロップダウンリストから、移行インスタンスが配置されているリージョンを選択します。
新しい DTS コンソールでは、左上隅のリージョンを選択してください。
ステップ 3：ソースおよび宛先データベースの構成
タスクの作成 をクリックし、以下のパラメーターを構成します。
ソースデータベース（ApsaraDB RDS for PPAS）
| パラメーター | 値 |
|---|---|
| タスク名 | DTS が自動的に名前を生成します。タスクを識別しやすい意味のある名前を指定してください。タスク名は一意である必要はありません。 |
| データベースタイプ | PostgreSQL を選択します。ApsaraDB RDS for PPAS は選択肢に表示されません。 |
| アクセス方法 | Express Connect、VPN Gateway、または Smart Access Gateway を選択します。 |
| インスタンスリージョン | ソースの ApsaraDB RDS for PPAS インスタンスが配置されているリージョン。 |
| Alibaba Cloud アカウント間でのデータ複製 | 同一アカウント内での移行の場合は、いいえ を選択します。 |
| 接続済み VPC | ソースインスタンスに接続されている仮想プライベートクラウド (VPC)。 |
| IP アドレス | ApsaraDB RDS for PPAS インスタンスのプライベート IP アドレス。 |
| ポート番号 | ソースインスタンスのサービスポート。デフォルト値：3433。 |
| データベースアカウント | ソースインスタンス用のアカウント。 |
| データベースパスワード | ソースアカウントのパスワード。 |
宛先データベース（PolarDB for Oracle）
| パラメーター | 値 |
|---|---|
| データベースタイプ | PolarDB (Oracle 互換) を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | 宛先の PolarDB for Oracle クラスターが配置されているリージョン。 |
| インスタンス ID | 宛先の PolarDB for Oracle クラスターの ID。 |
| データベース名 | クラスター内の宛先データベースの名前。 |
| データベースアカウント | 宛先クラスター用のアカウント。詳細については、「必要な権限」をご参照ください。 |
| データベースパスワード | 宛先アカウントのパスワード。 |
ステップ 4：接続性のテスト
接続性のテストと続行 をクリックします。
DTS は、自動的にそのサーバーの CIDR ブロックを Alibaba Cloud データベースインスタンスのホワイトリストおよび自己管理データベースをホストする Elastic Compute Service (ECS) インスタンスのセキュリティグループルールに追加します。データセンターまたはサードパーティクラウド内の自己管理データベースの場合、DTS の CIDR ブロックをデータベースのホワイトリストに手動で追加します。詳細については、「DTS サーバーの CIDR ブロックをオンプレミスデータベースのセキュリティ設定に追加する」をご参照ください。ホワイトリストまたはセキュリティグループに DTS の CIDR ブロックを追加すると、セキュリティリスクが生じます。続行する前に、以下の対策を講じてください：強力なパスワードの使用、公開ポートの制限、API 呼び出しの認証、およびホワイトリストルールの定期的な監査。タスクが完了するかリリースされた後は、ホワイトリストから DTS の CIDR ブロックを削除してください。
ステップ 5：オブジェクトの選択と設定の構成
基本設定
| パラメーター | 説明 |
|---|---|
| タスク段階 | ライブ移行の場合は、[スキーマ移行]、[完全データ移行]、および [増分データ移行] を選択します。オフライン移行 (移行中にソースへの書き込みがない場合) の場合は、最初の 2 つの段階のみを選択します。 |
| 競合するテーブルの処理モード | [事前チェックとエラー報告]：宛先にソースと同じ名前のテーブルがすでに存在する場合、事前チェックは失敗します。必要に応じて、オブジェクト名マッピングを使用して、宛先オブジェクトの名前を変更します。[エラーを無視して続行]：このチェックをスキップします。スキーマが異なる場合、一部のカラムのみが移行されるか、タスクが失敗する可能性があります。データ不整合が発生する可能性が高いため、注意してご使用ください。 |
| 宛先インスタンスにおけるオブジェクト名の大文字/小文字の区別 | 宛先のデータベース、テーブル、およびカラム名の大文字/小文字の区別をコントロールします。デフォルト：DTS のデフォルトポリシー。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字/小文字の区別の指定」をご参照ください。 |
| ソースオブジェクト | [ソースオブジェクト] リストからオブジェクトを選択し、右矢印アイコンをクリックして [選択されたオブジェクト] に移動します。 説明 時間フィールドは TIMESTAMP データ型をサポートしています。ソースの時間フィールドの値が |
| 選択されたオブジェクト | 単一のオブジェクトの名前を変更するには、[選択されたオブジェクト] セクションで対象のオブジェクトを右クリックします。複数のオブジェクトを一度に名前変更するには、右上隅の [バッチ編集] をクリックします。詳細については、「オブジェクト名のマッピング」をご参照ください。 説明 オブジェクトの名前を変更すると、依存オブジェクトの移行が失敗する可能性があります。 |
高度な設定
| パラメーター | 説明 |
|---|---|
| アラートの設定 | [いいえ]: アラートなし。[はい]: タスクが失敗した場合や移行遅延がしきい値を超えた場合に通知を受信するため、アラートのしきい値と連絡先を設定します。詳細については、「DTS タスクを作成するときにモニタリングとアラートを設定する」をご参照ください。 |
| 失敗した接続の再試行時間 | DTS が失敗した接続を再試行する時間枠。有効範囲：10～1440 分。デフォルト値：120 分。少なくとも 30 分に設定してください。DTS がこの時間枠内で再接続できた場合、タスクは自動的に再開されます。 説明 複数のタスクが同じソースまたは宛先を共有する場合、最も最近設定された再試行時間枠が優先されます。再試行期間中は DTS インスタンスの課金が発生します。 |
| ETL の構成 | はい: コードエディタにデータ処理ステートメントを入力します。詳しくは、「データ移行またはデータ同期タスクで ETL を設定する」をご参照ください。いいえ: ETL の設定をスキップします。また、「ETL とは？」もご参照ください。 |
ステップ 6：事前チェックの実行
次へ：タスク設定の保存と事前チェック をクリックします。
DTS が自動的に事前チェックを実行します。事前チェックが成功するまで、タスクを開始できません。
項目が失敗した場合：失敗した項目の横にある 詳細の表示 をクリックし、問題を解決してから再度事前チェックを実行してください。
アラートがトリガーされた場合：
無視できないアラートの場合は、問題を解決してから再度事前チェックを実行してください。
無視できるアラートの場合は、アラートの詳細の確認 をクリックし、ダイアログで 無視、次に OK、そして 再チェック をクリックしてください。アラートを無視すると、データの不整合が発生する可能性があります。
ステップ 7：移行インスタンスの購入
事前チェックの成功率达到 100 % になったら、次へ：インスタンスの購入 をクリックします。
「[インスタンスの購入]」ページで、[インスタンスクラス] パラメーターを設定します。インスタンスクラスは移行速度を決定します。詳細については、「データ移行インスタンスの仕様」をご参照ください。
ステップ 8：タスクの開始
Data Transmission Service（従量課金）利用規約 を読み、チェックボックスをオンにしてください。
購入して開始 をクリックします。
移行タスクがタスクリストに表示されます。そこで進捗状況を監視してください。
宛先クラスターへの切り替え
増分データ移行が安定状態（移行遅延がほぼゼロ）に達した後、切り替えを実行できます。ワークロードを切り替える前に、以下の手順を完了してください。
シーケンスの処理。切り替え後、宛先で新しく書き込まれるシーケンスは、ソースのシーケンスの最大値から自動的に継続しません。切り替え前にソースの最大シーケンス値を照会し、それを宛先の初期値として設定してください。ソースの ApsaraDB RDS for PPAS インスタンスで次のコマンドを実行して、
setval文を生成します。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文を宛先の PolarDB for Oracle クラスターで実行します。移行タスクの停止。アプリケーションを宛先にリダイレクトする前に、DTS 移行タスクを停止またはリリースしてください。タスクが実行中のまま、障害発生後に DTS が自動的に再開した場合、ソースからの再開書き込みによって、宛先のデータが上書きされる可能性があります。
アプリケーションの接続先を切り替えます。読み書き分離を有効化し、クラスターへの負荷を軽減するには、PolarDB for Oracle クラスターエンドポイントを使用します。詳細については、「エンドポイントの表示または申請」をご参照ください。
次のステップ
コンピュートノードの仕様：接続数と IOPS 要件に合わせて PolarDB for Oracle クラスターを適切なサイズに設定します
オブジェクト名をマップする — 移行中にオブジェクトの名前を変更して、名前の競合を解決します
課金概要 — DTS の増分移行タスクの料金について理解する