效能提升利器：MySQL 5.7多源主從複製的獨特性
作者介紹
高強，DBAplus社群聯合發起人，開源技術專家。擅長MySQL、PostgreSQL等產品的實施、運維和故障處理。曾參與多個省級政府單位專案的實施和運維工作，具有豐富的運維經驗。
關於MySQL主從複製
複製技術顧名思義，就是通過資料庫的複製技術以一份資料為主，複製成另一份存放，資料來源的那一份做為主庫，存放複製資料的的稱為從庫。MySQL的複製方案有很多，比如主從複製、半同步複製、多主還有主主複製等。基本都是是通過把主庫的操作寫入二進位制日誌，將二進位制日誌傳送到從庫並且重演日誌中記錄的操作跟進主庫狀態以便達到在從庫資料同步的效果。
其中，主從複製可以變換、擴展出很多的組合方法，比如多源複製（多臺master將資料傳送到1臺數據庫）、1主多從或者還有從伺服器再延伸出從伺服器。
下面列舉一些資料庫主從複製架構：
注：主庫為Master（1,2,..,N），從庫為Slave(1,2,…,N)。
主從複製有如下一些優勢：
- 分擔負載：對業務進行讀寫分離，減輕主庫I/O負載，將部分壓力分擔到從庫上，縮短客戶查詢響應時間。
- 增加健壯性：在主庫出現問題時，可通過多種方案將從庫設定為主庫，替換主庫支撐業務，縮短停機視窗。
- 有利備份：在從庫上備份，即不影響主庫的事務，也不影響主庫效能和磁碟空間。
- 查詢分析：從庫可以作為統計、報表等資料分析工作所使用的的OLAP庫。
- 異地備份：將從庫放置在異地可作為異地資料同步備份所用。
從MySQL的5.7版本開始支援多源主從複製技術（Multi-SourceReplication），就是將多個數據庫（Master）的資料集中傳送到1臺從庫（Slave）上，該技術也具有剛才上文提到的主從複製的優勢，除了這些，它的獨特性還在於：
- 匯聚資料：尤其是在分庫分表的一些場景中，資料集中統計分析操作可以在1臺從庫伺服器上實現。
- 節省成本：資料集中存放可避免伺服器等軟硬體資源浪費，5.7之前1主1從或者1主多從的方案需要為每個主機都安置一臺備機；5.7推出多源複製之後，可以將多個從庫進行合併，至於是合併存放在高階還是低端伺服器上，取決於分析、統計等業務在整體業務中的優先順序、繁忙程度等因素。
- 集中備份：方便在一臺伺服器備份所有已收到的資料庫資料。
- 異地災備：將從庫放在距離遠的地方，可用於異地備份專案。
基本的1主1從複製實現過程
下面咱們先循序漸進簡單瞭解一下基本的1主1從（1master，1slave）複製的實現過程：
圖中Master為主庫的主機名，Slave為從庫主機名。同步的資料庫名為Music。從庫接收主庫（binlog dump執行緒）發過來的Binary Log，通過從庫的I/O執行緒（I/O thread）將日誌寫入從庫的Relay Log中，然後通過SQL執行緒（SQL thread）將日誌的內容應用到從庫中。
在從庫上通過命令可以看到2個必備程序(I/O thread和SQL thread)在待命狀態，執行緒狀態如下：
執行緒的功能主要通過state欄位確認：
- I/O執行緒:Waitingformastertosendevent
- SQL（Coordinator）執行緒：Slavehasreadallrelaylog;waitingformoreupdates
開啟併發後還會有以下執行緒：
- Worker執行緒：WaitingforaneventfromCoordinator
多源複製的實現與1主1從的類似，都是傳送二進位制日誌再重演，但是在SQL執行緒（SQLthread）上有略微區別，會為每個主庫例項提供一套SQL和IO執行緒：
配置多源複製的操作方法
多源複製的配置比較簡單：
- stop slave;
- SET GLOBAL master_info_repository = ‘TABLE’;
- SET GLOBAL relay_log_info_repository = ‘TABLE’;
- change master to master_host=’192.168.5.160′,master_user=’slave1′,master_password=’gaoqiang’ for channel ‘master1’;
- change master to master_host=’192.168.5.163′,master_user=’slave1′,master_password=’gaoqiang’ for channel ‘master2’;
- start slave;
圖中使用了2個主庫：music和habit，假設music存放音樂的歌手、名稱和其他資訊，habit儲存了使用者的偶像、最喜歡的歌、常聽的歌、播放高峰時間段和地理位置資訊的話，匯聚到從庫便可即實現了經濟實惠的從庫端分庫合併又實現了統一做使用者行為分析，還可以用一條mysqldump命令加個–all-databases引數全部匯出做備份。
考慮到多源複製執行過程中，一臺從庫要接受多方的資料，相比壓力會比單庫複製有所提升，因此需要優化一下從庫配置，從而提升從庫執行效率。
效能提升利器——並行複製
接下來要說的就是：效能提升利器——並行複製。為了提高SQL執行緒（SQLthread）的執行效率，減少主庫與從庫之間的延遲，MySQL提供了並行複製的特性，可以將事務在從庫上多執行緒併發的回放應用，從而達到加速同步速度的效果。
需要注意的是，使用過程中還是有一些問題需要稍加留意，如果設定不當，反而可能會畫蛇添足。
就拿效能來說，並不是併發開的越高越好，併發開的過高和過低，都可能帶來負面性能影響，比如引起Coordinator的判斷、分發等處理過程開銷升高，使用Sysbench進行壓力測試的過程中，該開銷升高症狀體現在CPU消耗高。可能在不同的環境和業務場景下都會有相應的反應，需要量體裁衣、因地制宜。
下圖為1主1從SQL執行緒並行複製回放過程：
圖2中，SQL執行緒（SQL thread）由原來的1個，分裂變成了1個Coordinator和N個worker。Coordinator主要用來分發工作給不同的worker，並且在必要時自己也進行重演操作。圖中分了18個並行，即18個worker並行工作。他們負責並行的將日誌中可以劃分成一組的事務進行並行回放。
在把事務應用到從庫的時候，根據binary log中last_committed（需設定並行型別為logical clock）的值判斷是否可以放在一組進行並行回放，如果取值相同，便並行執行。
日誌資訊：
從日誌中看到，資料庫已經開啟了GTID（全域性事務標識）功能，此功能是5.6版本出現的，可以保證每個提交的事務都會有一個全域性唯一的編號，日誌中也可看到GTID資訊。
多源複製開啟併發後的架構圖：
開啟並行複製操作的方法對於1主和多源是一樣的：
- stop slave;
- SET GLOBAL SLAVE_PARALLEL_TYPE=’LOGICAL_CLOCK’;
- SET GLOBAL SLAVE_PARALLEL_WORKERS=30;
- start slave;
驗證配置生效：
用show processlist命令會看到會出現多個coordinator執行緒和每個co執行緒所分配的30個worker執行緒，總共60多個執行緒。（由於worker陣容太龐大，超佔篇幅，就不在此展示了）
為什麼選擇並行度為30，原因是從1主1從的測試中發現該並行度在本次測試環境中磁碟資源利用率略高於其他場景，CPU消耗相對比較低，記憶體消耗差別不大，總體效率最高，執行時間最短。
1主1從複製時Slave資料庫的CPU效能狀態特徵：
CPU效能統計：
從圖中可以看到，在本次測試環境中，CPU狀態最好的是併發度為18和30的時候，併發度為300的時候CPU反而消耗明顯；併發為2的時候cpu消耗高，並且處理時間更耗時；併發為0的時候，其實等於不併發，CPU利用率不高，耗時也較長；值得關注的是，併發度設定為1的時候，即使只有1個worker，但是畢竟是併發模式，此時同樣在消耗coordinator的資源，並且此時coordinator也參與了重演操作，相當於2個執行緒進行重演，因此與併發度設定為2很接近，所以務必注意如果想關閉併發一定要設定為0，而不是1。
接下來進行多源複製的壓力測試與效能監控：
多源複製的壓力測試使用了Sysbench對2臺主庫（master和master1）一起加壓，同時對從庫slave進行效能監控。（3個數據庫所在的伺服器配置完全相同）
測試語句：
引數說明：
- OLTP場景
- Innodb引擎
- 對5張表操作
- 每資料庫1萬個操作請求（一共2萬個操作請求）
- 混合讀寫
- 每資料庫100併發
- 每表20萬條資料
考慮到30併發度的資源利用相對充分、執行效率相對較高的測試結果，在從庫開啟30個SQL執行緒並行後進行測試，並將從庫的監控資料進行統計做成視覺化曲線圖進行分析。
從下面3張測試後生成的曲線圖可以看到，對於從主庫發過來的2萬個請求，並行執行的完成時間（橫軸為時間）比單執行緒更短，資源利用率更高，執行效率更高。
CPU使用率：
從圖中可看到，開啟並行之後，CPU的利用率比之前有所升高，負載還OK，最高36%左右，利用較單執行緒更充分，操作完成時間更早（曲線最先恢復下降到0）。
Disk Write KB/s
硬碟使用率從圖中看出，並行SQL執行緒relay過程相對比較平穩，未出現明顯抖動，並且30併發的曲線最早歸零，結束操作。
Free Memory 剩餘記憶體：
記憶體使用差不太多。
由此可見，多源複製在合理的開啟並行之後，有助於提高複製效率，縮短資料的延遲。
小結
總體說來，MySQL的多源複製提供了更經濟、方便和安全的資料庫環境。如有感興趣的朋友，歡迎留言一起交流，模擬業務場景進行測試、提出測試建議、更正錯誤和共同研究都是非常歡迎的，希望與大家互助共進！
文章出處：DBAplus社群（訂閱號ID：dbaplus）