MySQL 高可用 MHA check scripts

介绍几个MHA check 命令,输出如下

[[email protected] bin]# pwd
/usr/local/bin
[[email protected] bin]# ls -l
total 104
-r-xr-xr-x. 1 root root 16367 Sep  7 09:43 apply_diff_relay_logs
-r-xr-xr-x. 1 root root  4807 Sep  7 09:43 filter_mysqlbinlog
-r-xr-xr-x. 1 root root  1995 Sep  7 09:22 masterha_check_repl
-r-xr-xr-x. 1 root root  1779 Sep  7 09:22 masterha_check_ssh
-r-xr-xr-x. 1 root root  1865 Sep  7 09:22 masterha_check_status
-r-xr-xr-x. 1 root root  3201 Sep  7 09:22 masterha_conf_host
-r-xr-xr-x. 1 root root  2517 Sep  7 09:22 masterha_manager
-r-xr-xr-x. 1 root root  2165 Sep  7 09:22 masterha_master_monitor
-r-xr-xr-x. 1 root root  2373 Sep  7 09:22 masterha_master_switch
-r-xr-xr-x. 1 root root  5171 Sep  7 09:22 masterha_secondary_check
-r-xr-xr-x. 1 root root  1739 Sep  7 09:22 masterha_stop
-rwxr-xr-x. 1 root root  4598 Sep  7 14:20 master_ip_failover
-rwxr-xr-x. 1 root root 10101 Sep  7 14:32 master_ip_online_change
-r-xr-xr-x. 1 root root  8261 Sep  7 09:43 purge_relay_logs
-r-xr-xr-x. 1 root root  7525 Sep  7 09:43 save_binary_logs
[[email protected] bin]# masterha_check_ssh --conf=/etc/app1.cnf
Sun Sep  9 08:27:02 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Sun Sep  9 08:27:02 2018 - [info] Reading application default configuration from /etc/app1.cnf..
Sun Sep  9 08:27:02 2018 - [info] Reading server configuration from /etc/app1.cnf..
Sun Sep  9 08:27:02 2018 - [info] Starting SSH connection tests..
Sun Sep  9 08:27:02 2018 - [debug]
Sun Sep  9 08:27:02 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.101:22) to [email protected](192.168.56.102:22)..
Sun Sep  9 08:27:02 2018 - [debug]   ok.
Sun Sep  9 08:27:02 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.101:22) to [email protected](192.168.56.103:22)..
Sun Sep  9 08:27:02 2018 - [debug]   ok.
Sun Sep  9 08:27:03 2018 - [debug]
Sun Sep  9 08:27:02 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.102:22) to [email protected](192.168.56.101:22)..
Sun Sep  9 08:27:03 2018 - [debug]   ok.
Sun Sep  9 08:27:03 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.102:22) to [email protected](192.168.56.103:22)..
Sun Sep  9 08:27:03 2018 - [debug]   ok.
Sun Sep  9 08:27:03 2018 - [debug]
Sun Sep  9 08:27:03 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.103:22) to [email protected](192.168.56.101:22)..
Sun Sep  9 08:27:03 2018 - [debug]   ok.
Sun Sep  9 08:27:03 2018 - [debug]  Connecting via SSH from [email protected](192.168.56.103:22) to [email protected](192.168.56.102:22)..
Sun Sep  9 08:27:03 2018 - [debug]   ok.
Sun Sep  9 08:27:03 2018 - [info] All SSH connection tests passed successfully.
[[email protected] bin]# masterha_check_repl --conf=/etc/app1.cnf
Sun Sep  9 08:27:15 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Sun Sep  9 08:27:15 2018 - [info] Reading application default configuration from /etc/app1.cnf..
Sun Sep  9 08:27:15 2018 - [info] Reading server configuration from /etc/app1.cnf..
Sun Sep  9 08:27:15 2018 - [info] MHA::MasterMonitor version 0.56.
Sun Sep  9 08:27:16 2018 - [info] GTID failover mode = 0
Sun Sep  9 08:27:16 2018 - [info] Dead Servers:
Sun Sep  9 08:27:16 2018 - [info] Alive Servers:
Sun Sep  9 08:27:16 2018 - [info]   master(192.168.56.101:3306)
Sun Sep  9 08:27:16 2018 - [info]   slave1(192.168.56.102:3306)
Sun Sep  9 08:27:16 2018 - [info]   slave2(192.168.56.103:3306)
Sun Sep  9 08:27:16 2018 - [info] Alive Slaves:
Sun Sep  9 08:27:16 2018 - [info]   slave1(192.168.56.102:3306)  Version=10.1.35-MariaDB (oldest major version between slaves) log-bin:enabled
Sun Sep  9 08:27:16 2018 - [info]     Replicating from 192.168.56.101(192.168.56.101:3306)
Sun Sep  9 08:27:16 2018 - [info]   slave2(192.168.56.103:3306)  Version=10.1.35-MariaDB (oldest major version between slaves) log-bin:enabled
Sun Sep  9 08:27:16 2018 - [info]     Replicating from 192.168.56.101(192.168.56.101:3306)
Sun Sep  9 08:27:16 2018 - [info] Current Alive Master: master(192.168.56.101:3306)
Sun Sep  9 08:27:16 2018 - [info] Checking slave configurations..
Sun Sep  9 08:27:16 2018 - [info] Checking replication filtering settings..
Sun Sep  9 08:27:16 2018 - [info]  binlog_do_db= , binlog_ignore_db=
Sun Sep  9 08:27:16 2018 - [info]  Replication filtering check ok.
Sun Sep  9 08:27:16 2018 - [info] GTID (with auto-pos) is not supported
Sun Sep  9 08:27:16 2018 - [info] Starting SSH connection tests..
Sun Sep  9 08:27:17 2018 - [info] All SSH connection tests passed successfully.
Sun Sep  9 08:27:17 2018 - [info] Checking MHA Node version..
Sun Sep  9 08:27:18 2018 - [info]  Version check ok.
Sun Sep  9 08:27:18 2018 - [info] Checking SSH publickey authentication settings on the current master..
Sun Sep  9 08:27:18 2018 - [info] HealthCheck: SSH to master is reachable.
Sun Sep  9 08:27:18 2018 - [info] Master MHA Node version is 0.56.
Sun Sep  9 08:27:18 2018 - [info] Checking recovery script configurations on master(192.168.56.101:3306)..
Sun Sep  9 08:27:18 2018 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data/binlogs --output_file=/var/log/masterha//save_binary_logs_test --manager_version=0.56 --start_file=mysql-bin.000005
Sun Sep  9 08:27:18 2018 - [info]   Connecting to [email protected](master:22)..
  Creating /var/log/masterha if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /data/binlogs, up to mysql-bin.000005
