Data Transmission Service:PolarDB for PostgreSQL から SelectDB へのデータ移行

ソースデータベース

• 移行対象のテーブルには、プライマリキーまたは NOT NULL の一意なインデックスが必要です。テーブルの状況に応じて以下の点に注意してください。

  • すべてのテーブルにプライマリキーまたは非 NULL の一意インデックスがある場合：テーブルフィールドが一意であることを確認してください。そうでない場合、ターゲットデータベースに重複データが発生する可能性があります。

  • 一部のテーブルにプライマリキーも非 NULL の一意インデックスもない場合：インスタンス構成時に、移行タイプ の下で スキーマ移行 を選択し、その後の データベース、テーブル、カラムの構成 手順で、これらのテーブルの エンジン を duplicate に設定してください。これを実施しないと、移行インスタンスが失敗したり、データが失われる可能性があります。

• スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。移行タスクが失敗します。

• 増分データ移行中は、単一のデータ変更が 256 MB を超えると、移行インスタンスが回復不能な状態で失敗します。その場合は、移行インスタンスを再構成する必要があります。

• 増分移行中に長時間実行されるトランザクションがあると、先行書き込みログ（WAL）が蓄積され、ソースデータベースのストレージ領域が不足する可能性があります。

ターゲットデータベース

• ターゲットの SelectDB インスタンス内のテーブルは、Unique または Duplicate エンジンを使用する必要があります。

• データベース名およびテーブル名は英字で始める必要があります。オブジェクト名マッピング 機能を使用して、英字で始まらないオブジェクトや、中国語文字を含む名前のオブジェクトをリネームしてください。

• 移行中に SelectDB インスタンスにバックエンド（BE）ノードを追加しないでください。タスクが失敗します。移行インスタンスを再起動することで再開できます。

• 移行中にターゲットの SelectDB インスタンスでクラスターを作成しないでください。タスクが失敗します。移行インスタンスを再起動することで再開できます。

移行動作

• 1 つの移行インスタンスでは、1 つのデータベースのみを移行できます。複数のデータベースを移行する場合は、各データベースごとに個別の移行インスタンスを作成してください。

• DTS では、TimescaleDB 拡張テーブルおよびスキーマ間継承テーブルはサポートされていません。

• DTS では、シーケンスなどのメタデータの検証は実施されません。移行後に、メタデータの妥当性を手動で確認してください。

• パーティションテーブルを移行する場合、親テーブルおよびすべての子パーティションを移行対象として含めてください。PostgreSQL のパーティションテーブルの親テーブルにはデータが直接格納されず、すべてのデータは子パーティションに格納されます。子パーティションが欠落すると、データの不整合が発生します。

• マルチテーブルマージのシナリオ（複数のソーステーブルを 1 つのターゲットテーブルに移行）では、すべてのソーステーブルのスキーマが同一である必要があります。

• 複数のカラムを同時に変更する DDL 操作や、同一テーブルに対して連続して DDL 操作を実行することはできません。

• DTS は、増分移行中にソースデータベースに以下のテンポラリテーブルを作成します。これらを削除しないでください。削除するとタスクが失敗します。移行インスタンスがリリースされた後、DTS により自動的に削除されます：public.dts_pg_class、public.dts_pg_attribute、public.dts_pg_type、public.dts_pg_enum、public.dts_postgres_heartbeat、public.dts_ddl_command、public.dts_args_session、および public.aliyun_dts_instance

Unique エンジンの動作

ターゲットテーブルが Unique エンジンを使用する場合、ターゲットテーブル内のすべての一意キーは、ソーステーブルにも存在し、かつ移行対象に含まれている必要があります。含まれていない場合、データの不整合が発生する可能性があります。

Duplicate エンジンの動作

ターゲットテーブルが Duplicate エンジンを使用する場合：

• DTS は UPDATE 文および DELETE 文を INSERT 文に変換します。

• 以下のケースでは、ターゲットに重複行が発生する可能性があります：リトライが発生した場合、移行インスタンスが再起動した場合、または移行開始後に同一行に対して 2 回以上 DML 操作が実行された場合。重複を特定・削除するには、追加カラム（_is_deleted、_version、および _record_id）をご利用ください。

増分データ移行の要件

