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

[5 Sep 2015 21:40] monty solomon
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.
[6 Oct 2015 22:42] monty solomon
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'
[6 Oct 2015 22:42] monty solomon
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'
[23 Nov 2016 10:41] Chiranjeevi Battula
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.
[7 Dec 2016 5:32] monty solomon
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@%
[14 Dec 2016 6:35] Chiranjeevi Battula
Hello monty solomon,

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

Thanks,
Chiranjeevi.
[22 Oct 2018 10:27] MateCat MateCat
Still present in 1.6.5

Can be forced with --force option
[22 Oct 2018 10:29] MateCat MateCat
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.