MHA 参数列表详解_MySQL
hostname
配置MySQL服务器的机器名或是IP地址，这个配置项是必须的，而且只能配置在[server_xxx]这个块下面。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| hostname | Yes | Local Only | - | hostname=mysql_server1, hostname=192.168.0.1, etc |
ip
MySQL服务器的ip地址。 默认从gethostname($hostname)中获得。 默认不用配置这个参数，MHA可以通过hostname自动获取，MHA通过IP地址连接MySQL服务器及SSH连接。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ip | No | Local Only | 通过gethostbyname($hostname)获得 | ip=192.168.1.3 |
port
MySQL运行的端口号。 默认是3306. MHA使用IP和端口号连接MySQL
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| port | No | Local/App/Glbal | 3306 | port=3306 |
ssh_host
(从MHA 0.53后开始支持） MHA要ssh上MySQL目标服务器使用hostname 或是ip地址。这个参数主要用于在使用多个VLAN的环境中。为了安全原因ssh默认不允许。默认这个参数和hostname相同。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ssh_host | No | Local Only | 和hostname相同 | ssh_host=mysql_server1, ssh_host=192.168.0.1, etc |
ssh_ip
(从MHA 0.53后开始支持） 和ssh_host作用相同。 默认是gethostname($ssh_host)获得。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ssh_ip | No | Local Only | gethostbyname($ssh_host) | ssh_ip=192.168.1.3 |
ssh_port
(从MHA 0.53后开始支持） SSH使用的端口号，默认是22.
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ssh_port | No | Local/App/Global | 22 | ssh_port=22 |
ssh_connection_timeout
(从MHA 0.54后支持)默认是5秒。在没添加这个参数之前ssh超时时间是写死的。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ssh_connection_timeout | No | Local/App/Global | 5 | ssh_connect_timeout=5 |
ssh_options
(从MHA 0.53后支持） 添加ssh命令行的支持参数，例如加上特别文件名的key的支持等。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ssh_options | No | Local/App/Global | “” 空的 | ssh_options=”-i /root/.ssh/id_dsa2″ |
candidate_master
你可能对于同一组slave中有着不同的规划，有的其望在Master故障时，提升为新的Master(如： Raid1+1的slave比Raid0的slave更适合做Master)
这个参数的作用是当设计candidate_master = 1时，这个服务器有较高的优先级提升为新的master(还要具备： 开启binlog, 复制没有延迟)。 所以当设置了candidate_master = 1的机器在master故障时必然成为新的master. 但这是很有用的设置优先级的一个参数。
如果设置了多台机器的caddidate_master = 1 , 优先策略依赖于块名字([server_xxx]). [server_1] 优衔权高于[server_2].
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| candidate_master | No | Local Only | 0 | candidate_mast＝1 |
no_master
当设置了no_master = 1的服务器，这个服务器永远不会提升为新的master. 这个参数据对于永远不期望成为master的机器很有用。 如： 你可能需要在使用raid0的机器上设置no_master = 1 或是你希望在远程的idc里运行一个slave. 注意： 当没有可以成为新master的机器是MHA就直接退出来了同时停止监控和master故障切换。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| no_master | No | Local Only | 0 | no_master=1 |
ignore_fail
在默认情况下，MHA manager不会在slave存在故障的情况下（已经不能通过SSH/MySQL进行连接，或是SQL Thread已经停止出错，其它原因）的情况下进行Master的故障切换（当不存在slave时MHA manager也会退出）。 但有些情况下你期望在slave存在问题的情况下，也进行故障切换。 所以当设置了ignore_fail = 1时，MHA会在所有的机器有问题的时间也会进行故障切换。 默认是0.
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ignore_fail | No | Local Only | 0 | ignore_fail=1 |
#skip_init_ssh_check#
在MHA manager启动时跳过ssh检查。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| skip_init_ssh_check | No | Local Only | 0 | skip_init_ssh_check=1 |
skip_reset_slave
(从MHA 0.56开始支持) Master故障切换后新的master上执行RESET SLAVE(ALL).
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| skip_reset_slave | No | Local/App/Global | 0 | skip_reset_slave=1 |
user
用于管理MySQL的用户名。这个最后需要root用户，因为它需要执行：stop slave; change master to , reset slave. 默认: root
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| user | No | Local/App/Global | root | user=mysql_root |
password
MySQL的管理用户的密码。 默认是空的
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| password | No | Local/App/Global | 空的 | password=rootpass |
repl_user
MySQL用于复制的用户，也是用于生成CHANGE MASTER TO 每个slave使用的用户。 这个用户必须有REPLICATION SLAVE权限在新的Master上。默认情况下 repl_user会在将来成为master的机器上运行show slave status获取到。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| repl_user | No | Local/App/Global | 从show slave status | repl_user=repl |
repl_password
MySQL中repl_user用户的密码。 默认是当前复制用的密码。 当你使用online_master_switch时，当使用–orig_master_is_new_slave(原来的Master成为新Master的一个slave)时，如果没有repl_password 开启同步就会失败了。因为当前master上用于复制的用户名和密码都是空的（MHA在原来的Master上执行change master to 时没有带复制的密码，虽然其它slave上设置了复制的密码）
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| repl_password | No | Local/App/Global | 当前复制用的密码 | repl_password=replpas |
disable_log_bin
当设置了这个参数，在slave应用差异的relay log时不会产生二进制日志。 内部实现通过mysqlbinlog的disable-log-bin实现。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| disable_log_bin | No | Local/App/Global | 0 | disable_log_bin=1 |
master_pid_file
指定MySQL的pid文件。 这个参数在一台服务器上运行多个MySQL服务进程时非常有用。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| master_pid_file | No | Local/App/Global | - | master_pid_file=/var/lib/mysql/master1.pid |
ssh_user
MHA Mananger, MHA node系统上的用户。 这个帐号需要在远程机器上有执行权限(Manager->MySQL),在slave成员之间复制差异的relay-log（MySQL->MySQL）
这个用户必须有读取MySQL的binary/relay日志和relay_log.info的权限，还需要对远程MySQL上remote_workdir目录的写权限。
这个用户还必须可以直接ssh到远程机顺上， 推荐使用ssh pbulic key . 一般使用的ssh_user也是运行manager那个那个用户。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ssh_user | No | Local/App/Global | 当前使用的系统用户 | ssh_user=root |
remote_workdir
MHA node上工作目录的全路径名。如果不存在，MHA node会自动创建，如果不允许创建，MHA Node自动异常退出。 需要注意MHA manager 或是MHA node上需要检查空间是否可用，所以需要注意检查这个。 一般默认, remote_workdir是的”/var/tmp”
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| remote_workdir | No | Local/App/Global | /var/tmp | remote_workdir=/var/log/masterha/app1 |
master_binlog_dir
master上用于存储binary日志的全路径。这个参数用于当master上mysql死掉后，通过ssh连到mysql服务器上，找到需要binary日志事件。这个参数可以帮助用于无法找到master进程死掉后binary日志存储位置。
一般: master_binlog_dir是”/var/lib/mysql/, /var/log/mysql”. “/var/lib/mysql/”是大多数系统发行版本的存放位置，”/var/log/mysql”是ubuntu发行版本的存放位置。 你也可以设置多个存放位置用逗号隔开。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| master_binlog_dir | No | Local/App/Gobal | /var/lib/mysql | master_binlog_dir=/data/mysql1,/data/mysql2 |
log_level
设置MHA manager记录LOG的级别。 默认是info级别而且大多数情况也是比较适合。 同样可以设置为: debug/info/warning/error.
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| log_level | No | App/Global | info | log_level=debug |
manager_workdir
用于指定mha manager产生相关状态文件全路径。 如果没设置 默认是/var/tmp
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| manager_workdir | No | App | /var/tmp | manager_workdir=/var/log/masterha |
manager_log
指定mha manager的绝对路径的文件名日志文件。 如果没设置MHA Manager将打印到STDOUT/STDERR。 当手工执行故障切换（交互模式切换），MHA Manager会忽略manager_log设置直接将日志输出到STDOUT/STDERR.
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| manager_log | No | App | STDERR | manager_log=/var/log/masterha/app1.log |
check_repl_delay
在默认情况下，当一个slave同步延迟超过100M relay log(需要应用超过100M relay log), MHA在做故障切换时不会选择这个slave做为新的master,因为恢复需要经过很长时间.当设置了check_repl_delay = 0, MHA将忽略被选择的slave上的同步延迟。 这个选项在设置了candidate_master = 1特声明的期望这台机器成为master的情况下特别有用。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| check_repl_delay | No | App/Golbal | 1 | check_repl_delay=0 |
check_repl_filter
在默认下情况，当master和slave设置了不同了binary log/replication 过滤规则时，MHA直接报错不会进行监控和故障切换。 这些将会导致出现一些异想不到的错误”Table not exists”。如果你100%确认不同的过滤规则不会导致恢复中的错误，设置check_repl_filter=0。 需要注意： 当使用了check_repl_filter = 0时，MHA不会检查过滤规则在应用差异的relay日志，所以有可能会出现”Table not exists”的错误。当你设置了这个参数请小心处理。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| check_repl_filter | No | App/Global | 1 | check_repl_filter=0 |
latest_priority
在默认情况下，和Master最接近的slave(一个slave从Master上获得了最一个binlog事件)是最有优先权成为新的master。 如果你想控制一下切换的策略（如: 先选择host2，如果不行，选host3；host3不行，选host4…） 那么设置latest_priority = 0 就可以了。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| latest_priority | No | App/Global | 1 | latest_priority=0 |
multi_tier_slave
从MHA 0.52开始, 多层复制可以支持了。在默认情况下，不支持三层或是更多层的复制配置。 如果： host2从host1上复制，host3从host2上复制。 在默认配置的情况下不支持写host{1,2,3}，因为这是一个三层的复制，MHA Manager会停止报错。 当设置了multi_tier_slave, MHA Manager就不会在三层复制报错停止。 但是会忽略第三层的机器。也就是如果host1挂了，host2将会成为新的master，host3还是从host2上进行复制。
这个参数在MHA Manager 0.52后的版开始支持。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| muli_tier_slave | No | App/Global | 0 | multi_tier_slave=1 |
ping_interval
这个参数设置MHA Manager多长时间去ping一下master(执行一些SQL语句）. 当失去和master三次偿试，MHA Manager会认为MySQL Master死掉了。也就是说，最大的故障切换时间是４次ping_interval的时间，默认是3秒。
如果MHA Manager在和MySQL创建连接时都收到多连接错误或是认证错误，这个就不做重试就会认为master已经挂掉。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ping_interval | No | App/Global | 3 | ping_interval=5 |
ping_type
(从MHA 0.53后开始支持) 在默认情况下， MHA manager和MySQL创建一个连接执行”select 1″（ping_type=select）用于检查master是否健康。 但有一些情况： 每次检测都连接/然后断开会比较好一点，这样对于tcp方面的错误感知更快一点。设置ping_type=CONNECT 就行了。从MHA 0.56后pint_type=INSERT也被添加。
如：
| 参数名 | 是否必须 | 作用域 | 默认值 | 例子及说明 |
| ping_type | No | App/Global | SELECT | ping_type=CONNECT |
secondary_check_script
一般来讲， 非常推荐使用更多网络上机器是不同路由策略上的机器来检查MySQL Master是否存活。 默认情况下，只有MHA Manager通过一个路由来检查Master是否存活。这个也是不推荐的。MHA可以通过外部secondary_check_script配置的脚本来做到从多个路由策略下进行检查。
secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2
secondary_check_script包含在MHA Manager发行包中。 MHA中内置的secondary_check_script在大多数情况下工作良好，但并不是任何地都可以使用这个脚本。
在上面的例子中， MHA Manager通过Manager->(A)->remote_host1->(B)->master_host 和Manager->(A)-remote_host2->(B)->master_host来检查MySQL master是否存活。如果在连接过程中通过A可以都成功，通过Ｂ是都失败，secondary_/check_/script返回０，而且认为master已经死掉，进行故障切换。如果通过A成功，但返回代码为: 2,则MHA manager有会认为是网络问题，则不会进行故障切换。如果Ａ成功，Ｂ也成功，masterha_secondary_check 退出返回:3 则MHA Manager就为认为MySQL Master为存活状态， 则不会进行故障切换。
一般来讲， remote_host1和remote_host2是和MHA Manager及MySQL Server位于不同的网段中。
MHA会调用secondary_check_script声明的脚本并自动带上一些参数。 masterha_secondary_check在很多场景都是适用的，但是你也可以自已实现这个程序带有更多的功能。