mysql 可用性的保障机制:主讲主从复制机制

文章目录

架构设计

innodb集群:一主一备、双主、一主多从

双主架构

循环复制问题

两个主节点,你复制我的日志,我复制你的日志,但怎么区分出来我复制你的日志是你执行了的的新日志,不是我传给你的我的日志呢(我不需要复制我的日志,循环复制)

日志的执行流程:

  • 节点A更新事务,binlog中记录A的日志和A的server id;
  • 传给B执行后,B生成的binlog中的server id保持A的server id // B自己的新日志写入binlog是server id是B的
  • 再传给A时,A发现是自己的就不执行了
如何不同步一个事务

B想执行一个事务,比如加个索引,但不同步给B执行。可以考虑的方案:

  1. 在A上stop slave

  2. 在B上执行语句。注意:这里不需要关闭binlog

  3. 执行完了,查出这个事务的GTID

  4. 到A上跳过这个GTID

    复制代码
    set GTID_NEXT="server_uuid_of_B:gno123"
    begin;
    commit; // 提交空事务,跳过server_uuid_of_B:gno123
    set gtid_next=automatic; // 恢复
    start slave;

复制机制

  • 主从切换,数据同步:GTID全局事务标识、位点、延迟时间=0 // 详见故障检测与恢复
  • 多线程复制提高从库应用速度:relay log中转日志给多个work并发复制
  • 延迟复制应对误操作场景:主库误删数据,快速同步给从库,又芭比Q了。准备一个从库延迟复制,抵御误删风险

复制流程

binlog格式

  • binlog=statement 直接复制语句。日志量少,可读性强
  • binlog=row 复制变更前后的数据和操作。日志量大,可用于恢复数据
  • binlog=mixed 不引起主备不一致的语句复制sql,可能引起主备不一致的复制具体语句,比如delete ... limit 1 复制原语句在主备上删除的行可能不同,所以复制变更前后的数据和操作

主从复制模式

  • 异步复制:主库复制完就返回客户端ok,异步进行binlog同步
  • 半同步复制(semi-sync):至少一个从库确认后返回。不然主库完成后通过客户端ok就挂了,那没有从库有数据就芭比Q了。等一个从库确认了再通知客户端成功,不然就认为失败。

多线程复制提高从库应用速度

主备延迟
原因
  • 从库机器性能比主库差
  • 从库读压力大 => 可以考虑加从库
  • 大事务,比如大的删除事务 主库执行10分钟然后发到从库去执行就会有延迟;大表的DDL操作,比如加个字段
  • 从库relay_log单线程,主库事务是并发执行的
解决方案
  • 强制走主库

    关键业务查询显示指定走主库

  • sleep一会儿,睡多睡少了都是事儿

  • 等 seconds_behind_master = 0

  • 等主库位点方案

  • 等GTID方案

    在从库上等这个事务(不是等所有延迟事务都同步完成)执行,等x秒,等到就返回;没等到(超时),就拒绝服务或者返回主库;

    如果存在大量返回主库的,需要主库做好限流,别被打崩;

    配合semi-sync方案(半同步复制)方案使用

从库并行复制策略

原则:

  • 同一个事务不能被拆开,必须放在一个worker中
  • 不能造成更新覆盖。更新同一行的两个事务必须在一个worker中
按表分发worker

每个worker维护一个hash表[库名-表名]:修改这个表的正在执行的事务list

如果一个要执行的事务和多个worker冲突,就阻塞等待只剩一个冲突worker放在这个worker中;修改热点表时,就容易变成单线程。

按行分发worker

每个worker维护一个hash表[库民-表名-唯一键名-唯一键值]

按行分发要求binlog必须是row模式

按行分发比按表分发粒度细,并发度高,但计算、维护hash成本也更高

大事务不适合按行分发worker,会有很大一个hash表,大事务要单线程执行,等执行完了再恢复并行能力

按库分发worker

比按表、行都快,方便;但你就一个库那就没有并行复制了

MariaDB 并行复制策略

想要从库并发,思考如何直接利用主库的并发校验结果 => group commit 组提交。一组提交的事务一定不是冲突的,能并发执行。

不过有个问题:一组事务这个粒度很大,而且同时只有一组事务committing完成在从库复制,要等这组复制完再进行下一组的复制,有空白期,并发能力不够

mysql 优化 MariaDB 并行复制策略

取事务状态再提前一点,同时处于redo log prepare状态的任务(// 已经写binlog但还没commit)就是可以并发执行的了;

同时,控制binlog_group_commit_sync_delay、binlog_group_commit_sync_no_delay_count 多攒点binlog一起提交,通过延迟,增加并发量

配置binlog-transaction-dependency-tracking

COMMIT_ORDER: 根据同时进入prepare和commit来判断是否可以并行复制

WRITESET:按行分发,计算hash。对于事务涉及更新的每一行,计算这一行的hash,得到writeset集合。如果两个事务writeset没有交集,就能并行执行

WRITESET_SESSION:在writeset基础上,加个约束:在主库同一个线程上先后执行的两个事务,在备库上也要保证相同的先后顺序

负载均衡

读写分离、连接池、多活部署

数据可靠性

持久性保证:WAL机制、redo log、binlog

崩溃恢复:redo 回放,undo log回滚(比如长事务回滚中崩溃了,重启了还需要继续回滚)

故障检测与恢复

mysql 故障检测与处理-CSDN博客