Sun Sep  9 08:27:19 2018 - [info] Binlog setting check done.
Sun Sep  9 08:27:19 2018 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Sun Sep  9 08:27:19 2018 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user=‘admin‘ --slave_host=slave1 --slave_ip=192.168.56.102 --slave_port=3306 --workdir=/var/log/masterha/ --target_version=10.1.35-MariaDB --manager_version=0.56 --relay_log_info=/data/mysql/relay-log.info  --relay_dir=/data/mysql/  --slave_pass=xxx
Sun Sep  9 08:27:19 2018 - [info]   Connecting to [email protected](slave1:22)..
  Checking slave recovery environment settings..
    Opening /data/mysql/relay-log.info ... ok.
    Relay log found at /data/relaylogs, up to relay-bin.000015
    Temporary relay log file is /data/relaylogs/relay-bin.000015
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Sun Sep  9 08:27:19 2018 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user=‘admin‘ --slave_host=slave2 --slave_ip=192.168.56.103 --slave_port=3306 --workdir=/var/log/masterha/ --target_version=10.1.35-MariaDB --manager_version=0.56 --relay_log_info=/data/mysql/relay-log.info  --relay_dir=/data/mysql/  --slave_pass=xxx
Sun Sep  9 08:27:19 2018 - [info]   Connecting to [email protected](slave2:22)..
  Checking slave recovery environment settings..
    Opening /data/mysql/relay-log.info ... ok.
    Relay log found at /data/relaylogs, up to relay-bin.000015
    Temporary relay log file is /data/relaylogs/relay-bin.000015
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Sun Sep  9 08:27:19 2018 - [info] Slaves settings check done.
Sun Sep  9 08:27:19 2018 - [info]
master(192.168.56.101:3306) (current master)
 +--slave1(192.168.56.102:3306)
 +--slave2(192.168.56.103:3306)

