Some notes on Galera that affect MediaWiki (some bits from https://mariadb.com/kb/en/mariadb/mariadb-galera-cluster-known-limitations/):

• GET_LOCK() is used in a few places. In Galera, it is only local to the mariadb server the client talks to, so something would have to change there.
• When we write to multiple DBs, it's a best-effort (BEGIN, BEGIN)...(COMMIT,COMMIT) in commitMasterChanges(). This works well with S2PL (as innodb and sqlite use) as rollbacks are very rare (e.g. connection loss after first COMMIT or internal commit failure on a node). Galera introduces optimistic transactions failures (e.g. when conflicting changes happen on other nodes and are first in the Group Broadcast queue). This might increase the chances of (COMMIT, ROLLBACK). Some of this can probably be improved by making sure centralauth updates are committed first or the some other secondary updates use the jobqueue (flowing from the main wiki DB to the foreign one, for example). I could add logging code to see what multi-db transaction we are actually doing to see what can be made more robust. This is partly a pre-existing problem for MediaWiki since COMMIT can certainly fail and for postgres (which we claim to support) using SERIALIZABLE or REPEATABLE-READ (which is really SNAPSHOT, having first-committer-wins).
• LOCK IN SHARE MODE has some bugs (https://github.com/codership/galera/issues/336#issuecomment-136635018) (mentioned at https://aphyr.com/posts/327-call-me-maybe-mariadb-galera-cluster)
• Any tables without PKs will block this probably T17441: Some tables lack unique or primary keys, may allow confusing duplicate data

@aaron Forget about that. Galera multimaster is not an option. A single master, that happens to have a "galera" slave, is (maybe).

In other words, slave1 is a master candidate, that by using GTIDs or cloning the binary logs (binlog server) we can continue replication automatically. But the idea is it being a passive master. Hopefuly that will give us automatic master failover.

Galera is only there to provide us more synchronization than regular replication so no transactions are lost, but I am not too fan of it given the large transactions that we have. So, maybe try it as active-passive, but I have already discarded it as a multi-master setup.

All other connections are regular slaves/semisync slaves. Maybe even the master candidate.

If the master is still passive, I assume that means other config changes are still need to use it when the active one fails, so the title of this task seems a bit strongly worded :)

That's partly what confused me and made me thing this involved galera, though OTOH galera isn't the only way to avoid a SPOF (the other option being some proxy and auto-switch logic).