増分移行対象のテーブルにデータを書き込む前に、ソースデータベースの各テーブルに対して次のコマンドを実行してください。

ALTER TABLE schema.table REPLICA IDENTITY FULL;

schema および table は、実際のスキーマ名およびテーブル名に置き換えてください。このコマンドは、トラフィックが少ない時間帯に実行し、テーブルをロックしないでください。ロックするとデッドロックが発生する可能性があります。

関連する事前チェック項目をスキップした場合、DTS はインスタンス初期化時にこのコマンドを自動的に実行します。これは、インスタンスが初めて実行されるとき、または移行対象の粒度がスキーマに設定されており、RENAME コマンドによって新しいテーブルが作成または再構築されたときに該当します。

レプリケーションスロットの管理

DTS は、増分データのレプリケーションのために、ソースデータベースにプレフィックス dts_sync_ のレプリケーションスロットを作成します。このスロットは、最大 15 分間の増分ログを保持します。

移行タスクが失敗した場合、または移行インスタンスがリリースされた場合、DTS はレプリケーションスロットの自動クリーンアップを試行します。ただし、以下のケースでは手動によるクリーンアップが必要です。

• ソースデータベースアカウントのパスワードは、移行中に変更されました。

• 移行中に、DTS の IP アドレスがホワイトリストから削除されました。

• プライマリ/セカンダリ フェールオーバーが発生した場合：セカンダリデータベースにログインしてクリーンアップを実行してください。

クリーンアップされないレプリケーションスロットは蓄積され、ディスク領域を消費し、最終的にソースデータベースが利用不可になる可能性があります。

ステップ 1：データ移行ページへ移動

以下のいずれかの方法をご利用ください。

ステップ 2：タスクの作成

タスクの作成 をクリックして、タスク構成ページに移動します。

ステップ 3：ソースおよびターゲットデータベースの構成

以下の表に記載されているパラメーターを構成します。

構成を完了したら、ページ下部の 接続テストと続行 をクリックします。

DTS サーバーの IP アドレスは、ソースおよびターゲットデータベースのセキュリティ設定に追加する必要があります。DTS では、これらの IP アドレスを自動的に追加することも、手動で追加することもできます。詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。

ステップ 4：移行オブジェクトの構成

オブジェクトの構成 ページで、以下のパラメーターを設定します。

パラメーター	説明
移行タイプ	移行戦略に応じて移行タイプを選択します。・完全移行（ダウンタイム許容不可）： スキーマ移行 および 完全なデータ移行 を選択します。開始前にソースへのすべての書き込みを停止してください。・オンライン移行（ゼロダウンタイム）： スキーマ移行、完全なデータ移行、および 増分データ移行 を選択します。
競合テーブルの処理モード	・事前チェックとエラー報告：DTS はターゲットに同名のテーブルが存在するかをチェックします。重複が見つかると、事前チェックは失敗します。解決策として、オブジェクト名マッピング 機能を使用してターゲットテーブルの名前を変更してください。・エラーを無視して続行：DTS は重複名チェックをスキップします。 警告 この設定はデータの不整合を引き起こす可能性があります。スキーマが一致する場合、ソースのレコードがプライマリキーが同じターゲットレコードを上書きします。スキーマが異なる場合、移行が失敗したり、不完全なデータが生成される可能性があります。慎重にご利用ください。
ターゲットインスタンスにおけるオブジェクト名の大文字小文字	ターゲットにおけるデータベース名、テーブル名、カラム名の大文字小文字を制御します。デフォルトは DTS デフォルトポリシー宛先インスタンスでのオブジェクト名の大文字と小文字の区別の指定 です。「」をご参照ください。
ソースオブジェクト	移行対象のオブジェクトを選択します。移動するには、 アイコンをクリックします。選択済みオブジェクト に移動します。移行対象の粒度は、スキーマ、テーブル、またはカラムのいずれかです。
選択済みオブジェクト	- オブジェクトを別の名前または送信先にマッピングするには、オブジェクトを右クリックし、[マッピング オプション] を選択します。詳細については、「オブジェクト名のマッピング」をご参照ください。<br>- オブジェクトを削除するには、オブジェクトをクリックしてから、 アイコンをクリックします。<br>- テーブルの bucket_count パラメーターを設定するには（[スキーマ移行] が選択され、移行オブジェクトの粒度がテーブルの場合に利用可能）：テーブルを右クリックし、[パラメーター設定の有効化] を [はい]アラート通知設定 に設定し、値を入力してから、[OK] をクリックします。<br>- SQL 条件で行をフィルターするには、テーブルを右クリックして条件を指定します。詳細については、「フィルター条件の指定」をご参照ください。<br>- 増分移行する SQL 操作を選択するには、オブジェクトを右クリックして操作を選択します。

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

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

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

