What are hidden, delayed, and priority-0 members in a MongoDB replica set used for?

## The common ground All three are **data-bearing secondaries**. They tail the oplog, hold a complete copy of the data set, and count as real redundancy. Nothing here resembles an arbiter, which stores nothing. What changes is only how the member participates in serving traffic and in becoming primary. ## priority: 0 A member with `priority: 0` replicates normally but is never eligible to become primary. It is still visible to clients, so it can serve secondary reads, and it still contributes a copy of the data. The typical reasons to use it: the member is in a distant region where promoting it would put the write path across an ocean; it runs on cheaper hardware that could not carry the write load; or it exists for a dedicated job and you want a guarantee that no automatic promotion will ever hand it production traffic. ## hidden: true A hidden member sets `priority: 0` implicitly and adds one thing: it is not advertised to client applications, so no read preference — not `secondary`, not `nearest`, not a tag-set match — will route a query to it. It replicates like any other secondary and it can still vote. This is the standard way to dedicate capacity. Point a nightly backup, a heavy reporting job, or an analytics extract at a hidden member and it consumes no capacity that live traffic depends on. Because it is invisible to drivers, adding or removing it does not perturb client routing. ## secondaryDelaySecs A delayed member intentionally applies oplog entries only after a configured interval, so its copy of the data reflects the state of the set as it was that long ago. Setting `secondaryDelaySecs: 3600` gives you a rolling one-hour-old copy, continuously maintained. What it protects against is not hardware failure — replication already covers that. It protects against **logical destruction**: someone drops a collection, runs an unfiltered `updateMany`, or a bad deploy corrupts documents. Ordinary replication propagates that mistake to every secondary within milliseconds. A delayed member has not applied it yet, so for the length of the delay you have a live, consistent copy of the data as it was before the mistake — recovered by taking its files rather than by restoring last night's backup and replaying. The constraints matter: - It **must** be `priority: 0`. Promoting a member that is deliberately an hour behind would discard an hour of writes. - It **should** be `hidden: true`, or read-preference traffic would be served stale data by a member that is stale by design. - The delay **must be shorter than the oplog window**. The member is, by construction, permanently that far behind — if the delay approaches the window, ordinary jitter pushes it outside and it goes stale and needs a rebuild. A one-hour delay against a ninety-minute window is a trap; against a thirty-hour window it is comfortable. - The delay sets your detection budget. A one-hour delay is only useful if a human or an alert notices the damage within the hour. Choosing it is really choosing how fast you believe you detect destructive mistakes. ## Configuring them All three are member fields in the replica set configuration, applied with `rs.reconfig()`. They can be combined — a delayed member is normally hidden and priority-0 at once. A related option, `buildIndexes: false`, exists for members that only ever supply file-level copies and never serve queries; it is rare and cannot be set on a member that might serve reads. ## Where they fit Think of them as three independent restrictions rather than three member types: can it be promoted, can clients see it, and does it apply changes now or later. Real deployments compose them — a hidden priority-0 analytics node, a hidden delayed safety copy, a priority-0 visible node in a secondary region for local reads — and each combination is a deliberate answer to a specific operational need.