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个独立的个体。由于相互失去了联系,都以为是对方出了故障。 |