Restoring a MySQL database to a failed master
Slow ALTER in Master-Master

In Master-Master, each server is acting both as a Master and a Slave to the other server.

STOP SLAVE -- When you later do START SLAVE, the stuff that was performed on the Master will be applied to the Slave.  If you did, say, a big ALTER on a big table, that ALTER will run, taking a long time.  This is probably the "downtime" you are worried about?

The alternative is to do the lengthy process twice.


Stop client usage of B.
On B, turn off writing to the binlog
On B, do the ALTER(s), etc.
On B, turn on writing to the binlog
Wait for replication to catch up.  (It was probably blocked by the ALTER.)
Flip -- that is stop talking to A and start talking to B.
On A, (steps 2,3,4,5) binlog off, ALTER, binlog on, catch up


Alternatives

In Galera, this is "RSU" (as opposed to "TOI").

See also pt-online-schema-change -- this tool (percona.com) allows for doing time consuming maintenance on a table with essentially no downtime.

5.7 can now do many ALTERs with ALGORITHM=INPLACE, hence little or no downtime.

Putting the burden on the Code

Keep in mind that some code changes involve schema changes.  Sometimes they can be done in a "backward compatible" manner, thereby obviating stuff like this.

In the extreme, you might need to double up the code.  That is, have it capable of handing the old schema and the new schema at the same time.  This complicates the code, but eliminates coordination problems between code and schema.  (The code should eventually be cleaned up to throw out the 'old' variant.)

That last way becomes especially important when you have Sharding, multiple clients, or other cases of "lots of servers to update".