Amazon Auroraから TiDB にデータを移行する

このドキュメントでは、Amazon Auroraから TiDB にデータを移行する方法について説明します。移行プロセスではDB スナップショットを使用するため、スペースと時間を大幅に節約できます。

移行全体には 2 つのプロセスがあります。

• TiDB Lightningを使用して TiDB に完全なデータをインポートする
• DM を使用して増分データを TiDB に複製する (オプション)

前提条件

• DumplingとTiDB Lightningをインストールする
• TiDB Lightningに必要なターゲット データベース権限を取得する .

完全なデータを TiDB にインポートする

ステップ 1.Aurora スナップショットをAmazon S3 にエクスポートする

1. Auroraで、次のコマンドを実行して現在のbinlog の位置を照会します。

   mysql> SHOW MASTER STATUS;
   

   出力は次のようになります。後で使用するためにbinlogの名前と位置を記録します。

   +------------------+----------+--------------+------------------+-------------------+
   | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
   +------------------+----------+--------------+------------------+-------------------+
   | mysql-bin.000002 |    52806 |              |                  |                   |
   +------------------+----------+--------------+------------------+-------------------+
   1 row in set (0.012 sec)
   

2. Auroraスナップショットをエクスポートします。詳細な手順については、 DB スナップショット データを Amazon S3 にエクスポートするを参照してください。

binlog の位置を取得したら、5 分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。

上記の 2 つの手順を実行したら、次の情報が準備できていることを確認してください。

• スナップショット作成時のAurorabinlogの名前と位置。
• スナップショットが保存されている S3 パス、および S3 パスにアクセスできる SecretKey と AccessKey。

ステップ 2. スキーマのエクスポート

Auroraのスナップショット ファイルには DDL ステートメントが含まれていないため、 Dumplingを使用してスキーマをエクスポートし、 TiDB Lightningを使用してターゲット データベースにスキーマを作成する必要があります。スキーマを手動で作成する場合は、この手順を省略できます。

次のコマンドを実行して、 Dumplingを使用してスキーマをエクスポートします。このコマンドには、目的のテーブル スキーマのみをエクスポートするための--filterパラメーターが含まれています。

tiup dumpling --host ${host} --port 3306 --user root --password ${password} --filter 'my_db1.table[12]' --no-data --output 's3://my-bucket/schema-backup' --filter "mydb.*"

上記のコマンドで使用されるパラメーターは次のとおりです。その他のパラメーターについては、 Dumplingの概要を参照してください。

ステップ 3. TiDB Lightning構成ファイルを作成する

次のようにtidb-lightning.toml構成ファイルを作成します。

vim tidb-lightning.toml

[tidb]

# The target TiDB cluster information.
host = ${host}                # e.g.: 172.16.32.1
port = ${port}                # e.g.: 4000
user = "${user_name}          # e.g.: "root"
password = "${password}"      # e.g.: "rootroot"
status-port = ${status-port}  # Obtains the table schema information from TiDB status port, e.g.: 10080
pd-addr = "${ip}:${port}"     # The cluster PD address, e.g.: 172.16.31.3:2379. TiDB Lightning obtains some information from PD. When backend = "local", you must specify status-port and pd-addr correctly. Otherwise, the import will be abnormal.

[tikv-importer]
# "local": Default backend. The local backend is recommended to import large volumes of data (1 TiB or more). During the import, the target TiDB cluster cannot provide any service.
# "tidb": The "tidb" backend is recommended to import data less than 1 TiB. During the import, the target TiDB cluster can provide service normally.
backend = "local"

# Set the temporary storage directory for the sorted Key-Value files. The directory must be empty, and the storage space must be greater than the size of the dataset to be imported. For better import performance, it is recommended to use a directory different from `data-source-dir` and use flash storage, which can use I/O exclusively.
sorted-kv-dir = "/mnt/ssd/sorted-kv-dir"

[mydumper]
# The path that stores the snapshot file.
data-source-dir = "${s3_path}"  # e.g.: s3://my-bucket/sql-backup

[[mydumper.files]]
# The expression that parses the parquet file.
pattern = '(?i)^(?:[^/]*/)*([a-z0-9_]+)\.([a-z0-9_]+)/(?:[^/]*/)*(?:[a-z0-9\-_.]+\.(parquet))$'
schema = '$1'
table = '$2'
type = '$3'

