mysql 强一致性_Mysql高一致高可用方案

一句话总结：使用官方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