目录

1 主备延迟

1.1 主备延迟

1.2 主备延迟的来源

1.2.1 主备机性能有差距

1.2.2 备库压力大

1.2.3 大事务

1.3 主备延迟的排查思路

3)查看MySQL状态

2 主备切换策略

2.1 可靠性优先策略

2.2 可用性优先策略

2.3 常见切换技术


从进入互联网时代开始,我们从单机走向集群再到当前的微服务架构,我们已经很少再使用单机架构来实现业务逻辑,即使没有使用微服务,但是主备、主从等集群已经属于是业务侧必备能力。

但是,无论是主备还是主从架构,实际上就是为了系统的高可用性实现的一个策略,防止主机因为某些故障导致异常下线,这时候备份或者从实例就会通过选择或者其他策略成为主服务实例,对外继续提供服务。

在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 status\G;

查看relay_master_log_file以及exec_master_log_pos

master上解析binglog日志:

mysqlbinlog -v --base64-output=decode-rows --start-position=exec_master_log_pos relay_master_log_file

如果发现卡在操作某表上:

1)检查表结构

  • 没有索引:stop slave 可能会卡主,建议关闭mysql,启动后先加索引,然后start slave
  • 有索引:只能等,大事务需要做拆分,不要操作太多数据

2)大事务:M上session回话使用statement格式,使用语句级别的复制

3)查看MySQL状态
  • 机器性能(CPU、IO等):从库配置适当高一点,使用新硬件PCI-E或SSD设备
  • 表结构: 设计要合理,必须有主键,主键要短小,为查询字段建索引
  • 业务程序:适当使用缓存,减少数据库压力

分析MySQL进程并结合源码:

perf top `pidof mysqld`

4)参数临时优化

  • 主库开启group commit
  • 从库开启writeset
  • 从库设置sync_binlog=0 && innodb_flush_log_at_trx_commit=2

5)检查锁情况

show engine innodb status\G;

2 主备切换策略

2.1 可靠性优先策略

在双M结构下,主备切换的流程如图:

  1. 判断备库 B 现在的 seconds_behind_master(SBM),如果小于某个值(比如 5 秒)继续下一步,否则持续重试这一步;这里主从延迟时间短,说明当前没有大事务,延迟比较低,减少因为延迟造成数据不可靠的几率;
  2. 把主库 A 改成只读状态,即把 readonly 设置为 true;
  3. 判断备库 B 的 seconds_behind_master 的值,直到这个值变成 0 为止;
  4. 把备库 B 改成可读写状态,也就是把 readonly 设置为 false;
  5. 把业务请求切到备库 B。

这个切换流程,一般是由专门的 HA 系统来完成的,我们暂时称之为可靠性优先流程。

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

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

2.2 可用性优先策略

如果是直接将第4和第5步提前,保证了系统几乎么有不可用时间,但是可能造成数据不一致。

其实这就是CAP中的C和A,MySQL主库在写完binlog后就给客户端响应了,没等binlog同步到一个或多个备库,这种策略是在C和A之间选择了A,牺牲了C,如果主库宕机了,但binlog的最后一个或几个事务没同步到备库,那备库成为主库后,数据就丢了。其它的NoSQL很多是给用户提供了选择,比如Mongo,用户可以设置日志同步到几个Slave后再给客户端响应,同步的Slave越多,C越强,A越弱,比如同步到X个Slave后再给客户端响应,那即使任何X个节点宕机,集群中仍然有1个节点有最新日志,它会成为主节点,数据没丢,集群还可以工作。

在满足数据可靠性的前提下,MySQL 高可用系统的可用性,是依赖于主备延迟的。延迟的时间越小,在主库故障的时候,服务恢复需要的时间就越短,可用性就越高。

2.3 常见切换技术

semi-sync在网络故障超时的情况下会退化成async,这个时候如果刚好主库掉电了,有些binlog还没有传给从库,从库无法判断数据跟主库是否一致,如果强行切换可能会导致丢数据,在金融业务场景下只能"人工智能"来做切换,服务中断时间长。AliSQL采用双通道复制更容易判断主备数据是否一致,如果一致可以自动切换,如果不一致才需要人工恢复数据。

相关内容拓展:(技术前沿)

近10年间,甚至连传统企业都开始大面积数字化时,我们发现开发内部工具的过程中,大量的页面、场景、组件等在不断重复,这种重复造轮子的工作,浪费工程师的大量时间。

针对这类问题,低代码把某些重复出现的场景、流程,具象化成一个个组件、api、数据库接口,避免了重复造轮子。极大的提高了程序员的生产效率。

推荐一款程序员都应该知道的软件JNPF快速开发平台,采用业内领先的SpringBoot微服务架构、支持SpringCloud模式,完善了平台的扩增基础,满足了系统快速开发、灵活拓展、无缝集成和高性能应用等综合能力;采用前后端分离模式,前端和后端的开发人员可分工合作负责不同板块,省事又便捷。

体验官网:https://www.jnpfsoft.com/?csdnxx

还没有了解低代码这项技术可以赶紧体验学习!