mysql 高可用方案梳理

---

集群部署种类

同步集群

1. 结构：data + sql + mgm节点
2. 特点
   • 内存级别的，对硬件要求较低，但是对内存要求较大。换算比例为：1：1.1
   • 数据同时放在几台服务器上，冗余较好；
   • 速度一般
   • 建表需要声明为engine=ndbcluster
   • 扩展性强
   • 可以实现高可用性和负载均衡，实现对大型应用的支持
   • 必须是特定的mysql版本，如：已经编译好的max版本
   • 配置和管理方便，不会丢失数据

异步集群

1. 结构：master + slave
2. 特点
   • 主从数据库异步数据
   • 数据放在几台服务器上，冗余一般
   • 速度较快
   • 扩展性差
   • 无法实现高可用性和负载均衡（只能在程序级别实现读写分离，减轻对主数据库的压力）
   • 配置和管理较差，可能会丢失数据

集群部署方案

高可用方案

参考地址

• 主从或主主半同步复制:需要额外考虑haproxy、keepalived的高可用机制
• 半同步复制优化
• 高可用架构优化
• 共享存储
• 分布式协议

常见实现方式

方案

描述

优点

缺点

LVS + Keepalived（最常用）

存在脑裂问题，还无法做到准确判断mysqld是否HANG的情况

DRBD + Heartbeat

存在脑裂问题，且DRDB并不需要，增加会有其他问题

MySQL Proxy

无法高可用，是一个写分离

MySQL Cluster

官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。

全部使用官方组件，不依赖于第三方软件；可以实现数据的强一致性；

国内使用较少；配置较复杂，需要使用NDB存储引擎，与mysql常规引擎存在一定差异；

MySQL MHA

可解决脑裂问题，但需要IP多，管理麻烦、坑多

相关产品比较

名称

描述

amoeba

中间件早期产品。应用连接amoeba操作mysql，就像操作单个mysql一样，后端还在使用jdbc driver

cobar

amoeba基础上发展版本，显著变化是将jdbc driver改为原生mysql通信协议层。去掉jdbc规范，即不能支持oracle等数据库

mycat

cobar基础上发展版本，显著变化是将BIO改为NIO，并发量大幅提高；增加对Order By、Group By、limit等聚合功能的支持

建议

依据业务场景、数据量、访问量、并发量、高可用要求等综合权衡。

1. 若是双主复制，不做数据拆分，可考虑使用MHA、Keepalived、heartbeat
2. 若是双主复制，做数据拆分，可考虑使用Cobar（阿里mysql中间件）
3. 若是双主复制 + Slave，做数据拆分，需要读写分离，可考虑使用Amoeba（mysql代理，增强mysql，类似产品有mycat）

实现方案

haproxy、keepalived 实现，参考地址

名词解释

名称

解释

脑裂问题

在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。