11 messages in com.mysql.lists.bugsRe: Diagnostic route for this replica...
FromSent OnAttachments
Whit Blauvelt13 Jun 2001 12:49 
Sasha Pachev14 Jun 2001 10:01 
Whit Blauvelt14 Jun 2001 11:31 
Sasha Pachev14 Jun 2001 12:19 
Whit Blauvelt24 Jun 2001 22:42 
Michael Widenius25 Jun 2001 00:28 
Whit Blauvelt25 Jun 2001 17:55 
Sasha Pachev25 Jun 2001 19:37 
Whit Blauvelt26 Jun 2001 10:36 
Whit Blauvelt26 Jun 2001 11:05 
Sasha Pachev26 Jun 2001 11:20.pub
Subject:Re: Diagnostic route for this replication problem?
From:Whit Blauvelt (wh@transpect.com)
Date:06/24/2001 10:42:08 PM
List:com.mysql.lists.bugs

Sasha,

Thanks much for the advice. Unfortunately, still having trouble - but making progress. Here's what I've learned (note: stunnel is a utility for port forwarding using ssl, see www.stunnel.org):

1. localhost (as you suggested) does not work in current MySQL as the designation of where to connect to an stunnel-forwarded port (it does try to connect to the slave instead). It did work in 2.23.25 and .27, for whatever quirky reason.

2. To connect with mysqld to the forwarded port in 2.23.38, it is necessary to have File_priv in the mysql 'user' table set to Y. In 2.23.27 it was enough to have privileges cleared in the mysql 'db' table for that database. (The current mysql client connects without this being set, which makes sense. The Replication HOWTO does have a GRANT step that accomplishes this for new setups, but doesn't mention that it's a new requirement for existing setups.)

3. With both these changes (and, yes, I am quite sure I'm using the same my.cnf all along, except now for having gone from 'localhost' to the machine name - it's the only my.cnf on the system), I can now do a successful LOAD TABLE tblname FROM MASTER.

4. However, replication still fails with:

010624 23:48:31 Slave: Failed reading log event, reconnecting to retry, log
'FIRST' position 4 010624 23:48:31 Slave: reconnected to master
'ft@china.patternbook.com:3307',replication resumed in log 'FIRST' at position
4 010624 23:48:31 Error reading packet from server: Access denied for user:
'ftp@localhost' (Using password: YES) (read_errno 0,server_errno=1045)

5. That is after a successful sequence of:

slave> slave stop; slave> reset slave; slave> drop table ftp; master> reset master; slave> load table ftp from master; slave> slave start;

Okay, so what do we have?

1. The mysql command-line client can connect through the stunnel-forwarded port.

2. The slave mysqld can load the table from the master through the stunnel-forwarded port.

3. What is the replication mini-client doing differently from (1) and especially (2) just above, so that access is denied for it? I can't see the sense in having a stricter standard for ongoing replication than for loading a whole table from the master, but effectively there is one, and I haven't worked around it yet.

Now, "china.patternbook.com:3307" is of course a port forwarded to the other machine's mysqld master at 3306. Is the replication mini-client (but not mysqld when loading a table from the master) sending this machine name through to the remote master, that's then saying "That's not me"?

Also, what is the reference to "log 'FIRST'" about. The log name is clearly specified in my.cnf on the master, as it always has been, with "log-bin = ftp" - and indeed that's the log file. There's no filename "FIRST*" on either system. Also, why "position 4"? I see "4" on the second line of master.info on the slave. I "reset slave", delete master.info and restart the slave server, and there is the spurious "4" again in both the new master.info and the err log. Does "reset slave" not work? Is there some other file on the slave I need to remove or alter to really clear things?

Thanks, Whit

On Thu, Jun 14, 2001 at 01:20:08PM -0600, Sasha Pachev wrote:

Note that the replication code has a mini-client, which has adapted a lot of code from libmysqlclient. The mini-client inside the server will connect through a local socket to whatever is running on that socket ( most likely, the slave server itself) if you have master-host=localhost line in my.cnf. The error message you are getting supports this hypothesis.