mysql replication 實現(xiàn)原理

一、replication 線程

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

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

MYSQL 復制的基本過程如下：

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

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

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

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

二、復制實現(xiàn)級別

（1）Row Level

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

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

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

?

（2）Statement Level

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

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

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

（3） Mixed Level

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

?

三、Replication 常用架構

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

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

?

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

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

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

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

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

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

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

（4）Dual Master 與級聯(lián)復制結合架構（Master-Master-Slaves）

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

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

?

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

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

總結

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

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