主從複製如何工作
-
在主庫把資料記錄到binlog（二進位制日誌）。
-
備庫開IO執行緒把binlog複製到自己的relaylog（中繼日誌）。
-
備庫讀取中繼日誌，重放到備庫上。
半同步複製
半同步複製可以確保備庫擁有主庫資料的拷貝，減少了資料丟失的危險。
半同步複製在提交過程中增加了一個延遲：提交事務時，在客戶端接收到查詢結束反饋前必須保證二進位制日誌已經傳輸到一臺備庫上。
-
半同步不會阻塞主庫上的事務提交，只有通知客戶端被延遲了。
-
備庫在接收到事務後傳送ack而不是完成事務後傳送。
-
如果備庫一直沒有回應，會超時轉化為非同步複製模式。
配置步驟
在master伺服器上
開啟binlog開啟gtid。
建立同步所用的資料庫賬號。
使用master_data引數備份資料庫。
把備份檔案傳輸到slave。
在slave上操作
開啟binlog開啟gtid。
恢復master上的備份資料庫。
使用change master配置鏈路。
使用start slave啟動複製。
GTID和日誌點
日誌點複製
-
slave請求master的增量日誌依賴於日誌偏移量。
-
配置鏈路時需要指定引數。
-
支援MMM和MHA。
GTID複製
-
全域性事務ID唯一，GTID=source_id:transaction_id。
-
slave增量同步master的資料依賴於其未同步的事務ID。
-
配置鏈路時，slave根據已經同步的事務ID繼續自動同步。
-
支援MHA。
複製方式選擇
-
相容老版本和MMM選擇日誌點複製。
-
其他選擇GTID複製。
MMM架構和MHA架構
MMM和MHA架構的作用
-
對主從複製叢集中的master的健康監控。
-
當master當機後把寫VIP遷移到新的master。
-
重新配置叢集中的其他slave對新的master同步。
MMM的主從複製架構
MMM是perl語言開發的用於管理MySQL主主同步架構的工具包。
主要作用：管理MySQL的主主複製拓撲，在主伺服器失效時，進行主備切換和故障轉移。
MMM無法完全的保證資料一致性，所以適用於對資料的一致性要求不是很高的場景。（因為主備上的資料不一定是最新的，可能還沒從庫的新。解決方法：開啟半同步）。
VIP是基於ARP協議，因此所有節點必須處於同一區域網。
MMM架構的故障轉移步驟
-
SLAVE：
-
已複製日誌的恢復。
-
使用Change Master命令配置新主。
-
-
主備：
-
關掉read_only。
-
遷移寫VIP到新主。
-
MMM架構的配置步驟
配置主主複製的叢集架構。
安裝centos的yum擴充套件包。
安裝所需的perl支援包。
安裝mmm工具包。
配置並啟用mmm服務。
MMM優點
- 提供了讀寫VIP的配置。
MMM缺點
-
故障切換會丟事務(主備使用半同步複製解決)。
-
不支援GTID。
-
社群不活躍。
MHA故障轉移步驟
-
選出最新更新的slave。
-
嘗試從當機的master儲存二進位制日誌。
-
應用差異的中繼日誌給到其他slave。
-
應用從master儲存的二進位制日誌。
-
提升選舉的slave為新的master。
-
配置其他slave向新的master同步。
MHA需要的資源
1主DB。
2-N從DB。
n+2IP地址。
監控使用者。
複製使用者。
MHA配置步驟
配置一主多從的複製架構。
安裝centos的yum擴充套件源和依賴包。
配置叢集內各主機的ssh免認證。
各節點安裝mha_node軟體。
管理節點安裝mha_manager。
配置並啟動mha管理程式。
MHA優點
-
基於gtid和日誌點。
-
選舉最合適的slave成為master。
MHA缺點
-
需要自行開發寫vip指令碼。
-
只監控master。
適用場景
-
使用gtid。
-
一主多從。
-
更少的資料丟失場景。
如何減小主從複製的延遲
主從複製延遲的原因
- 執行了大事務(解決：化為多個小事務)。
解決方法
-
多執行緒複製。
-
使用MGR複製架構(類似PXC)。
MGR架構
MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引進的一個資料庫高可用解決方案，以外掛形式提供。
MGR基於分散式Paxos協議，實現組複製，保證資料一致性。有故障檢測和自動選主功能。
提供單主模式與多主模式，多主模式支援多點寫入。
基於ROW格式的二進位制日誌檔案和GTID特性。
實現原理
MGR由若干個節點共同組成一個複製組，一個事務的提交，必須經過組內大多數節點（N / 2 + 1）決議並通過，才能得以提交。
引入組複製，主要是為了解決傳統非同步複製和半同步複製可能產生資料不一致的問題。組複製依靠分散式一致性協議(Paxos協議的變體)，實現了分散式下資料的最終一致性，提供了真正的資料高可用方案（迫真）。
單主模式
MGR優缺點:
-
組內成員基本無延遲。
-
支援多寫，讀寫服務高可用。
-
資料強一致，不丟事務。
MGR缺點:
-
單主模式很難確認下一個primary。
-
只能gtid，日誌格式必須為row。
場景
-
主從延遲敏感。
-
資料強一致。
-
讀寫高可用。
如何解決讀寫負載大的問題
讀負載大
-
讀寫分離加slave。
-
資料庫中間層做負載均衡。
寫負載大
- Mycat分庫分表。
擴充套件知識：VIP與腦裂
VIP的工作原理是，
- 為當期主機配置一個虛擬網路卡，如eth0:0，該網路卡繫結了唯一的MAC地址和虛擬IP地址VIP
- 區域網內的主機欲與該VIP通訊時，先通過ARP協議取到該VIP對應的MAC地址，再將VIP與MAC地址的對應關係快取在其主機上
- 後續通訊時，使用上一步驟取到的MAC作為報文的MAC地址
VIP切換的原理是，
- 將舊master繫結的虛擬網路卡登出掉
- 在新的master註冊新的虛擬網路卡（產生了新的MAC地址）
- 通知區域網節點更新VIP與MAC的對應關係，後續通訊採用新MAC地址
腦裂的原因，在於舊master節點沒有正常將VIP摘掉，這時區域網機器通過ARP獲取VIP的MAC時，就可能取到舊的MAC地址，導致與舊master通訊。什麼情況會出現這種情況呢？舊master由於上層交換機故障，未與manager節點正常通訊，此時VIP是沒有摘除掉的，過了一段時間上層交換機恢復了就會導致此問題。