【MHA】MySQL高可用MHA介绍3-命令详解

masterha_manager：运行 MHA Manager 的命令

通用参数

监控特定参数

故障转移特定参数

masterha_master_switch

手动故障转移

非交互式故障转移

计划（在线）主切换

masterha_check_status

masterha_check_repl

masterha_stop

masterha_conf_host

通用参数

masterha_manager：运行 MHA Manager 的命令

可以通过执行 masterha_manager 命令来启动 MHA Manager。

masterha_manager --conf=/etc/conf/masterha/app1.cnf

masterha_manager 接受以下参数。

通用参数

--conf=(配置文件路径)：应用和本地范围的配置文件路径。此参数是必需的。
--global_conf=(全局配置文件路径)：全局范围的配置文件路径。默认为 /etc/masterha_default.cnf。
--manager_workdir, --workdir：与 manager_workdir 参数相同。
--manager_log, --log_output：与 manager_log 参数相同。

监控特定参数

--wait_on_monitor_error=(秒)：如果在监视过程中发生错误，masterha_manager 将等待 wait_on_monitor_error 秒然后退出。默认为 0 秒（不等待）。此功能主要用于在守护程序脚本中执行自动化主监视和故障转移。在重新启动监视之前等待一段时间以处理错误是合理的。
--ignore_fail_on_start：默认情况下，如果一个或多个从服务器宕机，那么主监视（而不是故障转移）过程将停止，而不管 ignore_fail 参数设置如何。通过设置 --ignore_fail_on_start，如果标记为 ignore_fail 的从服务器宕机，则主监视不会停止。

故障转移特定参数

--last_failover_minute=(分钟)：如果上一次故障转移发生得太近（默认为 8 小时），则 MHA Manager 不会执行故障转移，因为仅通过执行故障转移可能无法解决问题。此参数的目的是避免 ping-pong 故障转移问题。您可以通过更改此参数来更改时间标准。默认值为 480（8 小时）。

如果设置了 --ignore_last_failover，则忽略此步骤。
--ignore_last_failover：如果上一次故障转移失败，则 MHA 不会开始故障转移，因为问题可能再次发生。启动故障转移的正常步骤是手动删除（manager_workdir）/(app_name).failover.error 下创建的故障转移错误文件。

通过设置 --ignore_last_failover，MHA 会忽略上次故障转移的状态并继续进行故障转移。
--wait_on_failover_error=(秒)：如果在故障转移过程中发生错误，MHA Manager 将等待 wait_on_failover_error 秒然后退出。默认为 0 秒（不等待）。此功能主要用于在守护程序脚本中执行自动化主监视和故障转移。在重新启动监视之前等待一段时间以处理错误是合理的。
--remove_dead_master_conf：当设置此选项时，如果故障转移成功完成，MHA Manager 将自动从配置文件中删除故障的主服务器部分。例如，如果死亡的主服务器的主机名为 host1，它属于 server1 部分，那么 server1 的整个部分将从配置文件中删除。默认情况下，配置文件不会被修改。在 MHA 完成故障转移后，死亡主服务器的部分仍然存在。如果立即启动 masterha_manager（这包括任何守护程序程序的自动重新启动），masterha_manager 将以 "存在死掉的从服务器"（先前的死掉的主服务器）错误停止。您可能希望更改此行为，特别是如果要连续自动监视和故障转移 MySQL 主服务器的话。在这种情况下，--remove_dead_master_conf 参数很有帮助。

masterha_master_switch

masterha_manager 是一个同时监视并进行主故障转移的程序。另一方面，masterha_master_switch 程序不监视主服务器。masterha_master_switch 可用于主故障转移，也可用于在线主切换。

手动故障转移

有时您可能想要手动执行故障转移。可以使用 masterha_master_switch 命令来执行手动故障转移。以下是一个示例。

$ masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=host1

虽然 masterha_manager 命令会自动监视主服务器并执行故障转移，但 masterha_master_switch 旨在用于手动故障转移。masterha_master_switch 接受以下参数。

--master_state=dead

这是一个必需的参数。--master_state 接受 "dead" 或 "alive"。如果设置为 "alive"，masterha_master_switch 将开始在线主切换操作。在这种情况下，原始主服务器必须存活。

--dead_master_host=(主机名)

死掉的主服务器的主机名。这也是一个必需的参数。--dead_master_ip 和 --dead_master_port 也可以选择设置。如果未设置这些参数，则 --dead_master_ip 将是 gethostbyname(dead_master_host) 的结果，--dead_master_port 将是 3306。

