mysql 高可用方案梳理
集群部署种类
同步集群
- 结构：
data + sql + mgm节点
- 特点
- 内存级别的，对硬件要求较低，但是对内存要求较大。换算比例为：
1：1.1
- 数据同时放在几台服务器上，冗余较好；
- 速度一般
- 建表需要声明为
engine=ndbcluster
- 扩展性强
- 可以实现高可用性和负载均衡，实现对大型应用的支持
- 必须是特定的mysql版本，如：已经编译好的max版本
- 配置和管理方便，不会丢失数据
异步集群
- 结构：
master + slave
- 特点
- 主从数据库异步数据
- 数据放在几台服务器上，冗余一般
- 速度较快
- 扩展性差
- 无法实现高可用性和负载均衡（只能在程序级别实现读写分离，减轻对主数据库的压力）
- 配置和管理较差，可能会丢失数据
集群部署方案
高可用方案
参考地址
- 主从或主主半同步复制:需要额外考虑
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等聚合功能的支持 |
建议
依据业务场景、数据量、访问量、并发量、高可用要求等综合权衡。
- 若是双主复制，不做数据拆分，可考虑使用
MHA、Keepalived、heartbeat
- 若是双主复制，做数据拆分，可考虑使用
Cobar（阿里mysql中间件）
- 若是双主复制 +
Slave，做数据拆分，需要读写分离，可考虑使用Amoeba（mysql代理，增强mysql，类似产品有mycat）
实现方案
haproxy、keepalived 实现，参考地址
名词解释
| 脑裂问题 |
在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。 |