On Wed, 18 Mar 2026 at 00:22, Kyle Kingsbury <[email protected]> wrote: > > Dear Gordan, > > On 3/17/26 15:26, Gordan Bobic via discuss wrote: > > - 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 > > Ah, I actually talk about this in the report too--MariaDB.com actually > says the opposite: https://mariadb.com/docs/galera-cluster/galera- > architecture/introduction-to-galera-architecture#read-and-write-scaling
Technically, you can write anywhere. They never claim that you won't drown in deadlocks and have terrible performance. Yes, it is disingenuous. > > A direct benefit of Galera's multi-master architecture is the > > ability to scale both read and write operations. > In general, I try to figure out whether systems deliver on their > marketing and documentation claims, and help users understand and use > their systems safely. As you've pointed out, that gets a little weird > when there's an overlapping-but-independent open-source community and a > corporate entity. I don't at all mean to imply that the OSS community is > responsible for the company's statements, but I did think it might be of > interest to the readers here. :-) I suspect most of the community is both aware and unimpressed. > > - 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. > > Ah, I also talk about this in the report--you're welcome to read it if > you like! I skimmed it earlier. > MariaDB.com explicitly claims there will be "no replica lag": > https://mariadb.com/docs/galera-cluster/galera-cluster-quickstart- > guides/mariadb-galera-cluster-guide There isn't - to the fastest responding quorum of nodes. For the other 49% of the nodes, all bets are off. AWS similarly claims there is no lag on Aurora, and that is similarly not true. > > 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). > > Ah, that sounds very exciting! Have you written that up anywhere, by chance? I haven't. I probably should. The diet version is: 1) Galera replication subsystem is entirely unaware of GTIDs 2.1) If you write some things into one node with sql_log_bin=0, this will be omitted from the local binlog 2.2) it will replicate over Galera 2.3) It will be written to the other Galera nodes, which will then write it to their binlog - and bump the transaction sequence id You then have GTIDs not being global, and same GTID will contain different transactions in binlogs on different nodes. And that's before we get into similar anomalies that can be introduced with out of order commits as configured using repl.commit_order. The good news is that the default is safe. The bad news is that the moment you change you will probably get GTID discrepancies between the nodes. -- 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]
