MySQL-03-故障转移

时间秒杀一切 提交于 2020-01-28 02:25:19

在高可用领域,除了通过规范化运维和软硬件优化,提升平均失效时间(MTBF), 降低平均恢复时间(MTTR)也非常关键,本文主要讲述的内容是其中的故障转移故障恢复部分。

降低平均恢复时间(MTTR)
  • 宕机的原因
    • 运行环境(操作系统、硬盘、网络等)原因占 35%
    • 性能问题(DDL/长事务导致资源耗尽等)占 35%
    • 复制原因占 20%
    • 其他(数据丢失或损坏)占10%
  • 基于复制的冗余
    • 使用 MySQL 的复制功能搭建热备份
    • 主备相隔粒度越大,可用性保障等级越高(机柜<机房<城市)
  • 故障转移
    • 应用和数据库连接方式会影响故障转移的时效,应用可以通过虚拟IP/DNS/中间件等形式访问数据库
    • 虚拟IP,一个虚拟 IP 绑定一个真实 IP,故障转移时把绑定的 IP 修改为备库的 IP 即可实现快速故障转移
    • DNS,一个 DNS 可以绑定多个 IP,可以实现快速故障转移,同时可以实现负载均衡
    • 中间件,通过重写 JDBC 等接口,灵活调用和访问数据库,可以实现快速故障转移、读写分离、负载均衡,同时可以实现分库分表等分布式查询等
故障探测
I. 探测方法
  1. ping 虚拟ip
  2. select 获取 test 库中的 heartbeat 表
  3. update 更新 test 库中的 heartbeat 表 create table heartbeat (ts timestamp);
II. 探测结果汇总
  1. 网络异常: 网络连接超时,无法从网络上找到对应主机
    • 被探测实例单机网络故障
    • 被探测实例所在机房网络故障
    • HA 程序所在机器网络故障
    • HA 程序所在机房网络故障
  2. 主机异常: 网络连接被拒绝,找到主机,无法在主机上找到对应服务端口的实例
    • 被探测实例所在机器机器故障
    • 被探测实例异常退出
  3. 实例异常: 探测连接创建超时,服务端口存在,但是创建连接时超时
    • 被探测实例异常,已经无法正常提供服务
  4. 读写异常: 成功创建连接,但 select/update 操作执行超时,但是无法执行读/写操作
    • 被探测实例 Hang 住
III. 探测程序部署架构
  1. 单点部署,自身不具备高可用
  2. 热备部署,自身具备高可用
    • 使用 Keepalived 进行监控和切换
    • 如果发生机房间的网络故障,容易产生脑裂(两个机房都认为对方有问题)
  3. 分布式部署,避免脑裂
    • HA 程序使用 zookeeper 保存、识别自身的状态,也可以用来并发同步
    • 需要至少在三个机房各一台机器,部署至少 3 个节点的 zookeeper 集群
    • 利用 PAXOS 协议的分布式一致性,避免脑裂,准确判断问题节点
故障转移和修复
  1. 根据探测结果判断是否出现故障,如果是故障,则判断是否是提供服务的主库
  2. 查看备库备库状态,确认备库可用,并且备库 Replication 的延迟小于阈值
  3. 等待备库应用 relay log(需要设置应用超时时间),然后 stop slave;
  4. 记录备库 relay log 对应主库的位点
  5. 掉用中间件/DNS/VIP 的接口,把应用流量转移到备库
  6. 把新主库设置为 RW
  7. 老主库再次连接上后,kill 掉它上面的所有连接,保证应用流量都到备库,避免 DNS 等 catch 功能导致的切换不干净
  8. 老主库再次连接上后,把它设置为 RO
  9. 老主库恢复后,进行故障恢复:
    • 修复数据:切花前备库往往存在一点延迟,根据记录的位点,从老主库 binlog 提取数据,来修复新主库
    • 修复复制:重新启动复制后,往往会出现主键冲突,需要谨慎对比和修复数据,不能盲目 skip 复制的错误
故障转移程序依赖的数据
  1. 主备关系和实时状态
  2. 故障转移黑名单
  3. 每个实例的故障转移类型:中间件、DNS、VIP
  4. 每种故障转移类型的切换接口
  5. 每个实例的故障转移级别:遇到哪一种类型的故障(探测结果)进行切换
MHA 介绍
  • 架构
    • Manager 单点部署
    • Node 随 MySQL 实例部署
IP 角色
192.168.1.200 Manager
192.168.1.201 Node
192.168.1.202 Node
192.168.1.203 Node

在这里插入图片描述

  • 功能简介

    • 一主多备情况下 Master 自动监控和快速故障转移(9-12s)。
    • 在线切换 Master 到不同主机,在替换 raid 控制器、提升 master 机器硬件等等情况下。
    • Master crash 不会导致主从数据不一致性,MHA 自动识别 slave 间 relay log events 的不同,然后应用与不同的slave,最终所有 slave 都同步。
    • 适用任何存储引擎。
  • MHA 的实施步骤

    • 从 Down 的主上面获取到 Binlog 事件
    • 确定最新(最全)的从库(比较Master_Log_File,Read_Master_Log_Pos)
    • 分别应用不同的relay log事件到其他从库
    • 应用从主库上获取的binlog事件(发生故障时的事件)
    • 提升一个从库为新的主库(此时从库已经一致)
    • 将其他从库的主库重新指定
  • 主库探测逻辑

    • 支持 masterha_secondary_check ,通过配置另外一个机器(remote_host1)作为跳板探测 Master,Manager-(A)->remote_host1-(B)->Master_host。B 探测失败才会执行 FO。
    • 两种探测方式可选: ping_connect/ping_select,默认为 select,间隔默认是 3 秒,失败 3 次(代码写死的)则认为 master_down 。
  • Node Fencing,用户可以自己实现一个 shutdown_script,设置配置文件后 MHA 会自动调用

  • 功能限制

    • 不支持多级复制 M->M->S
    • 保留中继日志,需要定期清理
    • 支持最大集群数 100 左右
    • MHA Manager 本身是单点(可结合 Keepalived 实现高可用)
参考文档

《高性能 MySQL》

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!