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