Targeted mirrored reads for replica cache warming
Parent: MongoDB Replication · Published reference · snapshot 2026-10-27
↓ Facts as markdownall context files
Source-anchored research for Targeted mirrored reads for replica cache warming. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- A historical MongoDB proposal describes hiding a restarted cold member while warming it and leaving enablement and later unhide decisions to an external mechanism. Treat this as motivation for an operator-controlled warming workflow, not evidence of automatic cache-readiness detection or automatic unhiding. (low confidence) [source]
- The upstream v8.2 implementation caches destinations by matching replica-set member tags. It refreshes the list when configuration version/term or the configured target tag changes, and defers computation if replica-set configuration is uninitialized. (low confidence) [source]
How-to and procedures
- Configure mirrorReads.targetedMirroring.tag as one key/value document, for example {warm:'standby'}. Only one tag is accepted; matching members in the same replica set are targeted. Use the nested tag document, not historical tagKey/tagValue proposal syntax. (high confidence) [source]
Measurements and reference values
- The targetedMirroring subdocument has its own samplingRate and maxTimeMS. The documented sampling range is 0.0–1.0, default 0.01; timeout defaults to 1000 ms. Targeted mirroring is off by default because tag is empty. (low confidence) (verified as of 2026-10-14) [source]
Problems, failure modes and limitations
- In the MongoDB 8.2 implementation, mirroredReads.targetedSent counts targeted network requests scheduled for sending, while targetedErroredDuringSend counts send errors. Successful-completion counters are exposed only under a test failpoint, so targetedSent alone cannot prove a warm cache. (low confidence) (verified as of 2026-10-27) [source]
Facts and statements
- Mirrored reads pre-warm secondary caches with application access patterns to reduce cold-cache performance loss after failover. (high confidence) [source]
- MongoDB documents targeted mirrored reads starting in 8.2. Replica-set tags select warming destinations, including hidden members, and targeted mirrors can originate on both primary and secondary nodes; ordinary mirroring targets electable secondaries. (high confidence) (verified as of 2026-10-14) [source]
- The replication manual explicitly permits targeted mirroring from both primary and secondary members. (low confidence) (verified as of 2026-10-14) [source]
- mirrorReads.targetedMirroring uses one tag key/value pair, targets matching members in the same replica set, and has its own samplingRate and maxTimeMS. (high confidence) (verified as of 2026-10-14) [source]
- Mirroring runs asynchronously without awaiting mirrored results for the client response; this does not establish zero resource cost. (high confidence) [source]
- mirrorReadsMaxConnPoolSize controls the mirroring connection pool for both general and targeted modes. The parameter reference identifies it as new in 8.2, with default 4 and minimum 1; increasing mirrored traffic still consumes destination resources. (high confidence) (verified as of 2026-10-14) [source]
- Cold-cache failover can raise read latency even after a new primary is elected. Alibaba Cloud describes this in ApsaraDB instances whose secondary served no reads; Percona independently explains the resulting disk reads. Mirrored reads aim to warm the working set before promotion, without guaranteeing a fixed recovery time. (high confidence) [source]
- General and targeted mirroring have separate sampling settings. A targeted configuration can supplement general mirroring; do not assume changing only the top-level samplingRate also disables targeted traffic. (high confidence) [source]
- Eligible operations include find, count and distinct, plus the filter portions of update and findAndModify. Mirroring those filters warms read paths; it does not replay the writes themselves. (medium confidence) [source]
- Mirrored reads run asynchronously as fire-and-forget requests. The original request does not wait for a mirrored result; the upstream implementation marks mirror requests and avoids mirroring an already mirrored request. (high confidence) [source]
- Inspect mirroring with db.serverStatus({mirroredReads:1}). In the inspected v8.2 implementation, targetedSent and targetedErroredDuringSend are exposed normally, while targetedResolved, targetedSucceeded and targetedResolvedBreakdown require mirrorMaestroExpectsResponse; pending/scheduled fields require mirrorMaestroTracksPending. Do not promise these test counters as normal production telemetry. (medium confidence) [source]
Children
- Replica tag selection for targeted mirroring (frontier)
- Hidden-member cache warming (frontier)
- Targeted mirroring counters and completion limits (frontier)
Frontier under this node: Hidden-member cache warming, Replica tag selection for targeted mirroring, Targeted mirroring counters and completion limits