Data Transmission Service:セルフマネージド TiDB から ApsaraDB RDS for MySQL への増分移行

前提条件

背景情報

TiDB のバイナリログ形式と実装メカニズムは MySQL とは異なります。移行元データベースへの変更を最小限に抑えながら増分移行を実行するには、Kafka クラスターと TiDB データベースの Pump コンポーネントおよび Drainer コンポーネントをデプロイする必要があります。

Pump コンポーネントは TiDB によって生成されたバイナリログをリアルタイムでキャプチャし、Drainer コンポーネントに提供します。Drainer はこれらのバイナリログをダウンストリームの Kafka クラスターに書き込みます。増分移行中、DTS は Kafka クラスターからこのデータを取得し、移行先の ApsaraDB RDS for MySQL インスタンスにリアルタイムで適用します。

注意事項

• 完全データ移行は、移行元と移行先の両方のデータベースの負荷を増大させ、特に低スペックのインスタンス、遅い SQL クエリ、主キーの欠落、またはデッドロックがある場合に、パフォーマンスの低下や利用できなくなる可能性があります。まずデータベースのパフォーマンスを評価し、オフピーク時間 (CPU 使用率が 30% 未満) に移行を実施してください。

• 移行元テーブルに主キーまたは一意性制約がない場合、移行先でデータが重複する可能性があります。

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

• DTS は移行先インスタンスにデータベースを自動的に作成します。移行元データベース名が ApsaraDB RDS の命名規則に準拠していない場合は、移行タスクを設定する前に、移行先インスタンスに有効な名前でデータベースを作成してください。

  説明

  命名規則と手順については、「データベースの作成」をご参照ください。

• DTS は失敗した移行タスクを自動的に再試行します。スイッチオーバー後に再試行によって移行先のデータが上書きされるのを防ぐため、業務を切り替える前に移行タスクを停止または解放してください。

課金

移行タイプ

事前準備

1. Pump コンポーネントと Drainer コンポーネントをデプロイします。詳細については、「TiDB Binlog クラスターのデプロイ」をご参照ください。

2. Drainer コンポーネントの設定ファイルを変更し、出力を Kafka に設定します。詳細については、「カスタム Kafka コンシューマーの開発」をご参照ください。

3. 次のいずれかの方法を使用して Kafka クラスターを準備します。

   • セルフマネージド Kafka クラスターをデプロイします。詳細については、Apache Kafka 公式ウェブサイトをご覧ください。

     警告

     Kafka クラスターが TiDB からの大容量バイナリログデータを受信できるようにするには、ブローカーコンポーネントの message.max.bytes および replica.fetch.max.bytes パラメータ、およびコンシューマーコンポーネントの fetch.message.max.bytes パラメータの値を増やしてください。詳細については、「Kafka 設定」をご参照ください。

   • ApsaraMQ for Kafka を使用します。詳細については、「ApsaraMQ for Kafka のクイックスタート」をご参照ください。

     説明

     適切な通信を確保し、ネットワークレイテンシーの影響を軽減するために、ApsaraMQ for Kafka インスタンスを移行元データベースサーバーと同じ仮想プライベートクラウド (VPC) にデプロイしてください。

4. セルフマネージド Kafka クラスターまたは ApsaraMQ for Kafka インスタンスにトピックを作成します。

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

操作手順

1. にログインします。 DTSコンソール。

   説明

   データ管理 (DMS) コンソールにリダイレクトされている場合は、にあるアイコンをクリックして、以前のバージョンのDTSコンソールに移動し。

2. 左側のナビゲーションウィンドウで、[データ移行] をクリックします。

3. [移行タスク] ページの上部で、移行先クラスターが存在するリージョンを選択します。

4. ページの右上隅にある [移行タスクの作成] をクリックします。

