Data Transmission Service:TiDB データベース（自己管理）から PolarDB for MySQL クラスターへのデータ移行

ソースデータベースの制限事項

• 送信帯域幅：ソースデータベースサーバーには十分な送信帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。

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

• 1 タスクあたりのテーブル数制限：列レベルの編集（例：列名の変更）を伴う個別テーブルの移行では、1 タスクあたり最大 1,000 個のテーブルをサポートします。1,000 個を超えるテーブルを移行する場合は、複数のタスクに分割するか、データベース全体を移行してください。

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

• プレフィックスインデックス：TiDB のメタデータにはプレフィックスインデックスの長さが格納されません。移行後、プレフィックスインデックスの長さが失われ、インスタンスが起動しなくなる可能性があります。移行後に影響を受けるテーブルのプレフィックスインデックス長を手動で修正してください。

• 増分データの要件：増分データ移行には Kafka クラスターおよび TiDB Binlog または TiCDC コンポーネントが必要です。詳細については、「（任意）増分データ収集のセットアップ」をご参照ください。

その他の制限事項

• 増分データパーティション：DTS は Kafka トピック内のパーティション ID 0 のみから増分データを読み取ります。

• 位置情報の初期化：増分移行を含むタスクを作成した後は、直ちにソースデータベースで変更またはテストデータの挿入を行い、位置情報を更新してください。これを怠ると、過度の遅延によりタスクが失敗する可能性があります。

• 4 バイト文字：データに稀な文字や絵文字（4 バイト文字）が含まれる場合、宛先データベースおよびテーブルは UTF8mb4 文字セットを使用する必要があります。DTS のスキーマ移行を利用する場合は、宛先データベースの character_set_server インスタンスパラメーターも UTF8mb4 に設定してください。

• 完全移行時のリソース使用量：完全なデータ移行は、ソースおよび宛先データベースの読み取りおよび書き込みリソースを消費し、負荷を高めます。移行を開始する前にデータベースパフォーマンスを評価し、非ピーク時間帯（例：CPU 負荷が 30 % 未満の時間帯）に完全移行を実行してください。

• 完全移行後の表領域サイズ：完全なデータ移行中の同時 INSERT 操作により、テーブルの断片化が発生します。移行完了後、宛先データベースの表領域はソースデータベースよりも大きくなります。

• 移行中の宛先への書き込み：移行中に宛先データベースへ書き込むと、ソースと宛先の間でデータの不整合が発生する可能性があります。

• FLOAT および DOUBLE の精度：DTS は FLOAT および DOUBLE 値の読み取りに ROUND(COLUMN,PRECISION) を使用します。FLOAT のデフォルト精度は 38 桁、DOUBLE のデフォルト精度は 308 桁です。これらの精度設定が要件を満たすことを確認してください。

• 自動再開：DTS は過去 7 日以内に失敗したタスクを自動的に再開しようと試行します。ワークロードを宛先インスタンスへ切り替える前に、DTS タスクを停止または解放するか、宛先インスタンス上の DTS アカウントから書き込み権限を削除するために REVOKE を実行してください。

• DDL 失敗: ターゲットデータベースで DDL 文が失敗した場合、DTS タスクは実行を継続します。失敗した DDL 文はタスクログで確認できます。「タスクログの表示」をご参照ください。

• テクニカルサポートによる対応: DTS タスクが失敗した場合、テクニカルサポートは 8 時間以内にその復旧を試みます。復旧中、タスクが再起動される場合があり、タスクパラメーター（データベースパラメーターを除く）が変更される場合があります。変更される可能性のあるパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。

ステップ 1：Kafka クラスターのセットアップ

以下のいずれかのオプションを選択してください。

• 自己管理 Kafka クラスター：Apache Kafka のドキュメントに従って Apache Kafka をデプロイします。

  警告

  TiDB のバイナリログデータのボリュームに対応するため、Kafka 構成ファイルの以下のパラメーターを増加させてください。「Kafka 構成」をご参照ください。

  コンポーネント	パラメーター	理由
  Broker	message.max.bytes	Broker が受け入れるメッセージの最大サイズを設定します。TiDB のバイナリログイベントは大規模になる可能性があるため、デフォルト値では書き込み失敗が発生します。
  Broker	replica.fetch.max.bytes	フォロワーが 1 回のリクエストでフェッチできる最大バイト数を設定します。message.max.bytes 以上に設定する必要があります。これにより、巨大メッセージのレプリケーションが可能になります。
  Consumer	fetch.message.max.bytes	コンシューマーがパーティションごとにフェッチする最大バイト数を設定します。message.max.bytes 以上に設定する必要があります。これにより、DTS が完全なイベントを読み取ることができます。

