MySQL主从复制（五）：读写分离

一主多从架构主要应用场景：读写分离。读写分离的主要目标是分摊主库的压力。

读写分离架构

读写分离架构一

架构一结构图：

这种结构模式下，一般会把数据库的连接信息放在客户端的连接层，由客户端主动做负载均衡。也就是说由客户端来选择后端数据库进行查询。

读写分离架构二

架构二结构图：

该架构模式下，在MySQL和客户端之间有一个中间代理层proxy，客户端只连接proxy，由proxy根据请求类型和上下文决定请求的分发路由。

两种架构的区别

1）客户端直连方案

因为少了一层proxy转发，所以查询性能稍微好一点儿，并且整体架构简单，排查问题更方便。但是这种方案，由于要了解后端部署细节，所以在出现主备切换、库迁移等操作的时候，客户端都会感知到，并且需要调整数据库连接信息。

你可能会觉得这样客户端也太麻烦了，信息大量冗余，架构很丑。其实也未必，一般采用这样的架构，一定会伴随一个负责管理后端的组件，比如Zookeeper，尽量让业务端只专注于业务逻辑开发。

2）带proxy架构

带proxy的架构，对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由proxy完成的。但这样的话，对后端维护团队的要求会更高。而且， proxy也需要有高可用架构。因此，带proxy架构的整体就相对比较复杂。

注：无论使用哪种架构都会遇到主从延迟问题（即在从库上会读到系统的一个过期状态），且主从延迟是不能100%避免的。

问：处理主从延迟有哪些方案？

答：主从延迟处理方案有以下几种：

强制走主库方案
Sleep方案
判断主备无延迟方案
配合semi-sync方案
等主库位点方案
等GTID方案

下面对这几种方案详细介绍。

强制走主库方案

强制走主库方案思路：对查询请求进行分类，对于必须要拿到最新结果的请求，强制将其发到主库上。对于可以读到旧数据的请求，才将其发到从库上。

这个方案最大的问题在于，有时候你会碰到“所有查询都不能是过期读”的需求，比如一些金融类的业务。这样的话，你就要放弃读写分离，所有读写压力都在主库，等同于放弃了扩展性。

尽管如此，该方案仍是用的最多的一种方案。

Sleep方案

Sleep方案思路：主库更新后，读从库之前先sleep一下。具体的方案就是，类似于执行一条select sleep(1)命令。

注：这个方案的假设是，大多数情况下主备延迟在1秒之内，做一个sleep可以有很大概率拿到最新的数据。

示例：

以卖家发布商品为例，商品发布后，用Ajax（Asynchronous JavaScript + XML，异步JavaScript和XML）直接把客户端输入的内容作为“新的商品”显示在页面上，而不是真正地去数据库做查询。

这样，卖家就可以通过这个显示，来确认产品已经发布成功了。等到卖家再刷新页面，去查看商品的时候，其实已经过了一段时间，也就达到了sleep的目的，进而也就解决了过期读的问题。

但从严格意义上来说，这个方案存在不精确问题。这个不精确主要包含两层意思：

1）假设一个查询请求原本可以在0.5s就可以在从库上拿到正确结果，此时也会等1s。

2）如果延迟超过1s，还是会出现主从延迟。

判断主备无延迟方案

确保备库无延迟，通常有以下三种做法：

查看seconds_behind_master确保主备无延迟

每次从库执行查询请求前，先执行show slave status\G判断seconds_behind_master是否已经等于0。如果还不等于0 ，那就必须等到这个参数变为0才能执行查询请求。注：seconds_behind_master的单位是秒。show slave status\G结果的部分截图：

对比位点确保主备无延迟

1）Master_Log_File和Read_Master_Log_Pos，表示的是读到的主库的最新位点。

2）Relay_Master_Log_File和Exec_Master_Log_Pos，表示的是备库执行的最新位点。

如果Master_Log_File和Relay_Master_Log_File、 Read_Master_Log_Pos和Exec_Master_Log_Pos这两组值完全相同，就表示接收到的日志已经同步完成。

show slave status\G结果部分截图：

对比GTID集合确保主备无延迟

1）Auto_Position=1 ，表示这对主备关系使用了GTID协议。

2）Retrieved_Gtid_Set，是备库收到的所有日志的GTID集合。

3）Executed_Gtid_Set，是备库所有已经执行完成的GTID集合。

如果这两个集合相同，也表示备库接收到的日志都已经同步完成。

可见，对比位点和对比GTID这两种方法，都要比判断seconds_behind_master是否为0更准确。

show slave status\G结果部分截图：

问：在执行查询请求之前，先判断从库是否同步完成的方法，相比于sleep方案，准确度确实提升了不少，但还是没有达到“精确”的程度。为什么这么说呢？

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

1）主库执行完成，写入binlog，并反馈给客户端。

2）binlog被从主库发送给备库，备库收到。

3）在备库执行binlog完成。

上面判断主备无延迟的逻辑，是“备库收到的日志都执行完成了”。但是，从binlog在主备之间状态的分析中，不难看出还有一部分日志，处于客户端已经收到提交确认，而备库还没收到日志的状态。

示例场景如下：

这时，主库上执行完成了三个事务trx1、 trx2和trx3，其中：

