總結
MMM是是Perl語言開發的用於管理MySQL主主同步架構的工具包。主要作用：管理MySQL的主主復制拓撲，在主服務器失效時，進行主備切換和故障轉移。
MMM缺點：故障切換可能會丟事務(主備使用半同步復制解決)。不支持GTID。社區不活躍。MMM無法完全的保證數據一致性，所以適用於對數據的一致性要求不是很高的場景。（因為主備上的數據不一定是最新的，可能還沒
從庫的新。解決方法：開啟半同步）。
MHA是開源的 MySQL 的高可用程序，它為 MySQL 主從復制架構提供了故障轉移功能。MHA提供了一個虛擬IP暴露給應用，這個虛擬IP在故障轉移發生時可以進行飄移。還有一個MHA管理者可以管理MHA中的node節點，他的作用是在發生故障時可以指揮故障轉移，可以對主節點進行健康檢查。
MHA優點：可以支持GTID復制，可以選舉最合適的slave成為master。
MHA缺點：需要自行開發實現VIP的配置，只監控了主節點是否可用，沒有監控從節點。
MGR是
主從復制如何工作
-
在主庫把數據記錄到binlog（二進制日志）。
-
備庫開IO線程把binlog復制到自己的relaylog（中繼日志）。
-
備庫讀取中繼日志，重放到備庫上。
半同步復制
半同步復制可以確保備庫擁有主庫數據的拷貝，減少了數據丟失的危險。
半同步復制指的就是主庫寫入 binlog 日志之后，就會將數據同步到從庫的 relay log 之后，會返回一個 ack 給主
庫，主庫接收到至少一個從庫的 ack 之后才會認為寫操作完成了。如果一直沒有響應，會超時轉化為異步復制。
半同步和異步復制區別是：半同步會延遲通知客戶端。
半同步復制的潛在問題
客戶端事務在存儲引擎層提交后，在得到從庫確認的過程中，主庫宕機了，此時，事務還沒發送到從庫上，此時，客戶端會收到事務提交失敗的信息，客戶端會重新提交該事務到新的主上，當宕機的主庫重新啟動后，以從庫的身份重新加入到該主從結構中，會發現，該事務在從庫中被提交了兩次，一次是之前作為主的時候，一次是被新主同步過來的。針對潛在問題，MySQL 5.7引入了一種新的半同步方案：將“Waiting Slave dump”被調整到“Storage Commit”之前。
- 半同步不會阻塞主庫上的事務提交，只有通知客戶端被延遲了。
- 備庫在接收到事務后發送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分庫分表。
分庫分表相關知識
切分方式
-
垂直切分：是按照業務對數據表分類，比如用戶表，商品表可以分成多個表，作用是可以分散數據庫的訪問壓力，這樣做並不能減少單表的數據量。
-
水平切分：是按照某個字段的某種規則，把數據切分到多張數據表。
分片集群的兩種算法
分庫分表集群模式適用於十億級數據總量大型應用
-
范圍法，例如有三個節點，第一個節點存放1-2億數據，第二個節點存放2-3億數據，第三個節點存放3-4億數據。優點是加節點比較方便，缺點是數據可能存放的不均勻。
-
hash法，用id取模的方法均勻的存到節點中，好處是數據分配均衡，缺點是節點不容易擴展，需要提前部署足夠的節點。
互聯網主流MySQL集群架構
讀寫分離和分片的組合運用。在中間件下掛載三個主庫的分片，為了讀寫分離和高可用，主庫下有兩個從庫可以備份數據和查詢數據。再配合MHA、MGR進行一個故障轉移。
擴展知識：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是沒有摘除掉的，過了一段時間上層交換機恢復了就會導致此問題。
Re
MOOC