TiDB クラスターで TLS を有効にする必要がある場合は、 TiDB Lightningコンフィグレーションを参照してください。

ステップ 4. 完全なデータを TiDB にインポートする

1. TiDB Lightningを使用してターゲット データベースにテーブルを作成します。

   tiup tidb-lightning -config tidb-lightning.toml -d 's3://my-bucket/schema-backup'
   

2. tidb-lightningを実行してインポートを開始します。コマンド ラインでプログラムを直接起動すると、プロセスが SIGHUP シグナルの受信後に予期せず終了することがあります。この場合、 nohupまたはscreenツールを使用してプログラムを実行することをお勧めします。例えば：

   S3storageパスにアクセスできる SecretKey と AccessKey を環境変数としてDumplingノードに渡します。 ~/.aws/credentialsから資格情報を読み取ることもできます。

   export AWS_ACCESS_KEY_ID=${access_key}
   export AWS_SECRET_ACCESS_KEY=${secret_key}
   nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 &
   

3. インポートの開始後、次のいずれかの方法でインポートの進行状況を確認できます。

   • grepログのキーワードprogress 。デフォルトでは、進行状況は 5 分ごとに更新されます。
   • 監視ダッシュボードで進行状況を確認します。
   • TiDB Lightning Web インターフェイスで進行状況を確認します。

4. TiDB Lightning がインポートを完了すると、自動的に終了します。 tidb-lightning.log最後の行にthe whole procedure completed含まれているかどうかを確認します。はいの場合、インポートは成功です。 「いいえ」の場合、インポートでエラーが発生します。エラー メッセージの指示に従って、エラーに対処します。

ノート：

インポートが成功したかどうかに関係なく、ログの最後の行にtidb lightning exitが表示されます。これは、 TiDB Lightning が正常に終了したことを意味しますが、必ずしもインポートが成功したことを意味するものではありません。

インポート中に問題が発生した場合は、トラブルシューティングについてTiDB LightningFAQを参照してください。

増分データを TiDB に複製する (オプション)

前提条件

• DMをインストール .
• DM に必要なソース データベースとターゲット データベースの権限を取得する .

ステップ 1: データ ソースを作成する

1. 次のようにsource1.yamlファイルを作成します。

   # Must be unique.
   source-id: "mysql-01"
   # Configures whether DM-worker uses the global transaction identifier (GTID) to pull binlogs. To enable this mode, the upstream MySQL must also enable GTID. If the upstream MySQL service is configured to switch master between different nodes automatically, GTID mode is required.
   enable-gtid: false
   
   from:
     host: "${host}"         # e.g.: 172.16.10.81
     user: "root"
     password: "${password}" # Supported but not recommended to use plaintext password. It is recommended to use `dmctl encrypt` to encrypt the plaintext password before using it.
     port: 3306
   

2. 次のコマンドを実行して、 tiup dmctlを使用してデータ ソース構成を DM クラスターに読み込みます。

   tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml
   

   上記のコマンドで使用されるパラメーターは、次のとおりです。

   パラメータ	説明
   --master-addr	dmctlが接続されるクラスタ内の任意の DM マスターの{advertise-addr}例: 172.16.10.71:8261
   operate-source create	データ ソースを DM クラスターに読み込みます。

ステップ 2: 移行タスクを作成する

次のようにtask1.yamlファイルを作成します。

# Task name. Multiple tasks that are running at the same time must each have a unique name.
name: "test"
# Task mode. Options are:
# - full: only performs full data migration.
# - incremental: only performs binlog real-time replication.
# - all: full data migration + binlog real-time replication.
task-mode: "incremental"
# The configuration of the target TiDB database.
target-database:
  host: "${host}"                   # e.g.: 172.16.10.83
  port: 4000
  user: "root"
  password: "${password}"           # Supported but not recommended to use a plaintext password. It is recommended to use `dmctl encrypt` to encrypt the plaintext password before using it.

# Global configuration for block and allow lists. Each instance can reference the configuration by name.
block-allow-list:                     # If the DM version is earlier than v2.0.0-beta.2, use black-white-list.
  listA:                              # Name.
    do-tables:                        # Allow list for the upstream tables to be migrated.
    - db-name: "test_db"              # Name of databases to be migrated.
      tbl-name: "test_table"          # Name of tables to be migrated.

