mysql高可用

高可用

一. 定义

服务正常无宕机
服务正常,且无数据丢失

二. 评价

一年内服务不可用时间百分比,9规则
99.9% --- 8h
99.999% --- 5min

三. 导致宕机的原因

35% 运行环境

系统和资源集合,如OS、硬盘、网络

最普遍--磁盘空间耗尽

35% 性能问题

如运行糟糕的SQL,
糟糕的Schema、索引设计
或服务器Bug、错误

20% 复制

主备数据不一致

10% 数据丢失、损坏

drop table 误操作

四. 如何实现高可用性

1. 提升平均失效时间

遵从最小权限
使用InnoDB引擎
除非证明有效,否则禁用查询缓存
监控磁盘空间和RAID卷等关键组件
为文件系统预留空间

2. 降低平均恢复时间

系统建立冗余
避免单点失效

五. 如何避免单点失效?

共享存储SAN,基于磁盘复制DRBD(distributed replicated block device)
mysql同步复制--Cluster方案
基于复制的冗余--MMH方案

六.SAN共享存储方案

SAN(Storage Area Network)网络中不同服务器的数据共享。
服务器正常挂载文件系统并操作,如服务器挂了,备用服务器挂载相同文件系统,执行恢复,然后启动MySQL。共享存储的架构如下:


mysql高可用_第1张图片

优点:

  1. 可以避免存储外的其它组件引起的数据丢失。
  2. 部署简单,切换逻辑简单,对应用透明。
  3. 保证主备数据的强一致。

缺点:

  1. 共享存储是单点,若共享存储挂了,则会丢失数据。
  2. 价格比价昂贵。

七.DRBD磁盘复制方案

DRBD(Distributed Replicated Block Device)
通过网卡将主服务器每个块复制到另一个服务器块设备上,并在主设备提交块之前记录下来


mysql高可用_第2张图片

优点

  1. 切换对应用透明
  2. 保证主备数据的强一致。

缺点:

  1. 影响写入性能,由于每次写磁盘,实质都需要同步到网络服务器。
  2. 一般配置两节点同步,可扩展性比较差
  3. 备库不能提供读服务,资源浪费

八. 基于主从复制(单点写)方案

实际中更多是依赖MySQL本身的复制,通过复制为Master制作一个或多个热副本,在Master故障时,将服务切换到热副本

8.1 keepalived、heartbeat

一种HA软件。
检测服务器(web服务器,DB服务器等)状态,
检查原理是模拟网络请求检测,
检测方式包括主要就是IP,端口(TCP_CHECK),keepalived也支持自定义脚本。
keepalived通过监听来确认服务器的状态,如果发现服务器故障,则将故障服务器从系统中剔除。


mysql高可用_第3张图片

优点

  1. 安装配置简单
  2. Master故障时,Slave快速切换提供服务,并且对应用透明。

缺点

  1. 主备IP在同一个网段
  2. 检测机制较弱,需自定义脚本确定Master是否能提供服务,比如更新心跳表等。
  3. 无法保证数据一致性,原生的MySQL采用异步复制,
    若Master故障,Slave数据不是最新
  4. keepalived软件自身的HA无法保证。

8.2 MHA(Master High Availability)

从宕机的主服务器上保存二进制日志来进行回补。


mysql高可用_第4张图片

由两部分组成:
MHA Manager(管理节点)和MHA Node(数据节点)。
MHA Manager定时探测集群中master节点,master故障时,自动将最新数据的slave提升为新master,然后将所有其他的slave重新指向新的master
MHA Node运行在每台MySQL服务器上,主要作用是切换时处理二进制日志

8.3 zookeeper

8.4 Cluster(多点写)方案

8.5 中间件proxy的方案

@参考

你可能感兴趣的:(mysql高可用)