[MDEV-5116] MariaDB upgrade breaks replication Created: 2013-10-09  Updated: 2016-04-26  Resolved: 2013-11-12

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.33a
Fix Version/s: 5.5.34, 10.0.6

Type: Bug Priority: Major
Reporter: Tim Gokcen Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: packaging, upstream
Environment:

Debian


Issue Links:
Relates
relates to MDEV-5786 mysql_upgrade on galera replicates "a... Closed
relates to MDEV-9996 Do not replicate debian-sys-maint use... Closed

 Description   

The Debian start script for MariaDB, in debian/additions/debian-start and debian/additions/debian-start.inc.sh, runs mysql_upgrade without specifying --skip-write-binlog. As a result, statements contained in scripts/mysql_system_tables_fix.sql will be replicated and fail on the slave.

To be more specific, the ALTER TABLE statements to general_log and slow_log will be replicated, and although mysql_system_tables_fix.sql does disable each of them before running the ALTER TABLEs, these SET statements will not be replicated. When the ALTER TABLE statements are replicated, if the slave system has either log enabled, then replication will break.

I believe debian/additions/debian-start should be modified so that

MYUPGRADE="/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf"

becomes

MYUPGRADE="/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf --skip-write-binlog"



 Comments   
Comment by Tim Gokcen [ 2013-10-09 ]

Note that the original MySQL bug for this seems to be:
http://bugs.mysql.com/bug.php?id=43579

Li-Bing.Song@sun.com first changed mysql_upgrade so that it always disabled the binary log, then revised his patch so that it is instead necessary to specify --skip-write-binlog.

Comment by Elena Stepanova [ 2013-10-09 ]

Probably it concerns RPMs as well.

Comment by Tim Gokcen [ 2013-10-09 ]

Link to related Percona issue 1065841

Comment by Sergei Golubchik [ 2013-11-07 ]

Perhaps we'd better change mysql_upgrade to do --skip-write-binlog by default, and one can specify --write-binlog explicitly, if desired?

Comment by Elena Stepanova [ 2013-11-08 ]

I think it makes sense. It's hard to imagine that somebody, while upgrading a slave, relies on mysql_upgrade actions coming from master through replication, and without that there should be no other reason to replicate mysql_upgrade activity, while the danger of doing so is obvious.

It would be interesting to know why Li-Bing.Song@sun.com changed the decision, but apparently the discussion hides somewhere in private.

Generated at Thu Feb 08 07:01:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.