MYSQL5.7实时同步数据到TiDB

操作系统：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依旧没有被刷新。

所以如果重启了，只能手工再导一次，

MYSQL5.7实时同步数据到TiDB

猜你喜欢