# Configures the data source.
mysql-instances:
  - source-id: "mysql-01"               # Data source ID, i.e., source-id in source1.yaml
    block-allow-list: "listA"           # References the block-allow-list configuration above.
#       syncer-config-name: "global"    # Name of the syncer configuration.
    meta:                               # The position where the binlog replication starts when `task-mode` is `incremental` and the downstream database checkpoint does not exist. If the checkpoint exists, the checkpoint is used. If neither the `meta` configuration item nor the downstream database checkpoint exists, the migration starts from the latest binlog position of the upstream.
      binlog-name: "mysql-bin.000004"   # The binlog position recorded in "Step 1. Export an Aurora snapshot to Amazon S3". When the upstream database has source-replica switching, GTID mode is required.
      binlog-pos: 109227
      # binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9"

# (Optional) If you need to incrementally replicate data that has already been migrated in the full data migration, you need to enable the safe mode to avoid the incremental data replication error.
   # This scenario is common in the following case: the full migration data does not belong to the data source's consistency snapshot, and after that, DM starts to replicate incremental data from a position earlier than the full migration.
   # syncers:            # The running configurations of the sync processing unit.
   #   global:            # Configuration name.
   #     safe-mode: true  # If this field is set to true, DM changes INSERT of the data source to REPLACE for the target database, and changes UPDATE of the data source to DELETE and REPLACE for the target database. This is to ensure that when the table schema contains a primary key or unique index, DML statements can be imported repeatedly. In the first minute of starting or resuming an incremental replication task, DM automatically enables the safe mode.

上記の YAML ファイルは、移行タスクに必要な最小限の構成です。その他の設定項目については、 DM 拡張タスクコンフィグレーションファイルを参照してください。

ステップ 3.移行タスクを実行する

移行タスクを開始する前に、エラーの可能性を減らすために、次のcheck-taskコマンドを実行して、構成が DM の要件を満たしていることを確認することをお勧めします。

tiup dmctl --master-addr ${advertise-addr} check-task task.yaml

その後、 tiup dmctlを実行して移行タスクを開始します。

tiup dmctl --master-addr ${advertise-addr} start-task task.yaml

上記のコマンドで使用されるパラメーターは、次のとおりです。

タスクの開始に失敗した場合は、プロンプト メッセージを確認し、構成を修正します。その後、上記のコマンドを再実行してタスクを開始できます。

問題が発生した場合は、 DM エラー処理およびDMFAQを参照してください。

ステップ 4. 移行タスクのステータスを確認する

DM クラスターに進行中の移行タスクとタスクのステータスがあるかどうかを確認するには、 tiup dmctl使用してquery-statusコマンドを実行します。

tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}

結果の詳細な解釈については、 クエリのステータスを参照してください。

ステップ 5. タスクを監視してログを表示する

移行タスクの履歴ステータスとその他の内部メトリックを表示するには、次の手順を実行します。

TiUPを使用して DM をデプロイしたときに Prometheus、Alertmanager、および Grafana をデプロイした場合は、デプロイ中に指定された IP アドレスとポートを使用して Grafana にアクセスできます。次に、DM ダッシュボードを選択して、DM 関連のモニタリング メトリックを表示できます。

DM が実行されている場合、DM-worker、DM-master、および dmctl は関連情報をログに出力します。これらのコンポーネントのログ ディレクトリは次のとおりです。

• DM-master: DM-master プロセス パラメータ--log-fileによって指定されます。 TiUPを使用して DM を展開する場合、ログ ディレクトリはデフォルトで/dm-deploy/dm-master-8261/log/です。
• DM-worker: DM-worker プロセス パラメータ--log-fileによって指定されます。 TiUPを使用して DM を展開する場合、ログ ディレクトリはデフォルトで/dm-deploy/dm-worker-8262/log/です。

次は何ですか

• 移行タスクを一時停止します .
• 移行タスクを再開します .
• 移行タスクを停止する .
• クラスター データ ソースとタスク構成のエクスポートとインポート .
• 失敗した DDL ステートメントを処理する .