MySQL MHA管理维护总结

 博客文章除注明转载外，均为原创。转载请注明出处。
本文链接地址：http://blog.chinaunix.net/uid-31396856-id-5766372.html

 

第一部分：mha日常管理

1.查看ssh登陆是否成功

masterha_check_ssh  --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

2.查看复制是否建立好

masterha_check_repl  --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 

3.启动mha

nohup  masterha_manager  --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf   >/etc/masterha/mha_manager.log   < /dev/null 2>&1 & 

(1)当有slave节点宕掉的情况，manager是无法启动的，

如果在配置文件中设置ignore_fail=1 ，就可以加上--ignore_fail_on_start ，这时候即使有节点宕掉也能启动mha manager。如下：

nohup  masterha_manager  --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf     --ignore_fail_on_start >  /etc/masterha/mha_manager.log   <  /dev/null 2>&1 & 

 

(2)wait_on_monitor_error=(seconds)

    在监控的过程，当发出错误了，masterha_manager 等待 wait_no_monitor_error 的时间后，退出。如果设置为了0，直接退出。这个好处，是当后台运行master monitor 和 failover scripts的时候，masterha_manager 可以在 wait_no_monitor_error 时间到达之前重启监控。

4.检查启动的状态

masterha_check_status--global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 

5.停止mha

masterha_stop  --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 

6.failover切换

(1)在failover后,下次重启mha manager

每次failover 切换后会在管理目录生成文件app1.failover.complete ，下次在切换的时候会发现有这个文件导致切换不成功，需要手动清理掉。

rm -rf /masterha/app1/app1.failover.complete

但是，也可以加上参数--ignore_last_failover 来启动mha manager

 

（2）参数last_failover_minute=(minutes)

    当最近的一个failover 切换发生在last_failover_minute(默认为8小时) 之内，MHA manager 将不会在切换。因为它会认为有些问题没有得到解决。如果设置了 --ignore_last_failover 参数，参数(--last_failover_minute) 将会失效

 

(3)参数ignore_last_failover

    如果最近failover 失败，MHA 将不会再次开始failover机制，因为这个问题可能再次发生。常规步骤:手动清理failover 错误文件，此文件一般在manager_workdir/app_name.failover.error文件，然后在启动failover机制。如果设置此参数，MHA 将会继续failover 不管上次的failover状态

 

（4）参数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的配置选项。

 

7.手工failover注意事项

手工failover 场景，master死掉，但是masterha_manager没有开启，这时候可以通过手工failover：

masterha_master_switch  --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf    --dead_master_host=old_ip  --master_state=dead --new_master_host=new_ip --ignore_last_failover

 

8.masterha_manager是一种监视和故障转移的程序。但是另一方面,masterha_master_switch 程序不监控主库。  masterha_master_switch可以用于主库故障转移,也可用于在线总开关。

 

9.手动在线切换方法：

(1)

masterha_master_switch  --global_conf=/etc/masterha/masterha_default.conf  --conf=/etc/masterha/app1.conf    --master_state=alive  --new_master_host=192.168.199.78 --orig_master_is_new_slave

或者

（2）

masterha_master_switch  --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf    --master_state=alive  --new_master_host=192.168.199.78 --orig_master_is_new_slave --running_updates_limit=10000

 

--orig_master_is_new_slave切换时加上此参数是将原master变为slave节点，如果不加此参数，原来的master将不启动 

--running_updates_limit=10000 切换时候选master如果有延迟的话，mha切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover时relay日志的大小决定

注意：

(1)手动在线切换mha，切换时需要将在运行的mha停掉后才能切换。

(2)在备库先执行DDL，一般先stop slave，一般不记录mysql日志，可以通过set SQL_LOG_BIN = 0实现。然后进行一次主备切换操作，再在原来的主库上执行DDL。这种方法适用于增减索引，如果是增加字段就需要额外注意。

Online master switch开始只有当所有下列条件得到满足。

1.所有从库的 IO线程正常运行。

