mysql | after_sync 增强半同步是否真的无损

最新推荐文章于 2024-08-24 11:04:30 发布

置顶微风轻轻起

最新推荐文章于 2024-08-24 11:04:30 发布

阅读量1.3k

点赞数 24

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/weixin_43490914/article/details/134977635

版权

关于MySQL主从复制相信大家都耳熟能详，在此就不赘叙。简单说下，引开今天得话题。

主从复制的原理，master dump 线程发送 binlog 到 slave ，slave 上的 io线程接收 binlog 并写入到 slave 上的 relay log 上，slave 上的 sql 线程对 relay log 进行回放。

在这里插入图片描述

MySQL复制分为

1.异步复制（async replication）

主库将更新写入 binlog 日志文件后，不需要等待数据更新是否已经复制到从库中，就可以继续处理更多的请求。master 将事件写入 binlog，但并不知道 slave 是否或何时已经接收且已处理。在异步复制的机制下，如果 master 宕机，事务在 master 上已提交，但很可能这些事务没有传到任何的 slave 上。假设有 master->salve 故障转移的机制，此时 slave 也可能会丢失事务。

2.半同步复制（semi-sync replication）

为了解决异步复制可能导致的数据不一致问题，半同步复制确保至少一个从服务器在事务提交之前已经收到了变更。这意味着如果主服务器发生故障，至少有一个从服务器有最近的数据。

3.同步复制（sync reolication）

在同步复制中，事务在主服务器上的提交要等待所有从服务器确认接收到所有变更。这确保了所有服务器在任何时候都有完全相同的数据。

半同步复制下的俩种模式 after commit 和 after sync

半同步复制 after_commit（5.5，5.6）：事务先在引擎层提交，收到 slave 的 ack 消息确认后才将 commit 的结果返回给客户端。（在收到ack之前，主库的其他客户端是可以看到这条记录的）

增强半同步复制 after_sync（5.7）：主库收到ack消息确认后再在引擎层提交并返回 commit 。这样主库 crash ，所有在主库上已提交的事务都能保证已经同步到了从库的 relay log 中。（无损半同步说的也是这个）

MySQL5.7的半同步复制引入 after_sync 模式，主要是解决了 after_commit 导致的主库 crash 后主从之间数据不一致的问题。在引入 after_sync 模式后，所有提交的数据都已经被复制，故障切换时数据一致性将得到提升。

那么问题来了，无损半同步在故障切换后真的可以无损吗？思考一下。

我们先结合俩阶段提交（2PC），说下故障切换后的崩溃恢复流程
在这里插入图片描述

在 redo prepare 阶段，此时机器宕机会有这几种情况

1.写了 binlog，崩溃恢复机制会让事务会提交。

2.没写 binlog，此时既没有写 binlog，redo 也不完整，事务会回滚。

我们再来看看半同步复制（after commt & after sync）流程图
在这里插入图片描述

简单说，对于半同步复制和增强半同步复制，无非就是主库等待从库返回ack的节点位置不同。

现在我们知道了什么是 after commit & after sync，知道了2PC & cash recover，我们来考虑下面这几种情况。

什么情况增强半同步复制下新主比旧主多数据？新主比旧主少数据呢？

现在我们结合2PC和 cash recover ，来拆分增强半同步复制 after sync。
在这里插入图片描述

1，在时刻A，主库崩溃，毫无疑问，故障转移后，根据崩溃恢复机制，新主和旧主数据一致。

2，在时刻B，主库 binlog 已经写完，从库在接收 binary log 时，主库崩溃，此时从库在接收主库 binary log 写入 relay log 时，没接收完，导致 relay log 不完整，那么从库是回放不了这些 relay log，根据崩溃恢复机制，此时新主会比旧主少事务。

3，那么有没有新主比旧主多事务的可能性呢？？？

个人觉得，起码在 binlog sync = 1这个设置下，是不会的。在此设置下，每次事务提交 binlog 都会立即刷到磁盘上，能传到从库，说明已经写完了。

如果 binlog sync <>1 那么是有可能的，当主库把 binlog 传给从库后，主库操作系统奔溃，此时会丢失 os cache 中的 binlog 缓冲，在奔溃恢复流程下，主库会丢失这个事务的binlog，此时redo日志也不完整，会回滚掉这个事务，对于从库而言，就会多了这个事务，此时新主会比旧主多事务。

对此官方文档其实也有相关说明
在这里插入图片描述