MongoDB的"数据丢失"批评在多大程度上仍然有效？I'm referring to the following:
1. MongoDB issues writes in unsafe ways by default in order to win benchmarks
如果不发出getLastError()，MongoDB不会等待任何错误
- 在并发环境(连接池等)中，您可以
- 任何数量未知的保存操作都可以放在地板上
2. MongoDB can lose data in many startling ways
以下是我们个人经历的记录丢失的方式:
- 他们只是偶尔消失.原因不明.
- 对损坏数据库的恢复未成功，
- 主设备和从设备之间的复制在oplogs中有gaps个，
- 复制有时会停止，不会出错.班长
...[其他批评]
如果这些批评仍然有效，在一定程度上会令人担忧.本文主要参考v1.6和v1.8，但从那时起，v2已经发布.到目前为止，文章中讨论的缺点是否仍然存在？
Note on Context:
这个问题是在2012年提出的，但至今仍能看到流量和投票.最初的答案是专门反驳一篇在提问时很受欢迎的帖子.自从这个答案被写出来后，情况已经发生了巨大的变化(并将继续发生变化).与2012年相比，MongoDB无疑变得更加耐用和可靠，当时甚至连基本的日志(log)记录都相对较新.我对这个答案投了反对票和 comments ，因为人们觉得我没有针对这个名义上的问题(而不是细节)"丢失数据的批评仍然有效吗？"，给出当前(给定当前值)的一般答案.我试图在下面的更新中澄清，但这个问题基本上没有完美的答案，这取决于你的视角、你的期望是什么、你使用的是什么版本、什么配置、你是否对默认设置感到不安等等.
Original Answer:
MongoDB首席技术官兼联合创始人艾略特·霍洛维茨在这里逐一揭穿了这篇文章:
http://news.ycombinator.com/item?id=3202959
这里还有一个很好的总结:
http://www.betabeat.com/2011/11/10/the-trolls-come-out-for-10gen/
简短的版本是，看起来这基本上是一个吸引注意的人(成功)，没有确凿的证据或佐证.过go 曾发生过真实的事件，随着产品的发展(例如，请参见1.8中日志(log)的介绍)或更具体的错误被发现并修复，这些事件会得到处理.
Disclaimer:我确实为MongoDB(前10gen)工作，我喜欢philnate首先来到这里并独立反驳这一事实——这可能比其他任何东西更能说明该产品:)
Update: August 19th 2013
我最近看到了很多关于这个答案的活动，我认为这与SERVER-10478年发布的bug有关——这肯定是一个边缘 case ，但我仍然建议任何使用大文档切分的人尽快升级到v2.2.6和v2.4.6其中包括此问题的修复.
Update: March 24th 2017
我不再为MongoDB工作，但仍然支持这个答案.考虑到这个答案的得票率持续上升(和下降)，并且收到了很多意见，我想让大家看一下MongoDB自提出这个问题以来所取得的进展.该数据库现在通过了Jepsen项测试，在其构建过程中有integrated the tests项测试，还有很多成熟得多的系统没有通过.任何在2017年仍在鼓吹数据丢失的人都没有真正注意到这一点.
Update: May 24th 2020
鉴于MongoDB现在提供"完整的ACID事务"，Jepsen有re-analyzed MongoDB 4.2.6个，虽然它在某些方面相当技术化，但如果MongoDB中的数据丢失是您担心的问题，我强烈建议您阅读这篇文章(我建议您查看Jepsen测试中使用的任何数据库，您可能会对它们的弱点感到惊讶).该报告总结了默认读写关注点的弱点，讨论了非事务读写的可靠性，以及适当的读写关注点，解决了文档中的缺陷，然后提供测试新ACID事务时遇到的问题(以及相关的读/写问题)的重要细节.
So, can you still lose data with MongoDB?是的，尤其是默认设置，但大多数数据库都是这样.现在的情况比回答这个问题时要好得多，而且这些功能具有更高的可靠性和耐用性，而且它们似乎可以工作(交易除外).我的建议是了解您操作的配置的限制，然后确定您的产品/业务/用例是否可以接受数据丢失风险.