3 ms·
“Your data is safe, because we’ve never written it to disk.”
by 0xblinq 3y ago
“Your data is safe, because we’ve never written it to disk.”
- satvikpendem 3y ago/dev/null is web scale https://youtube.com/watch?v=b2F-DItXtZs https://youtube.com/watch?v=b2F-DItXtZs
- hybridtupel 3y agoLuckily already using https://devnull-as-a-service.com/ https://devnull-as-a-service.com/
- parkerduckworth 3y agoDoes /dev/null support sharding?
- webappguy 3y agoMongo has made huge improvements tbf, but this is funny
- belter 3y agoAsked 11 years ago and still going strong... "To what extent are 'lost data' criticisms still valid of MongoDB?" - https://stackoverflow.com/questions/10560834/to-what-extent-are-lost-data-criticisms-still-valid-of-mongodb https://stackoverflow.com/questions/10560834/to-what-extent-...
- insanitybit 3y agoHN users would rather meme than read.
- dgellow 3y agoIsn’t mongodb data losses commonly referred related to their use of fsync()? From what I vaguely remember they call fsync() every 100ms or so and just assume everything went fine, resulting in potential data loss.
- winrid 3y agoNo. The default write concern as of version 5 is "majority" which "Requests acknowledgment that write operations have been durably committed to the calculated majority of the data-bearing voting members" (as long as writeConcernMajorityJournalDefault is true which is the default). So fsync is called on every write.
- Too 3y agoIt all depends on your writeConcern setting. This option is super critical to understand when deploying an MongoDb. Older versions had defaults that were more optimized for availability than consistency. Even so, not flushing each write is not as bad as it sounds, if you have a 3-node replicaset and your w-parameter is set to majority (default), it means at least 2 servers have the write in memory. It would take both of them crashing at the same time for the unflushed write to be lost. The idea is that MongoDB allows you to choose which corner of the CAP triangle you want, if you chose AP, that’s your decision. The defaults can of course be argued and I believe it’s been gradually moving over to more and more C for each version. Nowadays the journal does get flushed as next comment described.
- Salgat 3y agoYep, Jepsen has not only confirmed but later reconfirmed that MongoDB has for many years been on par with other NoSQL databases when it comes to transaction guarantees and data consistency.
- belter 3y agoEr...no.... "Jepsen Disputes MongoDB’s Data Consistency Claims" - https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/
- fortani 3y agoAlso, "2020-05-26: MongoDB identified a bug in the transaction retry mechanism [2] which they believe was responsible for the anomalies observed in this report; a patch is scheduled for 4.2.8." [1] [1] https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 [2] https://jira.mongodb.org/browse/SERVER-48307 https://jira.mongodb.org/browse/SERVER-48307
- Salgat 3y agoThose same issues exist in most NoSQL databases. If you're going to avoid MongoDB for data safety reasons, you should just go straight to SQL.
- sigzero 3y agoThat is 3 years old.
- deleted 3y ago[deleted]