Mysql高一致高可用方案

Posted 2021-01-08 余正忠

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