Ⅰ、背景
搭建MySQL复制环境非常简单
你的系统是否也是像我之前那么搭建的呢？
那么,你的复制系统是否出现过以下的情况呢？
- 复制报错,例如：1062,1032
- 主从数据不一致
Ⅱ、真正高可靠复制环境相关配置(crash-safe replication)
master:
binlog_do_db # if possible
binlog_ignore_db # if possbile
max_binlog_size = 2048M
# 默认1g,其实也够用,MySQL每次写满1g后做的切换代价太大,但5.7已经修复了,不是太大问题
binlog_format = ROW
transaction_isolation = read-committed
expire_logs_days = 7 #capacity plan
server_id = # Unique
binlog_cache_size = # take care
# 默认32k,如果一个大事务,产生日志大于32k,那内存写不下就要写磁盘了
# show global status like 'binlog_cache_disk_use';
# 表示使用了基于磁盘的binlog的cache有多少
# 如果这个值比较高,那就可以考虑调大binlog_cache_size
# 通常32k够用,但是批量删除或者更新就可能超过32k,这时候性能就会下降了
sync_binlog = 1 # must set to 1,default is 0,5.7.7 default is 1
# 二进制日志一定要实时落盘,这个时时落盘,上一个参数就没用了
innodb_flush_log_at_trx_commit = 1 # redo也必须实时落盘
innodb_support_xa = 1
# 上面两个参数是通过内部分布式事务实现的,所以要开
relay_log_recovery = 1 # I/O thread crash safe 默认关的
relay_log_info_repository = TABLE # SQL thread crash safe 默认是file
# 高可用切换时,主可能变成从,所以上面两个参数主也要配上
master_info_repository = TABLE
slave:
log_slave_updates
# 级联复制用,对于同步过来的操作回放后,再产生日志,这样就不用做增量备份了
replicate_do_db
replicate_ignore_db
replicate_do_table
replicate_ignore_table
server_id = # Unique
relay_log_recovery = 1 # I/O thread crash safe 默认关的
relay_log_info_repository = TABLE # SQL thread crash safe 默认是file
master_info_repository = TABLE
read_only = 1
Ⅲ、sql/io高可靠
3.1 sql线程高可靠
背景：
- 如果将relay_log_info_repository设置为FILE,MySQL会把回放信息记录在一个relay-info.log 的文件中,其中包含SQL线程回放到的Relay_log_name和Relay_log_pos,以及对应的Master的Master_log_name和Master_log_pos
- SQL线程回放event
- 将回放到的binlog的文件名和位置写到relay-info.log文件
- 参数sync_relay_log_info = 10000（fsync）代表每回放10000个event,写一次 relay-info.log,默认1w
综上：SQL线程的数据回放是写数据库操作,relay-info是写文件操作,这两个操作很难保证一致性,看下面这种情况
step1：
主上顺序插入1,2,3
step2：
从同步主,插入1,2,3,成功且已刷盘
刚好1这条记录刚好是第 N w个event,此时relay-info.log刷盘,这样就只刷到1的位置,2,3没被刷进去
step3：
无独有偶,slave挂了
这时候slave起来之后,继续回放的时就会从1后面的位置开始回放,这样问题就出来了,报1062,2,3这两条记录重复了
解决：
有人说把sync_relay_log_info设置为1就好了,其实不然
- 如果该参数设置为 1,则表示每回放一个event,就写一次relay-info.log ,那写入代价很大,且性能很差
- 设置为1后,即使性能上可以接受,还是会丢最有一次的操作,恢复起来后还是有1062的错误
MySQL 5.6之后,我们将relay_log_info_repository设置为TABLE,relay-info将写入到mysql.slave_relay_log_info这张表中
原理：
将event的回放和relay-info的更新放在同一个事物里面,变成原子操作,从而保证一致性（要么都写入,要么都不写）每一次事物提交,都会写入mysql.slave_relay_log_info中,sync_relay_log_info=N将被忽略
BEGIN;
apply log event;
apply log event;
UPDATE mysql.slave_relay_log_info
SET Master_log_pos = Exec_Master_Log_Pos,
Master_log_name = Relay_Master_Log_File,
Relay_log_name = Relay_Log_File,
Relay_log_pos = Relay_Log_Pos;
COMMIT;
3.2 io线程高可靠
背景：
- io线程负责接收event到relay log file,每接收到一个event会在master-info.log记录一下IO线程接收到的位置（Master_log_name和Master_log_pos）
- sync_master_info=10000表示每接收10000个event,写一次master-info
这里存在同样的问题,master-info.log和relay log无法保证一致性,还是之前的例子：
step1：
主上顺序插入1,2,3
step2：
event已经都传到relay log中了
但2,3两个记录的master-info还未刷到master-info.log
step3：
io线程挂了
重新拉起来,io线程又会去拉一遍2和3送到relay log中,当sql线程执行到这一块也是报错冲突了
看到的现象还是 IO线程正常,SQL线程报错
- 可通过设置参数master_info_repository来选择master-info.log信息写入到FILE或TABLE
解决：
- 设置master_info_repository = TABLE？？？
没用的,event是写到relay log文件里的,不是数据库操作,所以写表里也没用,做不到原子性 - 正确做法是配置relay_log_recovery = 1,表示当slave重启时,将所有relay log删除,通过sql线程重放的位置点去重新拉日志
- master_info_repository设置为TABLE虽然对crash-safe没有帮助,但也请设置为TABLE，特别是5.7，并行复制会大幅提升master.info更新的消耗，所以设置为TABLE降低消耗
tips：
如果 Slave落后Master的时间很多,超过了Master上binlog的保存时间,那Master上对应的binlog就会被删除,Slave的I/O Thread就拉不到数据了,注意监控主从落后的时间
3.3 小结
真正的MySQL复制的高可靠是从 5.6 版本开始的,通过设置以下三个参数确保复制的高可靠(换言,之前的版本复制不可靠很正常)
relay_log_recover = 1
relay_log_info_repository = TABLE
master_info_repository = TABLE
非常建议这3个参数主从配置完全一致,主从是平等的,尽量对称
Ⅳ、并行复制(Multi-Threaded Slave)
4.1 背景
主从复制延迟是老生常谈的问题了,这里只谈sql线程回放慢的问题,其他因素不考虑,sql线程回放慢最主要的原因就是MySQL 5.5之前都是单线程回放
- 5.6开始支持多线程复制
slave_parallel_workers 0表示只有1个线程,可以动态设置,但是要重启一下复制,线上设为8或者16
注意：5.6版本只支持基于database的并行回放,所以不能选择并行模式,有多少个库,就可以开多少个线程,每个线程回放指定的库,缺点就是只有一个库的时候就并行不了,所以说这时候的并行复制用的并不多
- 5.7支持并行复制模式设置
slave_parallel_type=logical_clock
配置很简单,性能很棒棒,主上面怎么并行,从上面就怎么回放,基于逻辑时钟的概念
5.7才有,5.7.19之前有bug,会导致主从不一致,慎用
- Slave上commit的顺序保持一致,否则可能会有GAP锁产生
slave_preserve_commit_order=1
- 并行复制时,slave上coordinator线程负责任务指派,work thread负责回放如下
(root@172.16.0.10) [test]> show processlist;
+----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
| 1 | system user | | NULL | Connect | 26277 | Waiting for master to send event | NULL |
| 2 | system user | | NULL | Connect | 26217 | Slave has read all relay log; waiting for more updates | NULL |
| 4 | system user | | NULL | Connect | 26277 | Waiting for an event from Coordinator | NULL |
| 5 | system user | | NULL | Connect | 26277 | Waiting for an event from Coordinator | NULL |
| 6 | system user | | NULL | Connect | 26277 | Waiting for an event from Coordinator | NULL |
| 7 | system user | | NULL | Connect | 26277 | Waiting for an event from Coordinator | NULL |
| 10 | root | localhost | NULL | Query | 0 | starting | show processlist |
+----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
7 rows in set (0.00 sec)
tips:
这里的并行复制指的是SQL Thread,而非IO Thread
Waiting for master to send event 这个State在show processlist中只有一个,即只有一个IO Thread
4.2 理解logical_clock
这是一种基于组提交的并行复制
如果一批事务在一组里提交,这些事务之间是没有锁冲突的(有锁冲突就要等待了,不可能在一组里提交)
此时,binlog就会记录组提交的信息,从回放的时候就可以知道哪些事务是一组里面的,一组里面的就丢到不同线程去回放,不是一组里的就等待,以此来提升并行度
5.7相关测试：
单线程,从机回放速度只能达到5k的qps
设置为logical_clock,从的qps能超过2.5w
tips：
- 如何看哪些事务在一组？
[root@VM_0_5_centos ~]# mysqlbinlog xxx |grep last_comitted
last_comitted相等的事务是在同一组里提交的
- last_commited记录了上一组提交的事务号,而每个事务的sequence_number是一直递增的
- 每组的last_committed值,都是上一个组中事务的sequence_number最大值,也是本组中事务sequence_number最小值减1
- last_committed和sequence_number作用域不得跨文件
Ⅴ、8.0并行复制初探
MySQL 8.0出了一个更屌的复制并行回放,即使主上面是单线程执行了几个事务(更改了很多行,但是这些行不相关),从也可以并行回放这些事务
如何实现：
- 这种情况没有组提交,一组里面只有一个事务
- MySQL的binlog记录的行,每行都保存了这个库这张表以及它对应的主键值
- 如果两个事务之间修改的每行操作主键没有重复,没有交叉,就可以并行回放
- 基于writeset,所谓的writeset其实就是我们的row格式,写的结果集不就是row嘛
tips：
这种并行复制的前提是,binlog_format必须是row模式
没有主键的情况暂时没搞明白怎么做的,需要研究下官方文档
5.7.22已经引入了基于writeset的并行复制
小结
主从延迟问题困扰了MySQL差不多十年
5.7为什么这么重要？,最重要的就是并行复制,增强型的多线程回放,这可以说是一个里程碑
如果没有这个机制,做高可用切换,读写分离,效果都不好