Bug #31543 LOAD DATA INFILE replication from 4.1 to 5.1 fails
Submitted: 11 Oct 2007 19:39 Modified: 29 Jan 2008 15:57
Reporter: Dave Bailey Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:5.1.22-rc OS:Any
Assigned to: CPU Architecture:Any
Tags: Contribution, LOAD DATA INFILE, replication

[11 Oct 2007 19:39] Dave Bailey
Replication of a LOAD DATA INFILE statement from a 4.1 master to a 5.1 slave fails, causing replication to stop on the slave.

The problem is in sql/log_event.cc in the function sql_ex_info::init().  The addition of 'ptr' (most likely to get around a compiler warning due to a change in the read_str() prototype) needs to be accompanied by a corresponding update to 'buf' after the read_str() calls update 'ptr'.  Otherwise, the position in the binary log is incorrect.  The patch is a trivial one line change that fixes the problem.

I would guess that this is the same problem that affects bug 31240, but I do not have a 4.0 version of MySQL to test.

How to repeat:
tar zxf read_str_test.tar.gz
cd read_str_test

This will run mysqlbinlog on binary log files generated from 4.1.22, 5.0.44, and 5.1.21.  Each binary log file includes a LOAD DATA INFILE statement.  A mysqlbinlog built from MySQL 5.1.22-rc will fail to process the 4.1.22 binary log, but will successfully process the other two.

Expected output from read_str_test.sh with MySQL 5.1.22-rc:

4.1.22 binlog: not ok
5.0.44 binlog: ok
5.1.21 binlog: ok

Suggested fix:
Apply the patch read_str_patch.diff in the top directory of a 5.1.22-rc source tree via patch -p0 < read_str_patch.diff.  Rebuild, and rerun read_str_test.sh.  Expected output:

4.1.22 binlog: ok
5.0.44 binlog: ok
5.1.21 binlog: ok
[11 Oct 2007 19:40] Dave Bailey
Test case and patch for bug 31543

Attachment: read_str_patch.tar.gz (application/gzip, text), 1.32 KiB.

[20 Oct 2007 1:56] Valeriy Kravchuk
Thank you for a bug report and patch contributed. This report looks like a duplicate of bug #31240. Please, check.
[20 Oct 2007 3:38] Dave Bailey
I've asked Andrei Elkin to try the patch to see if it also fixes the parsing of binlogs from a 4.0 master.
[28 Oct 2007 13:10] Valeriy Kravchuk
Duplicate of bug #31240.
[28 Jan 2008 16:24] [ name withheld ]
Can we get a recheck of this issue? 

It was marked as a duplicate of something that was flagged as a documentation issue where the documentation now states that 4.0 -> 5.1 replication has challenges. 

However given this bug report was against 4.1 and a simple patch fixing the problem was included, could this issue be re-opened and the patch be considered for inclusion into the 5.1 tree?

[29 Jan 2008 7:40] kris dba
I have the same issue, LOAD DATA INFILE statement from a 4.1.22 master to a 5.1.22 slave fails causing the replication slave_sql process to fail.
i had tried with applying the read_str_patch.diff patch and compiling the source 5.1.
no improvement.the statement is causing the slave_sql to fail with Error:0.
when i verified the binlog of (4.1 master) and relaylog of (5.1 slave) files ,the entried for load data file are missing in the relaylog.

when test script is showing no errors.
4.1.22 binlog: ok
5.1.22 binlog: ok

/sql/log_event.cc has the entries of 
	read_str(&ptr, buf_end, (const char **) &line_start, &line_start_len) ||
 	read_str(&ptr, buf_end, (const char **) &escaped,    &escaped_len))
       return 0;
+    buf += ptr-buf;
     opt_flags = *buf++;

Please confirm if this patch fixes for 4.1 version.
[29 Jan 2008 15:57] Dave Bailey
The patch should fix the LOAD DATA INFILE problem.  I just noticed that there is another log_event.cc in the MySQL 5.1 source tree - apparently the file is duplicated in libmysqld/log_event.cc (there is actually a third log_event.cc, but it's a symbolic link from client/log_event.cc -> sql/log_event.cc).  I don't think this matters unless you are using a program that links with libmysqld, but the same modification that was made to sql/log_event.cc should also be made to libmysqld/log_event.cc.

Can you give more information about your setup?  In particular, a binlog from your 4.1.22 master that reproducibly breaks replication on your 5.1.22 slave would be very helpful.  Beyond that, perhaps I can provide a modified patch that also prints some debug information as the read_str() function is executed, etc.  Then we can dig a little deeper.

[1 Feb 2008 7:04] kris dba
I think it's been addressed with the commit 
http://lists.mysql.com/commits/41422 and added to the source tree.

hopefully we can get this resolved in that commit.

Thank you for your quick response.