Atlas Stream Processing regional failover processor semantics
Parent: MongoDB Atlas Stream Processing · Published reference · snapshot 2026-10-27
↓ Facts as markdownall context files
Source-anchored research for Atlas Stream Processing regional failover processor semantics. 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.
Problems, failure modes and limitations
- Atlas connections are shared across regions and cannot have region-specific variants. Kafka public connections can be reused; Kafka Private Link or VPC peering requires a same-name, same-type connection to each regional endpoint, including regional mTLS keystores where applicable. (low confidence) (verified as of 2026-10-14) [source]
Comparisons and alternatives
- MongoDB documents a product feature named failover processors: checkpoint replication mirrors an active processor in configured failover regions, and pipeline edits synchronize to its failover processors. This is stream-processor regional execution recovery, rather than a description of replica-set primary election. (medium confidence) (verified as of 2026-10-14) [source]
- Built-in failover must be configured at the workspace, connection, and processor levels. The operations guide sets failoverEnabled=true when creating the processor and instructs users to start only the primary-region processor rather than directly starting standby processors. (medium confidence) (verified as of 2026-10-14) [source]
Facts and statements
- Regional failover promotes a standby processor and resumes the last available checkpoint. Records processed since that checkpoint can be processed again; the documented guarantee is at-least-once processing, not duplicate-free output. (high confidence) (verified as of 2026-10-14) [source]
- The operations guide states that checkpoints are guaranteed to be no more than ten minutes old. This checkpoint-age statement does not specify a ten-minute failover completion or recovery-time guarantee. (low confidence) (verified as of 2026-10-14) [source]
- Graceful failover checkpoints and stops the active processor before activating recovery in the target region. Forced failover attempts to stop the active processor but proceeds even if it does not stop; by default it recovers the latest checkpoint. (high confidence) (verified as of 2026-10-14) [source]
- For forced failover, clearCheckpoints=true discards checkpoint recovery and starts at the current stream position. MongoDB warns that clearing checkpoints can produce missing or duplicate output records. (low confidence) (verified as of 2026-10-14) [source]
- A failover dry run tests configuration without consuming data. The operations guide recommends testing network connectivity and checkpoint loading periodically and after configuration changes. (high confidence) (verified as of 2026-10-14) [source]
- Managed failover processors require SP10 or higher and support Atlas-to-Atlas or Atlas-to-Kafka pipelines. A workspace supports at most two failover regions in the same cloud provider; cross-cloud failover is unsupported. (medium confidence) (verified as of 2026-10-14) [source]
- Processor failover alone does not make source and sink systems resilient. MongoDB recommends multi-region Atlas clusters, backup network connections, and provider-specific disaster recovery; it does not block failover for single-region Atlas clusters. (high confidence) (verified as of 2026-10-14) [source]
- If a failover processor fails to start during a regional failover event, the operations guide says it still assumes the active role; operators must troubleshoot and restart it in that region. Active-role assignment alone therefore does not prove that data processing resumed. (low confidence) (verified as of 2026-10-14) [source]
- The management guide initiates individual failover using Start One Stream Processor With Options or sp.processor.start({failover: ...}). The Go SDK reference exposes StartStreamProcessorWith and regional failover-connection CRUD methods. (high confidence) (verified as of 2026-10-14) [source]
- Built-in failover processors require an Atlas source with either an Atlas sink or an Apache Kafka sink, and processor tier SP10 or higher. Other supported source/sink combinations require a separately designed manual failover architecture. (medium confidence) (verified as of 2026-10-14) [source]
- A workspace supports at most two failover regions, and they must use the same cloud provider as its default region; cross-cloud failover is unsupported. (low confidence) (verified as of 2026-10-14) [source]
- Processor failover can be requested with sp.<processor>.start({failover:{region:<configured-region>,mode:"GRACEFUL"|"FORCED",dryRun:<boolean>}}). MongoDB also documents processor, workspace, and region-wide failover scopes. (medium confidence) (verified as of 2026-10-14) [source]
Children
- Forced failover fencing and duplicate suppression (frontier)
- Regional Kafka connection rebinding (frontier)
- Checkpoint replication lag and source retention (frontier)
- Forced regional failover fencing (frontier)
- Checkpoint replay and sink idempotency (frontier)
- Regional Kafka private endpoint rebinding (frontier)
- Built-in failover versus manual workspace recovery (frontier)
Frontier under this node: Built-in failover versus manual workspace recovery, Checkpoint replay and sink idempotency, Checkpoint replication lag and source retention, Forced failover fencing and duplicate suppression, Forced regional failover fencing, Regional Kafka connection rebinding, Regional Kafka private endpoint rebinding