加速MySQL主从同步，核心架构设计思路！（第23讲）

《架构师之路：架构设计中的100个知识点》

23.MySQL主从同步加速架构

MySQL主从同步为什么这么慢？

如上所示，主库binlog同步到从库，从库单线程落盘relaylog，单线程重放relaylog，在数据量大并发量大的时候，就会很慢。

如何来进行优化？

可以多线程并行重放relaylog来缩短同步时间。

多线程并行重放能否保证与主库数据的一致性？

例如：三个set语句，分在三个线程重放，不能保障与主库执行序列的一致性。

update X set money=100 where uid=58;

update X set money=150 where uid=58;

update X set money=200 where uid=58;

随机分配肯定不行，但可以按库来分配：

（1）同一个MySQL实例中的同一个DB库，由一个线程来重放；

（2）不同的DB库，由不同的线程来并行重放；

以此来够缩短同步时间。

为什么很多公司还是同步很慢呢？

这个锅DBA不背。

大概是架构师在数据库架构设计时，MySQL使用了单库多表模式，升级为多库多表模式即可。

画外音：单库多表模式，还是一个线程重放。

数据库架构，多库多表模式有什么好处？

（1）主从同步快；

（2）逻辑上还能按照业务子业务进行库隔离；

（3）扩容方便，性能出现瓶颈时，加实例就能拆库扩容；

架构师说拆不开怎么办？

要么是架构师不懂，要么是把业务实现在SQL语句里了，导致拆不开。

如果已经是单库多表模式，库无法拆分开，还有其它方法缩短主从同步时间吗？

可以进一步优化：将主库上同时并行执行的事务，分为一组，编一个号，这些事务在从库上的回放也可以并行执行。

画外音：事务在主库上的执行同时进入到prepare阶段，说明事务之间没有冲突，否则就不可能提交。

简言之：同一组提交的事务，没有锁冲突，可以并行重放。

MySQL将组提交的信息存放在GTID中，使用mysqlbinlog工具，可以看到组提交内部的内部信息：

14:15 XXX GTID last_committed=0 sequence_numer=1

14:15 XXX GTID last_committed=0 sequence_numer=2

14:15 XXX GTID last_committed=0 sequence_numer=3

14:15 XXX GTID last_committed=0 sequence_numer=4

如果具备相同的last_committed，说明它们在一个组内，可以并发回放执行。

总结

mysql并行复制，缩短主从同步时延的核心架构思路无非两点：

（1）单线程回放，升级为多线程并发回放；

（2）确保并发回放幂等性：“按照库幂等”，“按照组幂等”是两种不同颗粒度的实现方式；

更具体的

mysql5.5 -> 不支持并行复制，赶紧升级mysql；

mysql5.6 -> 支持按照库并行复制，赶紧升级“多库”架构；

mysql5.7 -> 支持按照GTID并行复制；

知其然，知其所以然。

==全文完==

宝藏号，置顶标星，日更好文。

点赞，转发，在看三连。感谢！