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.
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).
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.
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.
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]
https://youtube.com/watch?v=b2F-DItXtZs