mysql的io和sql两个线程作用_mysql复制原理/基于库的多线程复制原理/基于BLGC的多线程复制原理...

mysql复制原理/基于库的多线程复制原理/基于BLGC的多线程复制原理

单线程主从复制：

从库向主库请求binlog,并将binlog转存到自己的relaylog中,从库重做binlog里面的sql,

主要由以下三个线程完成.

dump thread: 在主库上,发送binlog

io thread: 在slave上,接收,转存,请求binlog

sql thread :在slave 上,重做binlog

基于库的多线程复制原理：

从库向主库请求binlog,并将binlog转存到自己的relaylog中,从库重做binlog里面的sql,

主要由以下三个线程完成.

dump thread: 在主库上,发送binlog

io thread: 在slave上,接收,转存,请求binlog

sql thread :在slave 上,读取binlog,并分配binlog给work thread (分配原则,判断并行执行的事务是否拥有相同的数据库)

work thread:执行binlog ,可以有多个

多线程复制

mysql5.7 基于BLGC的多线程复制原理,同时处于prepare阶段的事务不会有冲突。

在mysql5.7 的binlog中新增了两个字段来来标注哪些事务可以并行执行,和binlog的写入顺序

last_committed:事务提交编号,同一组内的事务,编号相同,可以并行执行。

sequence_number:binglog写入顺序,用户确保master的binlog顺序和slave的binlog顺序的一致。

多线程复制中的一些问题

1.binlog以组为顺序并发重做,如果上一组binlog中有某个sql执行失败,整组sql是否回滚,slave复制是否暂停？

如果一组中的某个sql执行失败,整组sql都会回滚,

这个时候整个slave是否会暂停，有待验证

2.并行复制中如何保证master上的binlog和slave上binglog的顺序一致

在mysql5.7中为了实现并行复制,特地在binlog日志中增加了两个字段,last_committd,sequence_number,

在slave上按组并行重放的时需要等待组中所有sql执行完成,然后在flush阶段按照sequence_number排序,并行提交,

这样就保证了,master上binlog的的写入顺序就和slave上的binlog的写入顺序相同了。

参考资料

mysql5.7并行复制相关简介：