Refresh scheduling on Atlas (Scheduled Triggers, cron, secondary or analytics reads)
Parent: Read Offload via Caching and Precomputed Views ($merge/$out, Computed Pattern) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Refresh scheduling on Atlas (Scheduled Triggers, cron, secondary or analytics reads). 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
- Starting in MongoDB 5.0, a refresh pipeline ending in $merge can execute reads on a replica-set secondary when every node has featureCompatibilityVersion 5.0 or higher, the read preference permits secondary reads, and the driver supports this behavior; output writes still go to the primary. (high confidence) [source]
- Choosing secondaryPreferred does not guarantee isolation from the primary: when no eligible secondary is available, reads can fall back to the primary; secondary instead fails if no eligible secondary exists. (high confidence) [source]
- Secondary reads may return stale data because replication is asynchronous; maxStalenessSeconds filters estimated replication lag and can be combined with tag sets, but it does not set the age of the last completed materialized-view refresh. (high confidence) [source]
- Atlas Scheduled Triggers provide a managed scheduling alternative with five-field cron expressions interpreted in UTC, and their documented daily-report example runs an aggregation and stores its result in a reports collection. (low confidence) (verified as of 2026-10-31) [source]
- Starting in MongoDB 5.0, pipelines ending in $merge or $out can execute on replica-set secondaries when all nodes have featureCompatibilityVersion 5.0 or higher and read preference permits secondary reads; driver support must also be checked. (medium confidence) (verified as of 2026-10-31) [source]
- For strict Atlas analytics-read isolation, use readPreference=secondary with readPreferenceTags=nodeType:ANALYTICS. An empty fallback tag permits other eligible secondaries, and secondaryPreferred can fall back to the primary when no eligible secondary is available. (medium confidence) (verified as of 2026-10-31) [source]
Comparisons and alternatives
- For an external refresh worker scheduled with Kubernetes CronJob, concurrencyPolicy:Forbid prevents overlap only among Jobs from that same CronJob; delayed or duplicate execution remains possible, so make the refresh idempotent and monitor completed runs rather than assuming every scheduled tick succeeds. (low confidence) [source]
- Percona's January 14, 2026 workload study found almost no throughput gain from secondaryPreferred for its 54%-read/46%-write workload, while a read-only workload benefited; secondary read offload therefore needs workload-specific measurement rather than an assumed speedup. (low confidence) [source]
- Kubernetes CronJob scheduling is approximate: a scheduled execution can create two Jobs or no Job. Refresh workers should therefore be idempotent rather than assume exactly-once execution. (low confidence) [source]
- Design inference: assess refresh freshness from completed runs and source replication lag, rather than equating the cron interval with a hard freshness bound; missed or overlapping jobs and stale secondary inputs can invalidate that bound. (medium confidence) [source]
Facts and statements
- Atlas exposes the predefined nodeType:ANALYTICS tag; combine it with secondary read preference to target analytics nodes for refresh reads, while an empty fallback tag permits other secondaries if analytics nodes are unavailable. (high confidence) [source]
- The manufacturing-mes-dashboard repository documents scheduled batch refresh through refresh_views.py and explicitly says automatic change-stream or Atlas Stream Processing refresh was not implemented in that demonstration; it is an implementation example, not production validation of a streaming refresh system. (low confidence) (verified as of 2026-10-31) [source]
- Executing a $merge or $out refresh pipeline on a secondary offloads eligible read execution, while output writes are sent to the primary; it does not remove refresh write load from the primary. (medium confidence) [source]
- Read preference tags can direct reporting or refresh reads to selected secondary members. Atlas exposes nodeType:ANALYTICS for targeting its analytics nodes; Percona independently demonstrates purpose-based tagged read routing in a replica-set example. (medium confidence) [source]
- MongoDB secondary reads may return stale data. A scheduled refresh that reads a secondary therefore must tolerate stale inputs; completing a refresh does not by itself prove that it includes the latest source writes. (low confidence) [source]
- Kubernetes concurrencyPolicy: Forbid skips a new run while a previous run remains active. Its concurrency policy applies only to Jobs created by that same CronJob, so separate refresh CronJobs can still overlap. (low confidence) [source]
- Kubernetes CronJobs without spec.timeZone use the controller local time zone; spec.timeZone: Etc/UTC makes UTC interpretation explicit. (low confidence) [source]
Children
- Refresh-worker driver compatibility (frontier)
- CronJob overlap and missed-run handling (frontier)
- Secondary-input freshness budgets (frontier)
Frontier under this node: CronJob overlap and missed-run handling, Refresh-worker driver compatibility, Secondary-input freshness budgets