replication-manager icon indicating copy to clipboard operation
replication-manager copied to clipboard

Error 1045 with mysql 5.7

Open dimon00 opened this issue 6 years ago • 10 comments

replication-manager-cli version Replication Manager 2.0.1 for MariaDB 10.x and MySQL 5.7 Series Full Version: 2.0.1-1-gaea9c25e Build Time: 2018-06-12T10:37:38+0000 mysql --version mysql Ver 14.14 Distrib 5.7.22, for Linux (x86_64) using EditLine wrapper

gtid is configured on master and slave (and it is working correctly).

My configuration is minimal: [Default] title = "ClusterTestMasterSlave"

db-servers-hosts = "support01:3306,support02:3306" db-servers-prefered-master = "support01:3306" db-servers-credential = "root:xxxxxx" db-servers-connect-timeout = 1

replication-credential = "slave_user:xxxxxx"

monitoring-datadir = "/var/lib/replication-manager" monitoring-sharedir = "/usr/share/replication-manager" log-file = "/var/log/replication-manager.log"

logfile = "/var/log/replication-manager.log"

verbose = true

But I'm getting:

2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] INFO - Loading database TLS certificates 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] INFO - Don't Have database TLS certificates 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] INFO - New server monitored: support01:3306 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] INFO - New server monitored: support02:3306 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] INFO - Failover in interactive mode 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] INFO - Loading 0 proxies 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] STATE - OPENED ERR00010 : Could not find a slave in topology 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] STATE - OPENED ERR00012 : Could not find a master in topology 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] STATE - OPENED ERR00004 : Database support01:3306 access denied: Error 1045: Access denied for user 'root'@'172.16.0.13' (using password: NO) 2018-06-22 15:41:28 2018-06-22 15:23:16 [Default] STATE - OPENED ERR00021 : All cluster db servers down 2018-06-22 15:41:28 2018-06-22 15:23:24 [Default] INFO - Declaring server support01:3306 as failed 2018-06-22 15:41:28 2018-06-22 15:23:24 [Default] INFO - Declaring server support02:3306 as failed 2018-06-22 15:41:28 2018-06-22 15:23:24 [Default] ALERT - Server support01:3306 state changed from Suspect to Failed 2018-06-22 15:41:28 2018-06-22 15:23:24 [Default] ALERT - Server support02:3306 state changed from Suspect to Failed

What I find unusual is the: (using password: NO)

Any help?

dimon00 avatar Jun 22 '18 13:06 dimon00

Hi,

Can you check that you can connect with mysql client from the replication-manager host with the user password provided to replication-manager

Could be that root@repman_host is not declared or the DB servers are bind to localhost only

Tx /svar

svaroqui avatar Jun 22 '18 14:06 svaroqui

I can connect properly with root from support01 and support02. I tried to configure the same replication manager to another cluster, with two mariadb databases and I obtain the same error. The strange behavior remains "(using password: NO)". It seems replication-manager doesn't provide the password. Am I forgetting any configuration option?

dimon00 avatar Jun 22 '18 14:06 dimon00

Le 22 juin 2018 à 16:15, dimon00 [email protected] a écrit :

I can connect properly with root from support01 and support02. I tried to configure the same replication manager to another cluster, with two mariadb databases and I obtain the same error. The strange behavior remains "(using password: NO)". It seems replication-manager doesn't provide the password.

Looks good to me,

Long time i did not check 2.0 on MySQL 5.7 but now 2.1 is currently monitoring some 5.7 servers without issues

Could it be that the password itself have some charset that disturb golang splitting string function Unfortunalty requesting server json information via api do not print server password for some security reason but i can send a modify branch that can print what internal password is store per server .

Tx Stéphane

Am I forgetting any configuration option?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/signal18/replication-manager/issues/241#issuecomment-399457024, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1RIAOTZvx5ysfQ7Ia3sB4g5xmTE9d8ks5t_PvlgaJpZM4Uz0XD.

Stéphane Varoqui, VP of Products Phone: +33 695-926-401, skype: svaroqui https://signal18.io/ https://signal18.io/

svaroqui avatar Jun 22 '18 14:06 svaroqui

I have just installed replication-manager-osc_2.1.0-dev-549-g78466f_amd64.deb and I'm getting: OPENED ERR00004 : Database support01:3306 access denied: Error 1045: Access denied for user 'root'@'172.16.0.13' (using password: NO)

the password is correct and doesn't contain any weird unicode chracter. I tried cutting and pasting it on mysql client without issues.

What's bother me is "(using password: NO)". That message comes when the password is not passed at all. This is an example when I put the wrong password in a mysql client: ERROR 1045 (28000): Access denied for user 'root'@'172.16.0.13' (using password: YES)

dimon00 avatar Jun 25 '18 08:06 dimon00

This is very unusual,

Could it be that you get some config.toml overwriting the config you are using somewhere in file system

svaroqui avatar Jun 25 '18 08:06 svaroqui

It doesn't seem the case. I changed root in Proot and the error is now: OPENED ERR00004 : Database support01:3306 access denied: Error 1045: Access denied for user 'Proot'@'172.16.0.13' (using password: NO) so it seems the configuration file is the right one.

dimon00 avatar Jun 25 '18 08:06 dimon00

Not sure why but deleting .replication-manager.key fixed the issue.

dimon00 avatar Jun 25 '18 10:06 dimon00

Humm .replication-manager.key tell the server that the password are encrypted and that they should be decrypted before using ! Hope it's not coming with the packages and it's something that was here previously ?

svaroqui avatar Jun 25 '18 10:06 svaroqui

There is something we should do for printing more verbosity on such feature ! so that it get less complicate to track it down

svaroqui avatar Jun 25 '18 10:06 svaroqui

Probably .replication-manager.key was there from an older replication-manager version. The timestamp was old: -rw------- 1 root root 16 Feb 13 15:00 .replication-manager.key

dimon00 avatar Jun 25 '18 10:06 dimon00