• Message Queue for Apache Kafka：Alibaba Cloud のマネージド Kafka サービスを利用します。「はじめに」をご参照ください。

  Kafka クラスターのネットワーク遅延を低減し、安定した接続性を確保するため、Message Queue for Apache Kafka インスタンスをソースデータベースサーバーと同じ仮想プライベートクラウド（VPC）内にデプロイしてください。

ステップ 2：Kafka トピックの作成

Kafka クラスターまたは Message Queue for Apache Kafka インスタンス内にトピックを作成します。

ステップ 3：TiDB Binlog または TiCDC の構成

環境に応じて、以下のいずれかの方法を選択してください。

<details> <summary>オプション A：TiDB Binlog</summary>

ネットワーク遅延の影響を最小限に抑えるため、Pump コンポーネント、Drainer コンポーネント、および Kafka クラスターを、ソース TiDB データベースサーバーと同じ内部ネットワーク上にあるサーバーにデプロイしてください。

1. Pump および Drainer コンポーネントをデプロイします。「TiDB Binlog クラスターのデプロイ」をご参照ください。

2. Drainer の構成ファイルを編集し、出力先を Kafka に設定します。「Kafka カスタム開発」および「Kafka カスタム開発」をご参照ください。

3. TiDB データベースサーバーから Kafka クラスターへの接続を確認します。

4. DTS サーバーの CIDR ブロックを TiDB データベースのホワイトリストに追加します。詳細については、「DTS サーバーの CIDR ブロックを追加する」をご参照ください。

</details>

<details> <summary>オプション B：TiCDC</summary>

1. TiCDC コンポーネントをインストールします。TiUP を使用して、既存の TiDB クラスターに TiCDC を追加またはスケールアウトします。「TiCDC のデプロイ」および「」をご参照ください。

2. tiup cdc cli changefeed create \ コマンドを最初のコマンドとして使用して、増分データを Kafka へレプリケートします。「Kafka へのデータレプリケーション」および「」をご参照ください。

3. TiDB データベースサーバーから Kafka クラスターへの接続を確認します。

</details>

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

以下のいずれかの方法を使用してください。

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

1. タスクの作成 をクリックします。

2. タスク構成ページで、ソースおよび宛先データベースを構成します。

ソースデータベースのパラメーター

宛先データベースのパラメーター

ステップ 3：接続のテスト

ページ下部の 接続のテストと続行 をクリックします。DTS サーバーの CIDR ブロック ダイアログボックスで、接続のテスト をクリックします。

DTS サーバーの CIDR ブロックが、ソースおよびターゲットデータベースのセキュリティ設定に追加されていることを確認してください。詳細については、「DTS サーバーの CIDR ブロックをセキュリティ設定に追加する」をご参照ください。

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

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

移行タイプおよび競合処理

オブジェクトの選択

パラメーター	説明
移行元オブジェクト	移行するテーブルまたはデータベースを選択します。 をクリックして、選択したオブジェクトを 選択済みオブジェクト に移動します。
選択済みオブジェクト	オブジェクトを右クリックして名前を変更できます。「単一オブジェクトの名前をマップする」をご参照ください。一括編集 をクリックすると、複数のオブジェクトを一度に名前変更できます。「複数のオブジェクト名を一度にマップする」をご参照ください。テーブルを右クリックして、WHERE フィルター条件を設定できます。 説明 オブジェクトの名前を変更すると、依存オブジェクトが移行されなくなる場合があります。 説明

1. 次へ：高度な設定 をクリックします。

高度な設定

1. データ検証を設定するには、[次のステップ：データ検証] をクリックします。詳細については、「データ検証タスクを設定する」をご参照ください。

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

1. このタスクの API パラメーターをプレビューするには、次へ：タスク設定の保存と事前チェック の上にポインターを置き、OpenAPI パラメーターのプレビュー をクリックします。

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

DTS は移行を開始する前に事前チェックを実行します。事前チェックが成功した場合にのみ、タスクが開始されます。

事前チェックで失敗した項目については、詳細の表示 をクリックして原因を診断し、問題を解決した後、再度事前チェックを実行してください。

警告項目については、無視できない警告の場合は問題を修正して事前チェックを再実行してください。無視可能な警告の場合は、警告の詳細の確認 をクリックし、その後 無視 > OK > 再び事前チェック をクリックしてください。

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

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

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

1. Data Transmission Service（従量課金）利用規約 のチェックボックスをオンにして、規約を読み、同意してください。

2. 購入して開始 をクリックし、その後 OK をクリックします。

タスクは データ移行 ページに表示されます。そこで進行状況を監視してください。