--new_master_host=(主机名)

新主服务器的主机名。此参数是可选的。当您希望显式设置新主机时（这意味着您不希望让 MHA 自动确定新主机）时，此参数很有用。如果未设置 new_master_host，则 MHA 根据与自动故障转移相同的规则确定新主机（检查 candidate_master 参数等）。如果设置了 new_master_host，则 MHA 将确定主机为新主机。如果主机不能成为新主机（例如，未启用日志二进制），则 MHA 会中止。

--new_master_port=(端口号)

新主服务器上 mysql 实例的监听端口。此参数是可选的。与 --new_master_host 选项一起使用，如果目标主服务器端口不是默认的 3306。

--interactive=(0|1)

如果要执行下面描述的非交互式故障转移，请设置 --interactive=0。默认值为 1（交互式）。

--ssh_reachable=(0|1|2)

指定主服务器是否可通过 SSH 访问。如果不可访问，请设置为 0；如果可访问，请设置为 1；如果未知，请设置为 2。默认值为 2。如果设置为 2，则命令内部会检查主服务器是否可通过 SSH 访问，并将内部 SSH 状态更新为 0 或 1。如果主服务器可通过 SSH 访问，并且设置了 master_ip_failover_script 或 shutdown_script，则命令会传递 "--command=stopssh"。如果未设置，则 masterha_master_switch 传递 "--command=stop"。此外，如果崩溃的主服务器可通过 SSH 访问，则故障转移脚本会尝试从崩溃的主服务器复制未发送的二进制日志。

--skip_change_master

在故障转移时设置此参数，MHA 在应用差异中终止后退出，并跳过 CHANGE MASTER 和 START SLAVE。因此，从服务器不会指向新主服务器。如果您想要手动双重检查从服务器恢复是否成功，这可能有所帮助。

--skip_disable_read_only

通过传递此参数，MHA 跳过在新主服务器上执行 SET GLOBAL read_only=0。当您想要手动禁用。

--last_failover_minute=(分钟)

与 masterha_manager 相同。

--ignore_last_failover

与 masterha_manager 相同。

--wait_on_failover_error=(秒)

与 masterha_manager 相同。

请注意，此参数仅适用于自动/非交互式故障转移，不适用于交互式故障转移。也就是说，如果未设置 --interactive=0，则 wait_on_failover_error 简单地被忽略，并且在出现错误时不会休眠。

--remove_dead_master_conf

与 masterha_manager 相同。

masterha_master_switch 默认运行交互式故障转移过程。您需要从键盘键入 "yes"，如下所示。

... Starting master switch from host1(192.168.0.1:3306) to host2(192.168.0.2:3306)? (yes/NO): yes ...

如果未设置 --new_master_host，则新主服务器由与自动故障转移相同的规则确定。当您运行手动故障转移时，您可以选择显式设置新主服务器。以下是一个示例。

Starting master switch from host1(192.168.0.1:3306) to host2(192.168.0.2:3306)? (yes/NO): no Continue? (yes/NO): yes Enter new master host name: host5 Master switch to gd1305(10.17.1.238:3306). OK? (yes/NO): yes ...

在这种情况下，host5 将成为新主服务器，只要启用了二进制日志记录并且主版本不高于其他从服务器。以下命令与上述命令具有相同的效果。

$ masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=host1 --new_master_host=host5

--wait_until_gtid_in_sync(0|1)

此选项自 0.56 版本开始提供。

在执行基于 GTID 的故障转移时，如果设置 wait_until_gtid_in_sync=1，则 MHA 将等待从服务器追赶新主服务器的 GTID。如果设置为 0，则 MHA 不会等待从服务器追赶。默认为 1。

--skip_change_master

此选项自 0.56 版本开始提供。

如果设置了此选项，则 MHA 跳过执行 CHANGE MASTER。

--skip_disable_read_only

此选项自 0.56 版本开始提供。

如果设置了此选项，则 MHA 跳过在新主服务器上执行 SET GLOBAL read_only=0。

--ignore_binlog_server_error

此选项自 0.56 版本开始提供。

如果设置了此选项，则 MHA 在故障转移期间忽略来自 binlog 服务器的任何错误。

非交互式故障转移

如果在 masterha_master_switch 中设置 "--interactive=0"，它会自动执行故障转移（非交互式）。

$ masterha_master_switch --master_state=dead --conf=/etc/conf/masterha/app1.cnf --dead_master_host=host1 --new_master_host=host2 --interactive=0

