MySQL Bugs: #78343: mysqlrpladmin fails to match passwords for rpl

Bug #78343	mysqlrpladmin fails to match passwords for rpl_user
Submitted:	5 Sep 2015 21:40	Modified:	14 Dec 2016 6:35
Reporter:	monty solomon	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Utilities	Severity:	S1 (Critical)
Version:	1.5.6,1.6.4	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
# Checking slaves configuration to master.
# When the master_info_repository variable is set to FILE, the --rpl-user option may be used only if the user specified matches what is shown in the SLAVE STATUS output unless the --force option is used.
ERROR: The specified replication user is using a different password that the one specified.
Use the --force option to force the use of the user specified with  --rpl-user and new password.
# Errors found. Switchover aborted.

How to repeat:
Create an entry in the configuration file for the replication user used by the replication cluster.

Run mysqlrpladmin to switch the master and reference the replication user in the configuration file

% mysqlrpladmin --verbose --demote-master --discover-slaves-login=.myrpladmin.cnf/[SUSR_rpladmin]  --new-master=.myrpladmin.cnf/[lively-haze] --master=.myrpladmin.cnf[noisy-pond] --rpl-user=.myrpladmin.cnf/[SUSR_Repl] --log=mysqlrpladmin.log switchover

Get an error

# Checking slaves configuration to master.
# When the master_info_repository variable is set to FILE, the --rpl-user option may be used only if the user specified matches what is shown in the SLAVE STATUS output unless the --force option is used.
ERROR: The specified replication user is using a different password that the one specified.
Use the --force option to force the use of the user specified with  --rpl-user and new password.
# Errors found. Switchover aborted.

The problem is caused by the method mysqlrpladmin uses to retrieve the password for the replication user in switchover() in topology.py.

It looks for an entry that matches the specified replication user and the specific candidate host, gets back an empty passwd_hash, and prints an incorrect error message -- "The specified replication user is using a different password that the one specified"

    passwd_hash = slave_qry(query.format(user=user, host=m_candidate.host))

This happens because the replication user grant on the servers has a wildcard host.

mysql> show grants for SUSR_Repl\G
Grants for SUSR_Repl@%: GRANT REPLICATION SLAVE ON *.* TO 'SUSR_Repl'@'%' IDENTIFIED BY PASSWORD '*redacted'

The problem is caused by the method mysqlrpladmin uses to retrieve the password for the replication user in switchover() in topology.py.

It looks for an entry that matches the specified replication user and the specific candidate host, gets back an empty passwd_hash, and prints an incorrect error message -- "The specified replication user is using a different password that the one specified"

    passwd_hash = slave_qry(query.format(user=user, host=m_candidate.host))

This happens because the replication user grant on the servers has a wildcard host.

mysql> show grants for SUSR_Repl\G
Grants for SUSR_Repl@%: GRANT REPLICATION SLAVE ON *.* TO 'SUSR_Repl'@'%' IDENTIFIED BY PASSWORD '*redacted'

Thank you for the bug report.

Please try with MySQL Utilities 1.6.4 version?
Please let us know if you are still having the issue with complete repeatable steps( version of C/Py, version of MySQL and a sample configuration file , etc. - please make it as private if you prefer) to confirm this issue at our end?

Thanks,
Chiranjeevi.

It still fails in the same way using version 1.6.4.

The query that is failing is 

"SELECT user, host, grant_priv, authentication_string, Repl_slave_priv FROM mysql.user WHERE user ='{user}' AND host ='{host}'"

generated from 

                passwd_hash = slave_qry(query.format(user=user,
                                                     host=m_candidate.host))

in topology.py because it expects there to be a specific grant for user@host and it fails to match a grant for user@%

Hello monty solomon,

Thank you for your feedback.
Verified based on internal discussion with dev's.

Thanks,
Chiranjeevi.

Still present in 1.6.5

Can be forced with --force option

Warning: for errant transactions:

--force

Ignore prerequisite checks or any inconsistencies found, such as errant transactions on the slaves or SQL thread errors, thus forcing the execution of the specified command. This option must be used carefully as it does not solve any detected issue, but only ignores them and displays a warning message.