当成员在故障转移后重新加入其副本集时，回滚会恢复前主节点 (primary node in the replica set) 的写入操作。Atlas 集群使用 { w: "majority" } 作为 MongoDB 的默认写关注（write concern）。使用此默认设置，Atlas 仅在将写入复制到大多数节点后才确认写入。已确认的写入不能回滚，因此回滚不会导致数据丢失。
如果配置 { w: 1 } 写关注（write concern），回滚可能会影响尚未复制的写入。在回滚发生之前，请规划如何识别已回滚的操作，并决定是否重新发出这些操作。
要了解副本集回滚机制，请参阅副本集故障转移期间的回滚。
Atlas 中的回滚行为
Atlas 中发生回滚时，适用以下条件：
Atlas 在项目操作日志中生成
HOST_ROLLBACK事件。要了解如何检查此事件，请参阅 检测回滚。Atlas 不保留回滚操作列表。
写关注（write concern）和回滚风险
Atlas 集群使用 { w: "majority" } 作为 MongoDB 的默认写关注（write concern）。使用此默认设置，回滚不会导致数据丢失。您配置的写关注（write concern）决定回滚是否会导致数据丢失：
{ w: "majority" }（默认）— Atlas 仅在大多数副本集确认后才确认写入。由于在主节点降级之前复制了写入，因此回滚不能包含这些写入。{ w: 1 }— Atlas 在主节点记录写入后立即确认写入，而不会等待复制到从节点。如果主节点在写入复制前降级，则写入可能会回滚，数据可能无法恢复。
与自管理部署不同，Atlas 还会在常规维护操作期间触发副本集选举，包括：
滚动维护和补丁更新
扩展事件，例如更改集群层或磁盘大小
常规集群配置更改
Atlas 以滚动方式执行这些操作，以避免停机。但是，每次选举都会创建一个时段，在该时段内，{ w: 1 } 写入可能尚未复制到从节点。如果使用 { w: 1 }，在评估回滚风险容差时，请考虑这些选举源。
检测回滚
当 Atlas 在故障转移期间检测到回滚条件时，会生成 HOST_ROLLBACK 事件。您可以通过以下方式检查此事件：
操作日志：在您的项目操作日志中查看
HOST_ROLLBACK事件。要了解更多信息，请参阅 查看操作日志。警报：在
HOST_ROLLBACK事件类型上配置警报，以在事件发生时接收通知。要了解更多信息，请参阅配置警报设置。
注意
由于源集群和目标集群之间的数据差异，Atlas 还会在时点还原操作期间生成 HOST_ROLLBACK 事件。当此事件在该上下文中发生时，您可以忽略此事件。要了解详情，请参阅 从持续云备份恢复。
恢复已回滚的数据
如果发生回滚，请联系 MongoDB 支持团队 以确定是否可以恢复已回滚的数据。