这实际上与 masterha_manager 内部运行的相同。如果已经验证了主服务器已死，但希望尽快执行故障转移，则非交互式故障转移很有用。如果您使用其他现有的主监视软件，并希望从该软件中调用非交互式故障转移命令，则非交互式故障转移也很有用。典型的例子是从 Pacemaker 等群集软件调用 masterha_master_switch。

计划（在线）主切换

有时您可能希望进行计划的主切换，即使当前主服务器正在运行。典型的例子是更换部分损坏的硬件或升级主服务器。您无法更换 RAID 控制器或增加内存而不停止服务器。在这种情况下，您需要分配计划维护时间，并且必须将主服务器迁移到不同的服务器。

masterha_master_switch 命令可用于运行计划的主切换。

$ masterha_master_switch --master_state=alive --conf=/etc/app1.cnf --new_master_host=host2

必须设置 --master_state=alive。计划主切换的程序流与主故障转移略有不同。例如，您无需关闭主服务器，但需要确保不会在主服务器上执行写查询。通过设置 master_ip_online_change_script，您可以控制如何在执行 FLUSH TABLES WITH READ LOCK 之前禁止当前主服务器上的写流量（例如，删除可写用户，设置 read_only=1 等），以及如何在新主服务器上允许写流量。

仅当满足以下所有条件时，在线主切换才会启动。

所有从服务器上的 IO 线程正在运行
所有从服务器上的 SQL 线程正在运行
所有从服务器上的 Seconds_Behind_Master 小于或等于 --running_updates_limit 秒
在主服务器上，没有更新查询花费的时间超过 --running_updates_limit 秒在 show processlist 输出中这些限制的原因是出于安全考虑，以及尽快切换到新主服务器。在切换主服务器时，masterha_master_switch 在切换主服务器时采用以下参数。

--new_master_host=(主机名)

新主服务器的主机名。

--orig_master_is_new_slave

主切换完成后，先前的主服务器将作为新主服务器的从服务器运行。默认情况下，此选项已禁用（先前的主服务器不会加入新的复制环境）。如果使用此选项，则需要在配置文件中设置 repl_password 参数，因为当前主服务器不知道新主服务器的复制密码。

--running_updates_limit=(秒)

如果当前主服务器执行的写查询花费的时间超过此参数，或任何 MySQL 从服务器落后于主服务器超过此参数，则主切换将中止。默认为 1（1 秒）。

--remove_orig_master_conf

当设置此选项时，如果主切换成功完成，MHA Manager 将自动从配置文件中删除死掉的主服务器的部分。默认情况下，配置文件不会被修改。

--skip_lock_all_tables

在进行主切换时，MHA 在 orig 主服务器上运行 FLUSH TABLES WITH READ LOCK，以确保更新确实已停止。但是 FLUSH TABLES WITH READ LOCK 的成本很高，如果您可以确保 orig 主服务器上没有更新（通过在 master_ip_online_change_script 中杀死所有客户端等），则可以通过使用此参数避免锁定表。

`masterha_check_status`

检查管理器状态使用 masterha_check_status 命令，以确定管理器是否正确监控 MySQL 主服务器。以下是一个示例。

$ masterha_check_status --conf=/path/to/app1.cnf
app1 (pid:8368) is running(0:PING_OK), master:host1
$ echo $?
0

当 MHA 管理器成功监控 MySQL 主服务器时，应像上面一样返回状态码（退出码）0。

以下是所有状态码和描述：

Status Code (Exit code)	Status String	Description
0	PING_OK	Master is running and MHA Manager is monitoring. Master state is alive.
1	---	Unexpected error happened. For example, config file does not exist. If this error happens, check arguments are valid or not.
2	NOT_RUNNING	MHA Manager is not running. Master state is unknown.
3	PARTIALLY_RUNNING	MHA Manager main process is not running, but child processes are running. This should not happen and should be investigated. Master state is unknown.
10	INITIALIZING_MONITOR	MHA Manager is just after startup and initializing. Wait for a while and see how the status changes. Master state is unknown.
20	PING_FAILING	MHA Manager detects ping to master is failing. Master state is maybe down.
21	PING_FAILED	MHA Manager detects either a) ping to master failed three times, b) preparing for starting master failover. Master state is maybe down.
30	RETRYING_MONITOR	MHA Manager internal health check program detected that master was not reachable from manager, but after double check MHA Manager verified the master is alive, and currently waiting for retry. Master state is very likely alive.
31	CONFIG_ERROR	There are some configuration problems and MHA Manager can't monitor the target master. Check a logfile for detail. Master state is unknown.
32	TIMESTAMP_OLD	MHA Manager detects that ping to master is ok but status file is not updated for a long time. Check whether MHA Manager itself hangs or not. Master state is unknown.
50	FAILOVER_RUNNING	MHA Manager confirms that master is down and running failover. Master state is dead.
51	FAILOVER_ERROR	MHA Manager confirms that master is down and running failover, but failed during failover. Master state is dead.

