目录

18 MySQL 读写分离

读写分离,以及怎么处理主备延迟导致的读写分离问题。

1. 读写分离

读写分离的主要目标就是分摊主库的压力。一般有两种架构:

  1. 客户端(client)主动做负载均衡,即由客户端自己选择连接的 mysql 服务器
  2. 在 MySQL 和客户端之间有一个中间代理层 proxy,客户端只连接 proxy, 由 proxy 根据请求类型和上下文决定请求的分发路由。

两种架构的对比:

  1. 客户端直连方案,因为少了一层 proxy 转发,所以查询性能稍微好一点儿,并且整体架构简单,排查问题更方便。但是这种方案,由于要了解后端部署细节,所以在出现主备切换、库迁移等操作的时候,客户端都会感知到,并且需要调整数据库连接信息。一般采用这样的架构,一定会伴随一个负责管理后端的组件,比如 Zookeeper,尽量让业务端只专注于业务逻辑开发。
  2. 带 proxy 的架构,对客户端比较友好。客户端不需要关注后端细节,连接维护、后端信息维护等工作,都是由 proxy 完成的。但这样的话,对后端维护团队的要求会更高。而且,proxy 也需要有高可用架构。因此,带 proxy 架构的整体就相对比较复杂。

但是无论那种将架构,由于主从可能存在延迟,客户端执行完一个更新事务后马上发起查询,如果查询选择的是从库的话,就有可能读到刚刚的事务更新之前的状态。

主从延迟是不能 100% 避免的。不论哪种结构,客户端都希望查询从库的数据结果,跟查主库的数据结果是一样的。接下来,我们就来讨论怎么处理过期读问题。通常有下面这些解决方案:

  1. 强制走主库方案;
  2. sleep 方案;
  3. 判断主备无延迟方案;
  4. 配合 semi-sync 方案;
  5. 等主库位点方案;等 GTID 方案。

1.1 强制走主库方案

  1. 对于必须要拿到最新结果的请求,强制将其发到主库上。
  2. 对于可以读到旧数据的请求,才将其发到从库上

这个方案最大的问题在于,有时候你会碰到“所有查询都不能是过期读”的需求。

1.2 Sleep 方案

这个方案的假设是,大多数情况下主备延迟在 1 秒之内,主库更新后,读从库之前先 sleep 一下。

典型的场景是商品发布后,用 Ajax(Asynchronous JavaScript + XML,异步 JavaScript 和 XML)直接把客户端输入的内容作为“新的商品”显示在页面上,而不是真正地去数据库做查询。等到卖家再刷新页面,去查看商品的时候,其实已经过了一段时间,也就达到了 sleep 的目的,进而也就解决了过期读的问题。

如果这个查询请求本来 0.5 秒就可以在从库上拿到正确结果,也会等 1 秒;如果延迟超过 1 秒,还是会出现过期读。

1.3 判断主备无延迟方案

确保备库无延迟,通常有三种做法

  1. 查询前,判断 seconds_behind_master 是否为 0
  2. 采用对比位点和 GTID 的方法来确保主备无延迟

下图是 show slave status 结果的部分截图 /images/mysql/MySQL45%E8%AE%B2/show_slave_status.png

对比位点

  1. Master_Log_File 和 Read_Master_Log_Pos,表示的是读到的主库的最新位点;
  2. Relay_Master_Log_File 和 Exec_Master_Log_Pos,表示的是备库执行的最新位点。

这两组值完全相同,就表示接收到的日志已经同步完成。

对比 GTID 集合

  1. Auto_Position=1 ,表示这对主备关系使用了 GTID 协议。
  2. Retrieved_Gtid_Set,是备库收到的所有日志的 GTID 集合;
  3. Executed_Gtid_Set,是备库所有已经执行完成的 GTID 集合。

对比位点和对比 GTID 这两种方法,都要比判断 seconds_behind_master 是否为 0 更准确。但还是没有达到“精确”的程度。

一个事务的 binlog 在主备库之间的状态:

  1. 主库执行完成,写入 binlog,并反馈给客户端;
  2. binlog 被从主库发送给备库,备库收到;
  3. 在备库执行 binlog 完成。

们上面判断主备无延迟的逻辑,是“备库收到的日志都执行完成了”。但是,存在客户端已经收到提交确认,而备库还没收到日志的状态。要解决这个问题,需要引入“半同步复制”。semi-sync 配合前面关于位点的判断,就能够确定在从库上执行的查询请求,可以避免过期读。

1.4 配合 semi-sync

semi-sync 做了这样的设计:

  1. 事务提交的时候,主库把 binlog 发给从库;
  2. 从库收到 binlog 以后,发回给主库一个 ack,表示收到了;
  3. 主库收到这个 ack 以后,才能给客户端返回“事务完成”的确认。

也就是说,如果启用了 semi-sync,就表示所有给客户端发送过确认的事务,都确保了备库已经收到了这个日志。

