MySQL高可用机制分析

=======================================================================

2.1 备库所在机器的性能较差

---

更新请求对IOPS的压力，在主库和备库上是无差别的，做这种部署时，一般都会将备库设置为“非双1”的模式。

更新过程中也会触发大量的读操作，当备库主机上的多个备库都在争抢资源的时候，就可能会导致主备延迟了。

2.2 备库的压力大

---

主库既然提供了写能力，那么备库可以提供一些读能力。或者一些运营后台需要的分析语句，不能影响正常业务，所以只能在备库上跑。

备库压力大时一般可以这么处理：

1. 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。

2. 通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。

2.3 大事务

---

因为主库上必须等事务执行完成才会写入binlog，再传给备库。所以，如果一个主库上的语句执行10分钟，那这个事务很可能就会导致从库延迟10分钟。

一次性地用delete语句删除太多数据，就是一个典型的大事务场景。

另一种典型的大事务场景是大表DDL。解决方案是计划内的DDL，建议使用gh-ost方案。（《Mysql删除数据前后表文件大小相同》）

3 可靠性优先策略

=======================================================================

在图1的双M结构下，从状态1到状态2切换的详细过程如下：

1. 判断备库B现在的seconds_behind_master，如果小于某个值（比如5秒）继续下一步，否则持续重试这一步；

2. 把主库A改成只读状态；

3. 判断备库B的seconds_behind_master的值，直到这个值变成0为止；

4. 把备库B改成可读写状态；

5. 把业务请求切到备库B。

图2 MySQL可靠性优先主备切换流程（SBM：seconds_behind_master）

这个切换流程中是有不可用时间的。因为在步骤2之后，主库A和备库B都处于readonly状态，直到步骤5完成后才能恢复。

在这个不可用状态中，比较耗费时间的是步骤3，可能需要耗费好几秒的时间。所以需要在步骤1先做判断，确保seconds_behind_master的值足够小。

系统的不可用时间是由数据可靠性优先的策略决定的。也可以选择可用性优先的策略，来把这个不可用时间几乎降为0。

4 可用性优先策略

=======================================================================

如果把步骤4、5调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库B，并且让备库B可以读写，那么系统几乎就没有不可用时间了。

这个切换流程的代价，就是可能出现数据不一致的情况。

CREATE TABLE t (

id int(11) unsigned NOT NULL AUTO_INCREMENT,

c int(11) unsigned DEFAULT NULL,

PRIMARY KEY (id)

) ENGINE=InnoDB;

insert into t© values(1),(2),(3);

这个表定义了一个自增主键id，初始化数据后，主库和备库上都是3行数据。接下来继续在表t上执行两条插入语句的命令，依次是：

insert into t© values(4);

insert into t© values(5);

假设，现在主库上其他的数据表有大量的更新，导致主备延迟达到5秒。在插入一条c=4的语句后，发起了主备切换。

图3是可用性优先策略，且binlog_format=mixed时的切换流程和数据结果。

图3 可用性优先策略，且binlog_format=mixed

1. step2中，主库A执行完insert语句，插入了一行数据（4,4），之后开始进行主备切换。

2. step3中，由于主备之间有5秒的延迟，所以备库B还没来得及应用“插入c=4”这个中转日志，就开始接收客户端“插入 c=5”的命令。

3. step4中，备库B插入了一行数据（4,5），并且把这个binlog发给主库A。

4. step5中，备库B执行“插入c=4”这个中转日志，插入了一行数据（5,4）。而直接在备库B执行的“插入c=5”这个语句，传到主库A，就插入了一行新数据（5,5）。

可用性优先策略，但设置binlog_format=row

因为row格式在记录binlog的时候，会记录新插入的行的所有字段值，所以最后只会有一行不一致。而且两边的主备同步的应用线程会报错duplicate key error并停止。

图4 可用性优先策略，且binlog_format=row

使用row格式的binlog时，数据不一致的问题更容易被发现。

主备切换的可用性优先策略会导致数据不一致。因此，大多数情况下，都建议你使用可靠性优先策略。

5 可靠性优先时的异常切换

===========================================================================

假设，主库A和备库B间的主备延迟是30分钟，这时候主库A停电了，HA系统要切换B作为主库。

图5 可靠性优先策略，主库不可用

采用可靠性优先策略的话，就必须得等到备库B的seconds_behind_master=0之后，才能切换。但现在的情况比刚刚更严重，并不是系统只读、不可写的问题了，而是系统处于完全不可用的状态。

能否直接切换到备库B，但是保持B只读？

不行。因为，这段时间内，中转日志还没有应用完成，如果直接发起主备切换，客户端查询看不到之前执行完成的事务，会认为有数据丢失。

所以说，MySQL高可用系统的可用性，是依赖于主备延迟的。延迟的时间越小，在主库故障的时候，服务恢复需要的时间就越短，可用性就越高。

6 关于备库延迟监控的思考

===========================================================================

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Java开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Java开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！**

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！