[fluxcorethread]

I don't understand why, if you are creating a distributed db, that you don't at least try using eg. aphyrs jepsen library (1).

The story seems to repeat itself for distributed database: Documentation looks more like advertisement. Promises a lot but contains multiple errors, and failures that can corrupt the data. It's great that jepsen doing the work they do!

1. https://github.com/jepsen-io/jepsen

[aphyr]

I was kind of surprised by this one--I know the MariaDB folks and have worked with some of them before. They made significant changes to fix the Repeatable Read issues we found in the last report, so I know the team cares about safety.

There wasn't much reaction on the mailing list to the lost-write problem back in January, or to the Jira tickets. I actually tried calling MariaDB on the phone to see if they'd like to talk about it, but no dice. I assume they're probably busy with other projects at the moment (hi, it's me too) and haven't had a chance to switch gears.

[jwr]

It also surprises me. Every company that creates a distributed database should pay for Jepsen testing. First, it is a great chance to improve their software, and second, if there are problems, they will eventually come to light anyway.

[Sesse__]

> if there are problems, they will eventually come to light anyway

Not necessarily; before Kyle started this one-man crusade against data loss, database vendors would claim generally whatever and it would go unchallenged for decades. (You might get the occasional bug report, which you could handwave away as “hardware” or “you're holding it wrong” or just ignore it.) Now you're _slightly_ less likely to succeed, but only as long as e.g. your product is sufficiently uninteresting or hard enough to set up that he doesn't test it. :-)