作者： 大魚海棠 原文來源： https://tidb.net/blog/4540ae34
一、概述
DM有all、full、incremental三種數據遷移同步方式（task-mode），在all同步模式下，因一些特殊情況，需要變更上游MySQL的數據源IP，一般有如下幾種處理方式：
- 放棄已同步的數據，重新用all模式同步（適合數據量比較小的場景，操作簡單）
- 記錄同步到的位點信息，停掉task和數據源，將同步模式改為incremental并在task配置中指定MySQL示例的位點信息重新拉起任務
task中meta配置下游數據庫的 checkpoint 不存在時 binlog 遷移開始的位置; 如果 checkpoint 存在，則以 checkpoint 為準。如果 meta 項和下游數據庫的 checkpoint 都不存在，則從上游當前最新的 binlog 位置開始遷移
- 不修改task-mode的情況下，基于檢查點斷點續傳， 本文主要基于該場景測試
二、MySQL環境準備
mysql
set global validate_password_mixed_case_count=0;
set global validate_password_policy='LOW';
set global validate_password_number_count=0;
set global validate_password_special_char_count=0;
set global validate_password_length=4;
alter user root@'localhost' identified by 'dm_test';
配置文件
[mysqld]
datadir=/mysql57/data
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
binlog_format=ROW
log_bin=/mysql57/logbin/logbin
log-error=/mysql57/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
gtid_mode=ON
enforce_gtid_consistency=ON
# 主從使用不同的server_id
server_id=2
# 從庫開啟binlog記錄
log-slave-updates = 1
主從搭建
reset master;
change master to master_host='172.1.1.4', master_user='root', master_password='dm_test', master_port=3306, master_auto_position=1;
start slave;
show slave status\G
三、DM任務創建
1. 創建數據源
創建數據源配置文件
[tidb@vm10-2-103-112 ~]$ cat source-01.yaml
source-id: "mysql-01"
enable-gtid: true from: host: "172.1.1.2" port: 3306 user: "root" password: "dm_test"
上游數據源賬戶所需權限
上游數據源用戶所需權限：
- information_schem和需要同步的表的select權限
- reload權限
- REPLICATION CLIENT、REPLICATION SLAVE
創建數據源
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 operate-source create ./source-01.yaml
查看創建的數據源
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 config source mysql-01
2. 創建同步任務
task配置文件準備
vim task01.yamlname: test1
task-mode: all
shard-mode: "pessimistic" meta-schema: "dm_meta1"
# timezone: "Asia/Shanghai" case-sensitive: false
online-ddl: true
clean-dump-file: true # 是否清理 dump 階段產生的文件，包括 metadata 文件、建庫建表 SQL 文件以及數據導入 SQL 文件
collation_compatible: "loose" # 同步 CREATE 語句中缺省 Collation 的方式，可選 "loose" 和 "strict"，默認為 "loose"。"loose" 模式不會顯式補充上游缺省的 Collation，"strict" 會顯式補充上游缺省的 Collation。當使用 "strict" 模式，但下游不支持上游缺省的 Collation 時，下游可能會報錯。
ignore-checking-items: [] target-database:host: "172.1.1.4"port: 4000user: "dm_test"password: "dm_test" block-allow-list: bw-rule-1: do-dbs: ["dm_test.*"]mydumpers: global: threads: 4 chunk-filesize: 64 extra-args: "--consistency auto" loaders: global: pool-size: 16dir: "./dumped_data"import-mode: "logical"on-duplicate-logical: "replace"syncers: global: worker-count: 16 batch: 100 safe-mode: falsesafe-mode-duration: "60s"compact: falsemultiple-rows: false
# ----------- 實例配置 -----------
mysql-instances:-source-id: "mysql-01"block-allow-list: "bw-rule-1"mydumper-config-name: "global"loader-config-name: "global"syncer-config-name: "global"
下游tidb同步用戶所需權限：
- 待同步庫表的SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、ALTER、INDEX權限
- dm元數據庫表的 ALL 權限
前置檢查
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 check-task ./task01.yaml
創建task
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 start-task ./task01.yaml
查看同步狀態
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 query-status test1
四、單實例更換數據源IP
驗證不修改task配置，直接更換數據源IP
1. 不修改source-id
Stop 任務和數據源
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 stop-task test1
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 operate-source stop mysql-01
僅修改數據源IP
source-id: "mysql-01"
enable-gtid: true from: host: "120.1.1.115" port: 3306 user: "root" password: "dm_test"
創建數據源和task
tiup dmctl:v7.1.3 --master-addr 172.16.201.4:8261 operate-source create ./source-01.yaml
tiup dmctl:v7.1.3 --master-addr 172.16.201.4:8261 start-task ./task01.yaml
tiup dmctl:v7.1.3 --master-addr 172.16.201.4:8261 query-status test1
驗證同步無異常
不改變source-id的情況下，dm會去元數據表中找到斷點，進行斷點續傳，不會重新dump數據
2. 修改source-id
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 stop-task test1
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 operate-source stop mysql-01
修改數據源IP和source-id
source-id: "mysql-02"
enable-gtid: true from: host: "172.1.1.2" port: 3306 user: "root" password: "dm_test"
創建數據源和task
需要修改task01.yaml的數據源
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 operate-source create ./source-01.yaml
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 start-task ./task01.yaml
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 query-status test1
驗證同步無異常
修改了source-id的情況下，會觸發重新dump全量數據
3. 更換IP期間新增了表
在停掉task和數據源后，模擬MySQL增加表和數據（只修改數據源IP）
mysql> create table t3(id int primary key,b int);
Query OK, 0 rows affected (0.04 sec) mysql> insert into t3 values (1,1);
Query OK, 1 row affected (0.01 sec) mysql> insert into t3 values (2,1);
Query OK, 1 row affected (0.01 sec)
修改數據源IP后，創建task
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 operate-source create ./source-01.yaml
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 start-task ./task01.yaml
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 query-status test1
同步無異常，未dump全量數據
檢查點分為針對單表的同步位點和數據源的同步位點，如果存在當前表的位點，則基于位點繼續同步，如不存在，基于數據源位點往后同步
五、分片集群修改數據源IP
環境準備
基于單實例的環境，新增MySQL節點來測試
數據源配置
source-id: "mysql-04"
enable-gtid: true from: host: "172.1.1.4" port: 3306 user: "root" password: "dm_test"
task配置
name: test2
task-mode: all
shard-mode: "pessimistic" meta-schema: "dm_meta2"
# timezone: "Asia/Shanghai" case-sensitive: false
online-ddl: true
clean-dump-file: false # 是否清理 dump 階段產生的文件，包括 metadata 文件、建庫建表 SQL 文件以及數據導入 SQL 文件
collation_compatible: "loose" # 同步 CREATE 語句中缺省 Collation 的方式，可選 "loose" 和 "strict"，默認為 "loose"。"loose" 模式不會顯式補充上游缺省的 Collation，"strict" 會顯
式補充上游缺省的 Collation。當使用 "strict" 模式，但下游不支持上游缺省的 Collation 時，下游可能會報錯。
ignore-checking-items: [] target-database: host: "172.1.1.4" port: 4000 user: "dm_test" password: "dm_test" block-allow-list: bw-rule-1: do-dbs: ["dm_test"] mydumpers: global: threads: 4 chunk-filesize: 64 extra-args: "--consistency auto" loaders: global: pool-size: 16 dir: "./dumped_data" import-mode: "logical" on-duplicate-logical: "replace" syncers: global: worker-count: 16 batch: 100 safe-mode: false safe-mode-duration: "60s" compact: false multiple-rows: false
# ----------- 實例配置 -----------
mysql-instances: - source-id: "mysql-04" block-allow-list: "bw-rule-1" mydumper-config-name: "global" loader-config-name: "global" syncer-config-name: "global"
創建數據源和任務
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 operate-source create ./source-02.yaml
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 start-task ./task01.yaml
tiup dmctl:v7.1.3 --master-addr 172.1.1.4:8261 query-status test2
重復單實例數據源IP修改過程，驗證結果與單實例一致
六、總結
斷點續傳來源于dm元數據信息(dm_meta庫的表記錄信息)，主要包含以下幾點
- task.yaml的name的值
- task.yaml的meta-schema是否改變
- 數據源配置中source-id是否改變
如有其他變更項，可結合檢查點進行分析，通過檢查點信息是否改變來判斷是否可以斷點續傳
前提：
-
使用
query-status命令獲取當前 binlog replication 處理單元已復制到下游的 binlog 對應的 GTID sets (syncerBinlogGtid)，記為gtid-S。 -
在將要切換到的 MySQL 實例上使用
SELECT @@GLOBAL.gtid_purged;獲取已經被 purged 的 binlog 對應的 GTID sets，記為gtid-P。 -
在將要切換到的 MySQL 實例上使用
SELECT @@GLOBAL.gtid_executed;獲取所有已經執行成功的事務對應的 GTID sets，記為gtid-E。 -
確保滿足以下關系，否則不支持將 DM-worker 連接切換到相應的 MySQL 實例：
-
gtid-S包含gtid-P（gtid-P可以為空） -
gtid-E包含gtid-S
-
七、附加測試
1. 測試一
數據源的配置文件默認 enable-gtid: false ，現驗證同步過程中，是否可修改該參數
驗證修改后同步正常，在 enable-gtid: false 情況下，檢查點會同時攜帶position信息和gitd信息，修改后可基于位點斷點續傳
2. 測試二
DM配置文件 extra-args: "--consistency none" 默認值為none，none的官網解釋是不做一致性保障
none模式下
2024-06-21T08:23:44.159963Z 18511 Query SELECT @@max_allowed_packet
2024-06-21T08:23:44.160052Z 18511 Query SET time_zone = '+08:00'
2024-06-21T08:23:44.160149Z 18511 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2024-06-21T08:23:44.160242Z 18511 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
2024-06-21T08:23:44.160343Z 18511 Query SHOW MASTER STATUS
2024-06-21T08:23:44.160534Z 18511 Query SHOW SLAVE STATUS
2024-06-21T08:23:44.160731Z 18511 Query SHOW DATABASES 2024-06-21T08:23:44.161956Z 18511 Query SELECT COUNT(1) as c FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='SEQUENCE'
2024-06-21T08:23:44.171027Z 18511 Query SHOW TABLE STATUS FROM `dm_test`
2024-06-21T08:23:44.174675Z 18511 Query SHOW MASTER STATUS
2024-06-21T08:23:44.174826Z 18511 Query SHOW CREATE DATABASE `dm_test`
2024-06-21T08:23:44.174981Z 18511 Query SHOW COLUMNS FROM `dm_test`.`customer`
2024-06-21T08:23:44.175584Z 18511 Query SELECT `c_id`,`c_d_id`,`c_w_id`,`c_first`,`c_middle`,`c_last`,`c_street_1`,`c_street_2`,`c_city`,`c_state`,`c_zip`,`c_phone`,`c_
since`,`c_credit`,`c_credit_lim`,`c_discount`,`c_balance`,`c_ytd_payment`,`c_payment_cnt`,`c_delivery_cnt`,`c_data` FROM `dm_test`.`customer` LIMIT 1
2024-06-21T08:23:44.178285Z 18511 Query SHOW CREATE TABLE `dm_test`.`customer`
2024-06-21T08:23:44.178529Z 18511 Query SHOW INDEX FROM `dm_test`.`customer`
2024-06-21T08:23:44.178805Z 18511 Query EXPLAIN SELECT `c_w_id` FROM `dm_test`.`customer`
2024-06-21T08:23:44.179002Z 18511 Query SHOW INDEX FROM `dm_test`.`customer`
2024-06-21T08:23:44.179269Z 18511 Query SHOW INDEX FROM `dm_test`.`customer`
2024-06-21T08:23:44.179510Z 18511 Query EXPLAIN SELECT `c_w_id` FROM `dm_test`.`customer`
2024-06-21T08:23:44.179748Z 18511 Query SELECT MIN(`c_w_id`),MAX(`c_w_id`) FROM `dm_test`.`customer` 2024-06-21T08:23:44.173952Z 18512 Query SELECT @@max_allowed_packet
2024-06-21T08:23:44.174104Z 18512 Query SET time_zone = '+08:00'
2024-06-21T08:23:44.174281Z 18512 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2024-06-21T08:23:44.174546Z 18512 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
2024-06-21T08:23:44.182494Z 18512 Query SELECT `c_id`,`c_d_id`,`c_w_id`,`c_first`,`c_middle`,`c_last`,`c_street_1`,`c_street_2`,`c_city`,`c_state`,`c_zip`,`c_phone`,`c_
2024-06-21T08:23:45.888538Z 18512 Query SELECT `d_id`,`d_w_id`,`d_name`,`d_street_1`,`d_street_2`,`d_city`,`d_state`,`d_zip`,`d_tax`,`d_ytd`,`d_next_o_id` FROM `dm_test`.`district` ORDER BY `d_w_id`,`d_id`
2024-06-21T08:23:45.889394Z 18512 Query SELECT `h_c_id`,`h_c_d_id`,`h_c_w_id`,`h_d_id`,`h_w_id`,`h_date`,`h_amount`,`h_data` FROM `dm_test`.`history` WHERE `h_w_id` IS NULL OR (`h_w_id` >= 1 AND `h_w_id` < 11)
2024-06-21T08:23:46.281664Z 18512 Query SELECT `i_id`,`i_im_id`,`i_name`,`i_price`,`i_data` FROM `dm_test`.`item` ORDER BY `i_id`
2024-06-21T08:23:46.352202Z 18512 Query SELECT `no_o_id`,`no_d_id`,`no_w_id` FROM `dm_test`.`new_order` ORDER BY `no_w_id`,`no_d_id`,`no_o_id`
none模式使用 SESSION RR 隔離級別 和 START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */ 來構建一致性視圖，不存在非事務引擎表的時候，操作比FTWRL輕量
注意：
- 備份期間有DDL的話，有幾率觸發鎖等待，原因為DM開啟了兩個
START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */ SESSION，一個用來看表結構、構造導出執行計劃、查看索引等；另外一個用來dump數據，如果期間有DDL，有幾率出現等MDL鎖的情況(圖一) - 不開啟FTWRL的話，那么backupmeta的gtid信息有可能是不準的（show master status獲取的是當前值，不受
START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */限制）。備份文件 metadata 記錄的位點可能比 dumped data 要早，可以開啟safe-mode來規避（不能完全避免），DM會自行記錄兩次show master status位點信息來判斷是否進入safe-mode，以及何時退出safe-mode。
auto模式下
2024-06-21T09:31:56.773773Z 18684 Connect root@vm10-2-103-3 on using SSL/TLS
2024-06-21T09:31:56.776319Z 18684 Query SELECT version()
2024-06-21T09:31:56.776529Z 18684 Query FLUSH TABLES WITH READ LOCK
2024-06-21T09:31:56.778052Z 18684 Query UNLOCK TABLES
2024-06-21T09:31:56.778166Z 18684 Query SET SESSION time_zone = '+08:00'
2024-06-21T09:31:56.778236Z 18684 Quit
2024-06-21T09:31:56.780010Z 18685 Connect root@vm10-2-103-3 on using SSL/TLS
2024-06-21T09:31:56.780202Z 18685 Query SET time_zone = '+08:00'
2024-06-21T09:31:56.780405Z 18685 Query FLUSH TABLES WITH READ LOCK
2024-06-21T09:31:56.783146Z 18686 Connect root@vm10-2-103-3 on using SSL/TLS
2024-06-21T09:31:56.783335Z 18686 Query SET time_zone = '+08:00'
2024-06-21T09:31:56.783421Z 18686 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2024-06-21T09:31:56.783518Z 18686 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
2024-06-21T09:31:56.783611Z 18686 Query SHOW MASTER STATUS
2024-06-21T09:31:56.783755Z 18686 Query SHOW SLAVE STATUS
2024-06-21T09:31:56.786107Z 18686 Query SHOW DATABASES
2024-06-21T09:31:56.786563Z 18686 Query SELECT COUNT(1) as c FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='SEQUENCE'
2024-06-21T09:31:56.916141Z 18686 Query SHOW TABLE STATUS FROM `dm_test`
2024-06-21T09:31:56.919220Z 18687 Connect root@vm10-2-103-3 on using SSL/TLS
2024-06-21T09:31:56.919398Z 18687 Query SET time_zone = '+08:00'
2024-06-21T09:31:56.919483Z 18687 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2024-06-21T09:31:56.919570Z 18687 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
2024-06-21T09:31:56.919726Z 18685 Query UNLOCK TABLES
相對于mysqldump少了flush table的步驟（mysqldump在執行FTWRL前會執行flush tables），直接執行了FTWRL，第一次做權限探測，第二次執行備份
結論
結合業務應用情況綜合考慮，選擇auto/none模式
)
