MySQL Bugs: #50876: Upgrading in a replicated environment problems and known issues

Bug #50876	Upgrading in a replicated environment problems and known issues
Submitted:	3 Feb 2010 10:55	Modified:	24 Jul 2017 8:58
Reporter:	Roger David Nay	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.0+	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
There should be more information on the upgrading pages referring to the fact that mysql_upgrade runs during the upgrade and that that can cause problems in a replicated set up where different versions may be running. Turning off binary logging for the server may not be an option in a production environment, and currently there is no option to just turn off the binary logging just for the process doing the mysql_upgrade (there are feature requests for that).
http://bugs.mysql.com/bug.php?id=46638

Think of 5.0->5.0 latest update and you are running a 5.1 server in replication (which should be possible). You can see errors like these on the 5.1 slave during an upgrade. Looks like changes in the privilege tables in 5.0 that don't work with 5.1.

091215 8:27:33 [Note] Slave: connected to master 'mmmxxx@my4-o-vip:3306',replication resumed in log 'binlog.001057' at position 239124333
091215 8:27:33 [ERROR] Slave SQL: Error 'Column count doesn't match value count at row 1' on query. Default database: 'mysql'. Query: 'INSERT INTO tmp_db VALUES ('%','test','','Y','Y','
Y','Y','Y','Y','N','Y','Y','Y','Y','Y','Y','Y','Y','N','N')', Error_code: 1136
091215 8:27:33 [Warning] Slave: Column count doesn't match value count at row 1 Error_code: 1136

mysql_install_db is run as well, causing all sorts of binary log problems. There is a bug but nothing in the docs that I can find that warns about this behaviour.
http://bugs.mysql.com/bug.php?id=43398

How to repeat:
N/A

Suggested fix:
How about a warning somewhere about upgrades with replication/binary logs, plus there should be known issues added to the documentation with pointers to the bugs/feature_requests.

Also look at other comments I made on: http://blog.wl0.org/2010/01/further-thoughts-on-mysql-upgrades/

This problem appears to be solved with --skip-write-binlog in 5.1 (http://bugs.mysql.com/bug.php?id=43579), and it's use  should be highlighted in the docs.
http://dev.mysql.com/doc/refman/5.1/en/replication-upgrade.html

Still a problem in 5.0 though and it would be great to have the use case where this may get triggered in the documentation somewhere. Like in the upgrade notes with mention of special instructions when running on a master, or a master which itself is a slave.
http://dev.mysql.com/doc/refman/5.0/en/replication-upgrade.html

Discussed with Paul--I'll take this one.

Posted by developer:
 
I've been tasked with checking and closing out some of our old documentation bugs that were in the wrong pile. The --skip-write-binlog behavior is now the default since MySQL 5.6.7, and there is a warning against the use of --write-binlog, so users should not encounter these issues anymore. So I'll close off the bug. Thanks for the original report!