共計 2047 個字符，預(yù)計需要花費(fèi) 6 分鐘才能閱讀完成。
本篇內(nèi)容主要講解“MySQL 主從同步加速的方案”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓丸趣 TV 小編來帶大家學(xué)習(xí)“MySQL 主從同步加速的方案”吧!
一、問題起源
MySQL 的主從同步一直有從庫延遲的問題，背景資料網(wǎng)上很多，原因簡單描述如下：
1、MySQL 從庫上有一個 IO 線程負(fù)責(zé)從主庫取 binlog 到寫到本地。另外有一個 SQL 線程負(fù)責(zé)執(zhí)行這些本地日志，實(shí)現(xiàn)命令重放；
2、正常網(wǎng)絡(luò)狀況下 IO 線程沒有性能問題（這個待會會用到），問題是 SQL 線程只有一個，更新速度跟不上。所以經(jīng)常會看到從庫的 CPU idle 很高，但同步性能就是上不去。
二、方案雛形
單線程的 SQL 線程是造成這個問題的主要原因。比較直接的想法是把它改成多線程版本，這個據(jù)說官方版本開發(fā)中，其實(shí)我們也有一個這樣的 patch，但是直接寫大片代碼在線上提供服務(wù)的 slave 機(jī)器上這種事兒，都會因?yàn)閾?dān)心穩(wěn)定性而很難推動（寫 patch 的和運(yùn)維的同學(xué)，你們懂的）。
所以打算用一個“第三方”工具中轉(zhuǎn)，來實(shí)現(xiàn)多線程同步。基本結(jié)構(gòu)如下：
說明：
1、這些 transefer 從 master 上各自同步一部分的數(shù)據(jù)，分別獨(dú)立更新 slave。多進(jìn)程還是多線程均可。
2、Transfer 與 master 之間異步更新日志，transfer 與 slve 之間同步更新數(shù)據(jù)
3、從這可以看出這個方案的缺點(diǎn)之一：更新能夠被獨(dú)立分開。比較直觀的想法是，按照表分。
三、關(guān)于 transfer
作為這個關(guān)鍵的轉(zhuǎn)發(fā)工具 transfer，需要提供如下功能：
1、能夠指定同步 master 中的哪部分?jǐn)?shù)據(jù)，并且能夠方便地修改這個配置以應(yīng)對 master 的加表需求；
2、支持 stop slave、start slave。支持快速切換到新主庫的 change master 命令。
3、能夠記錄讀取點(diǎn)，transfer 自己重啟或 master 重啟后能夠按照記錄點(diǎn)繼續(xù)讀后面的 binlog；
4、能夠記錄分發(fā)點(diǎn)，transfer 自己重啟或 slave 重啟后能夠按照記錄點(diǎn)繼續(xù)同步給 slave
用起來就會發(fā)現(xiàn)還有好多要求。。。
四、方案實(shí)現(xiàn)
Transfer 的這么多功能，自己造輪子就累了。這里直接用 MySQL 來充當(dāng)此角色。為了方便描述，下文還將之稱為 transfer。Transfer 更新 slave 在功能上可以使用 federated 引擎，但由于其糾結(jié)的實(shí)現(xiàn)導(dǎo)致性能上達(dá)不到要求，因此在 MySQL 框架層中作了一點(diǎn)修改――讀到同步日志后，直接發(fā)送給 slave。
方案簡單描述如下：
1、Slave 機(jī)器上搭另外的若干個 MySQL(transfer)，將其設(shè)為 Master 的從庫，且設(shè)置 replicate-do-table, 每個 transfer 承擔(dān)一部分的表。
2、所有 Transfer 的更新目標(biāo)都設(shè)置為 slave，其更新方式是讀到日志后直接_real_query 執(zhí)行到 slave 上。
從這可以看出這個方案的缺點(diǎn)之二：只能支持 statement 格式的同步方式。其實(shí) row 也能支持，后面再說。
五、仍然延遲？
在 transfer 放棄 federated 引擎改用直接發(fā)送后，性能提升不少，從庫同步性能增加一倍，但從本文第一個圖的數(shù)據(jù)對比就知道，延遲還很大。
發(fā)現(xiàn)這個時候 slave 的機(jī)器 cpu 已經(jīng)很忙了，idle 20% 一下――這個算是好消息，總比 idle 很高但性能上不去好。
實(shí)際上是因?yàn)槊總€ transfer，雖然設(shè)置只同步其中的部分表，但在實(shí)現(xiàn)上是 IO 線程把 master 上的所有命令都備份到本地，然后在 SQL 線程執(zhí)行的時候再判斷，若不符合 replicate-do-table，再放棄。
這樣存在的問題，是 n 個 transfer，磁盤寫了 n 倍，更嚴(yán)重的是導(dǎo)致 SQL 線程空轉(zhuǎn)。
我們上文提到整個流程中 IO 線程是比較空閑的，因此修改 IO 線程邏輯，在寫入磁盤前先判斷，若不符合本 transfer 的 replicate-do-table 設(shè)置，不寫盤，直接放棄。
六、效果
從庫的 QPS 由于線程切換會有抖動，但總的執(zhí)行時間與主庫相同。從庫的 cpu idle 下降，與主庫幾乎同時恢復(fù)到 100。
七、小結(jié)
描述完了，總結(jié)一下，方案的代價：
1、要求在 slave 機(jī)器上多配置 n 個 transfer（是否在從庫上均可）
2、目前只能支持 statement 的 binlog 格式，實(shí)際上 row 可以支持，方案定了，開發(fā)計劃中。
3、跨表更新的語句，會按照其更新的第一個表，分發(fā)到唯一一個 transfer，沒有重復(fù)更新的問題，但有時序性問題。
方案的好處：
1、功能比較齊全。直接使用 MySQL，原有的管理功能基本都能用，主庫從庫重啟 / 換庫的代價比較小。
2、開發(fā)量小，只在 transfer 上修改兩處，不包括配置讀取部分，300 行以內(nèi)
3、風(fēng)險相對小。不直接修改 master 和 slve 上的代碼，線上比較容易接收。
到此，相信大家對“MySQL 主從同步加速的方案”有了更深的了解，不妨來實(shí)際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
