重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

TiDBデータ移行をv1.0.xからv2.0+に手動でアップグレードする

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

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

ノート:

  • 現在、データ移行タスクが完全エクスポートまたは完全インポートの処理中である場合、DMをv1.0.xからv2.0+にアップグレードすることはサポートされていません。
  • DMクラスタのコンポーネント間の相互作用に使用されるgRPCプロトコルは大幅に更新されるため、アップグレードの前後でDMコンポーネント(dmctlを含む)が同じバージョンを使用していることを確認する必要があります。
  • DMクラスタのメタデータストレージ(チェックポイント、シャードDDLロックステータス、オンラインDDLメタデータなど)が大幅に更新されるため、v1.0.xのメタデータをv2.0+で自動的に再利用することはできません。したがって、アップグレード操作を実行する前に、次の要件が満たされていることを確認する必要があります。
    • すべてのデータ移行タスクは、シャードDDL調整のプロセスではありません。
    • すべてのデータ移行タスクがオンラインDDL調整の過程にあるわけではありません。

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

ステップ1:v2.0+構成ファイルを準備する

v2.0 +の準備された構成ファイルには、アップストリームデータベースの構成ファイルとデータ移行タスクの構成ファイルが含まれています。

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

v2.0 +では、 アップストリームデータベース構成ファイルはDMワーカーのプロセス構成から分離されているため、 v1.0.xDMワーカー構成に基づいてソース構成を取得する必要があります。

ノート:

v1.0.xからv2.0+へのアップグレード中にソース構成のenable-gtidが有効になっている場合は、binlogまたはリレーログファイルを解析して、binlogの位置に対応するGTIDセットを取得する必要があります。

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+クラスタをデプロイ

ノート:

他のv2.0+クラスターを使用できる場合は、この手順をスキップしてください。

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

手順3:v1.0.xクラスタを停止する

元のv1.0.xクラスタがDM-Ansibleによってデプロイされている場合は、 DM-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. v1.0.xデータ移行タスク構成ファイルを更新して、新しいv2.0+データ移行タスクを開始します。

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

    • task_v2.yamlに次の変更を加えます。

      • nametask_v2などの新しい名前に変更します。

      • task-modeincrementalに変更します。

      • 手順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
        

        ノート:

        ソース構成でenable-gtidが有効になっている場合、現在、binlogまたはリレーログファイルを解析して、binlogの位置に対応するGTIDセットを取得し、 metabinlog-gtidに設定する必要があります。

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

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

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