MYSQL 备库延迟问题

MYSQL 备库延迟问题

一个线程负责客户端写入主库，另一线程sql_thread 执行中转日志（relay log）。

在官方的 5.6 版本之前，MySQL 只支持单线程复制，由此在主库并发高、TPS 高时就会出现严重的主备延迟问题。

coordinator (sql_thread)在分发的时候，需要满足以下这两个基本要求：

1.不能造成更新覆盖。这就要求更新同一行的两个事务，必须被分发到同一个 worker 中。
2.同一个事务不能被拆开，必须放到同一个 worker 中。

多线程复制的流程:
双1,配置为logical_clock,假设有三个事务并发执行也已经执行完成(都处于prepare阶段)
1.三个事务把redo log从redo log buffer写到fs page cache中
2.把binlog_cache flush到binlog文件中,最先进入flush队列的为leader,
其它两个事务为follower.把组员编号以及组的编号写进binlog文件中(三个事务为同一组).
3.三个事务的redo log做fsync,binlog做fsync.
4.dump线程从binlog文件里把binlog event发送给从库
5.I/O线程接收到binlog event,写到relay log中
6.sql thread读取relay log,判断出这三个事务是处于同一个组,
则把这三个事务的event打包发送给三个空闲的worker线程(如果有)并执行。

配置为writeset的多线程复制流程:
1.三个事务把redo log从redo log buffer写到fs page cache中
2.把binlog_cache flush到binlog文件中,根据表名、主键和唯一键(如果有)生成hash值(writeset),保存到hash表中
(不过一个组的事务个数也不是无限大,由参数binlog_transaction_dependency_history_size决定组内最多事务数)
3.然后做redo log和binlog的fsync
4.dump线程从binlog文件里把binlog event发送给从库
5.I/O线程接收到binlog event,写到relay log中
6.sql thread读取relay log,如果是同一个组的事务,则把事务分配到不同的worker线程去应用relay log.
不同组的事务,需要等到上一个组的事务全部执行完成,才能分配worker线程应用relay log.