MySQL 5.7多源主從復制的獨特性

下面我們來看一篇關於MySQL 5.7多源主從復制的獨特性例子,希望文章能夠幫助到各位朋友,希望文章能夠幫助到大家.

關於MySQL主從復制

 

 

復制技術顧名思義，就是通過數據庫的復制技術以一份數據為主，復制成另一份存放，數據來源的那一份做為主庫，存放復制數據的的稱為從庫。MySQL的復制方案有很多，比如主從復制、半同步復制、多主還有主主復制等。基本都是是通過把主庫的操作寫入二進制日志，將二進制日志傳送到從庫並且重演日志中記錄的操作跟進主庫狀態以便達到在從庫數據同步的效果。

 

 

 

其中，主從復制可以變換、擴展出很多的組合方法，比如多源復制（多台master將數據發送到1台數據庫）、1主多從或者還有從服務器再延伸出從服務器。

 

 

 

下面列舉一些數據庫主從復制架構：

 

 

 

注：主庫為Master（1,2,..,N），從庫為Slave(1,2,...,N)。

 

 

 

 

 

 

 

主從復制有如下一些優勢：

 

 

1. 
   分擔負載：對業務進行讀寫分離，減輕主庫I/O負載，將部分壓力分擔到從庫上，縮短客戶查詢響應時間。


2. 
   增加健壯性：在主庫出現問題時，可通過多種方案將從庫設置為主庫，替換主庫支撐業務，縮短停機窗口。


3. 
   有利備份：在從庫上備份，即不影響主庫的事務，也不影響主庫性能和磁盤空間。


4. 
   查詢分析：從庫可以作為統計、報表等數據分析工作所使用的的OLAP庫。


5. 
   異地備份：將從庫放置在異地可作為異地數據同步備份所用。

 

 

從MySQL的5.7版本開始支持多源主從復制技術（Multi-Source Replication），就是將多個數據庫（Master）的數據集中發送到1台從庫（Slave）上，該技術也具有剛才上文提到的主從復制的優勢，除了這些，它的獨特性還在於：

 

 

1. 
   匯聚數據：尤其是在分庫分表的一些場景中，數據集中統計分析操作可以在1台從庫服務器上實現。


2. 
   節省成本：數據集中存放可避免服務器等軟硬件資源浪費，5.7之前1主1從或者1主多從的方案需要為每個主機都安置一台備機；5.7推出多源復制之後，可以將多個從庫進行合並，至於是合並存放在高端還是低端服務器上，取決於分析、統計等業務在整體業務中的優先級、繁忙程度等因素。


3. 
   集中備份：方便在一台服務器備份所有已收到的數據庫數據。


4. 
   異地災備：將從庫放在距離遠的地方，可用於異地備份項目。

 

基本的1主1從復制實現過程

 

 

下面咱們先循序漸進簡單了解一下基本的1主1從（1 master，1 slave）復制的實現過程：

 

 

 

 

圖中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線程:
  Waiting for master to send event 


• 
  SQL（Coordinator）線程：
  Slave has read all relay log; waiting for more updates

 

 

開啟並發後還會有以下線程：

 

 

• 
  Worker線程：
  Waiting for an event from Coordinator  

 

 

多源復制的實現與1主1從的類似，都是發送二進制日志再重演，但是在SQL線程（SQL thread）上有略微區別，會為每個主庫實例提供一套SQL和IO線程：

 

 

 

 

 

配置多源復制的操作方法

 

 

多源復制的配置比較簡單：

 

 

1. 
   stop slave;


2. 
   SET GLOBAL master_info_repository = 'TABLE';


3. 
   SET GLOBAL relay_log_info_repository = 'TABLE';


4. 
   change master to master_host='192.168.5.160',master_user='slave1',master_password='gaoqiang'  for channel 'master1';


5. 
   change master to master_host='192.168.5.163',master_user='slave1',master_password='gaoqiang'  for channel 'master2';


6. 
   start slave;

 

 

 

圖中使用了2個主庫：music和habit，假設music存放音樂的歌手、名稱和其他信息，habit保存了用戶的偶像、最喜歡的歌、常聽的歌、播放高峰時間段和地理位置信息的話，匯聚到從庫便可即實現了經濟實惠的從庫端分庫合並又實現了統一做用戶行為分析，還可以用一條mysqldump命令加個--all-databases參數全部導出做備份。

 

 

 

考慮到多源復制運行過程中，一台從庫要接受多方的數據，相比壓力會比單庫復制有所提升，因此需要優化一下從庫配置，從而提升從庫執行效率。

 

 

性能提升利器——並行復制

 

 

接下來要說的就是：性能提升利器——並行復制。為了提高SQL線程（SQL thread）的執行效率，減少主庫與從庫之間的延遲，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主和多源是一樣的：

 

 

1. 
   stop slave;


2. 
   SET GLOBAL SLAVE_PARALLEL_TYPE='LOGICAL_CLOCK';


3. 
   SET GLOBAL SLAVE_PARALLEL_WORKERS=30;


4. 
   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個數據庫所在的服務器配置完全相同）

 

 

 

測試語句：

 

 

 

 

 

 

參數說明：

 

 

1. 
   OLTP場景


2. 
   Innodb引擎


3. 
   對5張表操作


4. 
   每數據庫1萬個操作請求（一共2萬個操作請求）


5. 
   混合讀寫


6. 
   每數據庫100並發


7. 
   每表20萬條數據

 

 

考慮到30並發度的資源利用相對充分、執行效率相對較高的測試結果，在從庫開啟30個SQL線程並行後進行測試，並將從庫的監控數據進行統計做成可視化曲線圖進行分析。

 

 

 

從下面3張測試後生成的曲線圖可以看到，對於從主庫發過來的2萬個請求，並行執行的完成時間（橫軸為時間）比單線程更短，資源利用率更高，執行效率更高。

 

 

 

CPU使用率：

 

 

 

 

 

 

從圖中可看到，開啟並行之後，CPU的利用率比之前有所升高，負載還OK，最高36%左右，利用較單線程更充分，操作完成時間更早（曲線最先恢復下降到0）。

 

 

 

Disk Write KB/s

 

 

 

 

 

 

硬盤使用率從圖中看出，並行SQL線程relay過程相對比較平穩，未出現明顯抖動，並且30並發的曲線最早歸零，結束操作。

 

 

 

Free Memory 剩余內存：

 

 

 

 

 

 

內存使用差不太多。

 

 

 

由此可見，多源復制在合理的開啟並行之後，有助於提高復制效率，縮短數據的延遲。

 

 

小結

 

 

總體說來，MySQL的多源復制提供了更經濟、方便和安全的數據庫環境。如有感興趣的朋友，歡迎留言一起交流，模擬業務場景進行測試、提出測試建議、更正錯誤和共同研究都是非常歡迎的，希望與大家互助共進！