Mysql高一致高可用方案
一句話總結：使用官方Mysql Innodb Cluster叢集方案實現Mysql冗餘備份，無單點故障的高可用性。
專案背景：
1、對資料可用性要求高，要求多節點冗餘備份，Mysql單點故障後可以切換到其他節點
2、對資料準確性要求高，對Mysql寫資料時，需要強一致性備份，不能是非同步的備份
3、併發請求低
業內方案：
| 方案 | 優點 | 缺點 |
| 主備或一主多備，預設為非同步複製，可安裝外掛半同步複製 | 官方方案，可進行讀寫分離，配置較簡單 | 1、寫節點單點故障 2、預設非同步備份，非強一致性 3、將從庫提升為主庫需要應用層實現 |
| 雙主 + keepalive + 虛IP | 雙主可同時寫 | 1、引入了keepalive元件 2、雙主同時寫存在較多衝突場景 |
| MariaDB Gelera Cluster | 支援多寫和高可用性，同步複製備份，每個節點保留全部資料 | 1、全同步寫，寫效能較低 2、不支援鎖的SQL如lock/unlock等 3、不支援XA事務 |
| Mysql NDB Cluster | 官方方案，支援分片即分散式儲存，支援多寫，號稱可做到99.999%的可用性 | 1、架構複雜，部署也較複雜 2、管理節點的可靠性需額外再考慮 |
| Mysql Fabric | 早起Oracle出的方案，支援分片和基於同步或半同步的複製備份 | 1、用的人較少，方案有點不成熟 2、需要修改程式碼，使用特定的mysql-connector |
業內在冗餘備份的基礎上，提高併發能力的設計思路有：
1、讀寫分離，單入口寫，多節點同時讀
2、寫併發提升：資料分片，即類似分庫，1~100的資料分佈在節點A，100~200的資料分佈在節點B，不同分片的資料如2和102可同時寫
3、寫併發提升：多主即多寫，大多數情況不同資料同時寫，當碰到同時操作同一資料如update同一條記錄，由額外的仲裁流程介入，Mysql多主模式的處理方式為先提交的事務寫成功，後提交的事務失敗丟擲異常，由應用層面處理看是丟棄或是讀取最新事務後重新發起事務
採用方案：
由於分片、多寫等複雜的方案架構複雜，都有一些限制，而專案還用到了Mysql的事務，XA事務，事務隔離，事務傳播，表鎖，行鎖等，固應根據專案需要選擇儘量簡單的方案，採用Mysql官方的Innodb Cluster方案：
Mysql Innodb Cluster方案其實是由Mysql幾個功能和外掛組成的：
1、Mysql Group Replication組複製
基於paxos協議的高一致性備份，寫節點掛掉後自動重新選主，支援單主模式和多主模式(這裡我們採用單主模式)。具體如下：
1）高一致性
基於原生複製及 paxos 協議的組複製技術，提供一致資料安全保證
2）高容錯性
多數派機制，只要不是超過一半節點掛掉就能工作，內建了叢集檢測、fail-tolarence、fail-over等機制
3）高擴充套件性
節點的新增和移除都是自動的，新節點加入後，會自動從其他節點上同步狀態，直到新節點和其他節點保持一致，如果某節點被移除了，其他節點自動更新組資訊，自動維護新的組資訊
4）高靈活性
有單主模式和多主模式，單主模式下，所有寫操作都在主上進行；多主模式下，所有 server 都可以同時處理寫操作
2、Mysql Router
Mysql Router更多是為應用層面服務的，假設應用層面如hibernate配置了資料庫url為具體某個寫節點，當該節點掛掉後，雖然組複製機制會自動重新選主，但應用層面就需要做額外處理如切換資料來源等。
而Mysql Router可以為應用層面遮蔽下面資料庫的變化，提供統一的操作入口。
3、Mysql shell
Mysql shell是作為Mysql Cluster的命令列管理工具。
引用：
https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html
https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html
https://dev.mysql.com/doc/mysql-router/8.0/en/mysql-router-innodb-cluster.html
