MongoDB 的插入安全模式有多安全？
我正在开发一个项目，其中包含一些重要数据。这意味着如果灯或服务器出现故障，我们不会丢失任何数据。我们使用 MongoDB 作为数据库。我想确保插入后我的数据位于数据库中，如果未插入一个元素，则回滚整个批次。我知道 Mongo 背后的理念是我们不需要事务，但是我如何确保我的数据在插入后真正安全地存储而不是发送到某个“黑洞”。
我应该进行搜索吗？
我应该使用一些特定的 mongoDB 命令吗？
即使一台服务器足以满足需求，我是否应该使用分片
速度，顺便说一下，如果光线充足，它不能保证任何东西
最好的解决方案是什么？
I am working on a project which has some important data in it. This means we cannot to lose any of it if the light or server goes down. We are using MongoDB for the database. I'd like to be sure that my data is in the database after the insert and rollback the whole batch if one element was not inserted. I know it is the philosophy behind Mongo that we do not need transactions but how can I make sure that my data is really safely stored after insert rather than sent to some "black hole".
Should I make a search?
Should I use some specific mongoDB commands?
Should I use sharding even if one server is enough for satisfying
the speed and by the way it doesn't guarantee anything if the light
goes down?
What is the best solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最好的选择是使用 Write Concerns - 这些可以让您告诉 MongoDB 一条数据的重要性。最快的写入关注也是最不安全的 - 数据不会刷新到磁盘，直到下一次计划刷新。最安全的方法是在返回之前确认数据已写入多台机器上的磁盘。
您正在寻找的写入问题是 FSYNC_SAFE （至少从 Java 驱动程序) 或 REPLICAS_SAFE 确认您的数据已被复制。
请记住，MongoDB 没有传统意义上的事务 - 您必须手动进行回滚，因为您无法告诉 Mongo 数据库为您执行此操作。
您需要做的另一件事是使用相对较新的
--journal选项（它使用预写日志），或者使用副本集在多台机器上共享数据，以最大限度地提高数据完整性发生碰撞/断电时。分片与其说是一种针对硬件故障的保护，不如说是一种在处理特别大的数据集时共享负载的方法 - 分片不应与副本集混淆，副本集是一种将数据写入多台计算机上的多个磁盘的方法。
因此，如果您的数据足够有价值，您绝对应该使用副本集，甚至可能将从站放置在其他数据中心/可用区/机架/等中，以提供您所需的弹性。
现在/将会有（不记得是否已实现）一种指定副本集中各个节点的优先级的方法，这样，如果主节点宕机，则选出的新主节点是相同数据中的节点如果有这样的机器可用，则中心（即阻止国家另一边的奴隶成为主人，除非它确实是唯一的其他选择）。
Your best bet is to use Write Concerns - these allow you to tell MongoDB how important a piece of data is. The quickest Write Concern is also the least safe - the data is not flushed to disk until the next scheduled flush. The safest will confirm that the data has been written to disk on a number of machines before returning.
The write concern you are looking for is FSYNC_SAFE (at least that is what it is called from the point of view of the Java driver) or REPLICAS_SAFE which confirms that your data has been replicated.
Bear in mind that MongoDB does not have transactions in the traditional sense - your rollback will have to be rolled by hand as you can't tell the Mongo database to do this for you.
The other thing you need to do is either use the relatively new
--journaloption (which uses a Write Ahead Log), or use replica sets to share your data across many machines in order to maximise data integrity in the event of a crash/power loss.Sharding is not so much a protection against hardware failure as a method for sharing the load when dealing with particularly large datasets - sharding shouldn't be confused with replica sets which is a way of writing data to more than one disk on more than one machine.
Therefore, if your data is valuable enough, you should definitely be using replica sets, perhaps even siting slaves in other data centres/availability zones/racks/etc in order to provide the resilience you require.
There is/will be (can't remember offhand whether this has been implemented yet) a way to specify the priority of individual nodes in a replica set such that if the master goes down the new master that is elected is one in the same data centre if such a machine is available (ie to stop a slave on the other side of the country from becoming master unless it really is the only other option).
我从 Google 群组中一个名为 GVP 的人那里收到了非常好的答案。我会引用它（基本上它与里奇的答案相加）：
I received a really nice answer from a person called GVP on google groups. I will quote it(basically it adds up to Rich's answer):