一句話總結：使用官方Mysql Innodb Cluster集群方案實現Mysql冗余備份，無單點故障的高可用性。
項目背景：
騰訊數據中心網絡的SDN控制器，項目業務對數據的要求如下：
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