masterha_check_repl

通过 masterha_check_repl 检查 MySQL 复制健康状态以下是一个示例。

manager_host$ masterha_check_repl --conf=/etc/app1.cnf
...
MySQL Replication Health is OK.

masterha_check_repl 连接配置文件中定义的所有 MySQL 服务器，然后检查复制是否正常工作。该命令与 masterha_manager 不冲突。您可以在 masterha_manager 工作时（监视当前主服务器）运行此命令。如果您想定期检查复制设置，这个命令非常有用。在 masterha_manager 监视 MySQL 主服务器后，它只检查主服务器的可用性。通过定期运行 masterha_check_repl 并在出现错误时发送警报（例如 SQL 线程停止），您将能够快速解决复制问题。

当检测到任何复制失败时，masterha_check_repl 返回错误。复制失败包括以下内容：

所有 MHA 无法监视/故障转移的复制失败（复制过滤规则不同，SQL 线程以错误停止，如果您有两个或更多主服务器等）
IO 线程已停止
SQL 线程正常停止
复制延迟超过 N 秒

除了 --conf 之外，masterha_check_repl 还接受以下参数。

--seconds_behind_master=(seconds)

masterha_check_repl 检查所有从服务器的 Seconds_Behind_Master，并且如果超过阈值则返回错误。默认值为 30（秒）。

--skip_check_ssh

默认情况下，masterha_check_repl 执行与 masterha_check_ssh 相同的检查脚本。如果您确定不需要 SSH 连接检查，请使用此选项。

masterha_stop

停止管理器 masterha_stop 您可以通过 masterha_stop 命令停止 MHA 管理器。

manager_host$ masterha_stop --conf=/etc/app1.cnf
Stopped app1 successfully.

masterha_stop 不会停止 MySQL 服务器，只会停止对MySQL的监控。

如果无法停止（例如挂起），请添加 "--abort" 参数。然后将 SIGKILL(-9) 发送到该进程及其所有子进程。

当当前管理器状态为 FAILOVER_RUNNING（正在运行故障转移操作）时，脚本会在不停止管理器进程的情况下退出（--abort 也会被忽略）。这是出于安全考虑。在中途停止故障转移将导致不一致的复制设置，应尽量避免。

如果您手动终止管理器进程（从 shell 发送 kill），进程会停止，但请确保它不处于故障转移阶段。

masterha_conf_host

masterha_conf_host 是一个辅助脚本，用于从配置文件中自动添加/删除主机条目。在某些情况下，您可能希望自动从配置文件中添加/删除主机条目。例如，当您设置新的从服务器时，您可以像下面这样简单地添加新的主机条目。

# masterha_conf_host --command=add --conf=/etc/conf/masterha/app1.cnf --hostname=db101

然后，以下行将被添加到配置文件中。

[server_db101] hostname=db101

请注意，新配置文件中的所有注释、空白等都将被修剪。

您可以通过传递以分号(;)分隔的 --param 参数，在配置文件中添加多个参数。

# masterha_conf_host --command=add --conf=/etc/conf/masterha/app1.cnf --hostname=db101 --block=server100 --params="no_master=1;ignore_fail=1"

以下行将被添加到配置文件中。

[server100] hostname=db101 no_master=1 ignore_fail=1

您还可以删除指定的块。以下命令将删除整个块 server100。

# masterha_conf_host --command=delete --conf=/etc/conf/masterha/app1.cnf --block=server100

masterha_conf_host接受以下参数。

通用参数

--command=(add|delete)

要添加(--command=add)或删除(--command=delete)一个块到/从配置文件中。此参数是必需的。

--conf=(配置文件路径)

应用程序和本地范围配置文件。此参数是必需的。

--hostname=(主机名)

将要添加的块的目标主机名。当设置 --command=add 时，此参数是必需的。

--block=(块名称)

配置文件的块名称。在添加块时，块名称不能与配置文件中现有的块名称相同。在删除块时，块名称必须存在于配置文件中。如果未设置 --block，则块名称将为 "server_$hostname"。_

--params=(key1=value1;key2=value2;...)

参数列表，以分号分隔。