MySQL-03-故障转移

在高可用领域，除了通过规范化运维和软硬件优化，提升平均失效时间（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 保存、识别 MySQL 实例和自身的状态，也可以利用它实现分布式锁，进行并发同步
   • 需要至少在三个机房各一台机器，部署至少 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》