操作系統：CentOS7
mysql版本：5.7
TiDB版本：2.0.0
同步方法：使用TiDB提供的工具集進行同步
說明：
單機mysql同步時，可以直接使用binlog同步，
但mysql集群進行同步時，則必須依靠GTID，但開啟GTID后，對事物要求更高，導致以下操作會失敗：
(1) 不能同時揉合多個事件；
(2) 事務內部不能創建臨時表；
(3) 不能在同一事務中即更新InnoDB表，又更新MyISAM表。
- 下載tidb的同步工具包
# wget http://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.tar.gz # wget http://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.sha256 # sha256sum -c tidb-enterprise-tools-latest-linux-amd64.sha256 # tar -xzf tidb-enterprise-tools-latest-linux-amd64.tar.gz # cd tidb-enterprise-tools-latest-linux-amd64
- mysql-binlog同步
配置mysql基本信息,添加如下配置
vi /etc/my.cnf # server-id默認為0，不接受任何slaves。所以必須修改為0以外的數字 server-id=1 # STATEMENT，ROW，MIXED三種模式。默認為MIXED，需要修改為ROW binlog_format=ROW # 開啟日志輸出，並指定log文件位置與名稱 log_bin=mysql-bin log-bin-index=mysql-bin.index # 日志提交后的寫入模式，提供0，1，2三種選擇，1是最為可靠的，也是性能最差的 # 0：log buffer將每秒一次地寫入log file中，並且log file的flush(刷到磁盤)操作同時進行。該模式下在事務提交的時候，不會主動觸發寫入磁盤的操作。 # 1：每次事務提交時MySQL都會把log buffer的數據寫入log file，並且flush(刷到磁盤)中去，該模式為系統默認。 # 2：每次事務提交時MySQL都會把log buffer的數據寫入log file，但是flush(刷到磁盤)操作並不會同時進行。該模式下，MySQL會每秒執行一次 flush(刷到磁盤)操作。 innodb_flush_log_at_trx_commit=1 # 二進制日志（binary log）同步到磁盤的頻率 # 0 不主動同步，而依賴操作系統本身不定期把文件內容 flush 到磁盤。 # 1 每個語句或者事物后同步一次 # n 指定為n個語句或者事物后同步一次 sync_binlog=1 # 是否將同步記錄記入自己的binlog，默認為0，即不記錄。 # 如果本機B有從機C，當A同步binlog到B時，該選項沒有開啟，則A的操作只會同步到B，而不會同步到C。即B不會記錄binlog，也就不會同步到C log-slave-updates=1
配置完成后重啟mysql
# systemctl restart mysql
- 導出前檢查
導出前需要對表進行檢查，這里以mysql的系統庫做例子，實際導出數據時，應指定對應庫。如果出錯，則說明無法進行同步
# 檢查整個mysql庫 ./checker -host 172.18.100.65 -L debug -user root -password root mysql # 檢查mysql庫下的db表 ./checker -host 172.18.100.65 -L debug -user root -password root mysql db
- 導出數據
./mydumper -h 172.20.51.68 -P 3306 -u root -p root -B housedata -t 5 -F 1 --skip-tz-utc -o test
-h 源數據庫IP
-P 源數據庫端口
-u 用戶名 -p 密碼
-B 源數據庫名
-t 導出線程數
-F 分割文件大小，單位M（推薦64）
--skip-tz-utc 不修改時間
-o 導出到文件夾名，支持絕對路徑
導出后，到對應文件夾中可以看到對應的導出數據：
數據庫名-schema-create.sql 庫信息 數據庫名.表名-schema.sql 表信息 數據庫名.表名.sql 表數據 metadata 同步信息（后續做增量同步時，需要用到該文件中的信息）
- 導入數據
./loader -h 172.18.100.66 -P 4000 -u root -t 3 -d test
-h 目標數據庫IP
-P 目標數據庫端口
-u 用戶名
-p 密碼（密碼為空時，去掉該參數）
-t 導入線程數
-d 導入的文件夾，支持絕對路徑
導入時會創建一個tidb_loader數據，里邊會有checkpoint表，記錄了每張表導入的進度
如果清理掉目標記錄，再次導入時，數據將不會被再次導入，可以清理掉checkpoint后，再進行導入。
- 啟動同步
在syncer的目錄下創建config.toml和syncer.mata
# vi syncer.meta
binlog-name = "mysql-bin.000001" binlog-pos = 68335
# vi config.toml log-level = "info" server-id = 101 #meta 文件地址 meta = "./syncer.meta" worker-count = 16 batch = 10 ## pprof 調試地址, Prometheus 也可以通過該地址拉取 syncer metrics ## 將 127.0.0.1 修改為相應主機 IP 地址 status-addr = "172.20.51.68:10086" replicate-do-db = ["housedata"] [from] host = "172.20.51.68" user = "root" password = "root" port = 3306 [to] host = "172.18.100.66" user = "root" password = "" port = 4000
啟動同步程序
./syncer -config config.toml
如果同步成功了，syncer.meta文件的binlog-pos應該被自動更新的，但實際上沒有，所以導致每次數據都會被重新同步一次。
這里要跟蹤一下，看看是什么問題。
- GTID同步
查看mysql版本，版本最好是5.7的，其它版本不保證能夠配置成功。因為GTID在5.6版本才剛剛提供
mysql>show variables like 'version';
在binlog同步配置的基礎上，再增加GTID的相關配置。
# vi /etc/my.cnf gtid-mode = ON enforce_gtid_consistency = ON
systemctl restart mysqld
使用./mydumper導出數據，方式與binlog方式一樣。
但注意導出前需要插入一條記錄，否則metadata文件中的GTID會時空的。因為剛剛啟用GTID，還沒有生成記錄。
./mydumper -h 172.20.51.68 -P 3306 -u root -p root -B housedata -t 5 -F 1 --skip-tz-utc -o test
導入數據與binlog方式一樣
./loader -h 172.18.100.66 -P 4000 -u root -t 3 -d test
設置syncer.mate，需要從meta文件中多拷貝一個binlog-gtid過來
binlog-name = "mysql-bin.000002" binlog-pos = 13355 binlog-gtid = "c1d8336d-5d6d-11e8-8ad0-0050563c1c70:1-30"
啟動同步，需要增加對應參數
./syncer -config config.toml --enable-gtid
同步后syncer.mate文件雖然刷新了binlog-pos，但是binlog-gtid依舊沒有被刷新。
所以如果重啟了，只能手工再導一次，