MySQL主從同步為什么這么慢？

如上所示，主庫(kù)binlog同步到從庫(kù)，從庫(kù)單線(xiàn)程落盤(pán)relaylog，單線(xiàn)程重放relaylog，在數(shù)據(jù)量大并發(fā)量大的時(shí)候，就會(huì)很慢。

如何來(lái)進(jìn)行優(yōu)化？

可以多線(xiàn)程并行重放relaylog來(lái)縮短同步時(shí)間。

多線(xiàn)程并行重放能否保證與主庫(kù)數(shù)據(jù)的一致性？

例如：三個(gè)set語(yǔ)句，分在三個(gè)線(xiàn)程重放，不能保障與主庫(kù)執(zhí)行序列的一致性。

update X set money=100 where uid=58;
update X set money=150 where uid=58;
update X set money=200 where uid=58;

隨機(jī)分配肯定不行，但可以按庫(kù)來(lái)分配：

• 同一個(gè)MySQL實(shí)例中的同一個(gè)DB庫(kù)，由一個(gè)線(xiàn)程來(lái)重放；
• 不同的DB庫(kù)，由不同的線(xiàn)程來(lái)并行重放；

以此來(lái)夠縮短同步時(shí)間。

為什么很多公司還是同步很慢呢？

這個(gè)鍋DBA不背。

大概是架構(gòu)師在數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)時(shí)，MySQL使用了單庫(kù)多表模式，升級(jí)為多庫(kù)多表模式即可。

畫(huà)外音：?jiǎn)螏?kù)多表模式，還是一個(gè)線(xiàn)程重放。

數(shù)據(jù)庫(kù)架構(gòu)，多庫(kù)多表模式有什么好處？

• 主從同步快；
• 邏輯上還能按照業(yè)務(wù)子業(yè)務(wù)進(jìn)行庫(kù)隔離；
• 擴(kuò)容方便，性能出現(xiàn)瓶頸時(shí)，加實(shí)例就能拆庫(kù)擴(kuò)容；

架構(gòu)師說(shuō)拆不開(kāi)怎么辦？

要么是架構(gòu)師不懂，要么是把業(yè)務(wù)實(shí)現(xiàn)在SQL語(yǔ)句里了，導(dǎo)致拆不開(kāi)。

如果已經(jīng)是單庫(kù)多表模式，庫(kù)無(wú)法拆分開(kāi)，還有其它方法縮短主從同步時(shí)間嗎？

可以進(jìn)一步優(yōu)化：將主庫(kù)上同時(shí)并行執(zhí)行的事務(wù)，分為一組，編一個(gè)號(hào)，這些事務(wù)在從庫(kù)上的回放也可以并行執(zhí)行。

畫(huà)外音：事務(wù)在主庫(kù)上的執(zhí)行同時(shí)進(jìn)入到prepare階段，說(shuō)明事務(wù)之間沒(méi)有沖突，否則就不可能提交。

簡(jiǎn)言之：同一組提交的事務(wù)，沒(méi)有鎖沖突，可以并行重放。

MySQL將組提交的信息存放在GTID中，使用mysqlbinlog工具，可以看到組提交內(nèi)部的內(nèi)部信息：

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，說(shuō)明它們?cè)谝粋€(gè)組內(nèi)，可以并發(fā)回放執(zhí)行。

總結(jié)

mysql并行復(fù)制，縮短主從同步時(shí)延的核心架構(gòu)思路無(wú)非兩點(diǎn)：

• 單線(xiàn)程回放，升級(jí)為多線(xiàn)程并發(fā)回放；
• 確保并發(fā)回放冪等性：“按照庫(kù)冪等”，“按照組冪等”是兩種不同顆粒度的實(shí)現(xiàn)方式；

更具體的：

• mysql5.5 -> 不支持并行復(fù)制，趕緊升級(jí)mysql；
• mysql5.6 -> 支持按照庫(kù)并行復(fù)制，趕緊升級(jí)“多庫(kù)”架構(gòu)；
• mysql5.7 -> 支持按照GTID并行復(fù)制；

知其然，知其所以然。

思路比結(jié)論更重要。