Re:MongoDB is actively investigating a security incident
by belter on Saturday December 16, 2023 @05:44PM
(#38668492)
Asked 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-...
[ Parent
| on HN ]
Re:MongoDB is actively investigating a security incident
by insanitybit on Saturday December 16, 2023 @05:49PM
(#38668525)
HN users would rather meme than read.
Re:MongoDB is actively investigating a security incident
by dgellow on Saturday December 16, 2023 @05:59PM
(#38668590)
Isn’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.
Re:MongoDB is actively investigating a security incident
by winrid on Sunday December 17, 2023 @01:40AM
(#38670865)
No. 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.
Re:MongoDB is actively investigating a security incident
by Too on Sunday December 17, 2023 @03:29AM
(#38671276)
It 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.
Re:MongoDB is actively investigating a security incident
by Salgat on Saturday December 16, 2023 @06:06PM
(#38668634)
Yep, 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.
Re:MongoDB is actively investigating a security incident
by belter on Saturday December 16, 2023 @06:17PM
(#38668723)
Er...no....
"Jepsen Disputes MongoDB’s Data Consistency Claims" - https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/
Re:MongoDB is actively investigating a security incident
by sigzero on Saturday December 16, 2023 @08:20PM
(#38669515)
That is 3 years old.
Re:MongoDB is actively investigating a security incident
by Salgat on Saturday December 16, 2023 @06:57PM
(#38669007)
Those 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.
Re:MongoDB is actively investigating a security incident
by fortani on Saturday December 16, 2023 @06:34PM
(#38668842)
Also, "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]