次へ：データベースおよびテーブルフィールドの構成 をクリックして、ターゲットテーブルの プライマリキーカラム、ディストリビューションキー、および エンジン を設定します。

このステップは、スキーマ移行 が選択されている場合にのみ利用可能です。すべてのテーブルを表示するには、定義ステータス を すべて に設定してください。

プライマリキーカラム は複合プライマリキーでも構いません。プライマリキーカラム から 1 つ以上のカラムを選択して、ディストリビューションキー として使用できます。

プライマリキーまたは UNIQUE 制約のないテーブルについては、エンジン を duplicate に設定してください。設定しないと、移行が失敗したり、データが失われる可能性があります。

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

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

このタスクの API パラメーターをプレビューするには、次へ：タスク設定の保存と事前チェック にカーソルを合わせ、OpenAPI パラメーターのプレビュー をクリックしてください。

DTS は、移行開始前に事前チェックを実行します。事前チェックが失敗した場合：

• 失敗した項目については、詳細の表示 をクリックして結果を分析し、問題を解決した後、再チェック をクリックしてください。

• 警告項目については、警告を無視できる場合は、警告詳細の確認 > 無視 > OK > 再チェック をクリックしてください。ただし、警告を無視するとデータの不整合が発生する可能性があります。

ステップ 8：インスタンスの購入

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

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

   セクション	パラメーター	説明
   新規インスタンスクラス	リソースグループ	移行インスタンスのリソースグループです。デフォルト： デフォルトリソースグループ。「Resource Management とは」をご参照ください。
   	インスタンスクラス	移行速度はインスタンスクラスによって決まります。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

3. Data Transmission Service（従量課金）サービス利用規約 のチェックボックスを読み、選択してください。

4. 購入して開始 をクリックし、確認ダイアログで OK をクリックします。

データ移行 ページで進捗を監視してください。

• 完全移行のみの場合：タスクは完了時に自動的に停止します。ステータスは 完了 と表示されます。

• 増分移行を含む場合：タスクは継続的に実行され、自動的に停止しません。ステータスは 実行中 と表示されます。

完全なデータ移行中は、DTS がソースおよびターゲットデータベースの読み取り／書き込みリソースを消費し、データベースの負荷が高まります。CPU 負荷が両方のデータベースで 30% 未満のトラフィックが少ない時間帯に移行を実行してください。

増分移行の遅延

DTS は、ターゲットの負荷を軽減するためにバッチ同期ポリシーを使用します。デフォルトでは、各同期対象オブジェクトは最大で 5 秒間に 1 回しか書き込まれません。通常の同期遅延は 10 秒以内です。

遅延を低減するには、DTS コンソールで移行インスタンスの selectdb.reservoir.timeout.milliseconds パラメーターを調整してください。有効範囲は 1,000～10,000 ミリ秒です。

バッチ処理時間を短くすると、書き込み頻度が増加し、ターゲットの負荷および応答時間が上昇します。これにより、逆に同期遅延が増加する可能性があります。ターゲットの実際の負荷に基づいて調整してください。

インスタンス障害の回復

移行インスタンスが障害を起こした場合、DTS サポートは 8 時間以内に回復を試みます。回復中、インスタンスが再起動されるか、またはそのパラメーターが調整される場合があります（変更されるのは DTS インスタンスのパラメーターのみであり、データベースのパラメーターは変更されません）。変更可能なパラメーターの一覧については、「インスタンスのパラメーターを変更する」をご参照ください。

トラフィックが少ない時間帯の移行

ソースおよびターゲットデータベースの CPU 負荷がともに 30% 未満のトラフィックが少ない時間帯に移行を実行してください。これにより、本番ワークロードのパフォーマンス劣化リスクを低減できます。