操作系统：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依旧没有被刷新。
所以如果重启了，只能手工再导一次，