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
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. :-)
- 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! MariaDB.com explicitly claims there will be "no replica lag":
https://mariadb.com/docs/galera-cluster/galera-cluster-quickstart-
guides/mariadb-galera-cluster-guide
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?
With best wishes,
--Kyle
_______________________________________________
discuss mailing list -- [email protected]
To unsubscribe send an email to [email protected]
