MySQL - 主备

简述

在实际的生产中，为了解决Mysql的单点故障，一般都会采用「主备模式」。
MySQL几乎所有的高可用架构，都直接依赖于 binlog。虽然这些高可用架构已经呈现出越来越复杂的趋势，但都是从最基本的一主一备演化过来的。

原理

下图为主备切换流程

主备切换流程

在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。

当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库。

在状态 1 中，虽然节点 B 没有被直接访问，但是依然建议把节点 B（也就是备库）设置成只读（readonly）模式。这样做，有以下几个考虑：

• 有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操作；
• 防止切换逻辑有 bug，比如切换过程中出现双写，造成主备不一致；
• 可以用 readonly 状态，来判断节点的角色。

主备同步流程

图下图 中画出的就是一个 update 语句在节点 A 执行，然后同步到节点 B 的完整流程图。

主备流程图

备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：

在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。

在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。

主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。

备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。

sql_thread 读取中转日志，解析出日志里的命令，并执行。

主备同步延迟

主库需要复制新增binlog到从库才能完成同步，这个同步过程就是同步延迟。主从延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。

延迟来源

• 从库所在机器的性能要比主库所在的机器性能差，例如从库集中放在一台机器，而主库比较分散，主库机器IOPS比从库好。 因为主备可能发生切换，备库随时可能变成主库，所以主备库选用相同规格的机器，并且做对称部署。
• 备库的压力大。主库既然提供了写能力，那么备库可以提供一些读能力。或者一些运营后台需要的分析语句，不能影响正常业务，所以只能在备库上跑。由于主库直接影响业务，大家使用起来会比较克制，反而忽视了备库的压力控制。结果就是，备库上的查询耗费了大量的 CPU 资源，影响了同步速度，造成主备延迟。这种情况，一般可以这么处理：一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力。
• 大事务，因为主库上必须等事务执行完成才会写入 binlog，再传给备库。所以，如果一个主库上的语句执行 10 分钟，那这个事务很可能就会导致从库延迟 10 分钟。不知道你所在公司的 DBA 有没有跟你这么说过：不要一次性地用 delete 语句删除太多数据。其实，这就是一个典型的大事务场景。比如，一些归档类的数据，平时没有注意删除历史数据，等到空间快满了，业务开发人员要一次性地删掉大量历史数据。同时，又因为要避免在高峰期操作会影响业务（至少有这个意识还是很不错的），所以会在晚上执行这些大量数据的删除操作。结果，负责的 DBA 同学半夜就会收到延迟报警。然后，DBA 团队就要求你后续再删除数据的时候，要控制每个事务删除的数据量，分成多次删除。另一种典型的大事务场景，就是大表 DDL。

延迟来源之 - 备库的并行复制能力

同步策略

「同步策略」：Master会等待所有的Slave都回应后才会提交，这个主从的同步的性能会严重的影响。

「半同步策略」：Master至少会等待一个Slave回应后提交。

「异步策略」：Master不用等待Slave回应就可以提交。

「延迟策略」：Slave要落后于Master指定的时间。

对于不同的业务需求，有不同的策略方案，但是一般都会采用最终一致性，不会要求强一致性，毕竟强一致性会严重影响性能。