主從復制如何作業
-
在主庫把資料記錄到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是沒有摘除掉的，過了一段時間上層交換機恢復了就會導致此問題，
https://zhangjunjia.github.io/2019/03/16/mysql-mmm-mha/
https://www.pianshen.com/article/13731481649/
Re
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/304831.html
標籤：MySQL