On Tue, 17 Mar 2026 at 21:38, Kyle Kingsbury <[email protected]> wrote: > > On 3/17/26 14:25, Gordan Bobic wrote: > > If you lose/partition majority of nodes, then yes, you can definitely > > lose transactions. Galera never guaranteed that all nodes will be in > > sync before acknowledging, only the majority of nodes, and only if the > > minority of nodes fail / partition simultaneously. > > Er, as the report notes, MariaDB goes to significant length to say the > opposite. Take, for example, > https://mariadb.com/docs/galera-cluster/galera-cluster-quickstart-guides/mariadb-galera-cluster-replication-guide
There seems to be some marketing over-promising on that page from mariadb.com (not to be confused with mariadb.org, where this list is): - In reality you would never have more than one writable node unless you have completely independent and separate data sets because otherwise you will drown in deadlocks - I'm pretty sure this part is false: Synchronous Replication (Virtual): Data is consistent across all nodes at all times, preventing data loss upon node failures. It isn't going to be synchronous across all nodes, only the quorum of nodes. > "Unlike traditional asynchronous or semi-synchronous replication, Galera > ensures that transactions are committed on all nodes (or fail on all) > before the client receives a success confirmation. This mechanism > eliminates data loss and minimizes replica lag, making all nodes active > and capable of handling read and write operations." Yup, I'm pretty sure that is not true. To summarise: - If you simultaneously lose the majority of nodes (e.g. 2 out of 3), you can lose transactions if the surviving node is the slow one. - You are not guaranteed that upon commit acknowledgement the data was written to all nodes, only the quorum of nodes. - Your reads are similarly not guaranteed to not be stale - the slowest nodes can return stale data because they haven't yet absorbed the write acknowledged by the quorum. You can mitigate this at the cost of redundancy, e.g. by running 2 nodes + a quorum daemon. The quorum daemon is there for the purpose of maintain quorum in the number of nodes, but will never acknowledge writes. That means that if you lose 1 node, the only surviving node will not go read only and will be fully up to date. But this costs you one node's worth of redundancy. > Obviously the docs are lying about this, haha, but still! More > pragmatically, this is kind of table stakes for any system that wants to > claim SI. The first-committer-wins principle is a consensus problem, and > consensus systems famously have to be careful about fsyncing to disk, > writing to quorums, and carefully picking leaders to prevent this kind > of scenario. See my earlier point - in reality you are gaining nothing by pain from having more than one galera node writable. In reality, Galera is a somewhat niche solution that only works well for a relatively narrow set of cases that don't fully live up to the marketing material. It has a place, but there are significant compromises involved. For what it's worth, the number of assignments I worked on that involved removing Galera and migrating to asynchronous replication outnumbers at least 10:1 the ones of moving to Galera. And that is before we start discussing things like GTID inconsistencies that will eventually come to bite you if you expect to have binlog based asynchronous replication out of Galera cluster nodes, and expect to be able to use GTID to switch the replication source (it won't work, but you probably won't realise before you corrupt the state of the downstream slaves). -- Gordan Bobic Database Specialist, Shattered Silicon Ltd. https://shatteredsilicon.net Follow us: LinkedIn: https://www.linkedin.com/company/shatteredsilicon X: https://x.com/ssiliconbg _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
