Markus Mäkelä via developers <developers@lists.mariadb.org> writes:
I think that sounds like a good idea. In step 4, instead of briefly replicating the lost changes and resuming writes on the same node, I think MaxScale could just move all writes to the node with the newest GTID and turn off read-only there, essentially performing a switchover to another node. I think that it might actually already handle this
Agree. I took a look at the original MDEV for AFTER_SYNC, https://jira.mariadb.org/browse/MDEV-162 . It mentions a different motivation for AFTER_SYNC over AFTER_COMMIT, to prevent phantom read. Ie. make sure at least one slave has the transaction before making it visible on the master; this way if any client saw the transaction, the transaction will still be recoverable on a slave if the original master is lost.
However, I'd imagine that this BEFORE_WRITE mode might not be super useful for manually managed replication. You'd have to always switch over to another node when a server crashes. All in all, the
Yes. BEFORE_WRITE would also provide "no phantom reads". But as you say, it means that a swich-over will be required after any master crash, otherwise slaves might be ahead and replication breaks. That seems to be the price for avoiding the expensive two-phase commit between binlog and InnoDB.
I'm looking forward to see more progress updates on this, it all seems very interesting.
Agree. I'll think a bit more on the BEFORE_WRITE idea. - Kristian.