MYSQL5.7实时同步数据到TiDB

时间：2021-04-05 22:58:53

操作系统：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=

# STATEMENT，ROW，MIXED三种模式。默认为MIXED，需要修改为ROW

binlog_format=ROW

# 开启日志输出，并指定log文件位置与名称

log_bin=mysql-bin

log-bin-index=mysql-bin.index

# 日志提交后的写入模式，提供0，，2三种选择，1是最为可靠的，也是性能最差的

# ：log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行。该模式下在事务提交的时候，不会主动触发写入磁盘的操作。

# ：每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去，该模式为系统默认。

# ：每次事务提交时MySQL都会把log buffer的数据写入log file，但是flush(刷到磁盘)操作并不会同时进行。该模式下，MySQL会每秒执行一次 flush(刷到磁盘)操作。

innodb_flush_log_at_trx_commit= 

# 二进制日志（binary log）同步到磁盘的频率

#  不主动同步，而依赖操作系统本身不定期把文件内容 flush 到磁盘。

#  每个语句或者事物后同步一次

# n 指定为n个语句或者事物后同步一次

sync_binlog=

# 是否将同步记录记入自己的binlog，默认为0，即不记录。

# 如果本机B有从机C，当A同步binlog到B时，该选项没有开启，则A的操作只会同步到B，而不会同步到C。即B不会记录binlog，也就不会同步到C

log-slave-updates=

配置完成后重启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  -u root -p root -B housedata -t  -F  --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  -u root  -t  -d test

-h 目标数据库IP

-P 目标数据库端口

-u 用户名

-p 密码（密码为空时，去掉该参数）

-t 导入线程数

-d 导入的文件夹，支持绝对路径

导入时会创建一个tidb_loader数据，里边会有checkpoint表，记录了每张表导入的进度

MYSQL5.7实时同步数据到TiDB

如果清理掉目标记录，再次导入时，数据将不会被再次导入，可以清理掉checkpoint后，再进行导入。

  • 启动同步

在syncer的目录下创建config.toml和syncer.mata

# vi syncer.meta 

binlog-name = "mysql-bin.000001"

binlog-pos = 
# vi config.toml

log-level = "info"

server-id = 

#meta 文件地址

meta = "./syncer.meta"

worker-count =

batch = 

## 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 = 

[to]

host = "172.18.100.66"

user = "root"

password = ""

port =

启动同步程序

./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  -u root -p root -B housedata -t  -F  --skip-tz-utc -o test

导入数据与binlog方式一样

./loader -h 172.18.100.66 -P  -u root  -t  -d test

设置syncer.mate，需要从meta文件中多拷贝一个binlog-gtid过来

binlog-name = "mysql-bin.000002"

binlog-pos =

binlog-gtid = "c1d8336d-5d6d-11e8-8ad0-0050563c1c70:1-30"

启动同步，需要增加对应参数

./syncer -config config.toml --enable-gtid

同步后syncer.mate文件虽然刷新了binlog-pos，但是binlog-gtid依旧没有被刷新。

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

相关文章