mysql主從主主與集羣

主從複製

主從複製原理

在Slave 服務器上執行start slave命令開啓主從複製開關，開始進行主從複製。
此時，Slave服務器的IO線程會通過在master上已經授權的複製用戶權限請求連接master服務器，並請求從執行binlog日誌文件的指定位置（日誌文件名和位置就是在配置主從複製服務時執行change master命令指定的）之後開始發送binlog日誌內容
Master服務器接收到來自Slave服務器的IO線程的請求後，其上負責複製的IO線程會根據Slave服務器的IO線程請求的信息分批讀取指定binlog日誌文件指定位置之後的binlog日誌信息，然後返回給Slave端的IO線程。返回的信息中除了binlog日誌內容外，還有在Master服務器端記錄的IO線程。返回的信息中除了binlog中的下一個指定更新位置。
當Slave服務器的IO線程獲取到Master服務器上IO線程發送的日誌內容、日誌文件及位置點後，會將binlog日誌內容依次寫到Slave端自身的Relay Log（即中繼日誌）文件（MySQL-relay-bin.xxx）的最末端，並將新的binlog文件名和位置記錄到master-info文件中，以便下一次讀取master端新binlog日誌時能告訴Master服務器從新binlog日誌的指定文件及位置開始讀取新的binlog日誌內容
Slave服務器端的SQL線程會實時檢測本地Relay Log 中IO線程新增的日誌內容，然後及時把Relay LOG 文件中的內容解析成sql語句，並在自身Slave服務器上按解析SQL語句的位置順序執行應用這樣sql語句，並在relay-log.info中記錄當前應用中繼日誌的文件名和位置點

主從複製模式

異步模式

如上圖，就是主服務接受到客戶端的操作請求，則正常執行然後記錄到binlog日誌後，就直接返回給客戶端結果。在此期間不會考慮binlog日誌是否完整傳輸到從服務器以及是否完整存放到從服務器上的relay日誌中。主節點的log dump線程再去發送日誌到從服務。這種模式對客戶端的響應返回最快，但是一旦主服務(器)宕機，數據就可能會因爲沒有及時發送給從服務而導致從服務數據丟失。

半同步模式

如上圖，這種模式下，當主服務寫入binlog日誌後，就會通知log dump線程發送日誌到從服務的I/O線程，等待從服務將日誌寫入到relay log中，然後返回給主服務一個確認通知，主服務只要接受到一個從服務的確認通知，就會返回給客戶端結果，否則需要等待直到超時時間然後切換成異步模式再返回給客戶端結果。這樣做的目的可以使主從數據庫的數據延遲縮小，可以提高數據安全性，確保了事務提交後，binlog至少傳輸到了一個從節點上，雖然不能保證從節點將此事務更新到db中，但確保了binlog日誌已經記錄到relay log中。性能上會有一定的降低，客戶端響應時間會變長。

全同步模式

此中模式就是在半同步的基礎上，等待從服務的I/O線程和SQL線程都執行完畢，將數據更新到從服務器後，返回確認信息後，主服務才返回給客戶端成功信息。此中模式完全保證了主從服務的數據一致性，但是相應的響應時間會變長，性能較低。

主從複製方式

傳統方式

傳統方式即是基於binlog日誌的position點來指定日誌從什麼位置開始執行增量同步，如果這個設置的不對，就會導致主從數據不一致。

GTID 方式

基於GTID的複製是從Mysql5.6開始支持的一種新的複製方式，此方式與傳統基於日誌的方式存在很大的差異，在基於GTID的複製中，首先從服務器會告訴主服務器已經在從服務器執行完了哪些事務的GTID值，然後主庫會有把所有沒有在從庫上執行的事務，發送到從庫上進行執行，並且使用GTID的複製可以保證同一個事務只在指定的從庫上執行一次，這樣可以避免由於偏移量的問題造成數據不一致。

GTID方式可以很方便的進行故障轉移，記錄master最後事務的GTID值。比如master：A，slave：B,C。當A掛了後，B執行了所有A傳過來的事務。當C連接到B後，在自己的binlog找到最後一次A傳過來的GTID。然後C將這個GTID發送給B，B獲取到這個GTID，就開始從這個GTID的下一個GTID開始發送事務給C。這種自我尋找複製位置的模式減少事務丟失的可能性以及故障恢復的時間。且slave不會丟失master的任何修改。雖然不支持非事務引擎，故障處理比較複雜，但作爲5.6新引入的功能，以取代舊的傳統方式。還是推薦使用GTID方式

