mongodb Journal

https://blog.youkuaiyun.com/yibing548/article/details/50844310

1.之前用mongodb数据的时候，有时候会有丢失，一开始考虑到是mongodb的安全性能不行吗，在网上看了一些资料，做了一些解释：

MongoDB确实在其发展的过程中，有一些数据持久化的问题没有处理好，特别是一些默认值的选定上。大部分用户会拿来就用，直到遇到问题之后才发现他们应该在开始的时候做一些必要的配置。但是，所有这些已经被发现的问题也好，默认设置也好，已经在 MongoDB 2.6以后得到了妥善的解决。我可以负责任地告诉你，你看到的数据安全问题，基本上都是2.4或者之前版本的问题或者是用户配置的问题。接下来我们来仔细分析一下MongoDB的数据安全机制，通过这个分析来更好地理解为什么有丢数据问题的说法，以及如何来正确的配置MongoDB来保证数据的安全。
MongoDB的数据安全包括以下几个概念：
恢复日志（Journal）
写关注（Write Concern)
恢复日志
在MySQL， PostgreSQL，Oracle等关系型数据库里都有一个Write Ahead Log（Redo Log）的机制用来解决因为系统掉电或者崩溃时导致内存数据丢失问题。MongoDB 的journal就是实现这个目的的一种WAL日志。在MongoDB 2.0之前，Journal没有被支持或者不是一个默认开的选项。所以当你进行写入操作时。在没有Journal的情况下，MongoDB是这样保存数据的：

简单来说，数据在写入内存之后即刻返回给应用程序。而数据刷盘动作则在后台由操作系统来进行。MongoDB会每隔60秒强制把数据刷到磁盘上。那么大家可以想象得到，如果这个时候发生了系统崩溃或者掉电，那么未刷盘的数据就会彻底丢失了。如果大家看到的博客是2011年左右的，那基本上是碰到了这种情况。
自从2.0开始，MongoDB已经把Journal日志设为默认开启。

在上图的情况下，MongoDB会先把数据更新写入到Journal Buffer里面然后再更新内存数据，然后再返回给应用端。Journal会以100ms的间隔批量刷到盘上。这样的情况下，即使出现断电数据尚未保存到文件，由于有Journal文件的存在，MongoDB会自动根据Journal里面的操作历史记录来对数据文件重新进行追加。
有细心的同学可能注意到，Journal文件是100ms 刷盘一次。那么要是系统掉电正好发生在上一次刷journal的50ms之后呢？这个时候，我们就可以来看一下MongoDB持久化的下一个概念了：写关注