Parameters
hostname 目标Mysql服务器的主机名或者IP地址,这个参数是强制的,并且必须配置在[server_xxx]段落. ip 目标Mysql服务器的IP地址,默认是通过$hostname变量获取.MHA manager和MHA Node 内部使用这个IP地址链接到Mysql和SSH.通常你不需要配置这个参数,因为它可以通过$hostname解析获得. port mysql服务器使用的端口号,默认是3306,MHA链接到mysql通过IP地址和端口. ssh_host 从0.53版本开始支持此参数,此参数的主要目的在于你mysql复制使用的IP地址由于安全策略,不能直接连接,所以需要通过其他IP和端口连接到mysql server或者ssh,默认这个参数和hostname的值相同. ssh_ip 从0.53版本开始支持此参数,连接到目标mysql server的ssh ip地址,默认从$ssh_host获取. ssh_port 从0.53版本开始支持此参数,连接到目标mysql server的ssh端口,默认是22. ssh_connection_timeout 从0.54开始支持此参数,默认是5秒,添加此参数的原因是以前我们在程序里面写死了. ssh_options 从0.53开始支持此参数,可以添加SSH命令行的参数. candidate_master 你的slave的硬件配置或者用途可能不太一样,你想要提升更加可靠的slave作为新的master. 如果设置candidate_master的值为1,那么这个server会优先成为master,只要它满足成为master的条件(binlog开启的,没有严重的复制延时等).所以意味着配置了candiate_master=1的服务器并不是肯定可以成为new master,但是这个参数能够帮助提高优先级. 如果你在多个服务器上设置了candidate_master=1,那么在配置文件中[server_xxx]的配置顺序,会成为第二排序规则,排在上面的越优先. no_master no_master=1是默认值,意思是这个server从来不会成为新的master,这个参数用来标记某些从来不用成为new master的服务器。 ignore_fail 默认是0,当某个slave的ssh或者mysql当掉或者复制失败的时候,MHA manager不启动failover。但是有些环境下,你想要在某个特定的slave失败的时候继续执行failover,把么就设置这个ignore_fail=1,即时这个slave失败的时候,failover依然继续执行. skip_init_ssh_check 启动的时候跳过ssh连接测试. skip_reset_slave 从0.56版本开始支持此参数,在master执行failover以后跳过执行reset slave all(译者感觉应该是方便MM复制的后期恢复). user mysql管理员命令,建议赋予all privileges权限. password 上面mysql user的密码. repl_user mysql复制使用的用户名,需要执行change master to命令和show slave status命令等.一般赋予replication slave,replication client权限。 repl_password 上面用户对应的密码.默认情况下,使用的是当前复制的密码。 disable_log_bin 当这个参数设置以后,当应用差异日志到slave的时候,slave不会生成binlog. Internally MHA passes --disable-log-bin to mysqlbinlog command. master_pid_file 设置master的pid文件位置,当你的服务器上运行了多个mysql的时候使用. ssh_user MHA manager和MHA node通过这个用户连接到mysql server的OS上,在对应的OS上执行相关命令和拷贝差异日志等等. 这个用户必须有读取mysql binary/relay 相关日志文件的权限,还有日志目录的写入权限.(remote_workdir目录) 这个用户必须可以直接连接到服务器上,不用任何交互的操作.通过使用ssh public key作为认证方式.默认使用的用户是manager当前的用户. remote_workdir 每个MHA node上,MHA工作使用的目录的绝对路径.如果目录不存在,MHA会自动创建,如果权限不够,那么MHA node会意外终止,注意MHA manager和MHA node都不会检查这个目录的磁盘可用空间,你需要自己保证有足够的可用空间.默认的remote_workdir是'/var/tmp'. master_binlog_dir master mysql保存binlog的目录的绝对路径.如果参数的主要目的是在master mysql宕机以后,为了通过ssh拷贝需要的binlog event.这个参数是需要的,因为当mysql宕机以后,没法自动获取binary log的目录。 默认情况下,master_binlog_dir的值是"/var/lib/mysql/,/var/log/mysql/",/var/lib/mysql/是大部分mysql发布版本的默认mysql输出目录,你可以设置多个目录,使用逗号分隔.比如(/data1,/data2,/data3) log_level MHA manager 的日志级别,默认是info级别,在大多数环境下没有问题.可用的级别有.debug/info/warning/error. manager_workdir MHA manager使用的工作目录,如果没有设置,默认使用/var/tmp. client_bindir 如果mysql命令行工具没有安装在默认目录,可以使用这个选项配置. client_libdir 如果mysql lib没有安装在默认目录,可以使用这个选项配置. manager_log MHA manager日志文件的绝对目录和文件名,如果没有设置,那么将直接打印到标准输出和标准错误输出.当执行交互式的failover时,MHA manager将会忽略manager_log设置,直接答应到标准输出和标准错误输出. check_repl_delay 默认情况下如果一个slave比master延时了100M的relay logs.MHA不会选择这个slave作为新的master.因为他需要更多的时间来recovery.设置check_repl_delay=0,MHA在选择new master时将会忽略复制的延时.这个参数通常和candidate_master=1同时使用. check_repl_filter 默认情况下如果master和slave有不同的binary log/replication 过滤规则的话,MHA打印错误,不进行start monitoring或者failover.这个么做的目的是为了避免recover的时候出现意外的错误,例如"Table not exists",如果你100%确定你不同的过滤规则不会导致recover时候报错,那么你可以设置check_repl_fiter=0,这样的话,MHA在应用差异日志的时候将不会在检查过滤规则.使用这个参数的时候需要非常小心. latest_priority 默认情况下,接收到了最新的binlog的slave优先被选为new master,如果你想要控制优先级的顺序,比如(host2>host3>host4),那么设置latest_priority=0会有所帮助. multi_tier_slave MHA manager从0.5.2开始支持多主复制.默认情况下,它不支持三层以上的复制架构.例如,host2是host1的slave,host3是host2的slave,默认不允许把这个三个主机写到同一个配置文件中,因为这是一个三层的复制架构,并且MHA会因此报错,并停止工作.如果设置了multi_tier_slave,MHA manager不会因为多层架构而终止,它会忽略三层及以上的主机,例如master(host1)挂掉以后,host2会被选为新的master,host3将继续从host2复制. 这个参数从MHA manager0.52版本开始支持. ping_interval 这个参数声明MHA manager pings(通过执行sql来ping) master的间隔.当连续三次ping失败,MHA manager认为这个Mysql master宕机,从宕机到检测到宕机,最大的消耗时间是这个参数的四倍,这个参数默认值是3(3秒). 如果MHA manager因为权限问题多次连接失败,这不认为master dead. ping_type 从MHA manager 0.53开始支持这个参数, MHA建立一个长连接到master,然后通过执行"SELECT 1" (ping_type=SELECT)来判断master是否可用.但是在一些环境下,最好使用短连接的方式,因为这样的方式更严格,也能检测TCP连接级别的失败.设置ping_type=CONNECT可以实现.从0.56版本开始,支持ping_type=INSERT. secondary_check_script 通常情况,强力推荐使用两个或者多个路由检测Mysql master.默认MHA通过一个路由检测:从manager到master.这是不推荐的.MHA manager可以通过secondary_check_script参数调用一个内部脚本来实现两个或者多个路由的检测.下面是一个配置实例. secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2 MHA manager包含masterha_secondary_check 脚本.内置的masterha_secondary_check脚本可以满足大多是环境,当然你也可以调用你自定义的脚本. 在上面的实例中,MHA manager通过这两个路由检测master主机. 通常来讲,remote_host1和remote_host2必须和 MHA manager及Mysql server不在同一个网段,这样才更有意义. MHA调用secondary_check_script参数对应的脚本会自动传递以下参数(所以你不需要在配置文件中设置),masterha_secondary_check适用于大多数环境,如果你需要其他的功能可以自己写一个网络检查的脚本.
注意:masterha_secondary_check脚本依赖于IO::Socket::INET perl包,在perl v5.6.0中默认包含,masterha_secondary_check脚本会通过ssh连接到所有的remote servers.所以SSH public key 认证需要设置.另外masterha_secondary_check脚本尝试使用TCP连接从remote server到mysql master.这意味着服务器设置的max_connections参数对此连接无效,并且如果TCP连接成功,Aborted_connects状态将会加1. master_ip_failover_script 常见的HA环境下,大多是情况会给master分配一个虚拟IP,如果master宕机,HA软件像一个Pacemaker将虚拟IP转移到备用的master上. 另外一种常见的方法就是创建一个全局目录数据库,包含所有应用和writer/reader ip地址.例如{app_master1,192.168.0.1},{app_master2,192.168.0.2}...,代替使用虚拟IP,这种情况,你需要在master宕机的时候更新目录数据库. 两种方法都有好的或者不好的地方,MHA不强制要求使用哪一种,但是提供了master_ip_failover_script参数来完成此目的.换句话说,你需要写一个脚本来调整应用服务连接到新的master,然后定义master_ip_failover_script的参数,下面是一个实例: master_ip_failover_script= /usr/local/sample/bin/master_ip_failover 你可以从(MHA Manager package)/samples/scripts/master_ip_failover找到一个简单的脚本.这个脚本在manager的tarball和GitHUb branch中才包含. MHA manager会调用master_ip_failover_script三次,第一次,在开始master monitor之前调用(目的是检查脚本是否可用),第二次是在调用shutdown_script脚本前调用,第三次是在new master应用完所有的差异日志以后,MHA manager会传递给脚本如下参数.(你不用在配置文件中指明这些参数)
如果你使用共享虚拟IP的方法,你不需要在master shutdown阶段做任何事情,只要通过shutdown_script脚本关掉原来master的电源,在激活new master阶段,你需要分配虚拟IP给new master.如果你使用目录数据库的方法,你需要在宕机的master shutdown阶段删除或者更新失效master的记录.在new master生效阶段需要插入或者更新new master的记录.另外你可以做任何事情来保证应用程序可以成功的写入new master.比如SET GLOBAL read_only=0,创建有写入权限的数据库用户等等. MHA manager检查脚本的退出状态,如果脚本退出状态是0或者10,MHA manager继续操作,如果脚本退出状态不是0或者10,MHA manager将会意外终止,并不继续continue failover.默认这个参数是空的. master_ip_online_change_script 这是几个简单版本的master_ip_failover_script参数,但是master failover命令并不调用它.master online change命令会调用它.(masterha_master_switch --master_state=alive),传递以下参数:
MHA在当前的master write freezing阶段后执行FLUASH TABLES WITH READ LOCK, 在new mastergranting write阶段你可以执行一些类似master_ip_failover_script的操作.比如创建一个有写入权限的用户,执行SET GLOBAL read_only=0,更新目录数据库等.如果你的脚本退出返回状态不是1或者10,那么MHA manager将会意外终止,停止master switch. 这个参数默认为空,所以MHA manager不做任何调用. 你可以从(MHA Manager package)/samples/scripts/master_ip_online_change找到一个简单的脚本.这个脚本在manager的tarball和GitHUb branch中才包含. shutdown_script 你可能需要强制关闭master服务器,避免他再次提供服务,这对于避免脑裂很重要.下面是一个实例: shutdown_script= /usr/local/sample/bin/power_manager 你可以从(MHA Manager package)/samples/scripts/power_manager找到一个简单的脚本.这个脚本在manager的tarball和GitHUb branch中才包含. 在调用shutdown_script脚本之前,MHA manager内部会通过ssh尝试连接到mysql master,如果ssh可以连接(意思就是OS是存活的,但是Mysqld没有运行),MHAmanager就会传递下面的参数:
如果master主机的ssh不能连接,那么MHA会使用如下参数:
这个脚本的大概功能如下,如果--command=stopssh被调用,脚本会使用killall -9 杀掉目标服务器上所有的mysqld_safe服务.如果--pid_file被设置,脚本尝试kill指定的进程.如果脚本执行成功,那么脚本会退出返回状态10.如果退出状态为10,MHA manager后面会通过ssh连接到master,获取需要的binary log.如果脚本通过ssh连接到服务器失败,那么就会传递--command=stop参数,这个参数尝试关闭机器的电源,关闭电源依赖于H/W.HP(ILO),DELL(DRAC).如果power off成功,脚本会然会状态0,其他情况会返回状态1.当返回状态是0的时候MHA manager 开始failover.如果返回状态不是0或者10,那么MHA manager会意外终止.这个参数默认是空,所以MHA manager不会调用任何脚本. 另外,MHA manager在启动monitoring之前调用shutdown_script.这时候会传递下面的参数.目的是检测脚本是否可用,如果发现错误,你可以提前知道.
report_script 你希望当failover发生以后可以发送一个报告(例如email),report_script可以达到这个目的,MHA manager传递下面的参数.
默认这个参数是空的,所以MHA manager不调用任何脚本. 你可以从(MHA Manager package)/samples/scripts/send_report找到一个简单的脚本.这个脚本在manager的tarball和GitHUb branch中才包含. init_conf_load_script 这个脚本可以在你不想在配置文件中写明文密码的时候使用.你可以覆盖全局配置参数.实例脚本如下. #!/usr/bin/perl 这个参数默认为空,所以MHA manager默认不调用任何脚本. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
转自http://isadba.com/upload/mha_Parameters.htm |