• 【MHA】MySQL高可用MHA介绍4-故障监控与切换具体流程


    目录

    一 故障监控与切换

    1 验证复制设置并识别当前主服务器

    2 监控主服务器

    3 检测主服务器故障

    4 再次验证从服务器配置

    5 关闭故障的主服务器(可选)

    6 恢复新主服务器

    6.1 保存来自 已崩溃主服务器的二进制日志事件(如果可能)

    6.2 确定新主服务器

    6.3 识别最新的从服务器(接收到最新中继日志的从服务器)

    6,4 恢复并提升新的主服务器

    7 上线新主服务器

    8 恢复其他从服务器

    9 通知(可选)

    二 MHA 在线(快速)主切换 流程

    1 验证复制设置并确定当前主服务器

    2 识别新的主服务器

    3 拒绝在当前主服务器上进行写操作

    4 等待所有从属服务器追赶复制进度

    5 在新主服务器上授予写入权限

    6 切换其他所有从属服务器上的复制


    一 故障监控与切换

    以下是MHA(masterha_manager)在主监控和故障转移中的基本流程。

    1 验证复制设置并识别当前主服务器

    • 通过连接配置文件中描述的所有主机来识别当前主服务器。您不必指定哪个主机是当前主服务器。MHA会自动检查复制设置并识别当前主服务器。>(注意:MHA不会自行构建复制环境(例如添加/删除从属服务器)。MHA在现有复制环境中监视主服务器。)
    • 如果在此阶段有任何从服务器已经宕机,出于安全原因终止脚本(如果有任何从服务器已经宕机,MHA当然无法恢复它)。
    • 如果在每个MySQL服务器(MHA节点)上没有安装任何必要的脚本,MHA会在此阶段中止,并且不会开始监视。

    2 监控主服务器

    • 等待当前主服务器死机。在这个阶段,MHA不监视从服务器。停止/重新启动/添加/删除从服务器对当前监视的MHA没有任何影响。当您添加/删除从服务器时,应更新配置文件,并最好重新启动MHA。

    3 检测主服务器故障

    • 如果MHA连续三次无法连接到主服务器,则进入此阶段。
    • 如果在配置文件中设置了secondary_check_script参数,则MHA调用该脚本以双重检查主服务器是否真的死机。

    4 再次验证从服务器配置

    • 重新读取配置文件,并连接到所有主机,验证当前主服务器是否已停止工作以及所有其他从服务器是否正在复制来自已停止工作的主服务器。如果检测到任何无效的复制配置(例如,某些从服务器正在复制来自不同的主服务器),MHA会在此处停止并显示错误。您可以通过在配置文件中设置ignore_fail参数来更改此行为。此步骤出于安全考虑。由于在启动masterha_manager后可能会花费很长时间(几周/几个月),复制配置可能会发生更改,因此通常建议进行双重检查。
    • 检查上次故障切换的状态 如果上次故障切换以错误结束,或者上次故障切换完成得太近,MHA会在此处停止并且不会开始故障切换。您可以通过在masterha_manager命令中设置ignore_last_failover和wait_on_failover_error参数来更改此行为。

    5 关闭故障的主服务器(可选)

    • 如果您在配置文件中定义了master_ip_failover_script和/或shutdown_script,MHA会调用这些脚本。
      • 使当前主服务器的IP地址失效
    • 关闭宕机的主服务器,以避免脑裂。

    6 恢复新主服务器

    • 6.1 保存来自 已崩溃主服务器的二进制日志事件(如果可能)

      • 如果已崩溃的主服务器可以通过SSH访问,从最新的从服务器的end_log_pos(Read_Master_Log_Pos)复制二进制日志。
    • 6.2 确定新主服务器

      • 基于配置文件设置和当前的MySQL设置
      • 如果您有一些主机作为候选主服务器,请在配置文件中设置candidate_master=1。
      • 如果您有一些永远不应该成为主服务器的主机,请在配置文件中设置no_master=1。
    • 6.3 识别最新的从服务器(接收到最新中继日志的从服务器)

    • 6,4 恢复并提升新的主服务器

      • 生成差异二进制/中继日志事件到主服务器
      • 将日志事件应用到新的主服务器上
      • 如果此处发生任何错误(例如重复键错误),MHA会中止,并且包括恢复其余从服务器在内的下面的恢复步骤不会发生。

    7 上线新主服务器

    • 如果您在配置文件中定义了master_ip_failover_script,MHA会调用该脚本。
      • 您可以执行各种操作,例如激活当前主服务器的IP地址,创建特权用户等。

    8 恢复其他从服务器

    • 恢复其他从服务器
      • 并行生成差异二进制/中继日志事件并将其应用到从服务器上,
      • 并从新主服务器开始复制。
      • 即使在此阶段发生恢复错误(例如从服务器 3 上的重复键错误),MHA也不会中止。失败的从服务器将不会从新主服务器复制数据,但其他成功恢复的从服务器可以开始复制。

    9 通知(可选)

    如果您在配置文件中定义了report_script,MHA 将调用该脚本。您可以执行任何您喜欢的操作,例如:

    • 发送邮件
    • 禁用新主服务器上的定期备份作业
    • 更新内部管理工具状态等

    二 MHA 在线(快速)主切换 流程

    以下步骤可以通过 masterha_master_switch 命令完成(带有 --master_state=alive 参数)

    1 验证复制设置并确定当前主服务器

    • 通过连接配置文件中描述的所有主机来确定当前主服务器(注意:MHA本身不会构建复制环境(例如添加/删除从属),而是监视现有复制环境中的主服务器)
    • 在当前主服务器上执行FLUSH TABLES操作(可选)。这是为了最小化稍后执行的FLUSH TABLES WITH READ LOCK操作的成本(时间)
    • 检查MHA主服务器监视和故障转移是否均未运行
    • 检查是否满足以下条件:
      • 所有从属服务器上的IO线程正在运行
      • 所有从属服务器上的SQL线程正在运行
      • 所有从属服务器上的Seconds_Behind_Master值都小于2秒(可以通过--running_updates_limit=(seconds)参数进行更改)
      • 在主服务器上,show processlist输出中没有任何更新查询花费超过2秒


    2 识别新的主服务器

    • 新主机可以通过"--new_master_host"参数设置。否则,新的主服务器将从配置文件中自动确定。
    • 原主服务器和新主服务器必须具有相同的二进制日志过滤规则(binlog-do-db和binlog-ignore-db)。

    3 拒绝在当前主服务器上进行写操作

    • 如果您在配置文件中定义了master_ip_online_change_script参数,MHA会调用该脚本。
      • 您可以在这里优雅地阻止写入(例如删除写入用户、执行SET GLOBAL read_only=1等)
    • 在当前主服务器上执行FLUSH TABLES WITH READ LOCK操作来阻止所有写入(可以通过--skip_lock_all_tables参数跳过)

    4 等待所有从属服务器追赶复制进度


    在此处使用MASTER_LOG_POS()函数

    5 在新主服务器上授予写入权限

    • 执行SHOW MASTER STATUS来确定新主服务器的当前二进制日志文件和位置
    • 如果您在配置文件中定义了master_ip_online_change_script参数,MHA会调用该脚本。您可以创建一个写入用户,执行SET GLOBAL read_only=0等操作。

    6 切换其他所有从属服务器上的复制

    • 并行执行CHANGE MASTER、START SLAVE

  • 相关阅读:
    Oracle数据中如何在 where in() 条件传参
    【历年NeurIPS论文下载】一文了解NeurIPS国际顶会(含NeurIPS2022)
    “一种三元前驱体废水螯合树脂回收钴的装置”实用新型专利
    计算机毕业设计ssm企业员工信息管理系统677du系统+程序+源码+lw+远程部署
    Primavera Unifier 21.12.4~21.12.7.0疑似漏洞
    面对以太坊合并,投资者有哪些参与策略?
    简单了解GaussDB
    yarn create vite my-vue-app --template /vue关于yarn创建vite所遇到的坑,创建vite错误
    element-plus 踩的坑
    【SpringSecurity】三更草堂项目案例分析1 - 环境配置与预备
  • 原文地址:https://blog.csdn.net/weixin_48154829/article/details/138190300