什么是高可用？ MySQL的主次延迟有哪些陷阱？有主备切换策略吗？

来源|微科技（ID：weiguanjishu）授权转载，原创公众号

作为一名开发同学，大家都必须了解MySQL，比如常见的事务函数❙隔离级别， 索引等

今天我们来聊一个关于MySQL的深度话题高可用

1。什么是高可用？

来自维基百科的定义：

高可用性（高可用性，缩写HA）是指系统能够不间断地执行其功能，代表系统可用性。高可用性通常是通过提高系统的容错能力来实现的。

MySQL高可用是如何实现的？

首先看图

流程：

• 一开始主要处理流程是场景一
• 客户端❀访问♻
• 主数据库同步数据与备用数据库通过某种机制实时进行。
• 当主数据库突然出现故障（如磁盘损坏等）时，无法正常响应客户端的请求。此时自动主备切换，并进入场景2
• 客户端读写，从而访问备库（此时备库已升级为新的主库）数据库）

看起来很简单，那么我们可以高枕无忧吗？ ？ ？兄弟，想太多了

主备切换确实可以保证高可用。但有一个前提：主备数据库的数据必须同步。但

数据同步是异步操作，无法实时发生，所以主备延时一定存在，而主延时是多少？

• 主库完成事务并写入binlog。 binlog中有一个time字段，用于记录主库写入的时间[时间t1]
• binlog与备库同步，备库接收并存储在中继日志中[ time t2]
• 备机状态下 SQL 数据库启动线程运行 binlog，数据将写入备库表 [time t3]

主备延迟时间计算公式：

t3 - t1

如果有简单的命令，直接查看。运行命令show status of Slave instandby Database

seconds_behind_master，指定落后当前备库

多少秒，细心的同学会有疑问。 t3和t1属于两台机器。如果时钟不一致，该怎么办？

初始化时，备库连接主库，执行SELECT UNIX_TIMESTAMP()获取当前主库的系统时间。

如果发现主库的系统时间与备库的系统时间不一致，备库在计算seconds_behind_master时会自动减去这个差值。

注意：

binlog 数据传输时间（t2 - t1）非常短，可以忽略。主要延迟是在备库Binlog日志的执行

3。 主备延时模式常见原因

1.备库机器配置不好

这个不难理解，“门当户对”和“志同道合”，如果主备机性能差异较大，会直接导致备份数据库的同步速度跟不上主数据库的生产节奏。

就像跑步一样，后面的差距会越来越大。

解决方案：

1。更新备用数据库计算机配置

2。他们是否在备用数据库上做私人工作

除了提供正常的阅读之外，其他人是否也在使用备用数据库？运营数据统计等特殊业务征用此类操作会消耗系统资源，也会影响数据同步的速度。

解决方案：

可以利用大数据平台和异构数据来满足各种特殊的统计查询。

3。大交易

我们知道只有当交易被确认时才会生成binglog。

如果您正在处理较大的交易，则执行时间会相当长（例如5分钟）。虽然备库拿到binlog很快，但是在备库上开始回放也需要差不多的时间，同样需要5分钟（在备库中，只有在事务提交发送后才可以）备库实际上对外可见。），导致主备延迟较大。

例如，谨慎使用删除操作从表名中删除。建议批量删除，减少大事务。

4。如果主数据库不可用，主备故障转移策略是什么？

1。可靠性第一

当主库 A 出现故障，变得不可用时，开始主备切换

• 首先检查 B 库 seconds_behind_master 是否小于设定的阈值（例如 4 秒）。如果满足条件
• ，则将库A更改为只读，并将只读设置为true。中止 A 库的写入操作，确保不会有新的写入进入 B 库
• 评估 B 库的 times_behind_master，直至为 0
• 调整 B 库的读写状态
• 客户端请求命中库B

此时主备模式切换完成。 ？写服务。

2。可用性优先

当然，我们也可以一开始就将操作切换到备库，而不需要等待主备数据同步。

这样备库的流量可以来自两个来源：

• 主库之前剩余的流量记录
• 新客户端请求传入的流量

两部分流量的影响对数据一致性别有一定影响。

我们来做个实验：

第一次创建用户表：

CREATE TABLE `person` (
  `id`  bigint(20) unsigned  NOT NULL AUTO_INCREMENT,
  `name` varchar(32) ,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

插入2条记录

insert into person(name) values ("tom");
insert into person(name) values ("jerry");

实验1：binlog_format=格式

说明：row模式，写bin时日志，所有字段的值都会被记录

同步数据时，A库和B库会报主键冲突。最终只有一行数据不一致，但是数据丢失了。

优点：可以在同步过程中及早发现问题。

实验2：

将binlog格式设置为command或mixed

同步原来的SQL bin可以看到数据项数量不会少，但是主键id会出现混乱。

3。结论

本着“要对付外部，首先要解决内部的情况”，我们的第一选择就是保证内部数据的准确性。所以一般建议大家先选择可靠性。

但是，优先考虑可靠性可能会导致数据库在一段时间内不可用。该时间值取决于主要和次要延迟时间。

因此，我们应该尽可能减少主备数据库的延迟时间，这样在主库故障后，备库能够更快地同步数据，完成主备切换，保证主备数据库的正常运行。服务可以更快恢复。