共计 5608 个字符,预计需要花费 15 分钟才能阅读完成。
这篇文章主要讲解了“mha 日常维护命令总结”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着丸趣 TV 小编的思路慢慢深入,一起来研究和学习“mha 日常维护命令总结”吧!
mha 日常维护命令
1. 查看 ssh 登陆是否成功
masterha_check_ssh --conf=/etc/masterha/app1.cnf
2. 查看复制是否建立好
masterha_check_repl --conf=/etc/masterha/app1.cnf
3. 启动 mha
nohup masterha_manager --conf=/etc/masterha/app1.cnf /tmp/mha_manager.log /dev/2 1
当有 slave 节点宕掉的情况是启动不了的,加上 --ignore_fail_on_start 即使有节点宕掉也能启动 mha
nohup masterha_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. 停止 mha
masterha_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,一般先 stop slave,一般不记录 mysql 日志,可以通过 set SQL_LOG_BIN = 0 实现。然后进行一次主备切换操作,再在原来的主库上执行 DDL。这种方法适用于增减索引,如果是增加字段就需要额外注意。可以通过如下命令停止 mha
masterha_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 在应用完不同的 relay log 退出,忽略 CHANGE MASTER 和 START SLAVE 操作。所以 slaves 不会指向 新的 master. 开启此参数,有利于手动的二次检查 slave 恢复是否成功
--skip_disable_read_only
设置此参数,MHA 将不会在新的主库上执行 SET GLOBAL read_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 跳过 CHANGE MASTER 的操作
--skip_disable_read_only
此参数从 0.56 版本开始可用,如果开启此选项,MHA 将会在新的 master 跳过 SET GLOBAL read_only = 0;
--ignore_binlog_server_error
此参数从 0.56 版本开始可用,如果开启此选项,当执行 failover 的时,MHA 忽略 binlog server 上任何错误
非交互式 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, 等等) 在执行 FLUSH TABLES WITH READ LOCK, 和如何让写在新 master。Online master switch 开始只有当所有下列条件得到满足。 1. IO threads on all slaves are running // 在所有 slave 上 IO 线程运行。 2. SQL threads on all slaves are running //SQL 线程在所有的 slave 上正常运行。 3. Seconds_Behind_Master on all slaves are less or equal than --running_updates_limit seconds // 在所有的 slaves 上 Seconds_Behind_Master 要小于等于 running_updates_limit seconds
4. On master, none of update queries take more than --running_updates_limit seconds in the show processlist output // 在主上,没有更新查询操作多于 running_updates_limit seconds 在 show processlist 输出结果上。这些限制的原因是出于安全原因, 并尽快切换到新主库。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 后,MHA manager 将会自动删除配置文件中关于 dead master 的配置选项。 --skip_lock_all_tables
当在做主库切换的时候,MHA 会在原先的主库上执行 FLUSH TABLES WITH READ LOCK 操作,确保没有跟新操作,但是 FLUSH TABLES WITH READ LOCK 操作是非常耗费资源的,并且你可以在原先的主库确定没有跟新操作(通过 master_ip_online_change_script 中 kill all clients 操作等)。可以利用此选项避免锁表。
感谢各位的阅读,以上就是“mha 日常维护命令总结”的内容了,经过本文的学习后,相信大家对 mha 日常维护命令总结这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是丸趣 TV,丸趣 TV 小编将为大家推送更多相关知识点的文章,欢迎关注!
正文完