一句话总结: 使用官方 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
来源: https://www.cnblogs.com/yuzhengzhong/p/9695499.html