读写分离有哪些坑?

读写分离基本架构.png

读写分离的主要目标是: 分摊主库的压力. 一般有两种架构. 客户端主动做负载 和 proxy做负载.

两种负载方式的差异:

1. Client负载、少了一层proxy转发、查询性能稍微好一些、且整体架构简单、排查问题方便、
但与DB层耦合性高、若出现主备切换或者库迁移、Client需要调整连接信息
2. proxy负载. 对Client友好、但proxy本身也需要高可用架构、整体架构设计较复杂.

不管采用哪种负载方式, 都会存在从库读到系统过期状态的现象, 称为过期读.
那么、如何解决过期读呢 ?
一、强制走主库
其实就是将查询分类、对于必须拿到最新结果的请求、强制转发到主库; 对于可以接受稍微延迟的请求、转发给从库. 但: 极端情况下、可能所有的请求都不能接受延迟、这样所有请求都打到主库、就失去了扩展性.

二、sleep一段时间
eg. 查询数据之前、先强制等待一段时间、但会失去用户体验度. 不过可以折中、用Ajax将客户端输入内容直接展示在页面上、而不去查询DB.
存在的问题是:

1. 若查询本可以0.5s就从从库拿到结果、也会等1s
2. 若延迟超过1s、还是会出现过期读.

三、判断主备无延迟

1. 每次从库查询前、先判断seconds_behind_master值、直到=0、才执行查询请求.

2. 对比位点、确保主备无延迟
   master_log_file 和 read_master_log_pos, 表示读到的主库的最新位点
   relay_master_log_file 和 exec_master_log_pos表示备库执行的最新位点
   这两组值完全相同时、表示接收的日志已完成同步.

3. 对比gtid
   auto_position=1, 表示主备关系使用了gtid协议
   retrieved_gtid_set, 表示的是备库收到的所有日志gtid集合
   executed_gtid_set, 是备库已经执行完成的gtid集合
   这两个集合相同、表示接收到的日志已同步完成.

   2、3两个方案都是基于备库接收到的日志执行完成了、但还有一部分日志是: Client已经收到提交确认、但备库还未收到日志的状态、所以, 比1要好些、但未达到精准的程度.

四、配合semi-sync方案
对于上边的问题、可以解决不? 利用版同步复制、semi-sync replication可以.
semi-sync设计:

1. 事务提交时、将binlog发给从库
2. 从库收到binlog、给主库发送一个ack、代表收到了
3. 主库收到ack以后、才返回给客户端事务完成的确认.
   这样, 使用semi-sync配合前边的位点判断、就可以确定从库上执行的查询请求、避免过期读

但: 一主多从的场景下、主库只要等到一个从库的ack、就开始对Client返回确认、这时可能会存在过期读(查询请求落到了非确认的从库上)

判断同步位点还有一个潜在问题: 若业务更新的高峰期、可能出现主库的位点或者GTID集合更新很快、导致位点等着判断一直不成立、从库迟迟无法响应的情况. 其实、我们并不需要完全同步、只希望要查询的数据已经同步即可.

五、等主库位点
可以解决上边两个问题:

1. 一主多从时、部分从库过期读
2. 过度等待

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

执行逻辑:

1. 从库上执行
2. file 和 pos 指主库上的文件名 和 位置
3. timeout 可选、设为正整数N表示这个函数最多等待N秒
   正常返回一个正整数M、表示从命令开始执行、到应用完file和pos代表的binlog位置、执行了多少事务.
   其它返回值:
4. null、表示执行期间、备库同步线程发生异常
5. -1、超过等待时间Ns
6. 0、刚开始执行时、发现该位置已经执行过了.
   则、查询逻辑变成了:

1. trx1更新完成后、马上执行 show master status 得到当前主库执行到的File 和 Pos
2. 选择一个从库执行查询语句
3. 在从库上执行 select master_pos_wait(File, Pos, 1);
4. 若返回值是>=0的正整数、则在该从库查询、否则到主库查询
同样存在的问题是: 若所有从库都延迟了、查询压力会打到主库

一般对于不允许过期读的要求、有两种方案: 超时放弃 和 转到主库, 要根据业务选择.

六、等GTID
若开启GTID模式、同样有等待GTID的方案

select wait_for_executed_gtid_set(gtid_set, 1);

执行逻辑:

1. 等待、直到该库执行的事务中包含传入的gtid_set、返回0
2. 超时返回1
   5.7.6版本开始、可以把事务的gtid返回给客户端
   此时、等GTID的执行流程就变成:

1. trx1事务更新完后、从返回包之间获取事务的gtid、记为gtid1
2. 选定一个从库执行查询语句
3. 在从库上执行 select wait_for_Executed_gtid_set(gtid1, 1);
4. 若返回0、则在该从库执行查询、否则、到主库执行查询.

问题跟等位点的一样、选择超时放弃还是转到主库查询、要根据业务场景选择.

思考:

若系统采用的是等待GTID的方案、此时要对一个大表做DDL、可能会出现什么情况呢? 为避免这种情况、改怎么做呢 ?

    这是一个典型的大事务的场景、若该DDL语句在主库执行了10min、提交到备库、也需要执行10min、
那么在主库DDL之后再提交的事务的GTID、去备库查的时候、就会等待10min才出现. 这样这个读写分离机制
至少10min内都会超时、既然是预期内的操作、应该在业务低峰期进行、确保主库可以支撑所有的业务查询、
然后把请求都切到主库、再在主库上做DDL.