mysql replication 實現原理

一、replication 線程

Mysql 的Replication是一個異步的復制過程，從一個 mysql Instance(master)復制到另一個mysql Instance(slave)。在Master與Slave之間的整個復制過程主要由三個線程來完成，其中兩個線程 SQL線程和IO線程在Slave端，另外一個線程 IO線程在Master端。

要實現Mysql Relication，首先必須打開Master的 Binary Log功能。因為整個復制功能實際上就是Slave從Master端獲取二進制日志，然后在自己身上完全按照產生的順序依次執行日志中所記錄的各種操作。

MYSQL 復制的基本過程如下：

（1）Slave的IO線程連接上Master，并請求日志文件的指定位置（或者從最開始的日志）之后的日志內容；

（2）Master接收到來自Slave的IO線程請求后，負責復制的IO線程根據請求信息讀取指定日志位置之后的日志信息，返回給Slave端的IO線程。返回信息中除了日志所包含的信息外，還包括本次返回的信息在Master端的Binary Log 文件的名稱和位置；

（3）Slave的IO線程接收到信息后，將日志內容依次寫入Slave端的Relay Log（中繼日志）文件的最末端，并將讀取到的Master端的Binary Log 文件名和位置記錄到master-info文件中，以便在下次讀取時能清楚地告訴master “我需要從某個bin-log文件的哪個位置開始完后的日志內容，發給我”；

（4）Slave的Sql線程檢測到Relay Log中新內容后，會馬上解析該Log文件中的內容，還原成在Master端真實執行的可執行Query語句，并執行這些Query。實際上就是在Master端和Salve端執行了同樣的Query，所以兩端的數據是完全一樣的。

二、復制實現級別

（1）Row Level

Binary Log會記錄成每一行數據被修改的形式，然后在Slave端再對相同的數據進行修改。

優點：在Row Level模式下，Binary Log可以不記錄執行的Query語句的上下文相關信息，只需要記錄哪一條記錄被修改了，修改成什么樣了。所以 Row Level的日志內容會非常清楚地記錄下每一行數據修改的細節，非常容易理解。而且不會出現某些特定情況下的存儲過程，或 function，以及 Trigger的調用和觸發無法正確復制的問題。

缺點：在Row Level模式下，當所有的執行語句記錄到Binary Log 中時，都將被記錄成每條記錄被修改的形式，這樣就會產生大量的日志內容。比如有這樣的一條 update語句：UPDATE group_message SET group_id = 1 WHERE group_id=2，執行后，日志記錄的不是該語句而是產生影響的 表中的每條記錄，即：如果group_message 中有 group_id=1 的記錄100條，那么Binary Log中記錄了這100條記錄的變化情況。尤其執行 Alter Table 之類的語句時，產生的日志量更大的驚人。因為MYSQL對于Alter Table之類的DDL變更語句是重建整個表的所有數據，即表中每一條記錄都要變動，那么該表中所有記錄都要記錄到日志中。

?

（2）Statement Level

每一條會修改數據的Query都會記錄到Master的Binary Log中以及執行語句時上下文的信息。Slave 在復制的時候，SQL線程會解析成和原來 Master 端執行過的相同的 Query，并再次執行。

有點：首先解決了Row Level的缺點，不需要記錄每一行記錄的變化，減少了Binary Log 日志量，節約了IO成本，提高了性能。

缺點：由于記錄的是執行語句，為了能讓這些語句在Slave端也能正確執行，就需要記錄每條語句在執行時的一些相關信息，即上下文信息。另外由于MYSQL發展比較快，很多新功能的加入，也使得mysql復制遇到不少挑戰，復制時涉及的內容越復雜越容易出現bug。在修改數據時使用了默寫特定的函數或功能后會出現問題。如 sleep()函數在默寫版本中不能正確復制，在存儲過程中使用 last_insert_id()函數，可能會使Slave 和Master得到不一致的ID，由于Row Level是基于每一行變化的所以不會出現這種情況。

（3） Mixed Level

在Mixed模式下，mysql會根據執行的每一條具體的Query語句來區分對待記錄的日志形式，也就是在 Statement和Row之間選擇一種。從5.1.8版本開始，Mysql提供了Statement Level 和 Row Level之外的第三種復制模式 Mixed Level

?

三、Replication 常用架構

（1） 常規復制架構 (Master - Slave)

主從復制架構，可以實現寫讀分離，只要Master端和 Slave端的壓力不是很大，異步復制的延時一般都很少很少。尤其是自從Slave端的復制方式改成兩個線程處理之后。

?

（2）Dual Master復制架構（Master - Master）

如果簡單用常規復制架構 切換的話，就會造成原來Master端數據的不一致性，當原來的Master啟動可以正常提供服務時，不得不通過反轉Master - Slave 關系重新搭建Replication 環境，并以 原 Master 作為 Slave來對外提供服務。這將增加很多工作量。為了避免這個問題，可以搭建 Dual Master （雙 Master），即兩個Mysql Server互相將對方作為自己的Master，自己作為對方的Slave來進行復制。這樣任何一方做的變更，都會通過復制應用到另一方數據庫中。

為避免循環復制，Mysql的Binary Log中記錄了當前Mysql的server-id ，mysql很容易判斷某個變更是從哪一個mysql server最初產生的。另外如果不打開Slave的Binary Log選項（--log-slave-update)時，mysql根本就不會記錄復制過程中產生的變更多 Binary Log中。

為了避免數據沖突一般指開啟一端寫服務，因為兩端如果同時更新一條記錄，會產生沖突 覆蓋。

（3）級聯復制架構(Master - Slave - Slave ...)

在有些應用場景中，也許讀寫壓力差別比較大，讀壓力特別大，一臺Master 可能需要10臺甚至更多的Slave才能支撐讀的壓力。

這時可利用MYSQL可以在 Slave端記錄復制所產生的變更的 Binary Log 信息的功能，也就是打開 -log-slave-update 選項。然后通過二級復制來減少 Master端因為復制所帶來的壓力。也就是說，首先通過少數幾臺Mysql從Master來進行復制，這幾臺機器我們稱為第一級Slave 集群，然后其他的Slave再通過第一級Slave集群來進行復制。從第一級Slave進行復制的Slave，稱之為第二級Slave集群。如果有需要還可以繼續往下增加更多層次的復制。

（4）Dual Master 與級聯復制結合架構（Master-Master-Slaves）

級聯復制在一定程度上確實解決了 Master因為所附屬的Slave過多而成為瓶頸的問題，但并不能解決人工維護和出現異常需要切換時可能存在重新搭建 Replication的問題。

和Master - Salve - Salve 架構相比，區別只是將第一級的Slave集群換成了一臺單獨的Master，作為備用Master，然后再從這個Master復制到一個Slave集群，這樣避免了主Master的寫操作受到Slave集群的復制所帶來的影響，同時主Master需要切換的時候也基本上不會出現重搭Replication的情況。但這個架構也有一個弊端，那就是備用的Master有可能成為瓶頸，如果后面Slave集群比較大的話，備用Master可能會因為過多的Slave IO線程請求而成為瓶頸。該備用Master不可供任何讀服務時，瓶頸出現的可能性并不是很高。

?

轉載于:https://www.cnblogs.com/shilijun/archive/2013/04/21/3034073.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Mysql Replication 机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。