一文詳解MySQL?Binlog日志與主從復(fù)制

更新時間：2022年07月31日 09:47:36 作者：樹獺叔叔

這篇文章主要介紹了一文詳解MySQL?Binlog日志與主從復(fù)制，Binlog是Binary?log的縮寫，即二進制日志，文章圍繞主題展開詳細的內(nèi)容介紹，具有一定的參考價值，需要的朋友可以參考一下

1. Binlog日志的介紹

Binlog是Binary log的縮寫，即二進制日志。Binlog主要有三個作用：持久化時將隨機IO轉(zhuǎn)化為順序IO，主從復(fù)制以及數(shù)據(jù)恢復(fù)。本文重點主從復(fù)制相關(guān)的問題。

Binlog日志由一個索引文件與很多日志文件組成，每個日志文件由魔數(shù)以及事件組成，每個日志文件都會以一個Rotate類型的事件結(jié)束。

對于每個事件，都可以分為事件頭與事件體兩部分：

事件頭的結(jié)構(gòu)如下所示：

事件體的結(jié)構(gòu)包括固定大小與可變大小兩部分。

對于Binlog日志的格式，做簡單的了解即可，感興趣的同學(xué)可以深入學(xué)習(xí)。

2. 主從復(fù)制

2.1 主從復(fù)制的流程

MySQL主從復(fù)制的流程大致如下：

主庫同步自己的Binlog日志給從庫
從庫的IO線程將Binlog日志內(nèi)容寫入Relay Log
從庫的SQL線程取Relay Log并在數(shù)據(jù)庫中進行回放

2.2 GTID

GTID是指全局事務(wù)標(biāo)志，用來標(biāo)記主從同步的情況。

master提交一個事務(wù)時會產(chǎn)生GTID，并且記錄在Binlog日志中。從庫的IO線程在讀取Binlog日志時，會將其儲存在自己的Relaylog中，并且將這個值設(shè)置到gtid_next中，即下一個要讀取的GTID，從庫讀取這個gtid_next時，會對比自己的Binlog日志中是否有這個GTID：

如果有這個記錄，說明這個GTID的事務(wù)已經(jīng)執(zhí)行過了，可以忽略掉（冪等）。
如果沒有這個記錄，slave就會執(zhí)行該GTID事務(wù)，并記錄到自己的Binlog日志中。

2.3 復(fù)制模型

異步復(fù)制：master 把Binlog日志推送給slave，master不需要等到slave是否成功更新數(shù)據(jù)到Relay log，主庫直接提交事務(wù)即可。這種模式犧牲了數(shù)據(jù)一致性。
同步復(fù)制：每次用戶操作時，必須要保證Master和Slave都執(zhí)行成功才返回給用戶。
半同步復(fù)制：不要求Slave執(zhí)行成功，而是成功接收Master日志就可以通知Master返回。

2.4 MGR模式

分布式一致性算法Paxos。由至少3個或更多個節(jié)點共同組成一個數(shù)據(jù)庫集群，事務(wù)的提交必須經(jīng)過半數(shù)以上節(jié)點同意方可提交提供，支持多寫模式。

MGR 是 share-nothing 的復(fù)制方案，基于分布式paxos協(xié)議實現(xiàn)，每個實例都有獨立的完整數(shù)據(jù)副本，集群自動檢查節(jié)點信息，做數(shù)據(jù)的同步。同時提供單主模式和多主模式，單主模式在主庫宕機后能夠自動選主，所有寫入都在主節(jié)點進行，多主模式支持多節(jié)點寫入。同時集群提供冗余的容錯功能，保證集群大多數(shù)節(jié)點正常集群就可以正常提供服務(wù)。