知数堂分享：MySQL高可用选型

HA考量

  1. 数据安全性，发生failover时要保证数据0丢失
  2. 服务连续性，发送failover时，整个过程需要耗时多久？ 业务是否可容忍这么长的时间？
  3. 服务读写性能

HA覆盖的故障

  1. 硬件故障
    • 磁盘、内存、电源
  2. 网络故障
    • 网络不可用：不通
    • 网络闪断：短时间内在可用和不可用之间震荡
    • 网络稳定性和延迟：网络包丢失率、网络包损坏率、网络包乱序率，网络包重复率、网络包延迟时间 PS: 设计网络方面的阈值时要仔细考量网络环境的网络性能指标和各比率，拿捏好度，过低则频繁触发，过高则failover发生的晚
  3. 系统故障
    • 磁盘空间、IO
    • 内存使用情况

  4. MySQL故障

    • 健康保障：

      • 进程崩溃
      • 连接失去响应：
      • 不能建立连接：连接数过多

    • 复制保障：

      • IO Thread故障
      • 网络故障
      • 数据不一致(可跳过、不可跳过需要通过DBA、业务的视角考虑是跳过还是手工不全，还是重做实例)
  5. 监控故障
    • 意外退出，通过守护进程保障监控端的异常挂掉后自动启动，例如Supervisor，mysqld_safe
    • 监控程序和其他程序发送资源争夺，导致无法响应或者处理缓慢
  6. 脑裂问题(多主)
    • 增加心跳线，例如冗余网络
    • FENCE，通过ssh等强制关闭掉老Master，避免脑裂
    • 一致性选举，paxos/raft，例如redis的sentinel，选举leader，当发生异常时，所有成员根据自己的判断进行投票，超过指定票数后才进行failover

HA方案选型

一致性 & 性能
    数据0丢失
    最大性能

选型
    半同步
    异步

Point:

统一访问IP
单机多实例
多高可用组
状态检测和切换
复制延迟检测
复制状态检测
复制自动修复
故障告警
策略化备份恢复
半同步方式实现数据0丢失
共享存储方式实现数据0丢失
数据库SLA协议:业务连续性、切换时间、数据丢失容忍
Master重启修复
Slave重启修复

results matching ""

    No results matching ""