Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's been a long way from the "Call Me Maybe: MongoDB" post from years back. Aphyr/Kyle took them to task in so many ways for playing fast and loose with data integrity, and rightly so. MongoDB could have said, "that guy's full of BS, ignore him," but instead they did the smart thing and paid Kyle to help solve the problem.

n.b. I can't find the original "Call Me Maybe" post, but this later one [1] is similar.

[1]: https://aphyr.com/posts/284-jepsen-mongodb




>paid Kyle to help solve the problem.

Any more information on this? How did he "solve" the problem?

Edit: straight from the horse's mouth [0]

[0] https://news.ycombinator.com/user?id=aphyr


I didn't say Kyle solved Mongo's problems, but that he helped solve the problems. He identified numerous data loss issues, explained them in great detail, and even has tooling to readily reproduce the data loss events. That's a massive contribution in my mind.

By comparison, it's the difference between a bug report that says "you lost my data, you suck!" and "I've identified [x] ways your product can lose data and here's exactly how to reproduce each one."


Whoops, wrong link. Here's the correct one: https://news.ycombinator.com/item?id=13591048

It seems the problems were indeed "solved" and not solved.


I'm not exactly sure what you're trying to say, but perhaps I can help provide context:

In 2013, I performed an unpaid analysis, in my nights and weekends, of MongoDB. I found a bug leading to the loss of acknowledged writes with majority write concern. Mongo fixed this bug within a few weeks.

In 2015, I performed a followup test as a part of my work at Stripe. I confirmed dirty reads (which were already documented, though perhaps not well-appreciated), and discovered stale reads (which ran counter to MongoDB's documentation). MongoDB wasn't enthusiastic about that report initially, but got things sorted out and started work on adding majority and linearizable read concerns. I found that writes appeared linearizable.

In spring and summer of 2016, MongoDB paid me to help expand the Jepsen tests and hook them up to their internal CI system, so they could use the Jepsen tests to help verify their ongoing work towards linearizable reads. I privately confirmed that MongoDB still failed to prevent stale reads, but the dirty-read failures I'd seen in 2015 appeared to be prevented by majority reads.

In fall 2016, MongoDB announced they were almost ready to release 3.4.0 with support for linearizable reads, and paid me to perform a full analysis so they could be more confident in the results. It passed the linearizability tests I had initially written in 2015, but I offered to expand the tests to be more aggressive. Our collaboration resulted in the present analysis, uncovering design flaws in v0 and implementation bugs in v1. MongoDB worked to develop patches prior to 3.4.0's release, and that's why it passes now. :)


Hi Kyle. I'm not trying to put words in anybody's mouth (though perhaps my tone suggested I was -- sorry!)

This is exactly the info I was looking for. Thank you.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: