Bug #24577 limited replication for upgrading major versions
Submitted: 24 Nov 2006 16:43 Modified: 3 Oct 2008 14:13
Reporter: Martin Friebe (Gold Quality Contributor) (OCA) Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Replication Severity:S4 (Feature request)
Version:* OS:Any (*)
Assigned to: Assigned Account CPU Architecture:Any
Tags: replication, upgrading

[24 Nov 2006 16:43] Martin Friebe
I understand the technical neccerserity of changing the binlog format, and the problems this causes to allow replication between differnet major versions (like 4.x and 5.x)

But from the point of having to upgrade a live database, this is a problem.

The manpage says: first upgrade your slaves, then the master.

To avoid downtime, this would mean to make the slave be the new master, and the upgrade the old master (which after the upgrade, will be the a slave, but wil not keep uptodate, until it is upgraded)

There is one problem with that. Despite all testing I have already twice run into the situation, were the upgraded mysql (minor version upgrade), caused problems due to a bug. This forced a fall back to the old-master (which was not upgraded, but up-to-date, as it was able to slave the upgraded server)

Not beeing able to slave the upgraded server, means that if a fallback is needed, data is lost (could be several days).

How to repeat:

Suggested fix:
Implement a combatibility mode:

for example, the 5x server rgocnizes a 4.0 connections, and converts to the data-stream to the correct format.

This needs only to deal with the differences in the binlog format. 

There is no need to deal with 5.0 sql statements, that are not understood, by a 4.x server, because in the above scenario, you would continue, with the same set of sql, fully compatible with both versions.

Such an option could be compiled only on demand.

[3 Oct 2008 14:13] Valeriy Kravchuk
Thank you for a reasonable feature request.