I studiously followed the documentation on replication and set up
replication. The master and slave are connected by a VPN and the
transaction load is very low (50 trans/hour).

The error log contains
[ERROR] Slave I/O: error connecting to master
'repl (AT) 192 (DOT) 168.10.101:3306

where
change mast to
master_host ='192.168.10.101',
master_user ='repl',
master_password='thePassword',
master_log_file='mysql-bin.000001',
master_log_pos=106;

I do have a user on the master named repl (AT) localhost (DOT)

The vpn is provided via a Netgear firewall/router which has no
limits on outbound initiated connections.

I can ping 192.168.10.101 from the slave server.

Perchance should the log file directive contain the whole path ?
The log is in the standard place /var/log/mysql/mysql-bin.log on
the master.

bill

bill wrote:
Tried to add a repl user which is allowed to connect from the slave too?




--

//Aho

bill <william (AT) TechServSys (DOT) com> wrote:

The user must be created on the master, the user name must be
repl@'slave-ip-address' and it needs the replication slave
privilege.

Besides that replication uses the normal MySQL protocol, so
you can use any MySQL client to test the connection. I.e.

mysql -h 192.168.10.101 -u repl -p

(to be run on the slave, of course)


XL

On Jul 28, 5:00*am, Axel Schwenke <axel.schwe... (AT) gmx (DOT) de> wrote:
XL, thanks, but...
I created a user on the master (which is 192.168.10.101) named
'repl (AT) 192 (DOT) 168.0.200' (the slave ip address) and verified that it in
the master's user file.

but trying (from 192.168.0.200)
mysql -h 192.168.10.101 -u repl -p
gets me:
ERROR 2003 (HY000): Can't connect to MySQL server on
'192.168.10.101' (111)

next suggestion ?

bill <william (AT) TechServSys (DOT) com> wrote:
OK

$perror 111
OS error code 111: Connection refused

The TCP connection was refused. Firewall?
Or maybe a VPN configuration issue?
Looks not like a MySQL problem.


XL

Axel Schwenke wrote:
That merely means the SYN packet got to the socket, and there was
nothing registered to listen for it.

Whilst that behaviour CAN be a firewall, its more likely that mysqld
simply isnt listening at the far end.

Firewalls are more likely to simply send nothing back at all. In which
case you get a timeout, not a connection refused.




It could be. mysqld - at least in my setups - is not configured to
listen on ip ports other that 127.0.0.1 or to remote requests.

On 7/29/2011 4:10 PM, bill wrote:
Assuming the master is running, is the port (default port 3306) open and
not firewalled? Try telnetting to that port from the remote to see if
you can get a connection. You won't be able to do anything - but
whether you get a connection or not is the critical part.

If not, check your MySQL configuration file to ensure networking is
enabled and the port is set properly. In the [mysqld] section look for:

port = (default 3306)
skip-networking = (should NOT be set or set to NO)
bind-address (should NOT be set or should be set to the remote's
ip address).

If these are set properly, try to telnet to port 3306 from the master
itself. If you can do it there, check your firewall - it's probably
blocking connections to the port from outside.

This should cover the most common problems with getting MySQL networking
going. Let us know if it works.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

The Natural Philosopher wrote:
Further research:
=================

e.g. in my my.cnf is:

# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#


That should be changed to 0.0.0.0

That will bind the daemon to any and all interfaces

If that presents a security issue, then use a firewall like IP tables to
reduce access to the desired remote clients.

On Fri, 29 Jul 2011 17:04:12 -0400, Jerry Stuckle
<jstucklex (AT) attglobal (DOT) net> wrote:

Are you sure? I would expect it should be set (in this
use case) to either

0.0.0.0 (=listen on all interfaces)

or

192.168.10.101 (=listen on the interface
the partner tries to connect to).

Best regards,
--
( Kees Nuyt
)
c[_]

Kees Nuyt wrote:
unsetting it has the same effect as setting it to 0.0.0.0