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

转自

https://blog.csdn.net/ashic/article/details/75645479

以下是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