什麼是GTID，也就是全局事務ID，其保證爲每一個在主上提交的事務在複製集羣中可以生成一個唯一的ID。

binlog格式選擇

STATEMENT

基於SQL語句的複製（statement-based replication，SBR），只記錄執行的sql，不需要記錄每一行數據的變化，減少bin-log日誌量，節約IO，提高性能，但是由於記錄的執行語句，所以爲了讓這些語句在slave端也能正確執行，那麼他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，且對非確定性時間，無法保證主從複製數據的一致性，比如uuid()。從而導致主從數據一致性，造成複製鏈路中斷。所以一般爲了複製都不會使用此格式。

ROW

基於行的複製（row-based replication，RBR)，日誌中會記錄每一行數據被修改的形式，然後在slave端再對相同的數據進行回放，僅僅只需要記錄那一條記錄被修改了，修改成什麼樣了。所以日誌內容會非常清楚的記錄下每一行數據修改的細節。任何情況都可以被複制，這對複製來說是最安全可靠的，但是所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容。對於性能要求不高的，數據量不大的可以採用此日誌記錄格式。

MIXED

混合模式複製（mixed-based replication,MBR)，就是上面兩種格式的混合，由mysql根據語句和操作選擇記錄日誌的方式，將上面兩種方式的優點都集合了，所以推薦使用此日誌格式。

主從複製優點

在從服務器可以執行查詢工作(即我們常說的讀功能)，降低主服務器壓力;（主庫寫，從庫讀，降壓）
在從主服務器進行備份，避免備份期間影響主服務器服務;（確保數據安全）
當主服務器出現問題時，可以切換到從服務器。（提升性能）

主從複製缺點

master和slave已經實現同步，即在master上寫入新數據，自動同步到slave。而從庫只能讀不能寫，一旦從庫有寫入數據，就會造成主從數據不一致！
只是提供一種成本較低的數據備份方案加不完美的容災和負載均衡

主從複製條件

開啓Binlog功能
主庫要建立賬號
從庫要配置master.info（CHANGE MASTER to…相當於配置密碼文件和Master的相關信息）
start slave 開啓複製功能
Mysql複製最好確保master和slave服務器上的Mysql版本相同（如果不能滿足版本一致，那麼要保證master主節點的版本低於slave從節點的版本）
master和slave兩節點間時間需同步
作爲複製的所有Mysql節點的server-id都不能相同
binlog文件只記錄對數據庫有更改的SQL語句（來自主庫內容的變更），不記錄任何查（select，show）語句

主從複製實踐

架構篇——MySQL主從複製(Master-Slave)詳解

MySql主主(主從)同步配置詳解

show master status 和 show slave status 可以查看複製線程狀態，狀態詳解參考：https://blog.csdn.net/qq_33285112/article/details/78793539

主主複製

主從複製：主庫授權從庫遠程連接，讀取binlog日誌並更新到本地數據庫的過程；主庫寫數據後，從庫會自動同步過來（從庫跟着主庫變）；
主主複製：主從相互授權連接，讀取對方binlog日誌並更新到本地數據庫的過程；只要對方數據改變，自己就跟着改變；

主主複製注意點

主主複製和主從複製有一些區別，因爲多主中都可以對服務器有寫權限，所以設計到自增長重複問題，例如：出現的問題（多主自增長ID重複）

首先在A和B兩個庫上創建test表結構;
停掉A，在B上對數據表test(存在自增長屬性的ID字段)執行插入操作，返回插入ID爲1;
然後停掉B，在A上對數據表test(存在自增長屬性的ID字段)執行插入操作，返回的插入ID也是
然後同時啓動A,B，就會出現主鍵ID重複

解決方法：

在主主同步配置時，需要將兩臺服務器的auto_increment_increment 設置爲 n, auto_increment_offset 分別配置爲1 2 ..., 第一臺從1開始，第二臺就是2，以此類推

集羣

官方 mysql cluster

需要用到mysql cluster安裝包，在集羣中的每一個機器上安裝。

有三個關鍵概念：Sql節點（多個），數據節點（多個），管理節點（一個），數據節點之間採用的是同步複製來保證各節點之間的數據一致性。

