一句话总结：使用官方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
随时随地看视频
