mysql AB複製理論

Mysql AB複製（主從複製）理論

 

MySQL 支持單向、異步複製，複製過程當中一個服務器充當主服務器,而一個或多個其它服務器充當從服務器。即從Master複製到一個或多個Slave上。

實現整個主從複製須要由Master上的IO進程，和Slave上的sql進程和IO進程共同完成。首先打開Master上的 binary log (bin-log)功能（修改配置文件），由於整個複製實際就是slave從master端獲取相應的二進制日誌，而後在slave端按順序執行日誌中的各類操做。（二進制日誌幾乎記錄了除select外全部的sql語句的操做）

基本過程：

(1)Slave端的IO進程鏈接到master，向master請求指定日誌文件的指定位置以後的日誌內容

(2)Master接收到Slave的IO進程請求後，根據請求信息，讀取相應位置的二進制日誌的內容，返回給Slave的IO進程。並將本次請求讀取的二進制日誌文件名及位置一塊兒返回給Slave

(3)Slave的IO進程接收到信息後，將接收到的日誌內容依次添加到Slave端的relay-log文件中，並將讀取到的Master的bin-log文件名和位置記錄在master-info文件中，方便下次讀取的時候可以清楚的告訴master從哪一個位置日後的日誌內容發給我

(4)Slave 的sql進程檢測到relay-log中新增長了內容後，會立刻解析其中的內容，轉變爲執行的sql語句，並在slave端執行。

注意：當你進行復制時,全部對複製中的表的更新必須在主服務器上進行（讀寫分離）。不然,你必需要當心,以免用戶對主服務器上的表進行的更新與對從服務器上的表所進行的更新之間的衝突。

 

單向複製有利於健壯性、速度和系統管理:

· 主服務器/從服務器設置增長了健壯性。主服務器出現問題時,你能夠切換到

從服務器做爲份。

· 經過在主服務器和從服務器之間切分處理客戶查詢的負荷,能夠獲得更好的

客戶響應時間。SELECT查詢能夠發送到從服務器以下降主服務器的查詢處理負

荷。但修改數據的語句仍然應發送到主服務器,以便主服務器和從服務器保持同

步。若是非更新查詢爲主,該負載均衡策略頗有效,但通常是更新查詢。

· 使用複製的另外一個好處是可使用一個從服務器執行備份,而不會干擾主服務

器。在備份過程當中主服務器能夠繼續處理更新。

 

MySQL 提供了數據庫的同步功能,這對咱們實現數據庫的冗災、備份、恢復、負載均衡等都是有極大幫助

 

 

 

 

 

注意:在同步以前確保 master 與 slave 上的數據一致性。由於在數據同步過程當中，是命令同步，即sql語句同步

 

相關文件做用:

1. mysql-bin.index:服務器一旦開啓二進制日誌,會產生一個與二日誌文件同名,可是以.index 結尾的文件。它用於跟蹤磁盤上存在哪些二進制日誌文件。MySQL 用它來定位二進制日誌文件。

2. mysqld-relay-bin.index:該文件的功能與 mysql-bin.index 相似,可是它是針對中繼日誌,而不是二進制日誌。

3. master.info:保存 master 的相關信息。不要刪除它,不然,slave 重啓後不能鏈接 master。

4. relay-log.info:包含 slave 中當前二進制日誌和中繼日誌的信息。

 

 

若是寫操做較少,而讀操做不少時,能夠採起上圖這種結構。你能夠將讀操做分佈到其它的 slave,從而減少master 的壓力。可是,當 slave 增長到必定數量時,slave 對 master 的負載以及網絡帶寬都會成爲一個嚴重的問題。這種結構雖然簡單,可是,它卻很是靈活,足夠知足大多數應用需求。當設置 log_slave_updates 時,你可讓 slave 扮演其它 slave 的 master。此時,slave 把 SQL 線程執行的事件寫進行本身的二進制日誌(binary log),而後,其它的 slave 能夠獲取這些事件並執行它,從而有效緩解master 的壓力。以下:

 

 

 

 

 

Mysql5.6之後版本

 

GTID （global transaction ID）是一個已提交事務的編號，且是全局惟一編號

GTID實際是UUID+TID組成的。其中UUID是一個mysql實例的惟一標識。TID表明了該實例上已提交的事務數量，而且隨着事務提交單調遞增。

GTID功能：(1)能夠知道事務最初是從哪一個實例上提交的

 (2)方便了Replication的Failover

 

 

Replication failover的操做過程

 A————>B ----------->C  

|_____________________|

 

 

若A 的服務器宕機了，須要將業務切換到B 上，同時又須要將C的複製源改成B ，修改複製源很簡單，（CHANGE MASTER TO MASTER_HOST=XXX，MASTER_LOG_FILE=XXX，MASTER_LOG_POS=XXX）難點在於，因爲同一個事務在每臺機器上的binlog名字和位置都不同，那麼怎麼找到C當前同步的中止點所對應B的master_log_file和master_log_pos是何時

因爲同一事務的GTID在全部節點上的一致性，根據C當前中止的GTID就能惟必定位到B上的GTID。只須要知道IP，密碼，端口就能夠了，mysql會從內部的GTID自動找到同步點

 

 

多線程：支持多線程的複製，採用多個線程，每一個線程處理不一樣的database，提升了併發性能，在必定程度上解決了slave延遲master並很難追上的問題

（延遲問題是當master宕機時，backup可能還未啓動?）

slave-parallel-workers=16最多爲16，=0則表示不開啓多線程，=1則效率最低

 

 

備份：5.7新增長的數據庫導出方法，用mysqlpump代替mysqldump，而mysqldump是單線程的，導出很慢；mysqlpump是多線程的，在社區版中mydumper是多線程的，支持並行操做