MySQL的高可靠和高可用机制

概念一：主备延迟（seconds behind master）

1. 主备延迟的概念

• 时间点T1：主库执行完事务写入bin log；
• 时间点T2：备库从主库的bin log中读取该事务的日志记录到自己的bin log中（速度很快）；
• 时间点T3：备库读取该事务的bin log日志进行归档（主备延时的主要耗时阶段）。

主备延时时间 = T3 - T1。

2. 主备延迟的原因

• 备库压力大（一些非业务sql语句会放到备库执行）----解决方法是设置一主多从，多个备库分担备库的压力；
• 执行的是大事务，那么主库需要耗费和主库差不多的时间去执行该事务（比如实际中要一次性删除大量记录）。----解决方法是将大事务分成多个小事务执行；
• 备库读取日志进行数据持久化的速度太慢----MySQL进行了优化，采用多线程并发对备库进行持久化。

概念二：主备切换

有时候主库要更新或者主库宕机，备库就会出来充当主库，两者切换。一般采用双M结构，也就是一个库可以在主库和备库之间来回切换（双方互为主库与备库）。

即：库B在上面是库A的备库，在下面库A是库B的备库。

概念三：数据库的高可靠和高可用（需要协调平衡）

高可靠：可靠性优先的主备切换过程

1. 主库A要切换前，先等待备库B的主备延迟时间(seconds behind master)小于很小的值；
2. 主库A变为readonly状态，等待备库的主备时间变为0（即备库完成当前的备份操作，此期间业务无法向数据库写入数据，可用性降低）；
3. 备库B切换为可读写状态，成为主库。
4. 业务请求打到主库B。

高可用：可用性优先的主备切换过程

与上述可靠性优先的主备切换过程差不多，就是不等备库B完成备份（主备延迟时间不为零），直接将库B切换为主库，并使其可读写，那么客户端可实时对数据库读写（有些数据还没有持久化，会导致数据的不一致，可靠性就降低了）。

主备延迟影响主备切换时系统的可用性：

如果主备延迟过大，当主库宕机时或者切换到备库时，备库还在执行备份操作，无法从readonly状态切换到主库的可读写状态，期间就会造成数据库的不可用（当然一种做法是在切换中转状态是将数据库的写操作放入到主备库之外的第三方日志文件，之后再写入数据主库），但一般建议是尽量调小seconds behind master的值，也就是在第一步时尽量等到延迟时间很小再将主库A切换为readonly，在保证数据库可靠性的前提下提高数据库的可用性。

参考文章：

https://time.geekbang.org/column/article/76795