Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Incomplete
-
Affects Version/s: 5.5.32
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:OpenVZ Container on Proxmox VE 3.1 (http://www.proxmox.com/)
Description
Setup replication and test that it work.
Create ssh tunnel with stunnel.
Test that the tunnel works with:
mysql -u root -h 10.0.0.1 -P 3310 -p
mysql -u root -h 127.0.0.1 -P 3310 -p
This DO NOT work
mysql -u root -h localhost -P 3310 -p
Change replication:
stop slave;
Change master to master_host='10.0.0.1', master_user='xxxx', master_port=3310 ...;
start slave;
Last IO Error = ... Access denied for user 'xxxx'@'localhost' ...
The problem seems to be that it tries to connect to localhost in stead of the server ip (10.0.0.1).
Localhost is a problem as explained in the article at:
http://pve.proxmox.com/wiki/Stunnel_in_DAB_appliances
Near the following position:
If we use localhost instead of the IP (192.168.5.45) in the above mysql connect string, we will get an error like:
I believe MariaDB it is trying to use a local socket and not 127.0.01 or 10.0.0.1
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
I think this is most likely a problem with the access rights set up in the
database, though there is insufficient information to say for sure.
It seems that the correct IP address is used through the ssh tunnel. If it was
trying to use a different destination address, it would not reach the ssh
tunnel, and then a different error would have occured than "access denied"
(like "connection refused" or something). But double-check that it does not
reach a different server running somewhere else, of course.
Note that on the master side, the connection will be seen as coming from the
same machine (it comes from the ssh daemon running on the master side of the
ssh tunnel). The 'localhost' in the error message might be a reverse-dns
lookup of 127.0.0.1 (what is the value of @@skip_name_resolve ?)
I see that there has been some edit of the actual host IP address and user in
the CHANGE MASTER and error message ('xxxx' and ... and so on). It seems most
likely that this is an incorrect GRANT ? Since the connection will be seen as
comming from 127.0.0.1 (or whatever interface the ssh daemon binds to for the
destination end of the tunnel), the exact user name at that exact local IP
address has to have the correct GRANT to be a slave.
Make sure that the exact same user name and password, connecting from the
exact same host as the slave server over the same ssh tunnel, works correctly.
Replication always uses an IP address to connect to the master, it can not use
a local unix socket for this AFAIK.