MySQL 有关MHA搭建与切换的几个错误log

1:masterha_check_repl 副本集方面报错  replicates is not defined in the configuration file!

具体信息如下:

# /usr/local/bin/masterha_check_repl --conf=/etc/mha/app1.cnf


Thu Nov 21 15:33:15 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Nov 21 15:33:15 2018 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Thu Nov 21 15:33:15 2018 - [info] Reading server configuration from /etc/mha/app1.cnf..
Thu Nov 21 15:33:15 2018 - [info] MHA::MasterMonitor version 0.56.
Thu Nov 21 15:33:16 2018- [error][/usr/local/share/perl5/MHA/ServerManager.pm, ln671] Master 179.179.19.179:3306 from which slave 179.179.19.180(179.179.19.180:3306) replicates is not defined in the configuration file!
Thu Nov 21 15:33:16 2018 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations.  at /usr/local/share/perl5/MHA/MasterMonitor.pm line 326.
Thu Nov 21 15:33:16 2018 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Thu Nov 21 15:33:16 2018 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!

分析:MHA 漂移过后,我们知道配置信息中 主节点的信息就不在了,我们需要及时维护,否则/usr/local/bin/masterha_check_repl --conf=/etc/mha/XXX.cnf 检查副本集状态报错。

2. masterha_master_switch 在线切换方面 报错 We should not start online master switch when one of connections are running long updates on the current master

具体信息如下:

# /usr/local/bin/masterha_master_switch --master_state=alive --conf=/etc/mha/app1.cnf

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 179.179.19.184(179.179.19.184:3306)? (YES/no): y

Tue Nov 19 17:19:09 2018 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Tue Nov 19 17:19:09 2018 - [info]  ok.
Tue Nov 19 17:19:09 2018 - [info] Checking MHA is not monitoring or doing failover..
Tue Nov 19 17:19:09 2018 - [info] Checking replication health on 179.179.19.185..
Tue Nov 19 17:19:09 2018 - [info]  ok.
Tue Nov 19 17:19:09 2018 - [error][/usr/local/share/perl5/MHA/MasterRotate.pm, ln161] We should not start online master switch when one of connections are running long updates on the current master(179.179.19.184(179.179.19.184:3306)). Currently 1 update thread(s) are running.
Details:
{‘Time‘ => ‘12815‘,‘db‘ => undef,‘Id‘ => ‘1‘,‘User‘ => ‘event_scheduler‘,‘State‘ => ‘Waiting on empty queue‘,‘Command‘ => ‘Daemon‘,‘Info‘ => undef,‘Host‘ => ‘localhost‘}
Tue Nov 19 17:19:09 2018 - [error][/usr/local/share/perl5/MHA/ManagerUtil.pm, ln177] Got ERROR:  at /usr/local/bin/masterha_master_switch line 53.

分析:set global event_scheduler=off; 主从都要关闭

3. masterha_master_switch 在线切换方面 报错 Got Error: DBI .....failed: Access denied for user

# /usr/local/bin/masterha_master_switch --master_state=alive --conf=/etc/mha/app1.cnf

Starting master switch from 179.179.19.185(179.179.19:3306) to 179.179.19.184(179.179.19.184:3306)? (yes/NO): yes

Tue Nov 19 18:52:04 2018 - [info] Checking whether 179.179.19.184(179.179.19.184:3306) is ok for the new master..
Tue Nov 19 18:52:04 2018 - [info]  ok.
Tue Nov 19 18:52:04 2018 - [info] ** Phase 1: Configuration Check Phase completed.
Tue Nov 19 18:52:04 2018 - [info]
Tue Nov 19 18:52:04 2018 - [info] * Phase 2: Rejecting updates Phase..
Tue Nov 19 18:52:04 2018 - [info]
Tue Nov 19 18:52:04 2018 - [info] Executing master ip online change script to disable write on the current master:
Tue Nov 19 18:52:04 2018 - [info]   /usr/local/bin/master_ip_online_change_appuanalysis --command=stop --orig_master_host=179.179.19.185 --orig_master_ip=179.179.19.185 --orig_master_port=3306--orig_master_user=‘weixinLX391P_xldbmha‘ --orig_master_password=‘weixinLX391P_xldbmha\)qlk‘ --new_master_host=179.179.19.184 --new_master_ip=179.179.19.184 --new_master_port=55988 --new_master_user=‘us_mha‘ --new_master_password=‘weixinLX391P_xldbmha\)qlk‘ --orig_master_ssh_user=root --new_master_ssh_user=root
Got Error: DBI connect(‘;host=179.179.19.184;port=3306;mysql_connect_timeout=4‘,‘weixinLX391P_xldbmha‘,...) failed: Access denied for user ‘weixinLX391P_xldbmha‘@‘179.179.19.166‘ (using password: YES) at /usr/local/share/perl5/MHA/DBHelper.pm line 205.
 at /usr/local/bin/master_ip_online_change_app1 line 119.

