凯子の博客

代码的成神之路

0%

MySql——如何保证高可用

发表于 分类于 Valine： 2.1k 2 分钟
MySql——如何保证高可用

主备延迟

img

  • 主备切换可能是一个主动运维动作，比如软件升级、主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电。

  • 在介绍主动切换流程的详细步骤之前，我要先跟你说明一个概念，即“同步延迟”。与数据同步有关的时间点主要包括以下三个：

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

  • 所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。

  • 你可以在备库上执行 show slave status 命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。

  • seconds_behind_master 的计算方法是这样的：

    1. 每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间；
    2. 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到 seconds_behind_master。

  • 所以说，主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。

主备延迟的来源

有些部署条件下，备库所在机器的性能要比主库所在的机器性能差。但实际上，更新过程中也会触发大量的读操作。所以，当备库主机上的多个备库都在争抢资源的时候，就可能会导致主备延迟了。

解决方法是：采用对称部署，也就是说让备库和主库所在的机器性能一致，这样做也方便了主备切换

备库的压力大。一般的想法是，主库既然提供了写能力，那么备库可以提供一些读能力。或者一些运营后台需要的分析语句，不能影响正常业务，所以只能在备库上跑。结果就是，备库上的查询耗费了大量的 CPU 资源，影响了同步速度，造成主备延迟。

解决办法是：

  1. 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。
  2. 通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力。

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

  • 另外，导致主备延迟的还有大表DDL和备库的并行能力等等。

可靠性优先策略

  • 在上图双M的转换，详细过程如下：
    1. 判断备库 B 现在的 seconds_behind_master，如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步；
    2. 把主库 A 改成只读状态，即把 readonly 设置为 true；
    3. 判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；
    4. 把备库 B 改成可读写状态，也就是把 readonly 设置为 false；
    5. 把业务请求切到备库 B。

img

  • 这个策略的优点是可靠性高，不会导致数据的不一致问题，但缺点也很明显，就是第三步需要等待second_behind_master的值变为0，这会导致整个系统处于一种不可用状态。

可用性优先策略

  • 可用性优先策略就是把可靠性优先策略的第四五步调到最前面，保证系统没有不可用的时间。但是这么做就会导致主备库数据不一致的问题。
  • 举个例子：有一张表，并插入两行数据
1
2
3
4
5
6
7
8
9
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(c) values(1),(2),(3);
/*========================*/
insert into t(c) values(4);
insert into t(c) values(5);
  • 假设，现在主库上其他的数据表有大量的更新，导致主备延迟达到了5秒，当插入一条c=4的语句后，发生了主备切换。
  • 如果此时binlog_format=mixed，用可用性优先策略进行切换，将会是如下情况：

img

  • 具体流程：

    1. 步骤 2 中，主库 A 执行完 insert 语句，插入了一行数据（4,4），之后开始进行主备切换。
    2. 步骤 3 中，由于主备之间有 5 秒的延迟，所以备库 B 还没来得及应用“插入 c=4”这个中转日志，就开始接收客户端“插入 c=5”的命令。
    3. 步骤 4 中，备库 B 插入了一行数据（4,5），并且把这个 binlog 发给主库 A。
    4. 步骤 5 中，备库 B 执行“插入 c=4”这个中转日志，插入了一行数据（5,4）。而直接在备库 B 执行的“插入 c=5”这个语句，传到主库 A，就插入了一行新数据（5,5）。

  • 最后的结果就是，主库 A 和备库 B 上出现了两行不一致的数据。可以看到，这个数据不一致，是由可用性优先流程导致的。

  • 如果把binlog_format设置成row格式，这时由于row格式下的binlog会记录数据行的所有字段，并是使用rowid进行应用的，所以回报重复主键异常，具体流程如下：

    img

  • 所以，主备切换一般采用可靠性优先策略，毕竟数据的可靠性是要优于可用性的。

-------------本文结束感谢您的阅读-------------