mysql高可用架构

高可用

---

 

高可用(High Availabiltity)

• 应用提供持续不间断(可用)的服务的能力
• 系统高可用性的评价通常用可用率表示

 

造成不可用的原因

• 硬件故障(各种)
• 预期中的系统软硬件维护
• 软件缺陷(应用代码，服务程序都可能存在bug)
• 攻击，泄露，认为失误...等安全事件
• 对于系统来说，不可用时间是各关键组件不可用时间的总和.....

 

提高可用性的主要手段

• 冗余，Redundancy
• 关键软硬件通过备用冗余避免故障时长时间的不可用
• 数据软件，硬件，存储的数据，都需要通过冗余确保故障时可替换

mysql高可用常见方案：

• 数据库服务在冗余实现上有其特殊性
• • 数据：服务＂有状态＂与数据冗余
  • 数据库可用性考虑两部分：数据可用性，服务可用性；
• 实现方式多种多样，同一种数据也会有多种实现方案
• 可用性目标循序渐进
• • 任何故障都不会造成数据丢失－＞可以较快速恢复服务（高可用）

 

高可用方案

---

 

1.mysql--基于共享存储的单活方案(不常用)

 

• SAN，方案比较昂贵；因此不常用；
• 且数据库备用机，只是机器活着，但是没有没有起mysql服务；
• • 因为大部分共享存储或数据库是不允许同一份数据被不同数据使用的；
• 本地数据通过RAID等手段保证数据安全

 

 

2.基于存储复制的数据冗余单活(不常用)

• 存在一定浪费，备用机器一直不在用，等待主机挂掉，才会使用备用机；
• 而且DRBD（两台机器间通过网络，备份数据），不是100%的保证数据不丢失；

 

 

3.基于集群提交通信协议的多主复制(一定场景适用)

 

 

基于主从复制的高可用方案

---

 

4.基于Mysql主从复制(常用，普适)

 

• 备库，在线上也会提供服务，避免浪费；
• 而主从复制，也保证了数据不会丢失。

 

mysql主从复制高可用方案需要改进的问题

1. 主从服务器各自有IP地址，发生主从切换后应用需要修改重启；
   • 如何让应用快速找到从库；VIP/DNS
2. 人工判断主库是否故障再发起切换需要花较多时间
   • 如何自动探知；监控探知并自动VIP/DNS;
3. 主从复制存在客观延迟，切换后可能造成事务数据丢失。
   • 由于网络延时，如何避免数据丢失。

 

1.为了避免应用人工修改切换IP，引入VIP（virtual ip）漂移方案：

 

方案二：

DNS，应用服务器，使用域名；

平时，将域名注册在主库上，而主库挂掉，将域名注册到从库就可以了；

 

 

2.为了减少人工介入处理的时间开销引入自动探活处理机制

 

高可用中间层与RDS

• VIP/DNS解决 应用切换问题
• 监控和管理服务器解决自动判断故障切换和VIP/DNS漂移
• VIP/DNS管理+探活+主从关系切换 = 高可用中间层
• • 透明切换管理+靠谱数据探活+使用切换 = 高可用中间层
• 云环境+高可用中间层+底层数据库=一种PaaS=基本RDS、

 

高可用中间层

• MHA
• • 自动选择复制延迟最小的从节点并试图补全日志（但大部分主机故障下行不通）
  • 通常要求两从以上，会进行主从关系切换
  • 不提供VIP管理方案
• MMM
• • 提供了基本的VIP管理功能
  • 适合双主配置的一对主机，不会主动切换主从关系
  • 不支持主从数据延迟判断和补全

 

一般使用MHA，开源；

 

 

3.mysql主从复制延迟

为什么日志传输延迟

为什么主从复制，主从库会数据不一致；

 

解决方案：

mysql半同步技术：

主库一次commit，要等到主库持久化完成，以及从库也持久化完成，才给主键放回commit成功。

 

但是问题：

主库等待从库的时间是不可控的；

主库发现从库写不进去了，可以等待几秒，之后主库复制自动降级成异步复制；但这也可能导致数据不一致；

 

较完善的mysql高可用方案

• 半同步复制+高可用中间层+VIP管理方案
• 高可用中间层=靠谱探活+主从切换+使用VIP管理的接口

 

例如：

• 半同步复制+MHA（高可用中间层）+Keeplive（VIP管理方案）
• 半同步复制+RDS

 

 

总结

---

 

• 高可用指标至少3个9目标4个9
• 高可用核心就是使用冗余
• 数据库高可用两个部分
• • 数据可用性--数据有状态
  • 服务可用性
• 高可用方案
• • 基于共享存储SAN的单活方案
  • • SAN,设备昂贵
    • 单活，备用机浪费，因为同一份数据不能被不同mysql实例使用；
    • 本地数据可以通过RAID等手段保证
  • 基于DRBD存储复制的数据冗余单活
  • • 基于SAN方案的改进，不使用SAN设备
    • 单活，备用机浪费
    • DRBD基于两台机器间通过网络备份数据，数据不能100%保证
  • 多主复制--mysql cluster
• 基于mysql主从复制（常用，普适）
• • 备份，在线上可提供只读服务，避免浪费；
  • 主从复制，也保证了数据不会丢失
• 基于mysql主从复制的问题
• • 主从服务器各有IP地址，发生主从切换后应用需要修改重启；
  • • 使用VIP(virtual IP)/DNS管理方案，当发生切换是，只需要将VIP从主库漂移到从库，对应用来说是透明的。
  • 人工判断主库是否故障，在发起切换需要时间长
  • • 使用监控服务器，自动靠谱探知+自动主从切换
  • 主从复制存在客观延迟，切换后可能造成事务数据丢失
  • • 使用半同步复制技术，但也要考虑到从库宕机，主库应该自动降级成异步复制；
  • 解决问题后的mysql高可用方案
  • • VIP管理方案+高可用中间层+半同步复制
• 高可用中间层
• • VIP/DNS管理+靠谱探活+主从关系切换=高可用中间层
  • 云环境+高可用中间层+底层数据库=一种paas=基本RDS
  • MHA/MMM
• MHA
• • 自动选择复制延迟最小的从节点并试图补全日志（主机故障下行不通）
  • 自动探活
  • 自动主从切换
  • 不提供VIP管理方案，但提供使用VIP方案的接口