On Tue, 17 Mar 2026 at 21:15, Kyle Kingsbury <[email protected]> wrote: > > On 3/17/26 14:03, Gordan Bobic via discuss wrote: > > I think this might depend on which node(s) you lose If you have 2 fast > > nodes and one far/slow node, you will commit acknowledgement back once > > the first node acknowledges the write. So if you lose two near/fast > > nodes, your 3rd node could actually be behind and you will lose > > transactions. > > Are you saying that you observed transaction loss in case of single node > > failure? > > I actually haven't dug that deeply into it--this has been a free-time > project and I've had to switch gears back to client work recently. That > particular data-loss bug was also harder to trigger, so I only have a > few exemplars to go on, and both involved long histories of faults prior > to the data-loss event. I can say that both kills (including more than > one node at once) and partitions are sufficient, but I'm not totally > sure what's *necessary*.
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. > On the P4 side, it looks like Galera allows Lost Update even when there > are no faults injected--that's just normal cluster behavior. That is more concerning, but are you sure this was tested from a clean starting point? If the data was not 100% in sync to begin with, then I can see a few possibility how this could manifest as follow-up damage (e.g. due to foreign key constraints) -- 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]
