这篇文章主要讲解了“mha日常维护命令总结”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“mha日常维护命令总结”吧！

1.查看ssh登陆是否成功masterha_check_ssh--conf=/etc/masterha/app1.cnf

2.查看复制是否建立好masterha_check_repl--conf=/etc/masterha/app1.cnf

3.启动mhanohupmasterha_manager--conf=/etc/masterha/app1.cnf>/tmp/mha_manager.log</dev/2>&1&当有slave节点宕掉的情况是启动不了的，加上--ignore_fail_on_start即使有节点宕掉也能启动mhanohupmasterha_manager--conf=/etc/masterha/app1.cnf--ignore_fail_on_start>/tmp/mha_manager.log</dev/2>&1&

4.检查启动的状态masterha_check_status--conf=/etc/masterha/app1.cnf

5.停止mhamasterha_stop--conf=/etc/masterha/app1.cnf

6.failover后下次重启每次failover切换后会在管理目录生成文件app1.failover.complete，下次在切换的时候会发现有这个文件导致切换不成功，需要手动清理掉。rm-rf/masterha/app1/app1.failover.complete也可以加上参数--ignore_last_failover

7.手工failover手工failover场景，master死掉，但是masterha_manager没有开启，可以通过手工failover：masterha_master_switch--conf=/etc/masterha/app1.cnf--dead_master_host=10.50.2.10--master_state=dead--new_master_host=10.50.2.12--ignore_last_failover

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

9.手动在线切换masterha_master_switch--conf=/etc/app1.cnf--master_state=alive--new_master_host=192.168.119.74--orig_master_is_new_slave或者masterha_master_switch--conf=/etc/app1.cnf--master_state=alive--new_master_host=192.168.119.74--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日志的大小决定手动在线切换mha，切换时需要将在运行的mha停掉后才能切换。在备库先执行DDL，一般先stopslave，一般不记录mysql日志，可以通过setSQL_LOG_BIN=0实现。然后进行一次主备切换操作，再在原来的主库上执行DDL。这种方法适用于增减索引，如果是增加字段就需要额外注意。可以通过如下命令停止mhamasterha_stop--conf=/etc/app1.cnf

常用参数介绍:

--master_state=dead强制的参数，参数值为"dead"或者"alive".如果设置为alive模式，masterha_master_switch开始在线主库切换操作。--dead_master_host=(hostname)强制参数，宕机的主库所在的主机名称。--dead_master_ip和--dead_master_port是可选参数，如果这些参数没有设置，--dead_master_ip就是--dead_master_host解析的IP地址。--dead_master_port为3306--new_master_host=(hostname)新主机地址，可选参数，这个参数在你明确新的主库的主机，非常有用。(这就意味着你不需要让MHA来决定新的主库)。如果不设置此参数，MHA将会利用自动failover的规则来选择新的主库。如果设置--new_master_host，MHA选择此主机为新的主库，如果不能成为主库，MHA将会退出--interactive=(0|1)如果设置为0，在masterha_master_switch，它自动执行故障转移(非交互式)。这实际上是和masterha_manager的内部运行机制一样，这种非交互式故障转移是有用的，如果你已经证实了master死了,但你想尽快做故障转移。非交互式故障转移也是有用的,如果你使用其他现有的主监控软件和要调用的非交互式故障转移命令软件。典型的例子是masterha_master_switch调用从集群软件像起搏器。--ssh_reachable=(0|1|2)指定master经过SSH是否可达。0:不可达、1:可达、2:未知(默认值)。如果设置为了2，此命令内部将会检测通过SSH是否可达master，并且跟新SSH状态。如果可达，且设置master_ip_failover_script或者shutdown_script.将会执行"--command=stopssh"。否则，执行"--command=stop"。另外，如果宕机的master通过SSH可达，failover脚本试图从宕机的master机器上拷贝没有没有发送的binlog。--skip_change_master如果设置此参数，当发生failover的时候，MAH在应用完不同的relaylog退出，忽略CHANGEMASTER和STARTSLAVE操作。所以slaves不会指向新的master.开启此参数，有利于手动的二次检查slave恢复是否成功--skip_disable_read_only设置此参数，MHA将不会在新的主库上执行SETGLOBALread_only=0操作，有利于手动操作--last_failover_minute=(minutes)参考master_manager--ignore_last_failover参考master_manager--wait_on_failover_error=(seconds)类似于master_manager,此参数只用于自动的/非交互式的failover。如果没有设置--interval=0，wait_on_failover_error将会被忽略，在发生错误的时候不会sleep。--remove_dead_master_conf参考masterha_manager--wait_until_gtid_in_sync(0|1)此参数从0.56版本开始可用，如果设置成1，当基于GITD的failover时,MHA会等待所有的从库追上新主库的GITD--skip_change_master此参数从0.56版本开始可用，如果开启此选项，MHA跳过CHANGEMASTER的操作--skip_disable_read_only此参数从0.56版本开始可用，如果开启此选项，MHA将会在新的master跳过SETGLOBALread_only=0;--ignore_binlog_server_error此参数从0.56版本开始可用，如果开启此选项，当执行failover的时，MHA忽略binlogserver上任何错误非交互式Failover

如果在masterha_master_switch中设置"--interactive=0",它自动执行故障转移(非交互式)。这实际上是和masterha_manager的内部运行机制一样，这种非交互式故障转移是有用的，如果你已经证实了master死了,但你想尽快做故障转移。非交互式故障转移也是有用的,如果你使用其他现有的主监控软件和要调用的非交互式故障转移命令软件。典型的例子是masterha_master_switch调用从集群软件像起搏器。[在线] 切换主库的开关 (Scheduled (Online) Master Switch)

有时你可能想做预定的主切换,即使当前的master正在运行。典型的例子是取代部分损坏的硬件或升级主服务器。你不能取代一个RAID控制器或增加内存没有停止服务器。在这种情况下,您需要分配一个预定的维护时间,你必须迁移到不同的服务器的master。masterha_master_switch命令可以用来运行计划总开关。$masterha_master_switch--master_state=alive--conf=/etc/app1.cnf--new_master_host=host2--master_state=alive必须设置。调度主开关的程序流与从主故障转移有稍微的不同。例如,你不需要关闭主服务器,但你需要确保写查询不在主上执行。通过设置主ip网上变更脚本,您可以控制阻塞当前master不允许写(即drop可写的用户,设置read_only=1,等等)在执行FLUSHTABLESWITHREADLOCK,和如何让写在新master。Onlinemasterswitch开始只有当所有下列条件得到满足。1.IOthreadsonallslavesarerunning//在所有slave上IO线程运行。2.SQLthreadsonallslavesarerunning//SQL线程在所有的slave上正常运行。3.Seconds_Behind_Masteronallslavesarelessorequalthan--running_updates_limitseconds//在所有的slaves上Seconds_Behind_Master要小于等于running_updates_limitseconds4.Onmaster,noneofupdatequeriestakemorethan--running_updates_limitsecondsintheshowprocesslistoutput//在主上，没有更新查询操作多于running_updates_limitseconds在showprocesslist输出结果上。这些限制的原因是出于安全原因,并尽快切换到新主库。masterha_master_switch需要以下参数切换时主在线。--new_master_host=(hostname)新主机地址，可选参数，这个参数在你明确新的主库的主机，非常有用。(这就意味着你不需要让MHA来决定新的主库)。如果不设置此参数，MHA将会利用自动failover的规则来选择新的主库。如果设置--new_master_host，MHA选择此主机为新的主库，如果不能成为主库，MHA将会退出--orig_master_is_new_slave当完成主库切换后，原先的主库将作为现在主库的slave运行。默认:不开启(原先的主库不会加入到新的复制环境中)。如果开启此选项，需要在配置文件中设置repl_password参数，由于当期的Master并不知道新的Master的replication的密码--remove_orig_master_conf如果设置此参数，当成功failover后，MHAmanager将会自动删除配置文件中关于deadmaster的配置选项。--skip_lock_all_tables当在做主库切换的时候，MHA会在原先的主库上执行FLUSHTABLESWITHREADLOCK操作，确保没有跟新操作，但是FLUSHTABLESWITHREADLOCK操作是非常耗费资源的，并且你可以在原先的主库确定没有跟新操作(通过master_ip_online_change_script中killallclients操作等)。可以利用此选项避免锁表。

感谢各位的阅读，以上就是“mha日常维护命令总结”的内容了，经过本文的学习后，相信大家对mha日常维护命令总结这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！