Docs 菜单

Docs 主页开发应用程序MongoDB Manual

延迟的副本集成员

在此页面上

  • 考虑因素
  • 例子
  • 配置

延迟成员包含副本集数据集的副本。但是,延迟成员的数据集反映了该数据集较早或延迟的状态。例如,当前时间为 09:52,成员有一小时延迟,则延迟成员在 08:52 之前没有任何操作。

延迟成员是数据集的“滚动备份”或正在运行的“历史”快照,因此可以帮助您从各种人为错误中恢复。例如,利用延迟成员,不成功的应用程序升级和操作员错误(包括删除的数据库和集合)都有可能恢复。

延迟成员:

重要

如果您的副本集包含延迟成员,请确保延迟成员处于隐藏状态,并且没有投票权。

隐藏延迟的副本集节点可以防止应用程序在没有直接连接到该节点的情况下查看和查询延迟数据。使延迟的副本集节点不投票意味着它们不会计入确认具有写关注 "majority" 的写入操作。

如果不隐藏延迟节点,并且一个或多个节点变得不可用,则副本集必须等待延迟节点并且提交点会延迟。延迟提交点可能会导致性能问题。

例如,考虑主节点-从节点-延迟的副本集配置,其中延迟的从节点延迟 10 分钟进行投票。

在一个非延迟从节点不可用的情况下,主节点-延迟节点的降级配置必须等待至少 10 分钟,才能确认使用 "majority" 的写入操作。多数提交点将需要更长的时间才能推进,从而导致具有从节点和仲裁节点的主节点 (PSA) 副本集出现类似缓存压力的性能问题。

有关多数提交点的更多信息,请参阅因果一致性和读写关注。有关解决性能问题的其他详细信息,请参阅副本集维护教程

延迟成员会复制并应用延迟中源 oplog 的操作。选择延迟量时,请考虑延迟量:

  • 必须等于或大于预期的维护窗口持续时间。

  • 必须小于 oplog 的容量。有关 oplog 大小的更多信息,请参阅 Oplog 大小

延迟的副本集成员可以确认 w: <number> 发出的写操作。但是,对于 w : "majority" 发出的写操作,延迟成员还必须是投票成员(即 members[n].votes 大于 0), 才能确认 "majority" 写操作。无投票权的副本集成员(即 members[n].votes0)无法参与确认具有 majority 写关注的写操作。

延迟的从节点在所配置的 secondaryDelaySecs 之前无法返回写入确认。

在分片群集中,启用负载均衡器后,延迟成员的作用有限。由于延迟成员会延迟复制数据段迁移,因此如果在延迟窗口期间发生任何迁移,则分片集群中延迟成员的状态对于恢复到分片集群的先前状态没有用。

在以下 5 个成员副本集中,主节点和所有从节点都有数据集副本。单个成员执行延迟 3600 秒(一小时)的操作。该延迟成员也是隐藏的优先级为 0

具有隐藏延迟优先级 0 节点的 5 节点副本集的图表。

延迟成员的 members[n].priority 等于 0members[n].hidden 等于 truemembers[n].secondaryDelaySecs 等于延迟秒数:

{
"_id" : <num>,
"host" : <hostname:port>,
"priority" : 0,
"secondaryDelaySecs" : <seconds>,
"hidden" : true
}

如需配置延迟成员,请参阅“配置延迟副本集成员”。

← 隐藏的副本集成员