Docs HomeMongoDB Manual

Delayed Replica Set Members延迟的副本集成员

Delayed members contain copies of a replica set's data set. 延迟成员包含副本集数据集的副本。However, a delayed member's data set reflects an earlier, or delayed, state of the set. 但是,延迟成员的数据集反映了该集的早期或延迟状态。For example, if the current time is 09:52 and a member has a delay of an hour, the delayed member has no operation more recent than 08:52.例如,如果当前时间是09:52,并且某个成员延迟了一个小时,则延迟的成员在08:52之前没有任何操作。

Because delayed members are a "rolling backup" or a running "historical" snapshot of the data set, they may help you recover from various kinds of human error. 由于延迟成员是数据集的“滚动备份”或正在运行的“历史”快照,因此它们可以帮助您从各种人为错误中恢复。For example, a delayed member can make it possible to recover from unsuccessful application upgrades and operator errors including dropped databases and collections.例如,延迟的成员可以从不成功的应用程序升级和运算符错误(包括丢失的数据库和集合)中恢复。

Considerations注意事项

Requirements要求

Delayed members:延迟成员:

  • Must be priority 0 members. Set the priority to 0 to prevent a delayed member from becoming primary.必须priority 0的成员。将优先级设置为0以防止延迟成员成为主要成员。
  • Must be hidden members. Always prevent applications from seeing and querying delayed members.必须隐藏成员。始终阻止应用程序查看和查询延迟的成员。
  • Do vote in elections for primary, if members[n].votes is set to 1. 如果members[n].votes设置为1,请在选举中投票给primary。Ensuring that delayed members are non-voting by setting members[n].votes to 0 can help improve performance.通过将members[n].votes设置为0来确保延迟成员没有投票权,这有助于提高性能。
Important

If your replica set contains delayed members ensure that the delayed members are hidden and non-voting.如果复制副本集包含延迟成员,请确保延迟成员是隐藏的并且没有投票权。

Hiding delayed replica set members prevents applications from seeing and querying delayed data without a direct connection to that member. 隐藏延迟的复制副本集成员可防止应用程序在没有直接连接到该成员的情况下查看和查询延迟的数据。Making delayed replica set members non-voting means they will not count towards acknowledging write operations with write concern "majority".使延迟的副本集成员无表决权意味着他们将不计入承认写入操作的"majority"

If you do not hide delayed members and one or more nodes become unavailable, the replica set has to wait for the delayed member and the commit point lags. A lagged commit point can lead to performance issues.如果不隐藏延迟成员,并且一个或多个节点不可用,则副本集必须等待延迟成员,提交点滞后。滞后的提交点可能会导致性能问题。

For example, consider a Primary-Secondary-Delayed replica set configuration where the delayed secondary is voting with a 10 minute delay.例如,考虑“主-辅助延迟副本集”配置,其中延迟的辅助副本以10分钟的延迟进行投票。

With one non-delayed secondary unavailable, the degraded configuration of Primary-Delayed must wait at least 10 minutes to acknowledge a write operation with "majority".在一个非延迟辅助不可用的情况下,主延迟的降级配置必须等待至少10分钟,才能用"majority"确认写入操作。The majority commit point will take longer to advance, leading to cache pressure similar performance issues with a Primary with a Secondary and an Arbiter (PSA) replica set.多数提交点将需要更长的时间才能推进,从而导致缓存压力,类似于带有辅助副本集的主副本集和仲裁器(PSA)副本集的性能问题。

For more information on the majority commit point, see Causal Consistency and Read and Write Concerns. 有关多数提交点的更多信息,请参阅因果一致性和读写入关注For additional details on resolving performance issues see the replica set maintenance tutorial.有关解决性能问题的其他详细信息,请参阅复制副本集维护教程

Behavior行为

Delayed members copy and apply operations from the source oplog on a delay. When choosing the amount of delay, consider that the amount of delay:延迟成员会延迟从源oplog复制和应用操作。在选择延迟量时,请考虑延迟量:

  • must be equal to or greater than your expected maintenance window durations.必须等于或大于预期的维护窗口持续时间。
  • must be smaller than the capacity of the oplog. For more information on oplog size, see Oplog Size.必须小于oplog的容量。有关操作日志大小的更多信息,请参阅操作日志大小

Write Concern撰写关注事项

Delayed replica set members can acknowledge write operations issued with w: <number>. 延迟的副本集成员可以确认使用w: <number>发出的写入操作。For write operations issued with w : "majority", however, delayed members must also be voting members (i.e. members[n].votes greater than 0) to acknowledge the "majority" write operation. 然而,对于以w : "majority"发出的写入操作,延迟成员也必须是有投票权的成员(即,members[n].votes大于0),以确认"majority"写入操作。Non-voting replica set members (i.e. members[n].votes is 0) cannot contribute to acknowledging write operations with majority write concern.无表决权的副本集成员(即members[n].votes0)不能参与确认majority写入操作。

Delayed secondaries can return write acknowledgment no earlier than the configured secondaryDelaySecs.延迟的secondary可以在配置的secondaryDelaySecs之前返回写确认。

Sharding分片

In sharded clusters, delayed members have limited utility when the balancer is enabled. 在分片集群中,启用平衡器时,延迟成员的效用有限。Because delayed members replicate chunk migrations with a delay, the state of delayed members in a sharded cluster are not useful for recovering to a previous state of the sharded cluster if any migrations occur during the delay window.由于延迟成员会延迟复制块迁移,因此如果在延迟窗口期间发生任何迁移,则分片集群中延迟成员的状态对于恢复到分片集群的先前状态没有用处。

Example实例

In the following 5-member replica set, the primary and all secondaries have copies of the data set. 在以下5个成员的副本集中,主副本和所有辅助副本都有该数据集的副本。One member applies operations with a delay of 3600 seconds (one hour). This delayed member is also hidden and is a priority 0 member.一个成员应用延迟3600秒(一小时)的操作。此延迟成员也是隐藏的,并且是优先级为0的成员。

Diagram of a 5 member replica set with a hidden delayed priority 0 member.

Configuration配置

A delayed member has its members[n].priority equal to 0, members[n].hidden equal to true, and its members[n].secondaryDelaySecs equal to the number of seconds of delay:延迟成员的members[n].priority等于0members[n].hidden等于truemembers[n].secondaryDelaySecs等于延迟秒数:

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

To configure a delayed member, see Configure a Delayed Replica Set Member.要配置延迟成员,请参阅配置延迟副本集成员