A rollback reverts write operations on a former primary when it rejoins its replica set after a failover. Atlas clusters use { w: "majority" } as the default write concern for MongoDB. With this default, Atlas acknowledges writes only after replicating them to a majority of members. Acknowledged writes cannot be rolled back, so a rollback does not result in data loss.
If you configure { w: 1 } write concern, a rollback can affect writes that have not yet replicated. Before a rollback occurs, plan how to identify rolled-back operations and decide whether to reissue them.
To learn about replica set rollback mechanics, see Rollbacks During Replica Set Failover.
Rollback Behavior in Atlas
When a rollback occurs in Atlas, the following conditions apply:
Atlas generates a
HOST_ROLLBACKevent in your project activity feed. To learn how to check for this event, see Detect Rollbacks.Atlas does not maintain a list of rolled-back operations.
Write Concern and Rollback Risk
Atlas clusters use { w: "majority" } as the default write concern for MongoDB. With this default, a rollback does not result in data loss. The write concern you configure determines whether a rollback can result in data loss:
{ w: "majority" }(default) — Atlas acknowledges a write only after a majority of replica set members confirm it. Because the write was replicated before the primary stepped down, a rollback cannot include these writes.{ w: 1 }— Atlas acknowledges a write after only the primary records it, without waiting for replication to secondaries. If the primary steps down before the write replicates, the write may be rolled back and the data may not be recoverable.
Unlike self-managed deployments, Atlas also triggers replica set elections during routine maintenance operations, including:
Rolling maintenance and patch updates
Scaling events, such as changing cluster tier or disk size
General cluster configuration changes
Atlas performs these operations on a rolling basis to avoid downtime. However, each election creates a period where { w: 1 } writes may not have replicated to secondaries. If you use { w: 1 }, account for these election sources when evaluating your tolerance for rollback risk.
Detect Rollbacks
When Atlas detects a rollback condition during a failover, it generates a HOST_ROLLBACK event. You can check for this event in the following ways:
Activity feed: View
HOST_ROLLBACKevents in your project activity feed. To learn more, see View Activity Feed.Alerts: Configure an alert on the
HOST_ROLLBACKevent type to receive a notification when the event occurs. To learn more, see Configure Alert Settings.
Note
Atlas also generates a HOST_ROLLBACK event during point-in-time restore operations due to data differences between the source and target clusters. You can ignore this event when it occurs in that context. To learn more, see Restore from Continuous Cloud Backup.
Recover Rolled-Back Data
If a rollback occurs, contact MongoDB Support to determine whether recovery of the rolled-back data is possible.