Recientemente nos encontramos con una incidencia respecto al oplog en un entorno MongoDB Community 4.4.5 desplegado sobre Windows Server y configurado como Replica Set de tres nodos.
El síntoma inicial parecía sencillo: uno de los nodos llevaba semanas sin sincronizar correctamente. Sin embargo, tras analizar el comportamiento del clúster comprobamos que el problema no estaba relacionado con la conectividad ni con el estado del resto de miembros, sino con el tamaño de la ventana de replicación disponible en el oplog.
Este artículo resume el análisis realizado, las conclusiones obtenidas y el procedimiento seguido para recuperar el nodo afectado.
Entorno
La infraestructura estaba compuesta por:
- MongoDB Community 4.4.5
- Replica Set de 3 nodos
- Windows Server
- Aproximadamente 190 GB de datos
- Oplog de unos 10 GB
- Ventana efectiva de replicación cercana a las 22 horas
Nodos:
- nodo01 -> RECOVERING
- nodo02 -> SECONDARY
- nodo03 -> PRIMARY
¿Qué es el Oplog y por qué es importante?
MongoDB utiliza una colección especial denominada Oplog (Operations Log) para registrar las operaciones realizadas sobre la base de datos. Los nodos secundarios leen continuamente este histórico para mantenerse sincronizados con el primario.
Mientras un nodo permanezca desconectado durante un tiempo inferior al cubierto por el Oplog, podrá recuperar automáticamente los cambios pendientes. Sin embargo, si el desfase supera la ventana disponible, el nodo pierde la referencia histórica necesaria para continuar sincronizándose y será necesario realizar una resincronización completa.
Pasos para la sincronización oplog en replica set
1.Verificar estado replicaset
rs.status()
Verificar:
- nodo01 = RECOVERING
- nodo02 o nodo03 = PRIMARY2.Verificar nuevo tamaño disco D:
En nodo01:
Get-PSDrive DVerificar que aparecen los nuevos GB tras la ampliación en disco.
3.Parar servicio MongoDB en el 01
En el nodo 01:
Stop-Service MongoDB y Get-Process mongod -ErrorAction SilentlyContinue (para comprobar que no queda nigún proceso mongod...)4.Configurar nuevo tamaño oplog
Editar el fichero:
C:\Program Files\MongoDB\Server\4.4\bin\mongod.cfg
Buscar:
replication:
replSetName: "mongo-pro"
Modificar dejando:
replication:
replSetName: "mongo-pro"
oplogSizeMB: 81920
NOTA:
81920 MB = 80 GB oplog
Guardar fichero.5.ELIMINAR datos antiguos del 01
IMPORTANTE:
Este paso SOLO se realiza en el nodo 01.
Eliminar contenido antiguo:
Remove-Item -Recurse -Force D:\mongodb\data\db\*NO borrar:
– D:\mongodb\security
– D:\mongodb\log
– mongod.cfg
6. Arrancar MongoDB y verificar initial sync
Ejecutar:
Start-Service MongoDB
y seguidamente:
rs.status()
El 01 debería aparecer pasando por estados similares a:
STARTUP2
RECOVERING
SECONDARY
7.Monitorización del proceso
En nodo01 revisar log:
Get-Content "D:\mongodb\log\mongod.log" -Tail 100 -Wait
Se deberían ver mensajes relacionados con:
- initial sync
- cloning
- syncing
- oplog application8.Verificar estado final
Conclusion
La recuperación del nodo requirió una resincronización completa debido al desfase acumulado y a una ventana Oplog demasiado reducida.
La ampliación del almacenamiento y el aumento del tamaño del Oplog permitirán disponer de un margen significativamente mayor ante futuras incidencias y reducirán la necesidad de reconstrucciones completas de los nodos del Replica Set.
¿No estas seguro de sincronizar el oplog?
No dudéis en poneros en contacto con nosotros en caso de necesitar ayuda en la gestión de vuestras bases de datos. Échale un vistazo a nuestros servicios de soporte y mantenimiento SQL Server y Oracle.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn