l MMAPv1默认每100ms就会把数据写入到硬盘中，如果日志系统部署在分立的设备中，则默认是30ms。除了可以保证持久性，日志功能还可以防止系统在未知宕机的情况下的数据腐败。MMAPv1默认是开启日志功能的。生产环境中都应该开启日志功能。
WiredTiger和MMAPv1共有的一个特性是压缩功能，以减少存储容量。
为了额外的保证，管理员可以配置日志写关注，这样MongoDB只会在数据写入日志后才确认。
数据冗余MongoDB使用本地复制集会维护多个数据副本。建议用户使用复制集防止数据系统掉线。MongoDB中的复制集故障转移是全自动的，不需要人工进行干预。
复制集由多个复制集成员组成。任何时候，一个成员充当主节点，其他成员充当此节点。如果主节点由于各种原因（比如主机宕机）出现故障，其中的一个次节点会自动被选举为主节点并接受所有的写入操作。
选举的过程是由复杂的算法控制的，保证所有次节点中最合适的成员被推举为主节点以较少不必要的故障风险。选举算法包含很多变量，包括分析历史数据确认哪些复制集成员从主节点哪里过去到最新的数据，心跳以及连接状态，还有其他用户定义的优先级。例如，管理员可以设置，次数据中心的副职及成员只有在主数据中心的主节点故障后才能被推举为主节点的候选人。一旦新的主节点被选举出来，其余的次节点就会自动的从新的主节点同步数据。如果之前的主节点重新上线了，会发现自己已经不再是主节点，并充当次节点的角色。
MongoDB复制集中的成员是可配置的，复制集成员越多，就可以为系统提供越大的保障。一个节点宕机，系统还是会正常运行。遇到故障后，DBA和系统管理员应该及时恢复或者替换有故障的设备以减轻系统暂时的弹性压力。
多数据中心复制集MongoDB副本集允许在数据中心内部和跨数据中心进行灵活的部署设计，从而解决服务器，机架和区域级别的故障。如果MongoDB复制集是跨多个机房部署的，则遇到自然或人为灾难，单个机房的故障可以在不宕机的情况下得到解决。
写关注MongoDB中，当把数据写入数据库中时，管理员可以使用写关注这个功能保证数据的持久性，并可以指定不同的级别。下面介绍的这几个选项可以在每个链接、每个数据库、每个集合甚至每个操作中进行配置。
l Write Acknowledged:这是写关注默认的配置。Mongo会去确认写操作的执行结果，并把网络、主键重复、文档重复以及其他异常反馈给客户端。
l Journal Acknowledged：只有数据被写入到主节点的日志后，mongod才会确认写操作的执行结果。这个配置能保证mongod在意外宕机的情况下写操作仍然可以写入到磁盘中。
l Replica Acknowledged：也可以等到数据同步到其他复制集成员后再确认，并且支持指定到具体那几个成员中。这就可以保证写操作写入到此节点的日志中。由于复制集成员可以在一个数据中心跨机架部署，也可以跨机房部署，所以把写操作执行到其他复制集成员中可以提供极大的耐用性。
l Majority：这种写关注的配置会等数据应用到复制集中的大多数成员中后，才确认。也能保证数据写入这些复制集成员的日志中。
l Data Center Awareness：使用标签集，可以创建复杂的策略保证数据可以写入具体的复制集组合中。比如，你可以创建这样一条策略，要求数据至少写入两个洲的三个数据中心才行，或者一个数据中心分布在不同机架的两个服务器中。详情见Data Center Awareness。
复制集读选项默认情况下，读取是从主节点读取的，这样能保证一致性。如果系统读取量比较大，建议使用MongoDB的自动分片功能，把读取操作分散到多个主节点上。
有些应用的复制集可以提高MongoDB系统的容错性。比如，分析系统以及商务智能系统这类的应用就可以在次节点上进行查询操作，这样就可以较少主节点上的负载，实现在单个系统中提供业务和分析操作。还可以直接把读取操作路由到离用户最近的复制集上，对于全球分布部署的应用来说就可以有效的减少读取延迟。
primaryPreferred配置选项是个非常实用的选项，它的作用就是只有在主节点故障时把读取路由到次节点上。在故障转移的过程中实现读取的可持续性。
读关注为保证数据的隔离性和一致性，把readConcern配置为majority就可以保证，只有主节点的数据被写到大多数复制集成员后，应用才能读取到主节点的数据，并且在故障的时候不能回滚。