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)