5. 移行元および移行先データベースを設定します。

   1. タスク名と移行元データベースを設定します。

      

      パラメータ	説明
      タスク名	DTS は自動的にタスク名を生成します。識別しやすいように、わかりやすい名前を指定することを推奨します。名前は一意である必要はありません。
      インスタンスタイプ	ソースデータベースのデプロイ場所を選択します。このトピックでは、[ECS インスタンス内のユーザー作成データベース] を例に説明します。 説明 他のインスタンスタイプについては、先に進む前に必要な「準備」を完了してください。
      インスタンスリージョン	TiDB データベースをホストする ECS インスタンスがデプロイされているリージョンを選択します。
      データベースタイプ	TiDB を選択します。
      ポート	TiDB データベースのサービスポートを入力します。デフォルト値は [4000] です。
      データベースアカウント	TiDB データベースのアカウントを入力します。このアカウントには、SHOW VIEW 権限と、移行対象オブジェクトに対する SELECT 権限が必要です。
      データベースパスワード	データベースアカウントのパスワードを入力します。 重要 ソースデータベース情報を入力した後、データベースのパスワード の横にある 接続テスト をクリックして、情報が正しいかどうかを確認できます。情報が正しい場合、合格 というメッセージが表示されます。メッセージが 失敗 と表示される場合は、失敗 の横にある チェック をクリックし、表示される指示に従ってソースデータベース情報を調整してください。
      増分移行を実行	ビジネス要件に基づいて、増分データ移行を実行するかどうかを選択します。このトピックでは、○ が選択されています。フルデータ移行のみを実行するには、「自己管理型 TiDB データベースから ApsaraDB RDS for MySQL インスタンスにフルデータを移行する」をご参照ください。
      Kafka クラスタータイプ	Kafka クラスターのデプロイ先を選択します。このトピックでは、[ECS インスタンス内のユーザー作成データベース] を例として説明します。セルフマネージド Kafka クラスターが異なるインスタンスタイプを使用している場合は、関連する準備も完了する必要があります。詳細については、「データ移行の準備」をご参照ください。 説明 現在、DTS は ApsaraMQ for Kafka インスタンスの直接選択に対応していません。ApsaraMQ for Kafka インスタンスを使用している場合は、自己管理型 Kafka クラスターとして設定する必要があります。[Express Connect、VPN Gateway、または Smart Access Gateway 経由で接続されたユーザー作成データベース] を選択し、次に ApsaraMQ for Kafka インスタンスが存在する仮想プライベートクラウド (VPC) を選択します。
      インスタンスリージョン	このパラメータは移行元インスタンスと同じリージョンに設定されており、変更できません。
      ECS インスタンス ID	セルフマネージド Kafka クラスターをホストする ECS インスタンスの ID を選択します。
      Kafka ポート	セルフマネージド Kafka クラスターのサービスポートです。デフォルト値は 9092 です。
      Kafka クラスターアカウント	セルフマネージド Kafka クラスターのユーザー名を入力します。認証が有効になっていない場合は、空白のままにできます。
      Kafka クラスターパスワード	ユーザー名のパスワードを入力します。認証が有効になっていない場合は、空白のままにできます。
      トピック	右側の[トピックリストを取得]をクリックし、ドロップダウンリストからトピックを選択します。
      Kafka バージョン	セルフマネージド Kafka クラスターのバージョンを選択します。
      Kafka クラスター接続方法	ビジネス要件とセキュリティ要件に応じて、非暗号化 または SCRAM-SHA-256 を選択します。

   2. 移行先データベースを設定します。

      

      パラメータ	説明
      インスタンスタイプ	RDS インスタンス を選択します。
      インスタンスリージョン	移行先 ApsaraDB RDS for MySQL インスタンスのリージョンを選択します。
      データベースアカウント	移行先 ApsaraDB RDS for MySQL インスタンスのデータベースアカウントを入力します。このアカウントには、移行先データベースに対する読み取りおよび書き込み権限が必要です。アカウントの作成方法と権限の付与方法については、「アカウントの作成」および「アカウント権限の変更」をご参照ください。
      データベースパスワード	データベースアカウントのパスワードを入力します。 重要 ソースデータベース情報を入力した後、データベースのパスワード の横にある 接続テスト をクリックして、情報が正しいかどうかを確認できます。情報が正しい場合、合格 というメッセージが表示されます。メッセージが 失敗 と表示される場合は、失敗 の横にある チェック をクリックし、表示される指示に従ってソースデータベース情報を調整してください。
      接続方法	要件に応じて、非暗号化 または SSL 暗号化 を選択します。SSL 暗号化 を選択した場合は、移行タスクを設定する前に ApsaraDB RDS for MySQL インスタンスの SSL 暗号化を有効にする必要があります。詳細については、「SSL 暗号化の設定」をご参照ください。 重要 暗号化 パラメーターは、中国本土および中国 (香港) リージョンのインスタンスでのみ利用可能です。

