mysql半同步复制单表数据_MYSQL 关于半同步复制

虽然我墙裂的感觉，MGR会成为超越Oracle RAC架构的一种高可用架构，可是现在毕竟还是有点瑕疵。导致第一个吃螃蟹的人，还没真正的出现。企业现在选型应该还是采用的主从的半同步复制。

从Mysql5.7说起：在5.7的时候推出了一种叫loss-less semi-synchronous replication(就是我们说的无损同步啦 今天分享的主角。)Mysql原生，能保证主从数据的一致性。

5.7中配置 rpl_semi_sync_master_wait_point=after_sync 5.6之前默认为after_commit

为什么5.6之前，包括5.6的Mysql没办法做到无损？因为他在做主从切换的时候，会出现幻读(不是数据库层面的幻读)的场景。就是切换之后，你在主库能看到的数据，可能在从库某一时刻并不能看到。

原理就是：rpl_semi_sync_master_wait_point的after_sync是先同步日志，再提交。但是after_commit是先提交在同步。

这样就会引出几个问题，比如这个参数到底是选择哪个value会比较好？很多人都会异口同声的说：选after_sync。 理由大概就是能无损复制。不丢数据。

这里直接给结果，选择AFTER_SYNC没问题。https://www.cndba.cn/supreme_aaron/article/3470

https://www.cndba.cn/supreme_aaron/article/3470

https://www.cndba.cn/supreme_aaron/article/3470https://www.cndba.cn/supreme_aaron/article/3470

下面的如果你对Mysql不需要深入的了解的话就没必要看了。

先开始分析半同步复制原理

一个transaction在rpl_semi模式下到底是怎么实现主从复制的。现在表基本就是innodb的咯，基于innodb来分析。

INNODB REDO FILE WRITE 1

BINLOG FILE FLUSH &SYNC 2

INNODB REDO FILE COMMIT 3 (释放事务持有的锁)

SEND BINLOG TO SLAVE 4

在after_sync 的时候顺序是 1=>2=>4=>3

在after_commit的时候顺序是 1=>2=>3=>4 这里也就是能知道为什么会出现’幻读’.

这样就会引发一个问题：如果我是after_commit我的主库可以在commit一个事务之后。接着在继续写事务。写完一整个binlog再去从库做恢复，回放。如果是after_sync他需要等这个事务同时写到slave上面的relaylog并且在数据库里面回放完毕，才会继续下一个事务。从这上面看是不是懵了？只是这么分析的话commit会比sync优秀。

所以到底是哪个性能更加优秀？答案还是sync!

原因就在于 事务有ACID不会产生事务之间的修改。这样Mysql有一个叫group commit的特性(虽然是单线程的产品)。刚好SYNC的groupcommit比例大于commit。因为commit基本用不上这个特性。但是sync可以用上。

SYNC需要等事物写到slave上，才会提交这样会把后续等待提交的队列拉长。这样groupcommit的比例也将会上升。IO的开销就会变小。当并发到达一定的阈值的时候，SYNC就会逆转commit了。https://www.cndba.cn/supreme_aaron/article/3470https://www.cndba.cn/supreme_aaron/article/3470https://www.cndba.cn/supreme_aaron/article/3470

希望此文能让大家了解下半同步复制，为什么要选择after_SYNC而不是after_commit。

不管是基于数据安全，还是Mysql性能都推荐使用after_SYNC。https://www.cndba.cn/supreme_aaron/article/3470https://www.cndba.cn/supreme_aaron/article/3470

https://www.cndba.cn/supreme_aaron/article/3470

版权声明：本文为博主原创文章，未经博主允许不得转载。