从MySQL看主从架构高可用性实现 _架构

从进入互联网时代开始，我们从单机走向集群再到当前的微服务架构，我们已经很少再使用单机架构来实现业务逻辑，即使没有使用微服务，但是主备、主从等集群已经属于是业务侧必备能力。
但是，无论是主备还是主从架构，实际上就是为了系统的高可用性实现的一个策略，防止主机因为某些故障导致异常下线，这时候备份或者从实例就会通过选择或者其他策略成为主服务实例，对外继续提供服务。
在MySQL的正常情况下，只要主库执行更新生成的所有binlog全部被正确的传到备库并且被正确执行，备库就能和主库数据一致，实现最终一致性。但是最终一致性并不能满足线上的性能需求，还需要保证集群的可用性。
1 主备延迟1.1 主备延迟在发生主备延迟时，与数据同步的时间点主要包括：

主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;
备库 B 执行完成这个事务，我们把这个时刻记为 T3 。

主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，就是T3-T1 。
在备库执行show slave status会得到seconds_behind_master，表示备库延迟的时间，计算方法为：

每个事务的binlog都有一个时间字段，用于记录主库写入时间；
备库取出当前正在执行的事务的时间字段的值，计算与当前系统时间差值，就是该值，单位为秒；

如果主备库机器的系统时间设置不一致，不会导致主备延迟的值不准。因为，备库连接到主库的时候，会通过执行 SELECT UNIX_TIMESTAMP() 函数来获得当前主库的系统时间。如果这时候发现主库的系统时间与自己不一致，备库在执行 seconds_behind_master 计算的时候会自动扣掉这个差值。
但是：如果备库已经连接主库后，修改主库的系统时间，备库同步的时候就不会再做时间的自动修正了，因此，时间修正只有第一次建连的时候才会执行。
在网络正常的时候，日志从主库传给备库所需的时间是很短的，即 T2-T1 的值是非常小的。也就是说，网络正常情况下，主备延迟的主要来源是备库接收完 binlog 和执行完这个事务之间的时间差。所以说，主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。
1.2 主备延迟的来源1.2.1 主备机性能有差距备库所在机器性能比主库的机器性能差，此时一般将备库设置为“非双1”模式【牺牲备库的一点可靠性，减少写盘次数，增强IO能力】，更新过程中触发大量读操作，可能会导致主备延迟。
现在这种情况比较少，因为现在都是主从部署，可能随时发生主从切换，因此一般都是对称部署。
1.2.2 备库压力大一般出现的原因是读写分离场景，备库对外提供读能力，查询耗费大量CPU资源，影响了同步速度，造成主备延迟。
此时的处理措施是：

一主多从，用从库分担压力；
通过binlog输出到外部系统，比如Hadoop系统，提供统计类查询能力；

从库和备库在概念上其实差不多。在我们这个专栏里，为了方便描述，我把会在 HA 过程中被选成新主库的，称为备库，其他的称为从库。
1.2.3 大事务主库必须等事务执行完成后才能写入binlog，再传给备库，造成主备延迟。
比如说大量数据的删除就会造成大事务，一般是要求分批执行。之所以删除会造成大事务，是因为无论是否有索引，存储引擎都是一条条数据查询并加锁，返回给执行引擎，执行引擎标记数据删除。所有的数据都处理完成后，才会提交事务释放锁。
另一种就是大表DDL 。
1.3 主备延迟的排查思路1）查数据库在干什么

pager cat - | grep -v Sleep | sort -rn -k 12 | head -n 20show full processlist; select * from information_schema.processlist where 1=1 order by TIME desc limit 10;

2）查看sql_thread在干什么
slave上查看状态：
show slave statusG;查看relay_master_log_file以及exec_master_log_pos