1）trx1和trx2已经传到从库，并且已经执行完成了。

2）trx3在主库执行完成，并且已经回复给客户端，但是还没有传到从库中。

如果这时候你在从库B上执行查询请求，按照我们上面的逻辑，从库认为已经没有同步延迟，但还是查不到trx3的。严格地说，就是出现了主从延迟。

配合semi-sync方案

该方案可以解决“对比GTID集合确保主备无延迟”中提到的不“精确”问题。

semi-sync replication（半同步复制）主备间的状态：

1）事务提交的时候，主库把binlog发给从库。

2）从库收到binlog后，给主库返回一个ack，表示收到了。

3）主库收到这个ack后，才能给客户端返回“事务完成”的确认。

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

问1：如果主库掉电的时候，有些binlog还来不及发给从库，会不会导致系统数据丢失？

1）如果使用的是普通的异步复制模式，则有可能会丢失数据。

2）如果使用的是semi-sync+位点判断的方案，则可以解决数据丢失问题。

需要注意的是，semi-sync+位点判断的方案，只对一主一备的场景成立。在一主多从场景中，主库只要等到一个从库的ack，就会开始给客户端返回确认。此时，在从库上执行查询请求，有以下两种情况：

1）如果查询落在这个响应了ack的从库上，能够确保读到最新数据。

2）如果查询落到其它从库上，他们可能还没有收到最新的日志，就可能会产生主从延迟。

注：如果在业务高峰期，主库的位点或者GTID集合更新很快，那么上面的两个位点等值判断就会一直不成立，很可能出现从库上迟迟无法响应查询请求的情况。

问2：当发起一个查询请求后，如果要求得到准确结果，是否需要等到“主备完全同步”，才能执行查询请求？

答：不需要。

示例如下：

图中备库B下的虚线框，分别表示relaylog（备库执行的最新位点）和binlog中的事务。可以看到，图中从状态1 到状态4，一直处于延迟一个事务的状态。

备库B一直到状态4都和主库A存在延迟，如果用上面必须等到无延迟才能查询的方案， select语句直到状态4都不能被执行。

但是，其实客户端是在发完trx1更新后发起的select语句，我们只需要确保trx1已经执行完成就可以执行select语句了。也就是说，如果在状态3执行查询请求，得到的就是预期结果了。

semi-sync+主备无延迟方案，存在两个问题：

1）一主多从的时候，在某些从库执行查询请求会存在主从延迟问题。

2）在持续延迟的情况下，可能出现过度等待的问题。

等主库位点方案

该方案能解决“semi-sync+主备无延迟方案”存在的两个问题。

下面先来看一条命令：

select master_pos_wait(file, pos[, timeout]);

这条命令的逻辑如下：

1）它是在从库执行的。

2）参数file和pos指的是主库上的文件名和位置。

3）timeout可选，设置为正整数N表示这个函数最多等待N秒。

这条命令返回结果如下：

1）如果执行期间，备库同步线程发生异常，则返回NULL。

2）如果等待超过N秒，就返回-1。

3）如果刚开始执行的时候，就发现已经执行过这个位置了，则返回0。

4）如果返回的是一个正整数M，表示从命令开始执行，到应用完file和pos表示的binlog位置，执行了多少事务。

对于上图中先执行trx1，再执行一个查询请求的逻辑，要保证能够查到正确的数据，我们可以使用这个逻辑：

1）trx1事务更新完成后，马上执行show master status得到当前主库执行到的File和Position。

2）选定一个从库执行查询语句。

3）在从库上执行select master_pos_wait(File, Position, 1)。

4）如果返回值是>=0的正整数，则在这个从库执行查询语句。

5）否则，到主库执行查询语句。

上述逻辑流程图：

这里我们假设，这条select查询最多在从库上等待1秒。那么，如果1秒内master_pos_wait返回一个大于等于0的整数，就确保了从库上执行的这个查询结果一定包含了trx1的数据。

步骤5到主库执行查询语句，是这类方案常用的退化机制（兜底方案）。因为从库的延迟时间不可控，不能无限等待，所以如果等待超时，就应该放弃，然后到主库去查。

GTID方案

MySQL中同样提供了一个类似的命令：

select wait_for_executed_gtid_set(gtid_set, 1);

这条命令的逻辑是：

1）等待，直到这个库执行的事务中包含传入的gtid_set，返回0。

2）超时返回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）否则，到主库执行查询语句。

上述逻辑流程图：

问：怎么能够让MySQL在执行事务后，返回包中带上GTID呢？

答：把参数session_track_gtids设置为OWN_GTID，然后通过API接口mysql_session_track_get_first从返回包解析出GTID的值即可。

小结：思考题

思考：假设你的系统采用了等GTID的方案，现在你要对主库的一张大表做DDL，在做读写分离时可能会出现什么情况呢？为了避免这种情况，你会怎么做呢？

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

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

这种预期内的操作，应该在业务低峰期的时候，确保主库能够支持所有业务查询，然后把读请求都切到主库，再在主库上做DDL。等备库延迟追上以后，再把读请求切回备库。

通过这个思考题，我主要想让关注的是，大事务对等位点方案的影响。

当然了，使用gh-ost方案来解决这个问题也是不错的选择。