Un rollback invierte las operaciones de escritura en una anterior primario cuando el nodo se reincorpora a su set de réplicas después de un failover. Un rollback solo es necesario si el primario había aceptado operaciones de escritura que los secundarios no habían replicado con éxito antes de que el primario se retirara. Cuando el primario se reincorpora al conjunto como secundario, revierte, o "retrocede", sus operaciones de escritura para mantener la coherencia de la base de datos con los demás nodos.
MongoDB intenta evitar rollbacks, que deberían ser raras. Cuando se produce un rollback, a menudo es el resultado de una partición de red. Las secundarias que no pueden mantenerse al día con el rendimiento de operaciones en el primario anterior, aumentan el tamaño y el impacto del rollback.
No se produce una reversión si las operaciones de escritura se replican a otro miembro del conjunto de réplicas antes de que las operaciones de escritura principal dejen de estar disponibles y si ese miembro permanece disponible y accesible para la mayoría del conjunto de réplicas.
Recopilar datos de rollback
Configurar datos de rollback
La createRollbackDataFiles El parámetro controla si se crean o no archivos de rollback durante los rollbacks.
Rollback Data
De forma predeterminada, cuando se produce una reversión, MongoDB escribe los datos de la reversión en archivos BSON.
Para cada colección cuyos datos se revierten, los archivos de rollback se ubican en un directorio <dbpath>/rollback/<collectionUUID> y tienen nombres de archivo con la forma:
removed.<timestamp>.bson
Por ejemplo, si los datos de la colección comments en la base de datos reporting se retrocedieron:
<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson
donde <dbpath> es el/la mongod de dbPath.
Tip
Nombre de colección
Para obtener el nombre de la colección, puedes buscar rollback file en el registro de MongoDB. Por ejemplo, si la entrada de registro es /var/log/mongodb/mongod.log, se puede usar grep para buscar instancias de "rollback file" en el registro:
grep "rollback file" /var/log/mongodb/mongod.log
Alternativamente, puedes recorrer todas las bases de datos y ejecutar db.getCollectionInfos() para el UUID específico hasta que obtengas una coincidencia. Por ejemplo:
var mydatabases=db.adminCommand("listDatabases").databases; var foundcollection=false; for (var i = 0; i < mydatabases.length; i++) { let mdb = db.getSiblingDB(mydatabases[i].name); collections = mdb.getCollectionInfos( { "info.uuid": UUID("20f74796-d5ea-42f5-8c95-f79b39bad190") } ); for (var j = 0; j < collections.length; j++) { // Array of 1 element foundcollection=true; print(mydatabases[i].name + '.' + collections[j].name); break; } if (foundcollection) { break; } }
Rollback exclusión de datos
Si la operación de reversión es la eliminación de una colección o un documento, la reversión de la eliminación de una colección o un documento no se escribe en el directorio de datos de reversión.
Advertencia
Si las operaciones de escritura utilizan el nivel { w: 1 } de confirmación de escritura (write concern), el directorio de rollback puede excluir las escrituras enviadas después de un oplog hole si el nodo primario se reinicia antes de que se complete la operación de escritura.
Leer datos de rollback
Para leer el contenido de los archivos de rollback, utiliza bsondump. En función del contenido y el conocimiento de sus aplicaciones, los administradores pueden decidir el siguiente curso de acción a seguir.
Evitar reversiones de conjuntos de réplicas
Para set de réplicas, el nivel de confirmación de escritura (write concern) { w: 1 } solo proporciona reconocimiento de las operaciones de escritura en el primario. Los datos pueden revertirse si el primario se cierra antes de que las operaciones de guardar se hayan replicado en alguna de las secundarias. Esto incluye datos escritos en transacciones multi-documento que se confirman usando un { w: 1 } nivel de confirmación de escritura (write concern).
Registro en la bitácora y nivel de confirmación de escritura (write concern) majority
Para evitar rollbacks de datos que ya han sido reconocidos al cliente, ejecutar todos los miembros votantes con la bitácora activada y utiliza { w: "majority" } nivel de confirmación de escritura (write concern) para garantizar que las operaciones de escritura se propaguen a la mayoría de los nodos del set de réplicas antes de devolver el acuse de recibo al cliente emisor.
A partir de MongoDB 5.0, { w: "majority" } es la preocupación de escritura predeterminada para la mayoría de las implementaciones de MongoDB.Consulte "Preocupación de escritura predeterminada implícita".
Con writeConcernMajorityJournalDefault configurado en false, MongoDB no espera a que las escrituras w: "majority" se registren en la bitácora en disco antes de confirmar las escrituras. Por lo tanto, "majority" las operaciones de escritura podrían revertirse en caso de una pérdida transitoria (p. ej., caída y reinicio) de la mayoría de los nodos en un set de réplicas determinado.
Visibilidad de los datos que se pueden revertir
Independientemente del nivel de confirmación de escritura (write concern) de una escritura, otros clientes que utilicen el nivel de consistencia de lectura
"local"o"available"pueden ver el resultado de una operación de escritura antes de que el cliente emisor acuse recibo de la operación de escritura.Los clientes que utilizan
"local"o"available"como nivel de consistencia de lectura pueden leer datos que pueden ser posteriormente revertidos durante las conmutaciones por error del set de réplicas.
Para las operaciones en una transacción multi-documento, cuando una transacción se confirma, todos los cambios de datos realizados en la transacción se guardan y son visibles fuera de la transacción. Es decir, una transacción no realizará la confirmación de algunos de sus cambios mientras revierte otros.
Hasta que se produzca la confirmación de una transacción, los cambios de datos realizados en la transacción no son visibles fuera de la transacción.
Sin embargo, cuando una transacción se guarda en múltiples fragmentos, no todas las operaciones de lectura externas necesitan esperar a que el resultado de la transacción confirmada sea visible en todos los fragmentos. Por ejemplo, si se confirma una transacción y la escritura 1 es visible en el fragmento A, pero la escritura 2 aún no es visible en el fragmento B, una lectura externa con el nivel de consistencia de lectura "local" puede leer los resultados de la escritura 1 sin ver la escritura 2.
Consideraciones para rollback
Operaciones de usuario
A partir de la versión 4.2, MongoDB mata todas las operaciones de usuario en progreso cuando un nodo entra en el estado ROLLBACK.
Creación de índices
Para la compatibilidad de características entre versiones (compatibilidad de características entre versiones)
"4.2", MongoDB espera a que finalicen las creaciones de índices en progreso antes de iniciar un rollback.
Para obtener más información sobre el proceso de creación de índices, consulta Creación de índices en colecciones pobladas.
Operaciones de índice cuando "majority" nivel de consistencia de lectura está deshabilitada
Si deshabilitas "majority" el nivel de consistencia de lectura, MongoDB previene collMod comandos que modifican un índice para revertirse. Si necesita revertir collMod comandos, debe resincronizar los nodos afectados con el nodo primario.
Limitaciones de tamaño
MongoDB admite los siguientes algoritmos de reversión, los cuales tienen diferentes limitaciones de tamaño:
Recuperar a una Marca de Tiempo, donde un primario anterior revierte a un punto en el tiempo coherente y aplica operaciones hasta ponerse al día con la rama del historial de la fuente de sincronización. Este es el algoritmo de rollback por defecto.
Al utilizar este algoritmo, MongoDB no limita la cantidad de datos que se pueden revertir.
Rollback mediante reobtención de datos, donde una antigua primaria encuentra el punto común entre su oplog y el oplog de la fuente de sincronización. Luego, el nodo examina y revierte todas las operaciones en su oplog hasta que alcanza este punto común. El rollback mediante reobtención de datos solo ocurre cuando la configuración
enableMajorityReadConcernen tu archivo de configuración está establecida enfalse.Al utilizar este algoritmo, MongoDB solo puede revertir hasta 300 MB de datos.
Nota
A partir de MongoDB 5.0,
enableMajorityReadConcernestá configurado entruey no se puede cambiar.
Limitaciones de tiempo transcurrido para revertir
El límite de tiempo para rollback se establece por defecto en 24 horas y puede configurarse utilizando el parámetro rollbackTimeLimitSecs.
MongoDB mide el tiempo transcurrido como el tiempo entre la primera operación común en los oplogs y la última entrada en el oplog del nodo que se está revirtiendo.