MHA在监控和故障转移时都做了什么

MHA在监控和故障转移时都做了什么

以下是MHA(masterha_manager)在监控和故障切换上的基本流程

验证复制配置和识别当前主库

  • 通过连接配置文件中描述的所有主机来识别当前主库.你不必手动指明那个主句是主库,MHA会自动检查复制设置并识别当前主库.

    注意:MHA本身不能构建复制环境,MHA监控已存在的复制环境

  • If any slave is dead at this stage, terminating the script for safety reasons(If any slave is dead, MHA can not recover the dead slave, of course). 开启监控时任何slave发生故障都会导致监控退出,MHA并不能修复从库

  • 如果任何必要的脚本没有安装在所有Node,MHA abort而不会启动监控

监控主库

  • 监控阶段MHA会持续监控主库直到其发生故障,MHA并不会监控从库.停止/重启/添加/移除从库不会对当前的MHA监控产生任何影响.但是注意当你添加或移除从库后应当更新MHA配置文件并重启MHA

监测主库故障

  • 如果MHA连续三次连接主库失败,将会进入此阶段
  • 如果你在配置文件中指定了secondary_check_script脚本,MHA会调用次脚本二次验证master状态看看是不是真的挂了

以下步骤也由masterha_master_switch命令执行. 您可以使用与masterha_manager相同的参数.

再次验证从库配置

  • 再次读取配置文件,并连接所有主机并验证当前故障主机状态和所有此主库的从库.如果检测到任何无效的复制配置(即某些从站从不同的主站复制),那么MHA将在此处停止。 您可以通过在配置文件中设置ignore_fail参数来更改此行为。 这一步是出于安全原因。 由于masterha_manager可能运行了很长时间(周/月),因此复制配置可能会更改,因此通常建议进行双重检查。
  • 检查上一个故障转移状态如果最后一个故障转移以错误结束,或最近一次故障转移最近完成,则MHA将在此停止,并且不会启动故障转移。 您可以通过masterha_manager命令中的ignore_last_failover和wait_on_failover_error参数更改此行为。

Shutting down failed master server (optional)

  • 如果你在配置文件中定义了 master_ip_failover_script and/or shutdown_script ,MHA会调用这些脚本
    • 当前主库(死掉的主库)的vip会通过master_ip_failover_script漂移到新主库
  • 关闭故障主库的服务器,避免脑裂

Recovering a new master

  • 从崩溃的主机中保存二进制日志事件(如果可能)
    • 如果可以通过SSH访问崩溃的主库,可以从最新的slave的end_log_pos(Read_Master_Log_Pos)位置开始复制二进制日志.
  • 选举新主库
    • 基于配置文件中的设置和当前MySQL的设置
    • 如果你希望某些从库作为优先备选主库,可以在配置中指定candidate_master=1
    • 如果你希望某些从库永远不会成为新主库,可以在配置中指定no_master=1
  • 识别最新的从众(接收了最新relay log的从库)
  • 恢复并提升新主库
    • 生成差异日志传输到新主库
    • 应用这些差异日志到新主库
    • 如果再次阶段产生任何错误(如,duplicate key error),MHA aborts,之后的恢复步骤,包括恢复其余从库将不会发生

激活新主库

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

恢复其他从库

  • 恢复其余从库
    • 并行的为所有从库生成差异日志
    • 并行的为所有从库应用差异日志
    • change master到新主库,并start slave
    • 即使在此阶段发生恢复错误,MHA也不会终止.故障的从库将不会从新主库复制,而其他成功恢复的从库可以启动复制

通知(可选)

  • 如果你在配置文件中定义了report_script,MHA会调用此脚本,再次脚本中你可以做任何你想做的事,例如:
    • 发送邮件
    • 停止新主库得定时备份任务(因为我们一般希望备份在从库做,新主库应取消定时备份任务)
    • 更细内部管理工具状态,等等

MHA在在线切换是做了什么

以下步骤可以通过masterha_master_switch命令(使用–master_state = alive参数)完成。

验证复制设置并识别当前主库

  • 通过连接配置文件中描述的所有主机来识别当前主库
  • 在当前主库执行FLUSH TABLES(可选).这一操作用来最小化之后的FLUSH TABLES WITH READ LOCK时间
  • 检查MHA主库监控和failover是否正在运行
  • 检查是否符合以下条件
    • 所有从库上的IO线程正在运行
    • 所有从库上的SQL线程正在运行
    • 所有从库的Seconds_Behind_Master小于2秒(可以用过—running_updates_limit=N更改)
    • 在主库上,通过show processlist输出中没有执行超过2秒的update语句

识别新主库

  • 新主库可以通过”—new_master_host”参数指定.否则吗,将从配置文件中自动识别新的主库.
  • 源主库和新主库必须拥有一致的过滤规则(binlog-do-db and binlog-ignore-db)

拒绝当前主库的写入

  • 如果您在配置文件中定义了master_ip_online_change_script参数,MHA会调用该脚本。
    • 您可以优雅地阻止写入(即删除写入用户,执行SET GLOBAL read_only = 1等)
  • 在当前主机上执行FLUSH TABLE WITH READ LOCK来阻止所有写入(可以使用–skip_lock_all_tables参数跳过)

等待所有从库追上复制进度

  • 这里会使用MASTER_LOG_POS()函数

赋予新主库写入权限

  • 执行show master status来获取新主库得file和position
  • 如果你在配置文件中定义了master_ip_online_change_script,MHA会调用次脚本.你可以在脚本里执行创建用户,set GLOBAL read_only=0等操作

为其他所有从库切换新主库

  • 所有从库并发的执行change master,start slave

Powered by Hexo and Hexo-theme-hiker

Copyright © 2013 - 2018 Fan() All Rights Reserved.

访客数 : | 访问量 :

#