Sun Sep  9 08:27:19 2018 - [info] Checking replication health on slave1..
Sun Sep  9 08:27:19 2018 - [info]  ok.
Sun Sep  9 08:27:19 2018 - [info] Checking replication health on slave2..
Sun Sep  9 08:27:19 2018 - [info]  ok.
Sun Sep  9 08:27:19 2018 - [info] Checking master_ip_failover_script status:
Sun Sep  9 08:27:19 2018 - [info]   /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=master --orig_master_ip=192.168.56.101 --orig_master_port=3306
    inet 192.168.56.105/32 scope global eth1
INFO: VIP 192.168.1.100 found on Master
Sun Sep  9 08:27:19 2018 - [info]  OK.
Sun Sep  9 08:27:19 2018 - [warning] shutdown_script is not defined.
Sun Sep  9 08:27:19 2018 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.
[[email protected] bin]#
[[email protected] bin]# masterha_check_s
masterha_check_ssh     masterha_check_status
[[email protected] bin]# masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).
[[email protected] bin]# masterha_check_status
Either --conf or --status_dir must be set.
 at /usr/local/share/perl5/MHA/ManagerAdminWrapper.pm line 121
[[email protected] bin]# 

原文地址:http://blog.51cto.com/roidba/2172752

时间: 2024-10-07 13:42:49

MySQL 高可用 MHA check scripts的相关文章

mysql高可用MHA架构搭建

前言:首先介绍一下mha,引用自网络. MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案. 该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点).MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上.MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自

Mysql高可用MHA

MHA(Master High Availability)目前在 MySQL 高可用方面是一个相对成熟的解决方案,它由 日本 DeNA 公司 youshimaton(现就职于 Facebook 公司)开发,是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件. 在 MySQL 故障切换过程中,MHA 能做 到在 0~30 秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA 能 在最大程度上保证数据的一致性,以达到真正意义上的高可用. MHA 里有两个角色

MySQL高可用MHA部署 (一主二从)

MHA介绍: MHA是一套MySQL故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性.MHA部署简单,也需要额外的服务器开销,运行MHA时对数据服务器性能几乎没有影响,也不需要对现有架构做调整. 同时MHA还支持主库在线切换,能够安全地将现在的主库切到新的主库,只会对写操作有0.5~2s的阻塞,对读没有影响. MHA有以下功能,对有高可用,数据一致性,主库不停机维

MySQL高可用MHA集群

MHA 简介 MHA(Master High Availability)它由日本DeNA公司youshimaton开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用.MHA软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点).MHA Manager可以单独部署在一台

MySQL 高可用MHA安装部署以及故障转移详细资料汇总 转

http://blog.itpub.net/26230597/cid-87082-list-2/ 1,简介 1.1mha简介 MHA,即MasterHigh Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性. MHA(Master High Availability)是自动的master故障转移和Sl

MySQL 高可用MHA安装部署以及故障转移详细资料汇总

1,简介 1.1mha简介 MHA,即MasterHigh Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性. MHA(Master High Availability)是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步). MHA有两部分组成:MHA M

mysql高可用MHA部署全过程

部署计划 mysql_master 192.168.2.74 centos6.9 mysql5.5/mha-node mysql_salve1 192.168.2.75 centos6.9 mysql5.5/mha-node mysql_salve2 192.168.2.76 centos6.9 mysql5.5/mha-node/mha-man 本次部署采用3台服务器,mha-manager不单独使用一台服务器安装,生产上可以单独出来,本次使用采用centos6.9系统(使用 http://y

MySQL高可用--MHA

准备环境: 1.至少三台虚拟机 2.MySQL5.6 (支持事务一致性) 一.环境准备 1. 时间同步 [[email protected] tom42 ~]# echo "*/5 * * * * /usr/sbin/ntpdate ntp1.aliyun.com >/dev/null 2>&1" >>/var/spool/cron/root 原文地址:https://www.cnblogs.com/gaiting/p/12304628.html

MySQL高可用之MHA的搭建

MySQL MHA架构介绍: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正的高可用. 该软件由两部分组成:MHA Manag