📣
TiDB Cloud Premium はパブリックプレビュー中です。エンタープライズワークロード向けの無制限のスケーリング、即時の弾力性、高度なセキュリティを提供します。このページは自動翻訳されたものです。原文はこちらからご覧ください。
AI
開発者
ベストプラクティス
API

TiDB Data Migrationをv1.0.xからv2.0+へ手動でアップグレードする

このドキュメントでは、TiDB DMツールをv1.0.xからv2.0+に手動でアップグレードする方法について説明します。主な手順は、v1.0.xのグローバルチェックポイント情報を使用して、v2.0+クラスタで新しいデータ移行タスクを開始することです。

TiDB DM ツールを v1.0.x から v2.0+ に自動的にアップグレードする方法については、 TiUPを使用して、DM-Ansibleによってデプロイされた1.0クラスターを自動的にインポートする。

手動アップグレードの手順は以下のとおりです。

ステップ1：v2.0+設定ファイルを準備する

バージョン2.0以降で準備された構成ファイルには、上流データベースの構成ファイルとデータ移行タスクの構成ファイルが含まれています。

アップストリームデータベース構成ファイル

v2.0以降では、アップストリームデータベース構成ファイルがDM-workerのプロセス構成から分離されているため、 v1.0.x DM-worker設定をベースにしたソース構成を取得する必要があります。

DM-Ansibleによってデプロイされたv1.0.xクラスターをアップグレードする

v1.0.x DM クラスターが DM-Ansible によってデプロイされ、 dm_worker_serversファイルに次のinventory.ini設定が含まれていると仮定します。

[dm_master_servers]
dm_worker1 ansible_host=172.16.10.72 server_id=101 source_id="mysql-replica-01" mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306
dm_worker2 ansible_host=172.16.10.73 server_id=102 source_id="mysql-replica-02" mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306

そうすれば、以下の2つのソース設定ファイルに変換できます。

# The source configuration corresponding to the original dm_worker1. For example, it is named as source1.yaml.
server-id: 101                                   # Corresponds to the original `server_id`.
source-id: "mysql-replica-01"                    # Corresponds to the original `source_id`.
from:
  host: "172.16.10.81"                           # Corresponds to the original `mysql_host`.
  port: 3306                                     # Corresponds to the original `mysql_port`.
  user: "root"                                   # Corresponds to the original `mysql_user`.
  password: "VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU="   # Corresponds to the original `mysql_password`.

# The source configuration corresponding to the original dm_worker2. For example, it is named as source2.yaml.
server-id: 102                                   # Corresponds to the original `server_id`.
source-id: "mysql-replica-02"                    # Corresponds to the original `source_id`.
from:
  host: "172.16.10.82"                           # Corresponds to the original `mysql_host`.
  port: 3306                                     # Corresponds to the original `mysql_port`.
  user: "root"                                   # Corresponds to the original `mysql_user`.
  password: "VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU="   # Corresponds to the original `mysql_password`.

バイナリによってデプロイされたv1.0.xクラスターをアップグレードする

v1.0.x DM クラスターがバイナリによってデプロイされ、対応する DM-worker 構成が以下のようになっていると仮定します。

log-level = "info"
log-file = "dm-worker.log"
worker-addr = ":8262"
server-id = 101
source-id = "mysql-replica-01"
flavor = "mysql"
[from]
host = "172.16.10.81"
user = "root"
password = "VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU="
port = 3306

そうすれば、以下のソース設定ファイルに変換できます。

server-id: 101                                   # Corresponds to the original `server-id`.
source-id: "mysql-replica-01"                    # Corresponds to the original `source-id`.
flavor: "mysql"                                  # Corresponds to the original `flavor`.
from:
  host: "172.16.10.81"                           # Corresponds to the original `from.host`.
  port: 3306                                     # Corresponds to the original `from.port`.
  user: "root"                                   # Corresponds to the original `from.user`.
  password: "VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU="   # Corresponds to the original `from.password`.

データ移行タスク構成ファイル

データ移行タスク構成ガイドについては、v2.0+ は基本的に v1.0.x と互換性があります。 v1.0.x の設定を直接コピーできます。

ステップ2：v2.0+クラスターをデプロイ

TiUPを使用する必要なノード数に応じて新しい v2.0+ クラスターをデプロイします。

ステップ3：v1.0.xクラスタを停止します

元の v1.0.x クラスターが DM-Ansible によってデプロイされている場合は、 DM-Ansibleを使用してv1.0.xクラスタを停止します 。

元のv1.0.xクラスタがバイナリでデプロイされている場合は、DM-workerプロセスとDM-masterプロセスを直接停止できます。

ステップ4：データ移行タスクのアップグレード

  1. operate-sourceコマンドを使用して、アップストリーム データベース ソース構成をステップ1から v2.0+ クラスターにロードします。

  2. 下流のTiDBクラスタでは、v1.0.xデータ移行タスクの増分チェックポイントテーブルから、対応するグローバルチェックポイント情報を取得します。

    • v1.0.x データ移行構成でmeta-schemaが指定されていない（またはデフォルト値dm_metaとして指定されている）場合、対応するタスク名がtask_v1であると仮定すると、対応するチェックポイント情報は、ダウンストリーム TiDB の`dm_meta`.`task_v1_syncer_checkpoint`テーブルにあります。

    • データ移行タスクに対応するすべての上流データベースソースのグローバルチェックポイント情報を取得するには、以下のSQL文を使用します。

      > SELECT `id`, `binlog_name`, `binlog_pos` FROM `dm_meta`.`task_v1_syncer_checkpoint` WHERE `is_global`=1;
+------------------+-------------------------+------------+
| id               | binlog_name             | binlog_pos |
+------------------+-------------------------+------------+
| mysql-replica-01 | mysql-bin|000001.000123 | 15847      |
| mysql-replica-02 | mysql-bin|000001.000456 | 10485      |
+------------------+-------------------------+------------+

  3. 新しいv2.0以降のデータ移行タスクを開始するには、v1.0.xのデータ移行タスク構成ファイルを更新してください。

    • v1.0.x のデータ移行タスク構成ファイルがtask_v1.yamlの場合、それをコピーしてtask_v2.yamlに名前を変更します。

    • task_v2.yamlに対して以下の変更を行ってください。

      • nameをtask_v2などの新しい名前に変更します。

      • task-modeをincrementalに変更します。

      • ステップ2で取得したグローバルチェックポイント情報に基づいて、各ソースの増分レプリケーションの開始点を設定します。例：

        mysql-instances:
  - source-id: "mysql-replica-01"        # Corresponds to the `id` of the checkpoint information.
    meta:
      binlog-name: "mysql-bin.000123"    # Corresponds to the `binlog_name` in the checkpoint information, excluding the part of `|000001`.
      binlog-pos: 15847                  # Corresponds to `binlog_pos` in the checkpoint information.

  - source-id: "mysql-replica-02"
    meta:
      binlog-name: "mysql-bin.000456"
      binlog-pos: 10485

  4. start-taskコマンドを使用して、v2.0以降のデータ移行タスク構成ファイルからアップグレードされたデータ移行タスクを開始します。

  5. query-statusコマンドを使用して、データ移行タスクが正常に実行されているかどうかを確認してください。

データ移行タスクが正常に実行された場合、DMのv2.0+へのアップグレードが成功したことを示します。

このページは役に立ちましたか？