Tue Nov 19 18:52:04 2018 - [error][/usr/local/share/perl5/MHA/ManagerUtil.pm, ln177] Got ERROR:  at /usr/local/bin/masterha_master_switch line 53.

分析:账号密码有需要转移字符的。app1.cnf 文件中user账号相应的密码 password 不能有待转移的字符,例如本例中的‘)‘,但是 账号 repl_user 相应的密码repl_password 没有此限制。

原文地址:https://www.cnblogs.com/xuliuzai/p/11980273.html

时间: 2024-11-09 02:22:57

MySQL 有关MHA搭建与切换的几个错误log的相关文章

Mysql高可以之MHA搭建

Mysql高可以之MHA搭建 系统:CentOS6.5_X86_64Mysql:MySQL-5.6.17-1.el6.x86_64 监控机(Manager):192.168.1.101主库(Master):192.168.1.102备主(Candicate Master):192.168.1.103从库(Slave):192.168.1.104虚拟IP(VIP):192.168.1.105 一.安装MySQL数据库(主.备.从)#yum install -y MySQL-server#yum i

MySQL MHA 搭建&测试

一:背景介绍 MHA(Master HA)是一款开源的MySQL的高可用工具,能在MySQL主从复制的基础上,实现自动化主服务器故障转移.虽然MHA试图从宕机的主服务器上保存二进制日志,但并不是总是可行的.例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失最新数据. MHA监控复制架构的主服务器,一旦检测到主服务器故障,就会自动进行故障转移.即使有些从服务器没有收到最新的relay log,MHA自动从最新的从服务器上识别差异的relay log并把这

mysql mha 主从自动切换 高可用

mha(Master High Availability)目前在MySQL多服务器(超过二台),高可用方面是一个相对成熟的解决方案. 一,什么是mha,有什么特性 1. 主服务器的自动监控和故障转移 MHA监控复制架构的主服务器,一旦检测到主服务器故障,就会自动进行故障转移.即使有些从服务器没有收到最新的relay log,MHA自动从最新的从服务器上识别差异的relay log并把这些日志应用到其他从服务器上,因此所有的从服务器保持一致性了.MHA通常在几秒内完成故障转移,9-12秒可以检测出

五、mysql集群-MHA搭建

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

mha 搭建 及注意事项

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

maxscale配合MHA搭建读写分离的高可用架构(基于GTID replication主从架构,mysql5.6)

基于GTID的主从replication并配合MHA搭建高可用架构,请参考之前的博客:http://linzhijian.blog.51cto.com/1047212/1906434.这里只叙述如何在此基础上增加maxscale中间件,实现读写分离的功能. MaxScale是maridb开发的一个MySQL数据中间件,其配置简单,能够实现读写分离,并且可以根据主从状态实现写库的自动切换.官方文档:https://mariadb.com/kb/en/mariadb-enterprise/about

MHA 搭建

备注: 此处搭建的MHA 为 一主一从的环境 manager:192.168.162.132 master:192.168.162.134 node134 slave:192.168.162.133 node133 1.搭建主从:liyingdi.blog.51cto.com/6397405/1915010 MHA不支持基于gtid的复制模式 2.所以节点下载安装MHA的软件 https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=

MySQL的MHA

参照原文:http://www.cnblogs.com/gomysql/p/3675429.html 简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大

MySQL之MHA架构的介绍

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