Un rollback revierte las operaciones de guardar en un primario anterior cuando se reincorpora a su set de réplicas después de una conmutación por error. Los clústeres de Atlas utilizan { w: "majority" } como nivel de confirmación de escritura (write concern) por defecto para MongoDB. Con esta configuración por defecto, Atlas confirma los guardar solo después de replicarlas en la mayoría de los nodos. Los guardados confirmados no se pueden revertir, por lo que un rollback no provoca la pérdida de datos.
Si configura el nivel de confirmación de escritura (write concern) { w: 1 }, un rollback puede afectar a las operaciones de guardar que aún no se han replicado. Antes de que se produzca un rollback, planifique cómo identificar las operaciones de rollback y decida si desea volver a emitirlas.
Para aprender sobre la mecánica de rollback del set de réplicas, consulte Rollback durante la conmutación por error del set de réplicas.
Comportamiento de rollback en Atlas
Cuando se produce un rollback en Atlas, se aplican las siguientes condiciones:
Atlas genera un evento
HOST_ROLLBACKen la fuente de actividad de su proyecto. Para aprender a comprobar este evento, consulte Detectar rollback.Atlas no mantiene una lista de operaciones revertidas.
Nivel de confirmación de escritura (write concern) y riesgo de rollback
Los clúster de Atlas utilizan { w: "majority" } como nivel de confirmación de escritura (write concern) por defecto para MongoDB. Con esta configuración por defecto, un rollback no provoca la pérdida de datos. El nivel de confirmación de escritura (write concern) que configure determina si un rollback puede provocar la pérdida de datos:
{ w: "majority" }(por defecto) — Atlas reconoce una escritura solo después de que la mayoría de los nodos del set de réplicas la confirmen. Debido a que el guardar se replicó antes de que el primario se retirara, un rollback no puede incluir estos guardados.{ w: 1 }— Atlas reconoce un guardar después de que solo el primario realiza el registro, sin esperar la replicación a los secundarios. Si el primario se retira antes de que se replique el guardar, el guardar puede revertirse y es posible que los datos no se puedan recuperar.
A diferencia de las implementaciones autogestionadas, Atlas también activa elecciones de set de réplicas durante las operaciones de mantenimiento rutinarias, que incluyen:
Mantenimiento continuo y actualizar de parches
Escalado de eventos, como cambiar el nivel de clúster o el tamaño del disco
Cambios generales en la configuración del clúster
Atlas realiza estas operaciones de forma continua para evitar el tiempo de inactividad. Sin embargo, cada elección crea un período en el que { w: 1 } guardados pueden no haberse replicado en los secundarios. Si utiliza { w: 1 }, tenga en cuenta estas fuentes de elección al evaluar su tolerancia al riesgo de rollback.
Detectar rollback
Cuando Atlas detecta una condición de rollback durante una conmutación por error, genera un evento HOST_ROLLBACK. Puede buscar este evento de las siguientes maneras:
fuente de actividad: vea
HOST_ROLLBACKeventos en la fuente de actividad de su Proyecto. Para aprender más, consulte Ver la fuente de actividad.Alertas: configure una alerta en el tipo de evento
HOST_ROLLBACKpara recibir una notificación cuando se produzca el evento. Para obtener más información, consulte Configurar ajustes de alerta.
Nota
Atlas también genera un evento HOST_ROLLBACK durante las operaciones de restauración a un punto específico del tiempo debido a las diferencias de datos entre los clúster de origen y de destino. Puede ignorar este evento cuando se produzca en ese contexto. Para aprender más, consulte Restauración desde las copias de seguridad en la nube.
Recuperar datos revertidos
Si se produce un rollback, póngase en contacto con el soporte de MongoDB para determinar si es posible recuperar los datos revertidos.