酷播亮新聞
文章摘要： slave本地的sql_thread應用中繼日誌到本地資料庫中 傳統的主從複製 對於傳統的主從複製多執行緒複製 半同步複製解決了傳統複製潛在的slave丟失master事物的問題
MySQL有很多種複製，至少從概念上來看，傳統的主從複製，半同步複製，GTID複製，多執行緒複製，以及組複製（MGR）。
咋一看起來很多，各種各樣的複製，其實從原理上看，各種複製的原理並無太大的異同。
每一種複製的出現都是有其原因的，是解決（或者說是彌補）前一種的複製方案的潛在的問題的。
新的複製方式的出現，是基於對原複製某一方面增強或者是優化的結果，而不是全新的一種方案或者技術，所以就不難理解為什麼有這麼多中複製。
其實搞出來這麼多概念，個人覺得是源於開源的原因吧，不同複製版本的出現，因為是一個不斷髮現問題就解決問題的過程。
如果是閉源的資料庫，你只管打補丁就行了，SP1,SP2,SP3……，應該不會出現這麼多概念上的東西。
本文僅從原理上粗略總結各種複製技術的特點以及解決的問題，不涉及太多的細節問題。
MySQL複製的原理圖（圖片來源於深入淺出MySQL）
大致的流程如下：
1，搭建完主從之後，slave連線至master，slave的io_thread等待主庫的binlog資訊
2，master上執行各種DDL或者DML命令，執行完成執行生成binlog
3，master上的binlog_dump執行緒將生成的binlog傳送給slave的slave的io_thread
4，slave的io_thread接受到master上的binlog之後將binlog寫入本地的中繼日誌檔案
5，slave本地的sql_thread應用中繼日誌到本地資料庫中
傳統的主從複製
對於傳統的主從複製,Slave連線至master的典型操作如下，就是手工指定slave要從master的哪個檔案的哪個點開始執行其二進制日誌。
CHANGE MASTER TO
MASTER_HOST=’***.***.***.***’,
MASTER_USER=’username’,
MASTER_PASSWORD=’pwd’,
MASTER_PORT = 3306,
MASTER_LOG_FILE=’mysql-bin.000047′,
MASTER_LOG_POS=3112;
潛在的問題：
1，資料非同步複製，master提交事物並不需要與slave確認，binlog以非同步的方式傳送到slave，很明顯，潛在的問題就是如果master宕機，可能存在沒有傳遞到slave的binlog，造成事物的丟失。
2，需要手工確認logfile以及logfile的偏移量
半同步複製
半同步複製最大的特點就是改進了傳統的主從複製潛在的主從不一致的問題，
半同步複製要求master提交事務之後，等到至少一臺slave接收到binlog並且成功寫入到中繼日誌中才算返回給客戶端成功提交的訊息。
這樣就確保了master上所有的事物，都可以傳遞至至少一個slave，master宕機的情況下並不會丟失事物，解決了傳統複製潛在的問題1 ，但是問題2依舊。
潛在的問題：
1，依舊需要手工確認logfile以及logfile的偏移量
GTID複製
GTID是一個基於原始mysql伺服器生成的一個已經被成功執行的全域性事務ID，它由伺服器ID以及事務ID組合而成。
這個全域性事務ID不僅僅在原始伺服器器上唯一，在所有存在主從關係 的mysql伺服器上也是唯一的。
正是因為這樣一個特性使得mysql的主從複製變得更加簡單，以及資料庫一致性更可靠。
典型的GTIDslave啟動指令碼如下
change master to
master_user=’username’,
master_password=’pwd’
MASTER_AUTO_POSITION = 1;
相對於傳統的主從複製，或者是提高了安全性的半同步複製，在搭建主從，或者是改變主從的時候，
操作方式都是需要手動指定binlog的檔案以及檔案的偏移量，說白了就是人為地去判斷slave應該從從master的哪個binlog中的哪個位置開始重放二進制日誌中的內容。
這樣勢必會增加手動操作以及人為判斷錯誤的可能性，不是太方便做主從或者故障轉移操作。
相對傳統的複製，GTID的優勢：
1、更簡單的搭建主從複製，以及實現故障轉移，不用以前那樣在需要手工指定log_file和log_pos。
2，正常情況下，GTID是連續沒有空洞的，因此主從庫出現數據衝突時，可以用新增空事物的方式進行跳過，跳過錯誤的事物更加方便。
多執行緒複製
半同步複製解決了傳統複製潛在的slave丟失master事物的問題，GTID複製簡化複製的實現，解決了傳統複製過於複雜的的問題，算是原始複製的兩個補丁。
從安全性和複雜程度兩個緯度改進了傳統複製，但是傳統複製依然潛在一個致命的問題，就是主從複製的延遲。
slave上的sql_thread應用中繼日誌到本地資料庫中，是一個單執行緒的操作，這樣面對大量的binlog，就可能存在效率上的問題，
多執行緒複製就是通過並行解析中繼日誌的方式，提要slave上sql_thread的執行效率，從而改善主從複製延遲的問題（當然也需要master的binlog做一定的優化）
MGR（MySQL Group Replication）
MGR，MySQL的組複製，不僅僅是複製的問題，可以認為是結合了傳統的複製，半同步複製（機制不一樣，多數節點同步提交），GTID複製等一系列特性的一種高可用解決方案，並且具備故障探測功能，自動檢測並剔除發生了故障的節點
因此說是一種高可用以及高擴充套件的解決方案，而不僅僅是完成複製的功能。
MGR的一些特性
高一致性，基於原生複製及paxos協議的組複製技術，並以外掛的方式提供，提供一致資料安全保證；
高容錯性，只要不是大多數節點壞掉就可以繼續工作，有自動檢測機制，當不同節點產生資源爭用衝突時，不會出現錯誤，按照先到者優先原則進行處理，並且內建了自動化腦裂防護機制；
高擴充套件性，節點的新增和移除都是自動的，新節點加入後，會自動從其他節點上同步狀態，直到新節點和其他節點保持一致，如果某節點被移除了，其他節點自動更新組資訊，自動維護新的組資訊；
高靈活性，有單主模式和多主模式，單主模式下，會自動選主，所有更新操作都在主上進行；多主模式下，所有server都可以同時處理更新操作。
對於MGR，筆者僅簡單做過測試，搭建起來一如跟普通的複製並無太大差異，並不複雜，網路上的評價也很高，大有一統各種第三方高可用技術的趨勢。
缺點是出來的時間太短（MGR是是MySQL官方於2016年12月推出的，對於網際網路來說，個人感覺超過已經不短了），可能存在這某些位置的問題。
總結
MySQL的複製，任何一種新方案的出現，其原理差異不大，都是爲了解決前一種方案潛在的問題的，是作為前一種複製的提升或者說增強，開源沒有完美的解決方案，但是有不斷完善的解決方案，這不是開源的魅力之一嗎？
不同的複製其技術細節上可能有差異，但是本質性的東西是一樣的。
當然每一種複製都有其自身的細節上的特性，只能在實際應用中實踐了。
這也不由得令人想到各種資料中的各種隔離級別（isolation），雖然不能完全做類比，與複製一樣，每一種增強的隔離級別的，都是為解決前一種隔離級別中存在的問題而出現的。
本文永久更新連結地址： https://www.linuxidc.com/Linux/2018-05/152528.htm