2. 所有从库的SQL线程正常运行。

3.  所有从库上slave参数Seconds_Behind_Master小于或者等于--running_updates_limit的时间

4.  主库上，没有更新查询操作多于running_updates_limit seconds  在show processlist输出结果上。

 

第二部分：配置文件部分参数说明

 

1、candidate_master

    如果设置candidate_master的值为1,那么这个server会优先成为master,但是前提是它需要满足成为master的条件(binlog开启的,没有严重的复制延时等)

2 、no_master

    当设置了no_master=1的服务器，这个服务器永远不会提升为新的master. 这个参数据对于永远不期望成为master的机器很有用。

　比如：在一些特定场景下，使用raid0的机器上设置no_master = 1；或者，是希望在远程的idc里运行一个slave.

注意：当没有可以成为新master的机器是MHA就直接退出来了同时停止监控和master故障切换。

3、disable_log_bin

当设置了这个参数，在slave应用差异的relay log时不会产生二进制日志。　内部实现通过mysqlbinlog的disable-log-bin实现。

 

4、check_repl_delay

     在默认情况下，当一个slave同步延迟超过100M relay log(需要应用超过100M relay log), MHA在做故障切换时不会选择这个slave做为新的master,因为恢复需要经过很长时间.当设置了check_repl_delay = 0, MHA将忽略被选择的slave上的同步延迟。　这个选项在设置了candidate_master = 1特声明的期望这台机器成为master的情况下特别有用。

 

5、latest_priority

在默认情况下，和Master最接近的slave(一个slave从Master上获得了最一个binlog事件)是最有优先权成为新的master。　如果你想控制一下切换的策略（如: 先选择host2，如果不行，选host3；host3不行，选host4…） 那么设置latest_priority = 0 就可以了。

 

6、log_level

MHA manager 的日志级别,默认是info级别,在大多数环境下没有问题.可用的级别有.debug/info/warning/error四种级别。

 

7、multi_tier_slave

从MHA 0.52开始, 多层复制可以支持了。在默认情况下，不支持三层或是更多层的复制配置

 

8、ping_interval

这个参数设置MHA Manager多长时间去ping一下master(执行一些SQL语句）. 当失去和master三次偿试，MHA Manager会认为MySQL Master死掉了。即最大的故障切换时间是４次ping_interval的时间，默认是3秒。

 

9、ping_type

     MHA 0.53后出现的参数.(1)在默认情况下，MHA　manager和MySQL创建一个连接执行”select 1″（ping_type=select）用于检查master是否健康。　

  （2）每次检测都连接/然后断开会比较好一点，这样对于tcp方面的错误感知更快一点。设置ping_type=CONNECT 就行了。

   (3) 从MHA 0.56后pint_type=INSERT也被添加。

三、脚本说明

1、master_ip_failover_script

    负责故障切换动作的脚本

2、master_ip_online_change_script

   负责在线切换动作的脚本

3、secondary_check_script

    默认MHA是通过一个路由检测:从manager到master.但是secondary_check_script脚本，让MHA manager可以通过t参数调用一个内部脚本来实现两个或者多个路由的检测.

4、shutdown_script

  为避免脑裂，有时候需要强制关闭master服务器,避免他再次提供服务。

如：shutdown_script= /usr/local/custom_script/master_shutdown

相关参数：

--command=stopssh (这个意思就是指停止服务,不会关机)

--ssh_user=(ssh username so that you can connect to the master)

--host=(master's hostname)

--ip=(master's ip address)

--port=(master's port number)

--pid_file=(master's pid file)

 

5、report_script

   这个脚本的功能：是在Master故障完毕后，也许想发一个送一个报告（如email）报告一下切换完毕或是发生的错误。

相关参数：

--orig_master_host = (死掉master机器名)

--new_master_host　= (新的master机器名)

--new_slave_hosts = (新的slave机器名列表，用逗号隔开)

--subject = (邮件名)–body = (正文)

 

---The end