semi-sync+ 位点判断的方案,只对一主一备的场景是成立的。在一主多从场景中,主库只要等到一个从库的 ack,就开始给客户端返回确认。这时对从库的查询请求,落在这个响应了 ack 的从库上,是能够确保读到最新数据;如果不是还是有可能发生过期读。

判断同步位点的方案还有另外一个潜在的问题,即:如果在业务更新的高峰期,主库的位点或者 GTID 集合更新很快,那么上面的两个位点等值判断就会一直不成立,很可能出现从库上迟迟无法响应查询请求的情况。

小结一下,semi-sync 配合判断主备无延迟的方案,存在两个问题:

  1. 一主多从的时候,在某些从库执行查询请求会存在过期读的现象;
  2. 在持续延迟的情况下,可能出现过度等待的问题。

等主库位点方案,就可以解决这两个问题。

1.5 等主库位点

要明白等主库位点,要先明白这条命令: select master_pos_wait(file, pos[, timeout]);

  • 执行逻辑:
    1. 它是在从库执行的;
    2. 参数 file 和 pos 指的是主库上的文件名和位置;
    3. timeout 可选,设置为正整数 N 表示这个函数最多等待 N 秒。
  • 返回结果:
    • 正常返回的结果是一个正整数 M,表示从命令开始执行,到应用完 file 和 pos 表示的 binlog 位置,执行了多少事务
    • 如果执行期间,备库同步线程发生异常,则返回 NULL;
    • 如果等待超过 N 秒,就返回 -1;
    • 如果刚开始执行的时候,就发现已经执行过这个位置了,则返回 0

使用等等主库位点,进行查询的逻辑是这样的:

  1. trx1 事务更新完成后,马上执行 show master status 得到当前主库执行到的 File 和 Position;
  2. 选定一个从库执行查询语句;
  3. 在从库上执行 select master_pos_wait(File, Position, 1);
  4. 如果返回值是 >=0 的正整数,则在这个从库执行查询语句;
  5. 否则,到主库执行查询语句

/images/mysql/MySQL45%E8%AE%B2/waiter_master.png

步骤 5 到主库执行查询语句,是这类方案常用的退化机制。因为从库的延迟时间不可控,不能无限等待,所以如果等待超时,就应该放弃,然后到主库去查。如果所有的从库都延迟超过 1 秒了,那查询压力不就都跑到主库上了吗?确实是这样。

按照我们设定不允许过期读的要求,就只有两种选择,一种是超时放弃,一种是转到主库查询。具体怎么选择,就需要业务开发同学做好限流策略了。

1.6 GTID 方案

select wait_for_executed_gtid_set(gtid_set, 1);

  • 执行逻辑:
    • 等待,直到这个库执行的事务中包含传入的 gtid_set,返回 0;
    • 超时返回 1。在前面等位点的方案中

在前面等位点的方案中,我们执行完事务后,还要主动去主库执行 show master status。而 MySQL 5.7.6 版本开始,允许在执行完更新类事务后,把这个事务的 GTID 返回给客户端,这样等 GTID 的方案就可以减少一次查询。

等 GTID 的执行流程就变成了:

  1. trx1 事务更新完成后,从返回包直接获取这个事务的 GTID,记为 gtid1;
  2. 选定一个从库执行查询语句;
  3. 在从库上执行 select wait_for_executed_gtid_set(gtid1, 1);
  4. 如果返回值是 0,则在这个从库执行查询语句;
  5. 否则,到主库执行查询语句

跟等主库位点的方案一样,等待超时后是否直接到主库查询,需要业务开发同学来做限流考虑。

/images/mysql/MySQL45%E8%AE%B2/waiter_gtid.png

怎么能够让 MySQL 在执行事务后,返回包中带上 GTID 呢?你只需要将参数 session_track_gtids=OWN_GTID,然后通过 API 接口 mysql_session_track_get_first 从返回包解析出 GTID 的值即可。

1.7 方案总结

在实际应用中,这几个方案是可以混合使用的。

比如,先在客户端对请求做分类,区分哪些请求可以接受过期读,而哪些请求完全不能接受过期读;然后,对于不能接受过期读的语句,再使用等 GTID 或等位点的方案。

但话说回来,过期读在本质上是由一写多读导致的。在实际应用中,可能会有别的不需要等待就可以水平扩展的数据库方案,但这往往是用牺牲写性能换来的,也就是需要在读性能和写性能中取权衡。

1.8 大事务的影响

对大表做 DDL 的时候会怎么样。假设,这条语句在主库上要执行 10 分钟,提交后传到备库就要 10 分钟(典型的大事务)。那么,在主库 DDL 之后再提交的事务的 GTID,去备库查的时候,就会等 10 分钟才出现。

这样,这个读写分离机制在这 10 分钟之内都会超时,然后走主库。

这种预期内的操作,应该在业务低峰期的时候,确保主库能够支持所有业务查询,然后把读请求都切到主库,再在主库上做 DDL。等备库延迟追上以后,再把读请求切回备库。当然了,使用 gh-ost 方案来解决这个问题也是不错的选择。