MySQL-03-故障转移 | 易学教程

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

宕机的原因
- 运行环境（操作系统、硬盘、网络等）原因占 35%
- 性能问题（DDL/长事务导致资源耗尽等）占 35%
- 复制原因占 20%
- 其他（数据丢失或损坏）占10%
基于复制的冗余
- 使用 MySQL 的复制功能搭建热备份
- 主备相隔粒度越大，可用性保障等级越高（机柜<机房<城市）
故障转移
- 应用和数据库连接方式会影响故障转移的时效，应用可以通过虚拟IP/DNS/中间件等形式访问数据库
- 虚拟IP，一个虚拟 IP 绑定一个真实 IP，故障转移时把绑定的 IP 修改为备库的 IP 即可实现快速故障转移
- DNS，一个 DNS 可以绑定多个 IP，可以实现快速故障转移，同时可以实现负载均衡
- 中间件，通过重写 JDBC 等接口，灵活调用和访问数据库，可以实现快速故障转移、读写分离、负载均衡，同时可以实现分库分表等分布式查询等

网络异常: 网络连接超时，无法从网络上找到对应主机
- 被探测实例单机网络故障
- 被探测实例所在机房网络故障
- HA 程序所在机器网络故障
- HA 程序所在机房网络故障
主机异常: 网络连接被拒绝，找到主机，无法在主机上找到对应服务端口的实例
- 被探测实例所在机器机器故障
- 被探测实例异常退出
实例异常: 探测连接创建超时，服务端口存在，但是创建连接时超时
- 被探测实例异常，已经无法正常提供服务
读写异常: 成功创建连接，但 select/update 操作执行超时，但是无法执行读/写操作
- 被探测实例 Hang 住

单点部署，自身不具备高可用
热备部署，自身具备高可用
- 使用 Keepalived 进行监控和切换
- 如果发生机房间的网络故障，容易产生脑裂（两个机房都认为对方有问题）
分布式部署，避免脑裂
- HA 程序使用 zookeeper 保存、识别自身的状态，也可以用来并发同步
- 需要至少在三个机房各一台机器，部署至少 3 个节点的 zookeeper 集群
- 利用 PAXOS 协议的分布式一致性，避免脑裂，准确判断问题节点

根据探测结果判断是否出现故障，如果是故障，则判断是否是提供服务的主库
查看备库备库状态，确认备库可用，并且备库 Replication 的延迟小于阈值
等待备库应用 relay log(需要设置应用超时时间)，然后 stop slave;
记录备库 relay log 对应主库的位点
掉用中间件/DNS/VIP 的接口，把应用流量转移到备库
把新主库设置为 RW
老主库再次连接上后，kill 掉它上面的所有连接，保证应用流量都到备库，避免 DNS 等 catch 功能导致的切换不干净
老主库再次连接上后，把它设置为 RO
老主库恢复后，进行故障恢复：
- 修复数据：切花前备库往往存在一点延迟，根据记录的位点，从老主库 binlog 提取数据，来修复新主库
- 修复复制：重新启动复制后，往往会出现主键冲突，需要谨慎对比和修复数据，不能盲目 skip 复制的错误

在这里插入图片描述

功能简介
- 一主多备情况下 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》

来源：CSDN

作者：阔海星沉

链接：https://blog.csdn.net/ManWZD/article/details/104094866

标签