apt-get upgrade mysql master-to-master replication

I have mysql master-to-master replication configured, and it works great. I have it set up to replicate everything, including the mysql db itself, so that user accounts and permissions are also propagated.

The problem is that in the past, regular apt-get upgrade attempts on mysql will run statements causing errors that halt replication (I believe schema changes on the users table, eg). In the past I've had to manually skip the errant statements in order to get replication to resume. This is both time-consuming and stress-inducing, as I don't want to skip too much or make any other mistakes in the process. Seems like a bad practice in general.

There's a new security update to mysql out (just 5.5.41 -> 5.5.43), and I've been procrastinating applying it to my live servers because of concerns over this. Do you have a recommended practice for performing upgrades like this on master-to-master setups?

I was thinking temporarily inserting a cnf file in conf.d that would skip-write-binlog, perform the upgrade, remove the temp cnf, and then restart clean. Would that be a wise path? In the temp cnf file itself, is there a way to ensure that my applications can't make changes to any data while the binlog is disabled? (while allowing the upgrade script to do what it needs to do)

0 Replies

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct