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

On this page本页内容

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. 必须是priority 0的成员。Set the priority to 0 to prevent a delayed member from becoming primary.将优先级设置为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. 延迟成员在延迟时从源oplog复制并应用操作。When choosing the amount of delay, consider that the amount of delay:选择延迟量时,应考虑延迟量:

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

Write Concern写入关注点

Delayed replica set members can acknowledge write operations issued with w: <number>. 延迟的副本集成员可以确认使用w: <number>发出的写入操作。For write operations isued 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)无法帮助确认具有多数写问题的写操作。

Delayed secondaries can return write acknowledgment no earlier than the configured secondaryDelaySecs.延迟的二级可以不早于配置的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). 一个成员应用延迟3600秒(一小时)的操作。This delayed member is also hidden and is a priority 0 member.此延迟成员也被隐藏,并且是priority 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等于0,其members[n].secondaryDelaySecs等于true,其members[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.要配置延迟成员,请参阅配置延迟副本集成员

←  Hidden Replica Set MembersReplica Set Arbiter →