masterha_manager: 启动 mha master manager 控制的脚本开关
eg: masterha_manager --conf=/home/server/mha/cnf/mysql_node_account_3306.cnf常用参数如下:
--conf=(config file path) 应用或本地范围的配置参数文件，必须指定
--global-conf=(global config file path): 全局范围的配置参数，默认 /etc/masterha_default.cnf
--manager_workdir,--workdir: manager 工作的目录，存放 mha manager 产生关联的状态文件
--masterha_log,--log_output:存放 mha manager 产生的日志文件，如果没有设置，将会使用标准输出，当执行failover，mha manager 忽略 此配置，使用标准的输出
monitor 特殊参数:
--wait_on_monitor_error=(seconds):在监控的过程，当发出错误了，masterha_manager 等待 wait_no_monitor_error 的时间后，退出。如果设置为了0，直接退出。这个好处，是当后台运行master monitor 和 failover scripts的时候，masterha_manager 可以在 wait_no_monitor_error 时间到达之前重启监控
--ignore_fail_on_start: 默认的情况下，当一个或多个从库宕机后，主库监控(不是 failover)进程会停掉，除非ignore_fail_on_start 参数开启。NOTE： 我们可以监控这个参数，如果从库宕机后，masterha_manager 会停掉，我们做从库高可用，切读域名。
Failover指定参数：
--last_failover_minute=(minutes):
当最近的一个failover 切换发生在last_failover_minute(默认为8小时) 之内，MHA manager 将不会在切换。因为它会认为有些问题没有得到解决。如果设置了 --ignore_last_failover 参数，参数(--last_failover_minute) 将会失效
--ignore_last_failover:
如果最近failover 失败，MHA 将不会再次开始failover机制，因为这个问题可能再次发生。常规步骤:手动清理failover 错误文件，此文件一般在manager_workdir/app_name.failover.error文件，然后在启动failover机制。如果设置此参数，MHA 将会继续failover 不管上次的failover状态
--wait_on_failover_error=(seconds):
在failover的过程，当发出错误了，masterha_manager 等待 wait_no_failover_error 的时间后，退出。如果设置为了0，直接退出。这个好处，是当后台运行master monitor 和 failover scripts的时候，masterha_manager 可以在 wait_no_failover_error 时间到达之前重启监控
--remove_dead_master_conf:
如果设置此参数，当成功failover后，MHA manager将会自动删除配置文件中关于dead master的配置选项。
eg: For example, if the dead master's hostname is host1 and it belongs to the section of server1, the entire part of the server1 will be removed from the configuration file. By default, the configuration file is not modified at all. After MHA finishes failover, the section of the dead master still exists. If you start masterha_manager immediately (this includes automatic restart from any daemon program), masterha_manager stops with an error that "there is a dead slave" (previous dead master). You might want to change this behavior especially if you want to continuously monitor and failover MySQL master automatically. In such cases, --remove_dead_master_conf argument is helpful.
