一種MySQL主從同步加速方案

一、問題起源
MySQL的主從同步一直有從庫延遲的問題,背景資料網上很多,原因簡單描述如下:
    1、 MySQL從庫上有一個IO線程負責從主庫取binlog到寫到本地。另外有一個SQL線程負責執行這些本地日志,實現命令重放;
   2、 正常網絡狀況下IO線程沒有性能問題(這個待會會用到),問題是SQL線程隻有一個,更新速度跟不上。所以經常會看到從庫的CPU idle很高,但同步性能就是上不去。
 
 原始性能
二、方案雛形
單線程的SQL線程是造成這個問題的主要原因。比較直接的想法是把它改成多線程版本,這個據說官方版本開發中,其實我們也有一個這樣的patch,但是直接寫大片代碼在線上提供服務的slave機器上這種事兒,都會因為擔心穩定性而很難推動(寫patch的和運維的同學,你們懂的)。
所以打算用一個“第三方”工具中轉,來實現多線程同步。基本結構如下:
 
       說明:
1、這些transefer從master上各自同步一部分的數據,分別獨立更新slave。多進程還是多線程均可。
2、Transfer與master之間異步更新日志,transfer與slve之間同步更新數據
3、從這可以看出這個方案的缺點之一:更新能夠被獨立分開。比較直觀的想法是,按照表分。
 
三、關於transfer
作為這個關鍵的轉發工具transfer,需要提供如下功能:
1、能夠指定同步master中的哪部分數據,並且能夠方便地修改這個配置以應對master的加表需求;
2、支持stop slave、start slave。支持快速切換到新主庫的change master命令。
3、能夠記錄讀取點,transfer自己重啟或master重啟後能夠按照記錄點繼續讀後面的binlog;
4、能夠記錄分發點,transfer自己重啟或slave重啟後能夠按照記錄點繼續同步給slave
用起來就會發現還有好多要求。。。
 
四、方案實現
Transfer的這麼多功能,自己造輪子就累瞭。這裡直接用MySQL來充當此角色。為瞭方便描述,下文還將之稱為transfer。Transfer更新slave在功能上可以使用federated引擎,但由於其糾結的實現導致性能上達不到要求,因此在MySQL框架層中作瞭一點修改――讀到同步日志後,直接發送給slave。
方案簡單描述如下:
    1、 Slave機器上搭另外的若幹個MySQL(transfer),將其設為Master的從庫,且設置replicate-do-table, 每個transfer承擔一部分的表。
   2、 所有Transfer的更新目標都設置為slave,其更新方式是讀到日志後直接mysql_real_query執行到slave上。
從這可以看出這個方案的缺點之二:隻能支持statement格式的同步方式。其實row也能支持,後面再說。
 
五、仍然延遲?
在transfer放棄federated引擎改用直接發送後,性能提升不少,從庫同步性能增加一倍,但從本文第一個圖的數據對比就知道,延遲還很大。
發現這個時候slave的機器cpu已經很忙瞭,idle 20%一下――這個算是好消息,總比idle很高但性能上不去好。
實際上是因為每個transfer,雖然設置隻同步其中的部分表,但在實現上是IO線程把master上的所有命令都備份到本地,然後在SQL線程執行的時候再判斷,若不符合replicate-do-table,再放棄。
這樣存在的問題,是n個transfer,磁盤寫瞭n倍,更嚴重的是導致SQL線程空轉。
我們上文提到整個流程中IO線程是比較空閑的,因此修改IO線程邏輯,在寫入磁盤前先判斷,若不符合本transfer的replicate-do-table設置,不寫盤,直接放棄。
六、效果

方案效果

從庫的QPS由於線程切換會有抖動,但總的執行時間與主庫相同。從庫的cpu idle下降,與主庫幾乎同時恢復到100。
 
七、小結
描述完瞭,總結一下,方案的代價:
1、要求在slave機器上多配置n個transfer(是否在從庫上均可)
2、目前隻能支持statement的binlog格式,實際上row可以支持,方案定瞭,開發計劃中。
3、跨表更新的語句,會按照其更新的第一個表,分發到唯一一個transfer,沒有重復更新的問題,但有時序性問題。
 
方案的好處:
1、功能比較齊全。直接使用MySQL,原有的管理功能基本都能用,主庫從庫重啟/換庫的代價比較小。
2、開發量小,隻在transfer上修改兩處,不包括配置讀取部分,300行以內
3、風險相對小。不直接修改master和slve上的代碼,線上比較容易接收。

作者“追風刀·丁奇”
 

發佈留言