MySQL Bugs: #49474: Replication from 4.0 to 5.1 broken

Bug #49474	Replication from 4.0 to 5.1 broken
Submitted:	5 Dec 2009 11:53	Modified:	6 Dec 2009 8:30
Reporter:	Domas Mituzas	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.1.42	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	regression

Description:
Currently 5.1 does way too many sanity checks that will fail on 4.0 masters (due to nonexisting variables), so replication from 4.0 to 5.1 is broken. 

How to repeat:
Replicate from 4.0 or older to 5.1.42 or newer.

There is no workaround. 

Suggested fix:
Raise warnings, don't just blindly break replication.

My current fix is at:
http://bazaar.launchpad.net/%7Ewikimedia/sakila-server/mysql-5.1-wm/revision/3191

Also see:
http://mituzas.lt/2009/12/05/on-replication-compatibility/

There're two cases when people are replicating from 4.0 to 5.1:

a) Ones that know what they're doing, so the check is meaningless.
b) Ones that have no idea, and no checks will help them.

I'm so unhappy about comment on #48369, that I won't consider this one duplicate for a while :)

Does  bug #48369 look better for you now?

A bit better. I'd still classify it as a regression, as it broke working functionality in 5.1 post-GA.

Agreed, seems to fail the regression requirements within a release. Also the code referenced in bug #48369 that is supposed to be there to be compatible with 4.x isn't compatible with 4.x, so it should have failed code review.

If you'd like to argue that we should not deprecate 4.0 to 5.5 replication and say that we expect it to be completely broken, now is a time to do it. For 5.1 we still have a graceful degradation expectation that applies to 4.0, in part because 4.0 was still in extended support while 5.1 was heading to GA, so coding needed to support it. Much 5.5 coding was after 4.0 extended support ended, so harder argument to make there. 4.1 extended support ends in three weeks and then new versions beyond 5.5 may have no 4.1 graceful degradation requirement. Too much of 5.5 has been written with supported 4.1 for me to think that dropping 4.1 backwards compatibility in 5.5 is a good idea - too little gain.

Note that the last paragraph is not official policy. It's just a description of one way in which developers might be expected to write code to support all supported versions at the time they are writing the code.

Now, when  bug #48369 is re-opened and escalated, I think this one can be declared as a duplicate.