Una reversión revierte las operaciones de escritura en un archivo anterior. El principal cuando el miembro se reincorpora a su conjunto de réplicas tras una conmutación por error. Una reversión solo es necesaria si el principal había aceptado operaciones de escritura que los secundarios no habían replicado correctamente antes de que el principal se redujera. Cuando el principal se reincorpora al conjunto como secundario, revierte sus operaciones de escritura para mantener la coherencia de la base de datos con los demás miembros.
MongoDB intenta evitar las reversiones, lo cual debería ser poco frecuente. Cuando se produce una reversión, suele deberse a una partición de red. Las bases de datos secundarias que no pueden mantener el ritmo de las operaciones de la base de datos principal anterior aumentan el tamaño y el impacto de la reversión.
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 reversión
Configurar datos de reversión
El createRollbackDataFiles El parámetro controla si se crean o no archivos de reversión durante las reversiones.
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 reversión se ubican en un directorio <dbpath>/rollback/<collectionUUID> y tienen nombres de archivo con el formato:
removed.<timestamp>.bson
Por ejemplo, si se revirtieron los datos de la colección comments en la base de datos reporting:
<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson
donde <dbpath> es el mongod dbPathdel.
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
Como alternativa, puede recorrer todas las bases de datos y ejecutar para el UUID específico hasta encontrar una coincidencia. Por db.getCollectionInfos() 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; } }
Revertir 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.
Leer datos de reversión
Para leer el contenido de los archivos de reversión, utilice 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 los conjuntos de réplicas, la solicitud { w: 1 } de escritura solo confirma las operaciones de escritura en el primario. Los datos pueden revertirse si el primario se desconecta antes de que las operaciones de escritura se repliquen en alguno de los secundarios. Esto incluye los datos escritos en transacciones multidocumento que se confirman { w: 1 } mediante la solicitud de escritura.
Diario y preocupación por escribir majority
Para evitar reversiones de datos que han sido reconocidos por el cliente, ejecute todos los miembros votantes con el registro en diario habilitado y utilice la operación de escritura { w: "majority" } para garantizar que las operaciones de escritura se propaguen a la mayoría de los nodos del conjunto de réplicas antes de regresar con el reconocimiento 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 la 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 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 de reversión
Operaciones de usuario
A partir de la 4.2 versión, MongoDB elimina todas las operaciones de usuario en curso cuando un miembro ingresa al ROLLBACK estado.
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 la preocupación de lectura está "majority" deshabilitada
Si deshabilita la "majority" lectura de, MongoDB impide que collMod los comandos que modifican un índice se reviertan. Si necesita collMod revivir los comandos, debe resincronizar los nodos afectados con el nodo principal.
Limitaciones de tamaño
MongoDB admite los siguientes algoritmos de reversión, que tienen diferentes limitaciones de tamaño:
Recuperar a una marca de tiempo: un archivo principal anterior vuelve a un punto constante en el tiempo y aplica operaciones hasta alcanzar la rama del historial de la fuente de sincronización. Este es el algoritmo de reversión predeterminado.
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
enableMajorityReadConcernse establece entruey no se puede cambiar.
Limitaciones de tiempo transcurrido para revertir
El límite de tiempo de reversión 24 predeterminado es rollbackTimeLimitSecs horas y se puede configurar mediante el parámetro.
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.