“丢失数据”的批评在多大程度上仍然对 MongoDB 有效？

在最近的版本中从未听说过这些严重的问题。您需要考虑的是 MongoDB 作为后面的关系系统没有十年的开发经验。此外，MongoDB 可能根本没有提供那么多的功能来避免数据丢失。但是即使使用关系系统，您也无法确保永远不会丢失任何数据。 这在很大程度上取决于您的系统配置(因此，使用 Replicationand 手动数据备份应该是相当安全的)。

作为避免早期版本的 Beta bug 或 bug 的一般指导原则，应避免在产品中使用新版本(Debian 在服务器中如此流行是有原因的)。如果 MongoDB (一直)遭遇这样严重的问题，那么用户列表就会变得更小: (http://www.MongoDB.com/community/loyments) rel = “ nofollow noReferrer”https://www.MongoDB.com/community/deployments 此外，我真的不相信这个粘贴信息，为什么这是匿名发表？这个人公司羞于告诉他们用了 mongodb，他们怕10gen 吗？那些 Bug 报告的链接在哪里(或者10gen 从 JIRA 中删除了它们?)

因此，让我们简短地谈谈这些观点:

1. 是的 MongoDB 在火灾和遗忘模式下运行正常。但是您可以使用几个选项来修改这种行为: https://docs.mongodb.com/manual/reference/command/getLastError/#dbcmd.getLastError。因此，仅仅因为 MongoDB 默认使用它，并不意味着您不能根据需要更改它。但是如果你不在你的应用程序中触发和遗忘，你需要更少的性能，因为你正在增加一个往返。

   更新: 从2.6版开始，默认情况下命令 insert、 update、 save、 remove确认写入。

2. 从来没有听说过这样的问题，除了那些导致自己失败的问题... ... 但是这也可能发生在关系系统上。我想这一点只谈到主从复制。副本集非常不稳定。 一些链接从网上其他数据库管理系统造成数据丢失，由于故障以及: http://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss-running-oracle-on.html http://dbaspot.com/oracle-server/430465-parallel-cause-data-lost-another-oracle-bug.html http://bugs.mysql.com/bug.php?id=18014 (这些发布的链接并不支持给定的系统，或者除了表明其他系统也存在可能导致数据丢失的错误之外，还应该暗示其他任何东西。)

3. 是的，实际上在实例级别有锁定，我不认为在分片环境中这是一个全局的，我认为这将在实例级别为每个分片分开，因为没有必要锁定其他实例，因为没有一致性检查需要。即将推出的2.2版本将锁定在 DB 级别，集合级别的票据，也可能存在扩展或文档(https://jira.mongodb.org/browse/SERVER-4328)。但是更深层次的锁定可能会影响 MongoDB 的实际性能，因为锁管理的开销很大。

4. 移动数据块应该不会引起太多问题，因为重新平衡应该从每个节点获取几个数据块，并将它们移动到新的节点。它不应该导致块的乒乓球，也不应该仅仅因为一个或两个块的差异就开始重新平衡。如果选择的碎片密钥不正确，就会出现问题。因此，最终可能会将所有新条目插入到一个节点而不是所有节点。因此，你会更经常地看到重新平衡可能会导致问题，但这不会是由于芒果，而不是你选择糟糕的鲨鱼。

5. 无可奉告

6. 不是100% 确定，但是我认为在1.6中引入的副本集，所以如前所述，永远不要在生产中使用最新版本，除非您可以忍受数据丢失。就像每个新特性一样，存在 bug 的可能性。即使是广泛的测试也不能揭示所有的问题。再一次，总是运行一些手动备份为上帝的缘故，除非你可以生活与数据丢失。

7. 无可奉告。但在现实中，软件可能包含严重的错误。许多游戏也存在这些问题，香蕉软件在其他领域也非常有名。在 MongoDB 时代之前，我不能评论一些具体的东西。

8. 复制会导致这样的问题。根据复制策略的不同，这可能是一个问题，而另一个系统可能更适合。但是，如果没有一个真正强大的编写工作负载，您可能就不会遇到这样的问题。实际上，从一个主服务器进行3个副本轮询更改可能会有问题。您可以通过添加更多的碎片来解决这个问题。

作为一般性的结论: 是的，这些问题可能是存在的，但 MongoDB 在这方面做了很多工作，而且我怀疑其他 DBMS 本身从来没有这样或那样的问题。就拿传统的关系数据库管理系统来说，如果它们能够很好地扩展到 Web 规模，那么就不需要 MongoDB、 HBase 等系统了。你不可能得到一个适合所有需要的系统。因此，你必须承受一个问题带来的负面影响，或者尝试建立一个多元化的组合系统，以获得你所需要的东西。

免责声明: 我不隶属于 MongoDB 或10gen，我只是与 MongoDB 工作，并告诉我的意见。

关于上下文的注释:

This question was asked in 2012, but still sees traffic and votes to this day. The original answer was specifically to refute a particular post that was popular at the time of the question. Things have changed (and continue to change) massively since this answer was written. MongoDB has certainly become far more durable and reliable than it was in 2012 when even things like basic journaling were relatively new. I get downvotes and comments on this answer because people feel I don't address the current (for a given value of current) general answer to the titular question (not the detail): "are lost data criticisms still valid?". I have attempted to clarify in updates below, but there is basically no perfect answer to this question, it depends on your perspective, what your expectations are/were, what version you are using, what configuration, whether you feel upset about the default settings etc.

原答案:

这篇文章被 MongoDB 的首席技术官兼联合创始人艾略特 · 霍洛维茨(Eliot Horowitz)一点一点地揭穿了:

Http://news.ycombinator.com/item?id=3202959

这里还有一个很好的总结:

Http://www.betabeat.com/2011/11/10/the-trolls-come-out-for-10gen/

简而言之，这看起来基本上是某人在(成功地)吸引注意力，没有确凿的证据或确凿的证据。过去曾经发生过真正的事件，这些事件随着产品的发展而得到处理(参见1.8中日志的介绍) ，或者随着更多特定的 bug 被发现和修复。

免责声明: 我确实为 MongoDB (原10gen)工作，并且喜欢 Philnate 先到这里，然后独立地反驳这个事实——这可能比其他任何东西都更能说明产品的问题:)

更新: 2013年8月19日

我最近看到了很多关于这个问题的回答，我认为这和 服务器编号10478中的 bug 有关——这当然是一个极端的情况，但是我仍然建议任何使用大文档分片的人尽快升级到2.2.6和2.4.6版本，其中包括这个问题的修复。

更新: 2017年3月24日

我不再为 MongoDB 工作，但仍然支持这个答案。鉴于这个答案继续得到上升(和下降)投票和收到很多意见，我想指出人们在 这篇文章，这显示了 MongoDB 已经取得的进展，因为这个问题提出。数据库现在通过了 杰普森测试，并且在构建过程中使用了 整合测试，还有许多更加成熟的系统没有通过测试。任何在2017年仍在鼓吹数据丢失的人，实际上都没有注意到这一点。

更新: 2020年5月24日

Jepsen 提供了 重新分析 MongoDB 4.2.6，因为 MongoDB 现在提供了“完整的 ACID 事务”，虽然它在某些方面非常技术化，但如果您担心 MongoDB 中的数据丢失，我强烈建议您阅读这篇文章(我建议检查您使用的 Jepsen 测试的任何数据库，您可能会对它们的弱点感到惊讶)。该报告总结了缺省读写关注点中的弱点，讨论了非事务读写关注点的可靠性，解决了文档中的缺陷，然后提供了测试新 ACID 事务时遇到的问题的重要细节(以及相关的读写关注点)。

那么，MongoDB 还能丢失数据吗？是的，特别是使用默认设置时，但大多数数据库都是这样。现在的情况比回答这个问题的时候要好得多，而且这些功能有更多的可靠性和持久性，而且它们似乎可以工作(事务除外)。我的建议是了解您所操作的配置的局限性，然后确定对于您的产品/业务/用例来说，数据丢失风险是否可以接受。