Comments on: Upgrading to MySQL 5.0.40 on RHEL and CentOS http://www.jasonlitka.com/2007/05/05/upgrading-to-mysql-5040-on-rhel-and-centos-4/ The random thoughts, musings, and mindless drivel of Jason Litka Thu, 04 Aug 2016 12:41:10 +0000 hourly 1 By: Jason http://www.jasonlitka.com/2007/05/05/upgrading-to-mysql-5040-on-rhel-and-centos-4/comment-page-1/#comment-4174 Mon, 07 May 2007 15:26:51 +0000 http://www.jasonlitka.com/2007/05/05/upgrading-to-mysql-5040-on-rhel-and-centos-4/#comment-4174 Good info. I didn't run into that with my replicating pairs because all of my servers were already running 5.0.38.

]]>
By: Dmitriy Kropivnitskiy http://www.jasonlitka.com/2007/05/05/upgrading-to-mysql-5040-on-rhel-and-centos-4/comment-page-1/#comment-4169 Mon, 07 May 2007 14:55:30 +0000 http://www.jasonlitka.com/2007/05/05/upgrading-to-mysql-5040-on-rhel-and-centos-4/#comment-4169 There is a problem upgrading a replication setup from versions prior to 5.0.36 to 5.0.40. Seems like there was a bug fix in the replication code that makes the replication deliberately incompatible between the versions. When trying to start replication on servers with incompatible replication you will see the following message

Slave: According to the master's version ('5.0.34-enterprise-gpl-log'), it is probable that master suffers from this bug: http://bugs.mysql.com/bug.php?id=24432 and thus replicating the current binary log event may make the slave's data become different from the master's data. To take no risk, slave refuses to replicate this event and stops. We recommend that all updates be stopped on the master and slave, that the data of both be manually synchronized, that master's binary logs be deleted, that master be upgraded to a version at least equal to '5.0.38'.

The correct way of upgrading a live replication setup to the new version would be to upgrade the slave to 5.0.38, promote it to master, upgrade master to 5.0.40 and reseed it as slave. Promote the slave and upgrade the 5.0.38 system to 5.0.40.

]]>