WL#3614: Multi-master upgrade

SUMMARY
--------

Make it possible to replicate from MySQL 5.1+ into MySQL 5.1, where 5.1+ denotes
the next version where a change of the binary log format is produced that cannot
be reliably replicated by a 5.1 server. This worklog contains work to do in 5.1+.


WORK
-----

C) Option in MySQL 5.1+ to control which binlog format to produce, so
   that one can tell a master to produce an old format
   (e.g. --binlog-version=5)

D) For every change of binlog format of MySQL 5.1+, add converter that
   produces the old format even in a new server.

E) Change of how we currently work when we start working on 5.1+,
   i.e. no more adding of new events and making headers longer without
   changing global version number for binlog.


LIMITATION
----------

This will probably only work with RBR (row-based) data, 
i.e. no DDL and no SBR (statement-based logging).  


For SBR and DDL, we would have to parse and check every statement, 
and that might be too much code in MySQL 5.2.

For RBR, we can parse the stored records and make sure that the 
record is transformed into the old format.


REFERENCES
----------

See WL#3610: Multi-master upgrade 5.1


USER SCENARIO
-------------

Normal circular replication, e.g. A <-> B.
You want to upgrade one by one, then immediately after you've
upgraded one (say A), it will replicate A (5.2) -> B (5.1).  
Solve this by upgrade in phases:

  1. Upgrade A to 5.2 (but set binlog version = 5.1)
  2. Upgrade B to 5.2 (it can read 5.1 format too)
  3. Change A to produce binlog version 5.2


On Fri, Dec 29, 2006 at 12:40:47PM +0100, Lars Thalmann wrote:
> Hi Jimmy,
> 
> Add in step 7: In Cluster B, execute "SET binlog-version=5" on one
> mysqld.  This will cause that node to create the old binlog version,
> readable by MySQL 5.1 slaves.
> 
> Note that this assumes that both WL#3610 and WL#3614 have been
> implemented.
> 
> Best wishes,
> Lars
> 
> 
> On Mon, Dec 18, 2006 at 10:33:53AM -0600, jguerrero wrote:
> > Hello,
> > 
> > Further our conversation concerning the ability to support "New Master 
> > -> Old Slave" configurations in a worst case scenario where a Cluster 
> > cannot be upgraded and must remain an older version, yet still be able 
> > to support replication.
> > 
> > Below is the scenario Nortel has described. Please advise on what to do 
> > in the event they find themselves in the situation described in #8.
> > 
> > Thanks,
> > 
> > Jimmy
> > 
> > ++++++++++++++++++++++++++++++++++
> > 
> > 1. Replication of Cluster A (Master 5.1) to Cluster B (Slave 5.1)
> > 
> > 2. Stop Cluster B
> > 
> > 3. Upgrade Cluster B to 5.2
> > 
> > 4. Start replication from Cluster A (Master 5.1) to Cluster B  (Slave
> > 5.2)
> > 
> > 5. Wait for Cluster B to 'catch up' with missed changes
> > 
> > 6. Stop replication at Cluster B
> > 
> > 7. Promote Cluster B to Master/Active
> > 
> > *
> > 
> > 8. All changes should allowed to be replicated to Cluster A in case the 
> > upgrade is a failure on Cluster A and must be backed-out, resulting in 
> > Cluster B (Master 5.2) replicating to Cluster A (Slave 5.1).
> > 
> > *
> > 
> > 9. Stop replication at Cluster A
> > 
> > 10. Stop Cluster A
> > 
> > 11. Upgrade Cluster A to 5.2
> > 
> > 12. Start replication on Cluster A
> > 
> > 13. Cluster A (Slave 5.2) and Cluster B (Master 5.2)
>