MySQL Bugs: #31543: LOAD DATA INFILE replication from 4.1 to 5.1 fails

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:	None
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

Description:
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
./read_str_test.sh

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

Test case and patch for bug 31543

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

Thank you for a bug report and patch contributed. This report looks like a duplicate of bug #31240. Please, check.

I've asked Andrei Elkin to try the patch to see if it also fixes the parsing of binlogs from a 4.0 master.

Duplicate of bug #31240.

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?

Thanks

Hi,
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.
./read_str_test.sh
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++;
   }
   else

Please confirm if this patch fixes for 4.1 version.

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.

-dave

Hi,
I think it's been addressed with the commit 
http://lists.mysql.com/commits/41424
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.