從 MySQL 遷移資料 —— 以 Amazon Aurora MySQL 為例

本文以 Amazon Aurora MySQL 為例介紹如何使用 DM 從 MySQL 協定資料庫遷移資料到 TiDB。

第 1 步：在 Aurora 叢集中啟用 binlog

假設有兩個 Aurora 叢集需要遷移資料到 TiDB，其叢集資訊如下，其中 Aurora-1 包含一個獨立的讀取器節點。

叢集 終端節點 端口 角色

Aurora-1 pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com 3306 寫入器

Aurora-1 pingcap-1-us-east-2a.h8emfqdptyc4.us-east-2.rds.amazonaws.com 3306 讀取器

Aurora-2 pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com 3306 寫入器

DM 在增量同步階段依賴 ROW 格式的 binlog，如果未啟用 binlog 及設定正确的 binlog 格式，則不能正常使用 DM 進行資料同步，具體可參見

注意：

Aurora 讀取器不能開啟 binlog，是以不能作為 DM 資料遷移時的上遊 master server。

如果需要基于 GTID 進行資料遷移，還需要為 Aurora 叢集啟用 GTID 支援。

基于 GTID 的資料遷移需要 MySQL 5.7 (Aurora 2.04.1) 或更高版本。

為 Aurora 叢集修改 binlog 相關參數

在 Aurora 叢集中，binlog 相關參數是叢集參數組中的叢集級參數，有關如何為 Aurora 叢集啟用 binlog 支援，請參考在複制主執行個體上啟用二進制日志記錄。在使用 DM 進行資料遷移時，需要将 binlog_format 參數設定為 ROW。

如果需要基于 GTID 進行資料遷移，需要将 gtid-mode 與 enforce_gtid_consistency 均設定為 ON。有關如何為 Aurora 叢集啟用基于 GTID 的資料遷移支援，請參考 Configuring GTID-Based Replication for an Aurora MySQL Cluster。

在 Aurora 管理背景中，gtid_mode 參數表示為 gtid-mode。

第 2 步：部署 DM 叢集

目前推薦使用 DM-Ansible 部署 DM 叢集，具體部署方法參照

在 DM 所有的配置檔案中，資料庫的密碼要使用 dmctl 加密後的密文。如果

買QQ賬号平台

資料庫密碼為空，則不需要加密。關于如何使用 dmctl 加密明文密碼，參考上下遊資料庫使用者必須擁有相應的讀寫權限。

第 3 步：檢查叢集資訊

使用 DM-Ansible 部署 DM 叢集後，相關配置資訊如下：

DM 叢集相關元件配置資訊

元件 主機 端口

dm_worker1 172.16.10.72 8262

dm_worker2 172.16.10.73 8262

dm_master 172.16.10.71 8261

上下遊資料庫執行個體相關資訊

資料庫執行個體 主機 端口 使用者名 加密密碼

上遊 Aurora-1 pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com 3306 root VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=

上遊 Aurora-2 pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com 3306 root VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=

下遊 TiDB 172.16.10.83 4000 root

dm-master 程序配置檔案 {ansible deploy}/conf/dm-master.toml 中的配置

Master 配置。

[[deploy]]

source-id = "mysql-replica-01"

dm-worker = "172.16.10.72:8262"

source-id = "mysql-replica-02"

dm-worker = "172.16.10.73:8262"

第 4 步：配置任務

假設需要将 Aurora-1 和 Aurora-2 執行個體的 test_db 庫的 test_table 表以全量+增量的模式同步到下遊 TiDB 的 test_db 庫的 test_table 表。

複制并編輯 {ansible deploy}/conf/task.yaml.example，生成如下任務配置檔案 task.yaml：

任務名，多個同時運作的任務不能重名。

name: "test"

全量+增量 (all) 同步模式。

task-mode: "all"

下遊 TiDB 配置資訊。

target-database:

host: "172.16.10.83"

port: 4000

user: "root"

password: ""

目前資料同步任務需要的全部上遊 MySQL 執行個體配置。

mysql-instances:

-

# 上遊執行個體或者複制組 ID，參考

inventory.ini

的

source_id

或者

dm-master.toml

source-id 配置

。

source-id: "mysql-replica-01"

# 需要同步的庫名或表名的黑白名單的配置項名稱，用于引用全局的黑白名單配置，全局配置見下面的

black-white-list

的配置。

black-white-list: "global"

# Mydumper 的配置項名稱，用于引用全局的 Mydumper 配置。

mydumper-config-name: "global"

source-id: "mysql-replica-02"

黑白名單全局配置，各執行個體通過配置項名引用。

black-white-list:

global:

do-tables:                        # 需要同步的上遊表的白名單。
- db-name: "test_db"              # 需要同步的表的庫名。
  tbl-name: "test_table"          # 需要同步的表的名稱。
           

Mydumper 全局配置，各執行個體通過配置項名引用。

mydumpers:

extra-args: "-B test_db -T test_table"  # mydumper 的其他參數，從 DM 1.0.2 版本開始，DM 會自動生成 table-list 配置，在其之前的版本仍然需要人工配置。           

第 5 步：啟動任務

進入 dmctl 目錄 /home/tidb/dm-ansible/resources/bin/

執行以下指令啟動 dmctl

./dmctl --master-addr 172.16.10.71:8261

執行以下指令啟動資料同步任務（task.yaml 是之前編輯的配置檔案）

start-task ./task.yaml

如果執行指令後的傳回結果中不包含錯誤資訊，則表明任務已經成功啟動

如果包含以下錯誤資訊，則表明上遊 Aurora 使用者可能擁有 TiDB 不支援的權限類型

{

"id": 4,
"name": "source db dump privilege chcker",
"desc": "check dump privileges of source DB",
"state": "fail",
"errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...",
"instruction": "",
"extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com"           

},

"id": 5,
"name": "source db replication privilege chcker",
"desc": "check replication privileges of source DB",
"state": "fail",
"errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...",
"instruction": "",
"extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com"           

}

此時可以選擇以下兩種處理方法中的任意一種進行處理後，再使用 start-task 嘗試重新啟動任務：

為用于進行資料遷移的 Aurora 使用者移除不被 TiDB 支援的不必要的權限

如果能確定 Aurora 使用者擁有 DM 所需要的權限，可以在 task.yaml 配置檔案中添加如下頂級配置項以跳過啟用任務時的前置權限檢查

ignore-checking-items: ["dump_privilege", "replication_privilege"]

第 6 步：查詢任務

如需了解 DM 叢集中是否存在正在運作的同步任務及任務狀态等資訊，可在 dmctl 内使用以下指令進行查詢：

query-status

如果查詢指令的傳回結果中包含以下錯誤資訊，則表明在全量同步的 dump 階段不能獲得相應的 lock：

Couldn't acquire global lock, snapshots will not be consistent: Access denied for user 'root'@'%' (using password: YES)

此時如果能接受不使用 FTWL 來確定 dump 檔案與 metadata 的一緻或上遊能暫時停止寫入，可以通過為 mydumpers 下的 extra-args 添加 --no-locks 參數來進行繞過，具體方法為：

使用 stop-task 停止目前由于不能正常 dump 而已經轉為 paused 的任務

将原 task.yaml 中的 extra-args: "-B test_db -T test_table" 更新為 extra-args: "-B test_db -T test_table --no-locks"

使用 start-task 重新啟動任務