- Frequently Asked Questions >
- FAQ:复制和复制集
FAQ:复制和复制集¶
这篇文档回答了MongoDB数据库复制的常见问题。
如果在这里没有找到你需要的答案,请检查 complete list of FAQs 或者在 MongoDB User Mailing List 提交你的问题。
MongoDB 支持那些类型的复制？¶
MongoDB 支持主-从复制和由主-从复制演化而来的复制集。 推荐使用复制集为复制拓扑。
“primary”和”master”是什么意思？¶
Primary 和 master 节点是可以接受写操作的节点。 MongoDB 的复制是 “single-master:” 一次只有一个节点可以接受写操作。
在一个复制集中, 如果当前的 “primary” 节点出错或者无法访问， 其他的节点可以自主的从中 选举 出一个节点并设定为新的 “primary”.
默认情况下，客户端向主节点发送所有的读操作；然而 read preference （读选项）以每个连接为基础，在客户端级别是可配置的， 这使得在”从节点”上进行读操作成为可能。
What do the terms “secondary” and “slave” mean?¶
Secondary 和 slave 节点是从 primary 复制而来的只读节点。
复制集中的 secondary/slave 节点自身申请新的操作，通过 oplog 进行复制操作。这个复制过程是异步的, 所以主节点上最新的写入不会立即反映在secondary/slave节点上。通常, 在本地网络环境中，主从节点间的差距只有几毫秒。
复制集故障转移需要多久？¶
这是不确定的，通常复制集会在 1 分钟内选择一个新的主节点。
It may take 10-30 seconds for the members of a replica set to declare a primary inaccessible. This triggers an election. During the election, the cluster is unavailable for writes.
选举过程自身需要消耗额外的 10-30秒。
注解
Eventually consistent reads, like the ones that will return from a replica set are only possible with a write concern that permits reads from secondary members.
可以在互联网和广域网（WAN）上进行复制吗？¶
可以。
例如，可能在东海岸的数据中心部署维护了一个 primary 和 secondary ，在遥远的西海岸，部署了一个 secondary 节点用于灾难恢复。
参见
MongoDB的复制可以部署在较差的网络环境中吗？¶
可以，但是并不是没有连接失败和明显的延迟。
复制集中的节点将根据所在网络瓣(networking flaps)的回应,尝试重新连接其他的复制集节点。这不需要管理员的干预。然而，如果复制集内节点之间的连接速度非常慢，对节点上的节点可能无法保持复制操作。
如果子节点和 主节点 的TCP连接被破坏， 复制集 将自动从复制集中选举出一个 term:子节点 并且将它设置为主节点。
既然复制已经提供了数据冗余，为什么还要使用日志？¶
日志 有助于系统崩溃后更快的恢复。在日志出现之前，系统崩溃往往需要 数据库修复 或者全部数据重新同步。这两种方法都很慢，第一种方法是不可靠的。
日志可以特别有效的预防电源故障，特别是如果你的复制集部署在一个单一的数据中心或单一的电源电路上。
如果一个 复制集 运行了日志， mongod 实例可以安全的重启，不需要任何管理员的干预。
注解
日志需要占用一些写操作的资源，但是，日志不会影响读操作的性能。
所有的 MongoDB 64 位 v2.0 或 v2.0 以上版本上，默认是启动日志的。
如果写关注没有确认写操作，写操作会持续吗？¶
可以。
然而，如果你希望确认一个给定的写操作到达了服务器上，使用 写关注.
在 改变默认写关注 后，默认的写关注会确认所有写操作，确认的写操作必须有一个明确的配置。参见： MongoDB Drivers and Client Libraries 文档获得更多的驱动器信息。
在 2.6 版更改: The mongo shell now defaults to use safe writes. See Write Method Acknowledgements for more information.
A new protocol for write operations integrates write concerns with the write operations. Previous versions issued a getLastError command after a write to specify a write concern.
复制集需要多少个投票节点？¶
某些配置中不需要任何 投票节点 实例。投票节点投票 选举 主节点 ，但是不会像 子节点 节点一样复制数据。
:term:`复制集 <replica set>`需要剩余的节点中多数的投票来选举出主节点。 投票节点允许你在不增加复制节点的情况下，构建出多数票数。
There are many possible replica set architectures.
一个复制集在投票时如果节点的数量是奇数，不需要投票节点。
考虑一个常见的配置：两个复制节点包含一个 主节点 和一个 子节点 ， 投票节点 作为第三个节点。这种配置使出现错误事件时，选举一个主节点成为了可能，不需要三个复制节点。
如果一个复制集有相等的数量的节点在两个设施或网络分区在两个设施之间，你也可以考虑在复制集中增加一个投票节点，在这种情况下，投票节点将打破两个设施间的平衡，允许复制集选举出一个新的主节点。
参见
投票节点和剩余的复制集节点交换什么信息？¶
投票节点从不接收任何数据集的内容，除了和其余的复制集节点交换以下数据：
用于验证复制集中投票节点的证书。复制集中所有的 MongoDB 进程使用密钥文件，交换信息是加密的。
复制集确认数据和投票数据。这些信息是非加密的，只有证书交换是加密的。
如果你的 MongoDB 使用 SSL 部署，那么在投票节点和复制集中其他节点的所有通信都是安全的。参见文档： Configure mongod and mongos for SSL 获得更多信息。像所有的 MongoDB 组件一样，运行所有的投票节点在安全的网络环境中。
参见
The overview of Arbiter Members of Replica Sets.
复制集中的哪些节点在选举中投票？¶
除去 votes 的值等于 0 的节点，所有的节点都会在选举中投票。包含所有的： delayed， hidden 和 secondary-only 节点, 此外，还有 arbiters 。
此外，投票节点的 state 也决定该节点是否可以投票。只有下列的资格中的投票节点才有投票的资格。
主节点
子节点
- RECOVERING
- ARBITER
- ROLLBACK
参见
复制集中的节点使用磁盘空间数量不同正常吗？¶
可以。
影响因素包括: 不同的 oplog 大小, 不同的存储碎片等级，MongoDB 的数据文件的预分配会导致不同的节点间存储利用率一些变化。在不同时期加入新节点会使存储利用出现明显的不同。