Una reversión revierte las operaciones de escritura en un nodo primario anterior cuando este se reincorpora a su conjunto de réplicas tras una conmutación por error. Los clústeres { w: "majority" } de Atlas utilizan como criterio de seguridad de escritura predeterminado para MongoDB. Con esta configuración predeterminada, Atlas solo confirma las escrituras después de replicarlas a la mayoría de los miembros. Las escrituras confirmadas no se pueden revertir, por lo que una reversión no conlleva pérdida de datos.
Si configura { w: 1 } write concern, una reversión puede afectar a las escrituras que aún no se han replicado. Antes de que se produzca una reversión, planifique cómo identificar las operaciones revertidas y decida si volver a emitirlas.
Para obtener información sobre la mecánica de reversión de conjuntos de réplicas, consulte Reversiones durante la conmutación por error de conjuntos de réplicas.
Comportamiento de reversión en Atlas
Cuando se produce una reversión en Atlas, se aplican las siguientes condiciones:
Atlas genera un
HOST_ROLLBACKevento en el registro de actividad de tu proyecto. Para saber cómo comprobar si se produce este evento, consulta la sección "Detectar reversiones".Atlas no mantiene una lista de las operaciones revertidas.
Escribir sobre la preocupación y el riesgo de reversión
Los clústeres de Atlas utilizan { w: "majority" } como preocupación de escritura predeterminada para MongoDB. Con esta configuración predeterminada, una reversión no produce pérdida de datos. La preocupación de escritura que configure determina si una reversión puede provocar pérdida de datos:
{ w: "majority" }(predeterminado) — Atlas solo reconoce una escritura después de que la mayoría de los miembros del conjunto de réplicas la confirmen. Dado que la escritura se replicó antes de que el nodo principal se desconectara, una reversión no puede incluir estas escrituras.{ w: 1 }Atlas confirma la escritura solo después de que el nodo principal la registra, sin esperar a que se replique en los nodos secundarios. Si el nodo principal se desactiva antes de que se replique la escritura, esta podría revertirse y los datos podrían ser irrecuperables.
A diferencia de las implementaciones autogestionadas, Atlas también activa elecciones de conjuntos de réplicas durante las operaciones de mantenimiento rutinarias, que incluyen:
Mantenimiento continuo y actualizaciones de parches
Eventos de escalado, como cambiar el nivel del clúster o el tamaño del disco.
Cambios en la configuración general del clúster
Atlas realiza estas operaciones de forma continua para evitar tiempos de inactividad. Sin embargo, cada elección crea un período en el que las escrituras { w: 1 } podrían no haberse replicado en los nodos secundarios. Si utiliza { w: 1 }, tenga en cuenta estas fuentes de elección al evaluar su tolerancia al riesgo de reversión.
Detectar reversiones
Cuando Atlas detecta una condición de reversión durante una conmutación por error, genera un evento HOST_ROLLBACK. Puede comprobar este evento de las siguientes maneras:
Fuente de actividad: Vea
HOST_ROLLBACKeventos en la fuente de actividad de su proyecto. Para obtener más información, consulte Ver fuente de actividad.Alertas: Configure una alerta para el
HOST_ROLLBACKtipo de evento para recibir una notificación cuando ocurra el evento. Para obtener más información, consulte Configurar ajustes de alerta.
Nota
Atlas también genera un HOST_ROLLBACK evento durante las operaciones de restauración a un punto en el tiempo debido a diferencias de datos entre los clústeres de origen y destino. Puede ignorar este evento cuando se produzca en ese contexto. Para obtener más información, consulte Restaurar desde una copia de seguridad continua en la nube.
Recuperar datos revertidos
Si se produce una reversión, póngase en contacto con el soporte técnico de MongoDB para determinar si es posible recuperar los datos revertidos.