Data Transmission Service:PolarDB-X 1.0 インスタンスから AnalyticDB for PostgreSQL インスタンスへのデータ移行

開始前の確認事項

移行タスクの構成を開始する前に、以下の制約事項を確認してください。

• ソースのストレージタイプ：PolarDB-X 1.0 インスタンスは、ストレージタイプとして ApsaraDB RDS for MySQL を使用する必要があります。PolarDB for MySQL はサポートされていません。

• 帯域幅要件：ソースデータベースが属するサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度に影響が出ます。

• ソーステーブルの制約：移行対象テーブルには、PRIMARY KEY または一意制約（UNIQUE constraint）が設定されている必要があり、すべてのフィールドが一意である必要があります。これらの制約がない場合、宛先データベースに重複レコードが発生する可能性があります。

• テーブル数の上限：テーブルを移行対象として選択し、宛先でテーブル名またはカラム名の変更を行う場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。この上限を超えるタスクはリクエストエラーを返します。1,000 個を超えるテーブルを移行する場合は、複数のタスクに分割するか、代わりにデータベース全体を移行してください。

• 増分移行 — バイナリログの構成：増分データ移行を行う場合、接続された ApsaraDB RDS for MySQL インスタンスの binlog_row_image パラメーターを full に設定してください。このパラメーターが正しく設定されていない場合、事前チェックが失敗し、タスクを開始できません。

• サポートされない宛先テーブルタイプ：宛先テーブルは、append-optimized（AO）テーブルであってはなりません。

• サポートされないデータ型：GEOMETRY、CURVE、SURFACE、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTION の各型は移行できません。

• 読み取り専用インスタンス：PolarDB-X 1.0 のコンピュート層における読み取り専用インスタンスはサポートされていません。

• 分割方法：PolarDB-X 1.0 のストレージリソースは、データベースおよびテーブルの両方において水平分割のみをサポートします。垂直分割はサポートされていません。

移行中

• バイナリログの保持期間：

  • 増分移行のみの場合：バイナリログは 24 時間以上保持する必要があります。

  • 完全移行＋増分移行の場合：バイナリログは少なくとも 7 日間保持する必要があります。

  • 完全なデータ移行が完了後は、保持期間を 24 時間以上に短縮できます。

  重要

  バイナリログの保持期間が要件を満たさない場合、DTS がログを読み取れず、タスクの失敗、データの不整合、またはデータ損失が発生する可能性があります。DTS のサービスレベルアグリーメント（SLA）は、バイナリログの保持期間不足による障害を保証対象外としています。

• ネットワークタイプの変更：移行中に PolarDB-X 1.0 インスタンスのネットワークタイプを変更する場合は、移行タスク内のネットワーク接続設定を適宜更新してください。

• ソースに対する禁止操作：ソースインスタンス（接続された ApsaraDB RDS for MySQL インスタンスを含む）の容量スケーリング、物理データベースおよびテーブルのディストリビューション変更、頻繁に更新されるテーブルの移行、シャードキーの変更、DDL 操作は実行しないでください。これらの操作はタスクの失敗またはデータの不整合を引き起こす可能性があります。

• 書き込みの隔離：移行中は、宛先データベースへの書き込みを DTS 経由でのみ行ってください。他の手段からの書き込みはデータの不整合を引き起こします。

• カラムマッピング：部分的なテーブル移行でカラムマッピングを使用する場合、またはソースと宛先のスキーマが異なる場合、宛先に対応するカラムがないソースカラムのデータは失われます。

• タスクトポロジー：DTS は、接続されたすべての ApsaraDB RDS for MySQL インスタンス間で PolarDB-X 1.0 のデータを移行し、各インスタンスに対してサブタスクを実行します。「タスクトポロジー」でサブタスクのステータスを追跡できます。

• パフォーマンスへの影響：完全なデータ移行では、ソースおよび宛先データベースの読み取りおよび書き込みリソースが使用されるため、データベースの負荷が増加する可能性があります。ピーク時を避けて移行タスクを実行してください。完全なデータ移行後は、同時 INSERT 操作による断片化（fragmentation）の影響で、宛先の表領域（tablespace）がソースより大きくなります。

ステップ 1：ソースおよび宛先データベースの構成

1. Data Management (DMS) コンソール にログインします。

2. 上部のナビゲーションバーで、DTS をクリックします。

