实战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 并行复制关键参数分析
binlog_group_commit_sync_delay = 100 【主库设置】, 表示延迟多少微秒后才调用 fsync。
binlog_group_commit_sync_no_delay_count = 2,表示累积多少次以后才调用 fsync。binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 是或的关系, 满足一个条件就提交。
binlog_transaction_dependency_tracking 【主库设置, 默认commit_order】 取值commit_order | writeset | writeset_session, 主要是控制binlog文件中last_committed的计算方式。
commit_order即group commit,同在prepare阶段的事务,在binlog中last_committed数值一样,传到从库之后可以并行执行;
writeset,会对事务处理的行数据哈希出一个writeset值,放到一个哈希表里,如果两个事务先后提交,但是处理的行数据没有冲突,即wirteset不一样,就可以有同样的last_committed,在从库可以并行执行;
writeset_session,比writeset多了一个约束,同一个session的事务,在binlog里保留先后顺序,也就是last_committed按先后顺序递增
slave-parallel-type = LOGICAL_CLOCK,
slave_preserve_commit_order=0,【从库设置,5.7 从库,默认值是0】当该值是1时,严格按照relay log的顺序提交;当该值是0时,从库自行决定提交顺序。
slave-parallel-workers = 4