28 | MySQL读写分离之主从延迟解决方案（主从延迟问题有救了）

一、前言

今天的这篇文章感觉有点难理解，最近这几篇其实都不太好理解。先整理自己的思路让自己更加好理解点～

二、正文

2.1.当下的主从架构都有哪两种？区别是什么？优缺点是什么？

1）客户端至连、2）proxy代理
第一种方式需要将连接信息放在客户端的链接层，客户端来选择后段数据库进行查询。第二种方式客户端只连接proxy，由proxy根据请求类型和上下文决定请求的分发路由。
第一种优点：查询性能好；缺点：在主备切换和库迁移等操作时候客户端需要感知调整连接信息【一般会有一个zk组件来管理后端】。第二种优点：客户端不需要关注后端工作；缺点：结构复杂。

2.2.针对于“过期读”的解决方案有哪六种方案？

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

2.3.什么时候会强制读主库？

金融场景较多。

2.4.Sleep方案查询命令是什么？弊端是什么？

select sleep(1)。弊端是略陋，等1秒这个事情随着业务的增产是在变化的。

2.5.主从无延迟有哪三种做法？每种的缺点是什么？

通过show slave status判断seconds_behind_master是否为0。秒级别，精确度不高。
通过show slave status中读到的主库最新位点信息[Read_Master_Log_Pos]和备库执行的最新位点信息[Exec_Master_Log_Pos]是否一致来判断。
通过show slave status中auto_position=1和备库收到的所有日志的GTID集合[Retrieved_Gtid_Set]和执行的所有GTID集合[Executed_Gtid_Set]是否一致。通过位点和GTID方式相对于seconds_behind_master精确度较高，因为是单个事务级别的精确度，做不到完全精度。

2.5.1.上述主备无延迟的判断依据是什么？为什么通过位点的方式来判断主从无延迟做不到完全精度（从binlog的主备之间的执行状态描述）？

备库收到的日志都执行完成。
一个事务的 binlog 在主备库之间需要经过三步：1）主库执行完成，写入binlog，反馈给客户端。2）备库接受主库发送的binlog。3）备库执行完成binlog。原因就是：其中在第1步执行完后，就有一个查询请求导致备库没有还没有同步过来binlog。--如何解决？就是配合semi-sync方案

2.6.semi-sync replication是什么意思？如何解决的主库和备库由于主从延迟造成的binlog堆积？这种方案的问题是什么？如何解决

半同步复制。
1）主库接执行完命令后写入binlog后，发送binlog给备库。2）备库接受到binlog后，告诉主库自己接受到了。3）主库接受到ack后返回给客户端事务执行完成。PS：同TCP三次握手原理。
两个问题：1）仅支持一主一备的情况。当有一主多从时其中有一个从库ack后，另外的从库没有确认这时有查询请求过来会出现过期读。2）在持续延迟的情况下，可能出现过度等待的问题。比如：主库更新快导致两个位点的判断一直不准确，即relay log中始终比binlog多出一个日志，所以此时查询请求就一直处于阻塞（如下图）。

通过等主库位点和等GTID方案。

2.7.等主库位点的命令是什么？在什么地方执行？返回结果的含义？如何选定命令中的pos[位置？这个方案有什么问题？

select master_pos_wait(file, pos[, timeout]);
从库执行
四种情况：1）正常返回M，表示从命令开始执行，到应用完主库 file 和 pos 表示的 binlog 位置，执行了多少事务。2）如果执行期间，备库同步线程发生异常，则返回 NULL。3）等待超过timeout描述返回-1。4）如果刚开始执行的时候，就发现已经执行过这个位置了，则返回 0。
1）trx1 事务更新完成后，马上执行 show master status 得到当前主库执行到的 File 和 Position；2）选定一个从库执行查询语句；3）在从库上执行 select master_pos_wait(File, Position, 1)；4）如果返回值是 >=0 的正整数，则在这个从库执行查询语句；5）否则，到主库执行查询语句。
一旦在timeout时间之后就会有请求到主库，给主库造成压力

2.8.等GTID的命令是什么？返回结果的含义是什么？比上一种好在什么地方？如何选定命令中的gtid_set？这个方案有什么问题？

select wait_for_executed_gtid_set(gtid_set, 1);
等待，直到这个库执行的事务中包含传入的 gtid_set，返回 0；超时返回 1。
无需在主库上执行 show master status
1）trx1 事务更新完成后，从返回包直接获取这个事务的 GTID，记为 gtid1【⭐️：如何在事务执行完带上gtid？将参数 session_track_gtids 设置为 OWN_GTID，然后通过 API 接口 mysql_session_track_get_first 从返回包解析出 GTID 的值即可】；2）选定一个从库执行查询语句；3）在从库上执行 select wait_for_executed_gtid_set(gtid1, 1)；4）如果返回值是 0，则在这个从库执行查询语句；5）否则，到主库执行查询语句。
问题同上

三、评论专区

3.1.MySQL 是怎么快速定位 binlog 里面的某一个 GTID 位置的？

答案是，在 binlog 文件头部的 Previous_gtids 可以解决这个问题。

3.2.sql_slave_skip_counter 跳过的是一个 event，还是一个事务？

答：由于 MySQL 总不能执行一半的事务，所以既然跳过了一个 event，就会跳到这个事务的末尾，因此 set global sql_slave_skip_counter=1;start slave 是可以跳过整个事务的

四、课后题

当采用等 GTID 的方案，现在你要对主库的一张大表做 DDL，可能会出现什么情况呢？为了避免这种情况，你会怎么做呢？

答：这条语句在主库上要执行 10 分钟，提交后传到备库就要 10 分钟（典型的大事务）。那么，在主库 DDL 之后再提交的事务的 GTID，去备库查的时候，就会等 10 分钟才出现。这样，这个读写分离机制在这 10 分钟之内都会超时，然后走主库。这种预期内的操作，应该在业务低峰期的时候，确保主库能够支持所有业务查询，然后把读请求都切到主库，再在主库上做 DDL。等备库延迟追上以后，再把读请求切回备库。