3. 左側のナビゲーションウィンドウで、DTS (DTS) ＞ データ移行 を選択します。

   新しい DTS コンソールの「データ移行タスク」ページに直接アクセスすることもできます。手順は、DMS コンソールのモードおよびレイアウトによって若干異なります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトおよびスタイルのカスタマイズ」をご参照ください。

4. データ移行タスク の横にあるドロップダウンリストから、移行対象インスタンスが存在するリージョンを選択します。

   新しい DTS コンソールでは、左上隅でリージョンを選択します。

5. タスクの作成 をクリックします。タスク作成ウィザードページで、ソースおよび宛先データベースを構成します。

   一般設定

   パラメーター	説明
   タスク名	タスクの名前。DTS が自動的に名前を割り当てます。識別しやすいように、意味のある名前を指定してください。名前は一意である必要はありません。

   ソースデータベース

   パラメーター	説明
   既存の DMS データベースインスタンスの選択	（任意）登録済みの DMS データベースインスタンスを選択して、接続パラメーターを自動入力します。既存のインスタンスを選択しない場合は、パラメーターを手動で構成してください。
   データベースタイプ	PolarDB-X 1.0 を選択します。
   アクセス方法	Alibaba Cloud インスタンス を選択します。
   インスタンスリージョン	ソース PolarDB-X 1.0 インスタンスが存在するリージョン。
   Alibaba Cloud アカウント間でのデータ複製	同一アカウント内での移行の場合は、いいえ を選択します。
   インスタンス ID	ソース PolarDB-X 1.0 インスタンスの ID。
   データベースアカウント	ソースインスタンスのアカウント。必要な権限については、「必要な権限」をご参照ください。
   データベースパスワード	データベースアカウントのパスワード。

   宛先データベース

   パラメーター	説明
   既存の DMS データベースインスタンスの選択	（任意）登録済みの DMS データベースインスタンスを選択して、接続パラメーターを自動入力します。既存のインスタンスを選択しない場合は、パラメーターを手動で構成してください。
   データベースタイプ	AnalyticDB for PostgreSQL を選択します。
   アクセス方法	Alibaba Cloud インスタンス を選択します。
   インスタンスリージョン	宛先 AnalyticDB for PostgreSQL インスタンスが存在するリージョン。
   インスタンス ID	宛先 AnalyticDB for PostgreSQL インスタンスの ID。
   データベース名	移行対象オブジェクトを受け取る宛先インスタンス内のデータベース名。
   データベースアカウント	宛先インスタンスのアカウント。必要な権限については、「必要な権限」をご参照ください。
   データベースパスワード	データベースアカウントのパスワード。

6. 接続テストと続行 をクリックします。DTS は、Alibaba Cloud のデータベースインスタンス（例：ApsaraDB RDS for MySQL）の IP アドレスホワイトリスト、または自己管理データベースをホストする Elastic Compute Service (ECS) インスタンスのセキュリティグループルールに、自動的に自身の CIDR ブロックを追加します。複数の ECS インスタンスにまたがる自己管理データベースの場合は、各 ECS インスタンスのセキュリティグループルールに DTS の CIDR ブロックを手動で追加してください。オンプレミスデータベースやサードパーティプロバイダーがホストするデータベースの場合は、データベースの IP アドレスホワイトリストに DTS の CIDR ブロックを手動で追加してください。DTS の CIDR ブロックの完全な一覧については、「オンプレミスデータベースのセキュリティ設定への DTS サーバー CIDR ブロックの追加」をご参照ください。

   警告

   IP アドレスホワイトリストまたはセキュリティグループルールへの DTS CIDR ブロックの追加は、セキュリティリスクを伴います。DTS を使用する前に、アカウントおよびパスワードのセキュリティ強化、公開ポートの制限、API 呼び出しの認証、ホワイトリストおよびセキュリティグループルールの定期的な監査、Express Connect、VPN Gateway、または Smart Access Gateway を介したデータベースと DTS の接続など、予防措置を講じてください。

ステップ 2：移行タイプおよび移行対象の選択

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

移行タイプの選択

DTS では、以下の 3 種類の移行タイプがサポートされています。ご要件に応じて選択してください。

• スキーマ移行＋完全なデータ移行：テーブルスキーマおよび既存のすべてのデータを移行します。移行中にソースデータベースへの書き込みを一時停止できる場合に使用します。

• スキーマ移行＋完全なデータ移行＋増分データ移行：既存のデータを移行し、その後の変更（INSERT、UPDATE、DELETE）を継続的にレプリケートします。ダウンタイムを最小限に抑え、サービス継続性を維持するために使用します。