6. 設定が完了したら、ページの右下隅にある[ホワイトリストを設定して次へ]をクリックします。

   移行元または移行先が Alibaba Cloud データベースインスタンス (ApsaraDB RDS for MySQL や ApsaraDB for MongoDB など) の場合、DTS は対応するリージョンの DTS サーバーの CIDR ブロックをインスタンスのホワイトリストに自動的に追加します。移行元または移行先が ECS インスタンス上のセルフマネージドデータベースの場合、DTS は CIDR ブロックを ECS インスタンスのセキュリティグループルールに自動的に追加します。また、セルフマネージドデータベースが ECS インスタンスからのアクセスを制限していないことを確認する必要があります。データベースが複数の ECS インスタンスにまたがるクラスターにデプロイされている場合は、残りの各 ECS インスタンスのセキュリティグループルールに DTS サーバーの CIDR ブロックを手動で追加する必要があります。移行元または移行先がオンプレミスデータセンターまたは別のクラウドのデータベースの場合は、アクセスを許可するため、DTS サーバーの CIDR ブロックを手動で追加する必要があります。DTS サーバーの CIDR ブロックの一覧については、「DTS サーバーの CIDR ブロック」をご参照ください。

   警告

   DTS サーバーのパブリック IP アドレスを追加すると、セキュリティリスクが生じる可能性があります。本製品を使用することにより、これらのリスクを認識し、受け入れたものとみなされます。強力なパスワード、ポートの制限、API 認証、定期的なネットワークセグメントのレビュー、または Express Connect、VPN Gateway、Smart Access Gateway を介したプライベート接続などの基本的なセキュリティ対策を実装してください。

7. 移行タイプとオブジェクトを選択します。

   

   パラメータ	説明
   移行タイプ	完全移行のみを実行するには、スキーマ移行 と [フルデータ移行] の両方を選択します。 ダウンタイムを最小限に抑えて移行を実行するには、スキーマ移行、[完全データ移行]、および[増分データ移行]を選択します。本トピックでは、これら 3 つの移行タイプがすべて選択されています。
   移行オブジェクト	[利用可能] ボックスで、移行するオブジェクトをクリックし、 アイコンをクリックして 選択中のオブジェクト ボックスに移動します。 説明 オブジェクトは、データベース、テーブル、または列レベルで選択できます。テーブルまたは列のみを選択すると、ビュー、トリガー、およびストアドプロシージャは除外されます。 デフォルトでは、オブジェクト名は変更されません。移行先でオブジェクト名を変更するには、「オブジェクト名のマッピング」を使用します。 オブジェクト名マッピング機能を使用すると、依存オブジェクトの移行が失敗する可能性があります。
   マップされたオブジェクト名の編集	移行先インスタンスで移行されたオブジェクトの名前を変更するには、オブジェクト名のマッピング機能を使用します。詳細については、「データベース、テーブル、および列のマッピング」をご参照ください。
   接続失敗時の再試行期間	デフォルトでは、DTS は 12 時間接続を再試行します。カスタム期間を指定することもできます。DTS が指定された期間内にデータベースに再接続した場合、タスクは自動的に再開されます。それ以外の場合、タスクは失敗します。 説明 再試行期間中、DTS インスタンスに対して料金が発生します。ビジネスニーズを満たす再試行期間を指定するか、移行元および移行先インスタンスが解放された後、できるだけ早く DTS インスタンスを解放してください。

8. ページの右下隅にある [事前チェック] をクリックします。

   説明

   • データ移行タスクを開始する前に、DTSは事前チェックを実行します。 データ移行タスクは、タスクが事前チェックに合格した後にのみ開始できます。

   • タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にあるアイコンをクリックして詳細を表示できます。

     • 原因に基づいて問題をトラブルシューティングし、事前チェックを再度実行できます。

     • 問題をトラブルシューティングする必要がない場合は、失敗した項目を無視して、再度事前チェックを実行できます。

9. タスクが事前チェックに合格したら、[次へ] をクリックします。

10. [設定の確認] ダイアログボックスで、[チャネル仕様] パラメーターを指定し、[データ送信サービス (従量課金) サービス規約] を選択します。

11. [購入と開始] をクリックして、データ移行タスクを開始します。

    • スキーマ移行とフルデータ移行

      フルデータ移行中は、手動でタスクを停止しないことをお勧めします。 そうしないと、ターゲットデータベースに移行されたデータが不完全になる可能性があります。 データ移行タスクが自動的に停止するまで待つことができます。

    • スキーマ移行、完全データ移行、および増分データ移行

      増分データ移行タスクは自動的に停止しません。 タスクを手動で停止する必要があります。

      重要

      データ移行タスクを手動で停止する適切な時期を選択することを推奨します。 たとえば、オフピーク時やワークロードを移行先クラスターに切り替える前にタスクを停止できます。

      1. 増分データ移行と移行タスクが遅延しませんが移行タスクのプログレスバーに表示されるまで待ちます。 その後、ソースデータベースへのデータの書き込みを数分間停止します。 増分データ移行のレイテンシは、プログレスバーに表示され得る。

      2. 増分データ移行のステータスが [移行タスクは遅延なし] に変わるまで待ちます。 次に、移行タスクを手動で停止します。