Uno de los grandes problemas en la corrupción de datos de aplicaciones o errores humanos es que la escritura infractora en el primario se replicará inmediatamente en el secundario.
Esta es una de las razones por las que los usuarios aprovechan "slaveDelay", una opción para ejecutar uno de sus nodos secundarios con un retraso de tiempo fijo (por supuesto, eso solo lo ayuda si descubre el error o error durante el período de tiempo que es más corto que el retraso en ese secundario).
En caso de que no tenga una configuración de este tipo, debe confiar en una copia de seguridad para recrear el estado de los registros que necesita restaurar a su estado previo al error.
Realice todas las operaciones en una copia independiente separada de sus datos; solo después de verificar que todo se recreó correctamente, debe mover los datos corregidos a su sistema de producción.
Lo que se requiere para poder hacer esto es una copia reciente de la copia de seguridad (digamos que la copia de seguridad tiene X horas de antigüedad) y el registro de operaciones en su clúster debe contener más de X horas de datos. No especifiqué el registro de operaciones de qué nodo porque (a) cada miembro del conjunto de réplicas tiene el mismo contenido en el registro de operaciones y (b) es es posible que el tamaño de su registro de operaciones sea diferente en diferentes miembros del nodo, en cuyo caso desea verificar el "más grande".
Entonces, digamos que su copia de seguridad más reciente tiene 52 horas, pero afortunadamente tiene un registro de operaciones que contiene 75 horas de datos (sí).
Ya se dio cuenta de que todos sus nodos (primarios y secundarios) tienen datos "malos", por lo que lo que haría es restaurar esta copia de seguridad más reciente en un nuevo mongod. Aquí es donde restaurará estos registros a lo que eran justo antes de la actualización infractora, y luego puede moverlos al principal actual desde donde se replicarán en todos los secundarios.
Mientras restaura su copia de seguridad, cree un mongodump de su colección de registros de operaciones a través de este comando:
mongodump -d local -c oplog.rs -o oplogD
Mueva el oplog a su propio directorio y cámbiele el nombre a oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Ahora necesita encontrar la operación "ofensiva". Puede volcar el registro de operaciones en un formato legible por humanos, utilizando bsondump comando en el archivo oplogR/oplog.bson (y luego use grep o lo que no sea para encontrar la actualización "mala"). Alternativamente, puede consultar el registro de operaciones original en el conjunto de réplicas a través de use local y db.oplog.rs.find() comandos en el shell.
Su objetivo es encontrar esta entrada y anotar sus ts campo.
Podría verse así:
"ts" : Timestamp( 1361497305, 2789 )
Tenga en cuenta que mongorestore El comando tiene dos opciones, una llamada --oplogReplay y el otro llamado oplogLimit . Ahora reproducirá este oplog en el servidor independiente restaurado PERO se detendrá antes de esta operación de actualización ofensiva.
El comando sería (el host y el puerto están donde está la copia de seguridad recién restaurada):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
Esto restaurará cada operación desde el archivo oplog.bson en el directorio oplogR deteniéndose justo antes de la entrada con el valor ts Timestamp(1361497305, 2789).
Recuerde que la razón por la que estaba haciendo esto en una instancia separada es para que pueda verificar la restauración y reproducir los datos correctos creados; una vez que lo haya verificado, puede escribir los registros restaurados en el lugar apropiado en el primario real (y permitir que la replicación se propague los registros corregidos a los secundarios).