増分データ移行 を選択しない場合、ソースと宛先のデータ整合性を保つため、移行中にソースデータベースへの書き込みを避けてください。

オブジェクトと設定

パラメーター	説明
移行タイプ	上記の通り、移行タイプを選択します。
競合するテーブルの処理モード	事前チェックおよびエラー報告（デフォルト）：移行開始前に、ソースおよび宛先で同名のテーブルがあるかをチェックします。競合が検出された場合、事前チェックが失敗し、タスクを開始できません。競合するテーブルの名前を変更するには、「オブジェクト名のマッピング」をご利用ください。エラーを無視して続行：同名テーブルの事前チェックをスキップします。スキーマが一致する場合、重複するプライマリキーを持つレコードは移行されません。スキーマが異なる場合、特定のカラムのみが移行されるか、タスクが失敗します。慎重に使用してください。
宛先インスタンスにおけるオブジェクト名の大文字小文字の設定	宛先におけるデータベース名、テーブル名、カラム名の大文字小文字の設定方法を制御します。デフォルト値：「DTS デフォルトポリシー」。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクト	ソースオブジェクト リストからテーブルを選択し、 をクリックして 選択済みオブジェクト リストに追加します。移行対象として選択できるのはテーブルのみです。
選択済みオブジェクト	単一のオブジェクトの名前を変更するには、右クリックして「単一オブジェクトの名前をマッピング」をご利用ください。複数のオブジェクトの名前を変更するには、右上隅の 一括編集 をクリックし、「複数のオブジェクト名を一度にマッピング」をご利用ください。SQL 条件でデータをフィルターするには、オブジェクトを右クリックして条件を指定してください。詳細については、「SQL 条件を使用したデータのフィルタリング」をご参照ください。 説明 オブジェクトの名前を変更すると、依存オブジェクトの移行が失敗する可能性があります。

ステップ 3：高度な設定の構成

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

ステップ 4：（任意）データベースおよびテーブルフィールドの構成

次へ：データベースおよびテーブルフィールドの構成 をクリックして、AnalyticDB for PostgreSQL インスタンスに移行するテーブルの タイプ、プライマリキー列、および 分散キー を指定します。

このステップは、スキーマ移行 が選択されている場合にのみ利用可能です。定義ステータス を すべて に設定すると、すべてのテーブルを表示および変更できます。複合プライマリキーの場合、1 つ以上のプライマリキー列を分散キー列としても指定する必要があります。詳細については、「テーブルの管理」および「テーブル分散の定義」をご参照ください。

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

次へ：タスク設定の保存および事前チェック をクリックします。

このタスクをプログラムで構成するための API パラメーターを表示するには、次へ：タスク設定の保存および事前チェック の上にポインターを合わせ、OpenAPI パラメーターのプレビュー をクリックします。

DTS は、移行開始前に事前チェックを実行します。事前チェックが完了するまでお待ちください。

• 事前チェックが成功した場合は、次のステップに進んでください。

• 事前チェックが失敗した場合は、失敗項目の横にある 詳細の表示 をクリックし、エラーメッセージに基づいて問題を修正した後、再事前チェック をクリックしてください。

• 事前チェックアラートが表示された場合：

  • 無視できないアラートの場合は、詳細の表示 をクリックし、問題を修正した後、再度事前チェックを実行してください。

  • 無視できるアラートの場合は、アラートの詳細の確認 をクリックし、詳細表示ダイアログボックスで 無視 をクリックし、OK をクリックした後、再事前チェック をクリックしてください。

  警告

  事前チェックアラートを無視すると、データの不整合やワークロードへのその他のリスクが発生する可能性があります。

ステップ 6：移行インスタンスの購入および開始

1. 成功率 が 100% に達したら、次へ：インスタンスの購入 をクリックします。

2. インスタンスの購入 ページで、インスタンスクラスを構成します。

   パラメーター	説明
   リソースグループ	移行インスタンスのリソースグループ。デフォルト：「デフォルトリソースグループ」。詳細については、「Resource Management とは
   インスタンスクラス	インスタンスクラスは移行速度を決定します。ワークロードに応じてクラスを選択してください。詳細については、「データ移行インスタンスの仕様」をご参照ください。

3. Data Transmission Service（従量課金）サービス利用規約 を読み、同意する場合はチェックボックスをオンにしてください。

4. 購入および開始 をクリックします。移行タスクが開始され、タスクリストに表示されます。