[MXS-1594] MASTER_PASSWORD not being correctly used when triggering a switchover Created: 2018-01-03  Updated: 2018-01-11  Resolved: 2018-01-11

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbmon
Affects Version/s: 2.2.1
Fix Version/s: 2.2.1

Type: Bug Priority: Blocker
Reporter: Wagner Bianchi (Inactive) Assignee: Esa Korhonen
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS 7



 Description   

Folks,

I found another problem guys when you do the switchover, you need to enter the CHANGE MASTER TO on the new slave to replicate off the new master. And then, a new file `master.info` is created with the information for the replication threads to start the replication. A couple of information is username and password, which in this case are equivalent to the replication_user and replication_password you set under the mysqlmon configurations for the Maxscale. Look at this:

#: when Maxscale does the switchover, the master.info looks like...
[root@box02 mysql]# cat master.info
33
 
4
192.168.50.11
repl
'KP
3306
60
0
 
#: when I enter the change master to manually to investigate why the replication wasn't OK when set by the switchover process
[root@box02 mysql]# cat master.info
33
 
4
192.168.50.11
repl
123456
3306
60
0

You can see that the password for the user `repl` isn’t `'KP` but `123456`…maybe something wrong going on with using the var after reading the replication_password under the monitor configuration?

After the switchover done by Maxscale, I’m always getting:

Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'repl@192.168.50.12:3306' - retry-time: 60  maximum-retries: 86400  message: Access denied for user 'repl'@'192.168.50.11' (using password: YES)

My monitor configurations

[root@maxscale maxscale.cnf.d]# cat cluster-monitor.cnf
[cluster-monitor]
type=monitor
module=mysqlmon
user=maxuser
password=ACEEF153D52F8391E3218F9F2B259EAD
monitor_interval=10000
backend_connect_timeout=3
backend_write_timeout=2
backend_read_timeout=1
backend_connect_attempts=1
journal_max_age=28800
script_timeout=90
servers=prod_mariadb01,prod_mariadb02
auto_failover=1
failover_timeout=1
master_failure_timeout=2
replication_user=repl    #: <<<
replication_password=123456  #: <<<
detect_replication_lag=false
detect_stale_master=true
detect_stale_slave=true
mysql51_replication=false
multimaster=false
detect_standalone_master=true
failcount=5
allow_cluster_recovery=true
ignore_external_masters=false
events=master_down,master_up,slave_down,slave_up,server_down,server_up,synced_down,synced_up,donor_down,donor_up,ndb_down,ndb_up,lost_master,lost_slave,lost_synced,lost_donor,lost_ndb,new_master,new_slave,new_synced,new_donor,new_ndb
switchover_timeout=90
verify_master_failure=true
auto_rejoin=false

Can you folks have a look at this issue?



 Comments   
Comment by Esa Korhonen [ 2018-01-11 ]

Clarified error message.

Generated at Thu Feb 08 04:07:57 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.