MySQL Bugs: #32434: Replication doesn't work between 5.2.1-a

Bug #32434	Replication doesn't work between 5.2.1-a_drop6p9-log and 5.1.22-ndb-6.3.6-telco
Submitted:	16 Nov 2007 12:44	Modified:	31 Jul 2008 20:05
Reporter:	Victoria Reznichenko	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	5.1	OS:	Any
Assigned to:	Paul DuBois	CPU Architecture:	Any
Tags:	replication, telco, upgrade, version

Description:
Replication between master 5.2.1-a_drop6p9-log and slave 5.1.22-ndb-6.3.6-telco-debug doesn't work.
Replication is running, no error, CREATE TABLEs replicated fine, but INSERTs/DELETEs/UPDATEs not replicated.

How to repeat:
1. setup replication between 5.2.1-a_drop6p9-log and 5.1.22-ndb-6.3.6-telco-debug
2. create simple ndbcluster test table and insert some data
3. check this table on the slave

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/41364

ChangeSet@1.2678, 2008-01-29 14:47:26+01:00, sven@riska.(none) +1 -0
  BUG#32434: Replication doesn't work between 5.2.1-a_drop6p9-log and 5.1.22-ndb-6.3.6-telco
  Problem: When slave reads format_description_log_event, it checks if the
  master is a version that uses an old binlog format. See also BUG#27779.
  Not all possible server_versions were listed.
  Fix: Check for all server_versions which use the old binlog_format.

This is the same problem as for BUG#27779: In the 5.x.y-a_drop5 clones, the binlog used an old format. More precisely, log events had different id numbers than in other clones. When replicating to a slave with the new format, the slave would try to read the wrong type of event.

In the fix for BUG#27779, the slave checks the master version and permutes the id numbers it receives from the master, if the master is a version known to use the old format. However, in the fix for BUG#27779, the slave did not check for all versions with the old format. It did not recognize 5.2.1-a_drop6p9-log, for instance. In the patch submitted for the present bug, the list of master versions is complete. See the source code comment introduced by the patch for details.

Docs team, please document the following in the manual when
documenting this bug:

On Tue, Feb 12, 2008 at 09:18:06AM +0100, Sven Sandberg wrote:
> A BINLOG statement X is executed as follows:
>
>  (1) If X is an FD event, save it for later use.
>
>  (2) If X is not an FD event, but there is a saved FD event (from a
> previous BINLOG statement executing case (1)), use the saved FD event to
> interpret X, and execute X.
>
>  (3) If X is not an FD event, and there is no saved FD event, print an
> error message and do not execute X.
>
> (Here, FD event means Format_description_log_event or Start_log_event_v3.)
>
> Therefore, the server can read BINLOG statements even for old logs,
> given that they are preceded by an appropriate FD event. I also made it
> so that mysqlbinlog always prints the FD event, even when outside the
> range specified by --start-position=X or --start-date=X (unless the flag
> --base64-output=never is specified). See also BUG#32407.

Pushed into 5.1.24-rc

Pushed into 6.0.5-alpha

I've noted in the 5.1.24/6.0.5 changelogs that this issue was resolved by the fix for Bug#27779, and reassigned this as a documentation bug to Paul per Lars' documentation request, since Paul is already working on documenting the binlog format.

Information about binary log version representation and detection is available here:

http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log

This includes a note about the exception to version-recognition that was instituted to handle the problem noted in this bug report.