Jesse wrote:
A couple of thoughts. Do you have slaves with duplicated server IDs?
That seems most likely to me.
Nope. I've got one master, and one slave. The server ID is set to 1 on
the master, and it's set to 2 on the slave.
If that's not it, is the max_packet_size mismatched on the master and
slave?
I don't find max_packet_size in the My.ini file on either server, and
when I do a show variables on both, max_packet_size is not listed on
either of them.
Whoops, I got the name wrong:
mysql> show variables like '%packet%';
+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 16776192 |
+--------------------+----------+
1 row in set (0.00 sec)
Can you connect to the master and view the binary log event at the
position it's trying to read, with SHOW BINLOG EVENTS?
That's where things get squirley. The position it reports always seems
to be incorrect. For instance, when this was happening previously, I
know that it had made it to a later position in the log. However, when
replication stopped, it reported a position earlier in the file. This
one, for instance, reports position 195. the Nearest one I have starts
at position 98 and ends at position 1032. This is an update statement.
If my logic is not flawed, I'm thinking that I should follow starting at
98 out until I get to position 195. When I do that, I come to:
RegOpenDate = '2007-11-05 00:00:00', which is part of the udpate
statement. This appears normal to me. I've checked, and it is a
DateTime field, and it is exactly the same on both the master and slave.
That's strange. I'm not sure I understand what's happening there.
Check the packet size and let's come back to this if that's not the problem.
Can you use the mysqlbinlog tool to verify that the binary log isn't
corrupted on the master?
I've dumped the log to a text file. What, exactly, should I look for?
The only suspicious thing I see is the first entry:
# at 4
#071020 15:45:34 server id 1 end_log_pos 98 Start: binlog v 4,
server v 5.0.17-nt-log created 071020 15:45:34 at startup
# Warning: this binlog was not closed properly. Most probably mysqld
crashed writing it.
ROLLBACK;
That's fine --it just means the log is still open. (It is still open,
right?) If you run this on a log other than the newest one, you
shouldn't see that.
If there was corruption, the mysqlbinlog tool would have crashed.
Baron
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
