I wrote about a 4.0 to 5.0 upgrade at http://mysqlha.blogspot.com/2008/02/upgrading-from-mysql-40-to-mysql-50.html. We were able to avoid data drift, but that took some work.

As in most MySQL issues, if you have really high expectations/demands from it, then you need to bring in the consultants or hire them full time.

It appears that the order FK constraints are returned is nondeterminstic, so your comparison will have to take this into account; I wrote a perl script to (hackily) parse out the constraints, sort them, and append at the end. This means I can still see if they are wrong on the slave, but won’t notice if they are in a different order.

Finally, if you thought you could run a different version on a slave, forget it. When you run a different MySQL version (even minor), all bets are off, especially in statement-based mode.

We found that migrating from 4.1.x to 4.1.y that

* Silent column specification changes happen, or don’t, which makes the schema check fail
* FLOAT rounds differently.

Of course these are just the differences we happened to hit.

You can pretty much forget replicating from 4.x to 5.x and have the data be the same on master & slave – if it even works at all. LOAD DATA crashed the slave in our tests.

And of course, you can forget data being the same if you use MyISAM, or if your master crashes ever. However, a system such as that described above will detect problems and allow them to be fixed operationally.

Hopefully in production your master doesn’t crash too often.