同步複製：

Master執行提交語句時，事務被髮送到slave，slave開始準備事務的提交。
每個slave都要準備事務，然後向master發送OK(或ABORT)消息，表明事務已經準備好（或者無法準備該事務）。
Master等待所有Slave發送OK或ABORT消息，如果Master收到所有 Slave的OK消息，它就會向所有Slave發送提交消息，告訴Slave提交該事務；如果 Master收到來自任何一個Slave的ABORT消息，它就向所有 Slave發送ABORT消息，告訴Slave去中止事務。
每個Slave等待來自Master的OK或ABORT消息。如果Slave收到提交請求，它們就會提交事務，並向Master發送事務已提交的確認；如果Slave收到取消請求,它們就會撤銷所有改變並釋放所佔有的資源，從而中止事務，然後向Masterv送事務已中止的確認。
Master收到來自所有Slave的確認後，就會報告該事務被提交（或中止），然後繼續進行下一個事務處理。
由於同步複製一共需要4次消息傳遞，故mysql cluster的數據更新速度比單機mysql要慢。所以mysql cluster要求運行在千兆以上的局域網內，節點可以採用雙網卡，節點組之間採用直連方式。

galera cluster

簡介

圖中有三個實例，組成了一個集羣，而這三個節點與普通的主從架構不同，它們都可以作爲主節點，三個節點是對等的，這種一般稱爲multi-master架構，當有客戶端要寫入或者讀取數據時，隨便連接哪個實例都是一樣的，讀到的數據是相同的，寫入某一個節點之後，集羣自己會將新數據同步到其它節點上面，這種架構不共享任何數據，是一種高冗餘架構。

一般的使用方法是，在這個集羣上面，再搭建一箇中間層，這個中間層的功能包括建立連接、管理連接池，負責使三個實例的負載基本平衡，負責在客戶端與實例的連接斷開之後重連，也可以負責讀寫分離（在機器性能不同的情況下可以做這樣的優化）等等，使用這個中間層之後，由於這三個實例的架構在客戶端方面是透明的，客戶端只需要指定這個集羣的數據源地址，連接到中間層即可，中間層會負責客戶端與服務器實例連接的傳遞工作，由於這個架構支持多點寫入，所以完全避免了主從複製經常出現的數據不一致的問題，從而可以做到主從讀寫切換的高度優雅，在不影響用戶的情況下，離線維護等工作，MySQL的高可用，從此開始，非常完美。

現在已經知道，Galera Cluster是MySQL封裝了具有高一致性，支持多點寫入的同步通信模塊Galera而做的，它是建立在MySQL同步基礎之上的，使用Galera Cluster時，應用程序可以直接讀、寫某個節點的最新數據，並且可以在不影響應用程序讀寫的情況下，下線某個節點，因爲支持多點寫入，使得Failover變得非常簡單。

所有的Galera Cluster，都是對Galera所提供的接口API做了封裝，這些API爲上層提供了豐富的狀態信息及回調函數，通過這些回調函數，做到了真正的多主集羣，多點寫入及同步複製，這些API被稱作是Write-Set Replication API，簡稱爲wsrep API。

通過這些API，Galera Cluster提供了基於驗證的複製，是一種樂觀的同步複製機制，一個將要被複制的事務（稱爲寫集），不僅包括被修改的數據庫行，還包括了這個事務產生的所有Binlog，每一個節點在複製事務時，都會拿這些寫集與正在APPLY隊列的寫集做比對，如果沒有衝突的話，這個事務就可以繼續提交，或者是APPLY，這個時候，這個事務就被認爲是提交了，然後在數據庫層面，還需要繼續做事務上的提交操作。

這種方式的複製，也被稱爲是虛擬同步複製，實際上是一種邏輯上的同步，因爲每個節點的寫入和提交操作還是獨立的，更準確的說是異步的，Galera Cluster是建立在一種樂觀複製的基礎上的，假設集羣中的每個節點都是同步的，那麼加上在寫入時，都會做驗證，那麼理論上是不會出現不一致的，當然也不能這麼樂觀，如果出現不一致了，比如主庫（相對）插入成功，而從庫則出現主鍵衝突，那說明此時數據庫已經不一致，這種時候Galera Cluster採取的方式是將出現不一致數據的節點踢出集羣，其實是自己shutdown了。