MySQL实战 8/32 并行复制

实战1 并行复制搭建

此处假设已经完成标准复制的搭建。

master ：10.67.36.124：3380
slave：10.67.36.124：3390

slave 配置

# MTS
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 4
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = on
binlog_transaction_dependency_tracking='WRITESET'

重启salve mysqld

mysqladmin -S data/kyle/mysql3390/tmp/mysql3390.sock -uroot -p shutdown
mysqld --defaults-file=/data/kyle/mysql3390/mysql3390.cnf &

master

binlog_group_commit_sync_delay = 100
binlog_group_commit_sync_no_delay_count = 10
binlog_transaction_dependency_tracking='WRITESET'

重启master mysqld

mysqladmin -S data/kyle/mysql3380/tmp/mysql3380.sock -uroot -p shutdown
mysqld --defaults-file=/data/kyle/mysql3380/mysql3380.cnf &

登录到salve

mysql -S data/kyle/mysql3390/tmp/mysql3390.sock -uadmin -p
# 重启start salve
change master to master_host='10.67.36.124', master_port=3380, master_user='repl', master_password='repl4slave', MASTER_AUTO_POSITION=1;
start slave;
# 查询复制的线程
select id, Relay_log_name,Relay_log_pos,Master_log_name,Master_log_pos,Channel_name  from slave_worker_info;

使用sysbench 做压力测试，测试并行复制

sysbench --mysql-host=10.67.36.124 --mysql-db=db1 --mysql-user=admin --mysql-password=admin123 --mysql-port=3380  --table_size=200000 --tables=10 --threads=10 --events=1000 --report-interval=10 --time=0  usr/local/share/sysbench/oltp_read_write.lua  prepare

查询时候使用了并行复制

select * from slave_worker_info;

master 上查看组提交信息

mysqlbinlog myql3380_binlog.000002 |grep last_committed

相同的last committed 都是组提交的事务。

在salve上查询并行复制的信息：

mysqlbinlog myql3390_binlog.000004 |grep last_committed

相同的 last committed 都是组提交的事务。

实战2 为什么会有延时

我们再看一下经典的复制原理图

1， 若在master 上运行一个delete from t1的语句，要全删除，没有where条件，假如表中有20000条数据， 则会产生20000条binlog， 这样情况，会有延时。

2， 在slave上，写入数据的线程只有一个sql thread；而在master 上， 有无数个链接线程在写入数据；所以理论上会有延时；

实战3 并行复制原理

MySQL5.6 加入了并行复制，但是只是只是数据库级别的并行复制 （即slave-parallel-type=DATABASE）， 即一个数据库一个sql thread， 对于现在流行的微服务， 一个MySQL实例，通常一个数据库，所以这种并行复制很鸡肋。

MySQL5.7有了基于组提交的并行复制（即slave-parallel-type = LOGICAL_CLOCK），主要原理是一个组内提交的事务，可以并行回放。而这种基于组提交的并行复制，顾名思义就是基于master的组提交。

实战4 并行复制关键参数分析

1. binlog_group_commit_sync_delay = 100 【主库设置】， 表示延迟多少微秒后才调用 fsync。

2. binlog_group_commit_sync_no_delay_count = 2，表示累积多少次以后才调用 fsync。binlog_group_commit_sync_delay  和 binlog_group_commit_sync_no_delay_count 是或的关系， 满足一个条件就提交。

3. binlog_transaction_dependency_tracking 【主库设置， 默认commit_order】  取值commit_order | writeset | writeset_session， 主要是控制binlog文件中last_committed的计算方式。

1. commit_order即group commit，同在prepare阶段的事务，在binlog中last_committed数值一样，传到从库之后可以并行执行；

2. writeset，会对事务处理的行数据哈希出一个writeset值，放到一个哈希表里，如果两个事务先后提交，但是处理的行数据没有冲突，即wirteset不一样，就可以有同样的last_committed，在从库可以并行执行；

3. writeset_session，比writeset多了一个约束，同一个session的事务，在binlog里保留先后顺序，也就是last_committed按先后顺序递增

4. slave-parallel-type = LOGICAL_CLOCK，

5. slave_preserve_commit_order=0，【从库设置，5.7 从库，默认值是0】当该值是1时，严格按照relay log的顺序提交；当该值是0时，从库自行决定提交顺序。

6. slave-parallel-workers = 4