主備同步,也叫主從復制,是MySQL提供的一種高可用的解決方案,保證主備數(shù)據(jù)一致性的解決方案。
在生產環(huán)境中,會有很多不可控因素,例如數(shù)據(jù)庫服務掛了。為了保證應用的高可用,數(shù)據(jù)庫也必須要是高可用的。
因此在生產環(huán)境中,都會采用主備同步。在應用的規(guī)模不大的情況下,一般會采用一主一備。
除了上面提到的數(shù)據(jù)庫服務掛了,能夠快速切換到備庫,避免應用的不可用外,采用主備同步還有以下好處:
提升數(shù)據(jù)庫的讀并發(fā)性,大多數(shù)應用都是讀比寫要多,采用主備同步方案,當使用規(guī)模越來越大的時候,可以擴展備庫來提升讀能力。
備份,主備同步可以得到一份實時的完整的備份數(shù)據(jù)庫。
快速恢復,當主庫出錯了(比如誤刪表),通過備庫來快速恢復數(shù)據(jù)。對于規(guī)模很大的應用,對于數(shù)據(jù)恢復速度的容忍性很低的情況,通過配置一臺與主庫的數(shù)據(jù)快照相隔半小時的備庫,當主庫誤刪表,就可以通過備庫和binlog來快速恢復,最多等待半小時。
說了主備同步是什么和好處,下面讓我們來了解一下主備同步是怎么實現(xiàn)的。
主備同步的實現(xiàn)原理
我們先來了解一下主備同步的原理,下面以一個update語句來介紹主庫與備庫間是如何進行同步的。

上圖是一個update語句在節(jié)點A執(zhí)行,然后同步到節(jié)點B的完整流程圖,具體步驟有:
- 主庫接受到客戶端發(fā)送的一條update語句,執(zhí)行內部事務邏輯,同時寫binlog。
- 備庫通過 change master 命令,設置主庫的IP、端口、用戶名和密碼,以及要從哪個位置開始請求 binlog。這個位置包含文件名和偏移量。
- 在備庫上執(zhí)行start slave命令,啟動兩個線程 io_thread 和 sql_thread,其中 io_thread 負責與主機進行連接。
- 主庫校驗完用戶名和密碼,按照接收到的位置去讀取binlog,發(fā)給備庫。
- 備庫接收到binlog后,寫到本地文件(relay log,中轉文件)。
- 備庫讀取中轉文件,解析出命令,然后執(zhí)行。
主備同步的工作原理其實就是一個完全備份加上二進制日志備份的還原。不同的是這個二進制日志的還原操作基本上是實時的。
備庫通過兩個線程來實現(xiàn)同步:
- 一個是 I/O 線程,負責讀取主庫的二進制日志,并將其保存為中繼日志。
- 一個是 SQL 線程,負責執(zhí)行中繼日志。
從上面的流程可以看出,主備同步的關鍵是binlog
常見的兩種主備切換流程
M-S結構
M-S結構,兩個節(jié)點,一個當主庫、一個當備庫,不允許兩個節(jié)點互換角色。

在狀態(tài)1中,客戶端的讀寫都直接訪問節(jié)點A,而節(jié)點B是A的備庫,只是將A的更新都同步過來,到本地執(zhí)行。這樣可以保持節(jié)點B和A的數(shù)據(jù)是相同的。
當需要切換的時候,就切成狀態(tài)2。這時候客戶端讀寫訪問的都是節(jié)點B,而節(jié)點A是B的備庫。
雙M結構
雙M結構,兩個節(jié)點,一個當主庫,一個當備庫,允許兩個節(jié)點互換角色。

對比前面的M-S結構圖,可以發(fā)現(xiàn),雙M結構和M-S結構,其實區(qū)別只是多了一條線,即節(jié)點A和B之間總是互為主備關系。這樣在切換的時候就不用再修改主備關系。
雙M結構的循環(huán)復制問題
在實際生產使用中,多數(shù)情況是使用雙M結構的。但是,雙M結構還有一個問題需要解決。
業(yè)務邏輯在節(jié)點A執(zhí)行更新,會生成binlog并同步到節(jié)點B。節(jié)點B同步完成后,也會生成binlog。(log_slave_updates設置為on,表示備庫也會生成binlog)。
當節(jié)點A同時也是節(jié)點B的備庫時,節(jié)點B的binlog也會發(fā)送給節(jié)點A,造成循環(huán)復制。
解決辦法:
- 設置節(jié)點的server-id,必須不同,不然不允許設置為主備結構
- 備庫在接到binlog后重放時,會記錄原記錄相同的server-id,即誰產生即為誰的。
- 每個節(jié)點在接受binlog時,會判斷server-id,如果是自己的就丟掉。
解決后的流程:
- 業(yè)務邏輯在節(jié)點A執(zhí)行更新,會生成帶有節(jié)點A的server-id的binlog。
- 節(jié)點B接受到節(jié)點A發(fā)過來的binlog,并執(zhí)行完成后,會生成帶有節(jié)點A的server-id的binlog。
- 節(jié)點A接受到binlog后,發(fā)現(xiàn)是自己的,就丟掉。死循環(huán)就在這里斷掉了。
以上就是MySQL是如何實現(xiàn)主備同步的詳細內容,更多關于MySQL 主備同步的資料請關注腳本之家其它相關文章!
您可能感興趣的文章:- MySQL GTID全面總結
- MYSQL數(shù)據(jù)庫GTID實現(xiàn)主從復制實現(xiàn)(超級方便)
- MySQL5.6 GTID模式下同步復制報錯不能跳過的解決方法
- Mysql GTID Mha配置方法
- MySQL5.7不停業(yè)務將傳統(tǒng)復制變更為GTID復制的實例
- 詳解MySQL主從復制實戰(zhàn) - 基于GTID的復制
- MySQL 5.6 GTID新特性實踐
- MySQL5.6基于GTID的主從復制
- 在MySQL中使用GTIDs復制協(xié)議和中斷協(xié)議的教程
- 關于mysql主備切換canal出現(xiàn)的問題解決
- 基于mysql+mycat搭建穩(wěn)定高可用集群負載均衡主備復制讀寫分離操作
- MySQL GTID主備不一致的修復方案