Shulou(Shulou.com)06/01 Report--

First take a look at the password that caused the problem, which contains two special characters [and ~.

$egrep-w'user | password' / etc/masterha/app1.cnf

Password=P [AI3M~5z

User=mha_mgr

The role of user mha_mgr, as described in the following document, shows that it plays a role in managing database instances.

MySQL administrative database username to the target MySQL server. This should be root because it runs all necessary administrative commands such as STOP SLAVE, CHANGE MASTER, RESET SLAVE.

Look at the phenomenon of handover failure in two scenarios.

1. Manual online switching, according to the log, MHA escaped the special characters in the password, causing the user mha_mgr to connect to the database failed.

Check the original master-slave replication status and find that there is no change, that is, the switch failed, and did not affect.

$masterha_master_switch-conf=/etc/masterha/app1.cnf-master_state=alive-orig_master_is_new_slave

...

Thu Jan 11 10:28:39 2018-[info] * Phase 2: Rejecting updates Phase..

Thu Jan 11 10:28:39 2018-[info]

Thu Jan 11 10:28:39 2018-[info] Executing master ip online change script to disable write on the current master:

Thu Jan 11 10:28:39 2018-[info] / usr/local/bin/master_ip_online_change-- command=stop-- orig_master_host=192.168.4.42-- orig_master_ip=192.168.4.42-- orig_master_port=3306-- orig_master_user='mha_mgr'-- orig_master_password='P\ [AI3M\ ~ 5z'-- new_master_host=192.168.4.43-- new_master_ip=192.168.4.43 -- new_master_port=3306-- new_master_user='mha_mgr'-- new_master_password='P\ [AI3M\ ~ 5z'-- orig_master_ssh_user=mysql-- new_master_ssh_user=mysql-- orig_master_is_new_slave

ARGS: $VAR1 = [

'--command=stop'

'--orig_master_host=192.168.4.42'

'--orig_master_ip=192.168.4.42'

'--orig_master_port=3306'

'--orig_master_user=mha_mgr'

'--orig_master_password=P\ [AI3M\ ~ 5z'

'--new_master_host=192.168.4.43'

'--new_master_ip=192.168.4.43'

'--new_master_port=3306'

'--new_master_user=mha_mgr'

'--new_master_password=P\ [AI3M\ ~ 5z'

'--orig_master_ssh_user=mysql'

'--new_master_ssh_user=mysql'

'--orig_master_is_new_slave'

]

Unknown option: orig_master_ssh_user

Unknown option: new_master_ssh_user

Unknown option: orig_master_is_new_slave

Got Error: DBI connect ('; host=192.168.4.43;port=3306;mysql_connect_timeout=4','mha_mgr',...) Failed: Access denied for user 'mha_mgr'@'192.168.4.45' (using password: YES) at / usr/local/share/perl5/MHA/DBHelper.pm line 205.

At / usr/local/bin/master_ip_online_change line 132.

Thu Jan 11 10:28:39 2018-[error] [/ usr/local/share/perl5/MHA/ManagerUtil.pm, ln177] Got ERROR: at / usr/local/bin/masterha_master_switch line 53.

two。 Automatic failover (manual shutdown of the main library, simulation failure), the log finally appeared the word "completed successfully", seems to be no problem, but a detailed look at the log, found a similar error above, see yellow.

Checking the original replication status, it is found that the replication relationship switch is normal, but the write virtual IP is missing, that is, it is not writable.

$tail-f / var/log/masterha/manager.log

...

Fri Jan 12 10:33:55 2018-[info] Executing master IP activate script:

Fri Jan 12 10:33:55 2018-[info] / usr/local/bin/master_ip_failover-- command=start-- ssh_user=mysql-- orig_master_host=192.168.4.42-- orig_master_ip=192.168.4.42-- orig_master_port=3306-- new_master_host=192.168.4.43-- new_master_ip=192.168.4.43-- new_master_port=3306-- new_master_user='mha_mgr'-- new_master_password='P\ [AI3M\ ~ 5z'

DBI connect ('; host=192.168.4.43;port=3306;mysql_connect_timeout=4','mha_mgr',...) Failed: Access denied for user 'mha_mgr'@'192.168.4.45' (using password: YES) at / usr/local/share/perl5/MHA/DBHelper.pm line 205.

At / usr/local/bin/master_ip_failover line 81.

Fri Jan 12 10:33:55 2018-[error] [/ usr/local/share/perl5/MHA/MasterFailover.pm, ln1588] Failed to activate master IP address for 192.168.4.43 (192.168.4.43) with return code 10:0

Fri Jan 12 10:33:55 2018-[warning] Proceeding.

Fri Jan 12 10:33:55 2018-[info] Setting read_only=0 on 192.168.4.43 (192.168.4.43)

Fri Jan 12 10:33:55 2018-[info] ok.

...

Master failover to 192.168.4.43 (192.168.4.43) completed successfully.

Fri Jan 12 10:33:57 2018-[info] Sending mail..

The solution is to change to a more normal password. As for fixing this small defect, you should also check the code carefully.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.