副本集协议版本

保留写入

可用性

pv1 在 MongoDB 版本 3.2 或更高版本中可用，并且是使用版本 3.2 或更高版本创建的所有新副本集的默认值。

仲裁节点

在下列的 MongoDB 版本中，对于带有仲裁节点的副本集，与 pv0 协议版本（MongoDB 4.0+ 中不再支持）相比，pv1 协议版本增加了 w:1 回滚的可能性：

• MongoDB 3.4.1

• MongoDB 3.4.0

• MongoDB 3.2.11 或更早的版本

对于支持 pv1 的其他 MongoDB 版本， pv1 不会增加具有仲裁节点的副本集发生 w:1 回滚的可能性。

优先级

对于以下 MongoDB 版本，对于具有不同 设置的副本集，与 相比，pv1 增加了w:1 pv0回滚的可能性（MongoDB4 中不再支持。0 members[n].priority+）：

• MongoDB 3.4.1

• MongoDB 3.4.0

• MongoDB 3.2.11 或更早的版本

对于支持 pv1 的其他 MongoDB 版本，pv1 并不会增加具有不同 members[n].priority 设置的副本集发生 w:1 回滚的可能性。

否决

pv1 不使用否决权。个人成员可以在特定选举中投票支持或反对候选人，但不能单方面否决（中止）选举。

检测同步主节点

在某些情况下，副本集中的两个节点可能会暂时认为它们是主节点，但最多只能有其中一个节点能够完成具有{ w: "majority" }写入关注的写入操作。可以完成{ w: "majority" }写入操作的节点是当前主节点，另一个节点是尚未识别其降级（通常是由于网络分区）的前主节点。发生这种情况时，尽管已请求读取偏好primary，但连接到前主节点的客户端可能会观察到过时数据，并且对前主节点的新写入操作最终将回滚。

pv1 使用术语的概念。 这样可以更快地检测到同时出现的主节点，并在短时间内成功进行多次选举。

背靠背选举

pv1 会“尽最大努力”尝试让具有最高可用priority的从节点发起选举。 这可能会导致连续选举，因为具有较高优先级的合格成员可以召集选举。

但是，在 MongoDB 3中。 6 +（以及 MongoDB 3 . 4 . 2 + 和3 . 2 . 12 +），对于pv1 ：

• 优先级选举仅限于较高优先级的节点距离当前主节点在 10 秒之内的情况。

• 如果仲裁节点检测到健康主节点的优先级等于或高于候选节点的优先级，则会在选举中投反对票。

双重投票

pv1 防止一名成员在召集选举时重复投票。 这是通过使用术语来实现的。

修改副本集协议版本

从版本4开始。 0 ，MongoDB 仅支持副本集协议版本1 ( pv1 )。

但是，MongoDB 3 . 2到 MongoDB 3 。 6支持副本集协议版本1和协议版本0 。

在更改 MongoDB 3的协议版本之前。 2到 MongoDB 3 。 6 ，确保至少一个 oplog 条目（从当前协议版本生成）已从主节点复制到所有从节点。 要进行检查，请在每个从节点上检查从optimes.lastCommittedOpTime.t 返回的rs.status() 字段。例如，将 mongosh连接到每个从节点并运行：

rs.status().optimes.lastCommittedOpTime.t

• 如果当前副本集协议版本为0 ，则t等于-1 。

• 如果当前副本集协议版本为1 ，则t大于-1 。

一旦验证至少一个 oplog 条目（使用当前协议版本）已复制到所有从节点，您就可以更改协议版本。

要更改副本集协议版本，请使用新的 重新配置 (rs.reconfig() )protocolVersion 副本集。例如，要升级到pv1 ，请将mongosh 连接到当前主节点并执行以下操作序列：

cfg = rs.conf();
cfg.protocolVersion=1;
rs.reconfig(cfg);

可以使用 catchUpTimeoutMillis 在更快的故障转移和保留 w:1 写入之间确定优先顺序。