Nota
No necesitas volver a sincronizar las bases de datos MongoDB que funcionan con una compatibilidad de características entre versiones de 4.2 o posterior.
Cuando una copia de seguridad se desincroniza con la implementación de MongoDB, Ops Manager genera un Backup requires a resync alerta. Si recibes esta alerta, debes volver a sincronizar la copia de seguridad para la instancia especificada de MongoDB.
Los siguientes escenarios activan una alerta Backup requires a resync:
- El Oplog se ha renovado
- Este es el caso más común para la alerta
Backup requires a resync. Ocurre cuando el cursor de seguimiento de la copia de seguridad no puede mantenerse al día con el oplog de la implementación. Esto es similar a cuando un secundario se retrasa demasiado con respecto al primario en un set de réplicas. Sin una resincronización, las copias de seguridad no se pondrán al día. - applyOps no seguros
- Esto ocurre cuando se indica un documento del que copia de seguridad no tiene una copia.
- Corrupción de datos u otra instrucción ilegal
- Esto suele causar que la replicación y, por lo tanto, la tarea de copia de seguridad se rompa. Cuando el demonio ve la tarea rota, pide una resincronización.
Durante la resincronización, se leen datos de un secundario en cada set de réplicas y Ops Manager no produce ningún nuevo snapshot.
Nota
Para implementaciones en producción con un FCV de 4.0 o anterior, debes volver a sincronizar todas las copias de seguridad anualmente.
Importante
Ops Manager no intenta recuperarse automáticamente de las condiciones que causaron la Backup requires a resync alerta. Esta alerta significa que no hay suficientes datos para completar una restauración. No hay forma de recuperarse automáticamente de no tener suficientes datos de los snapshots y del oplog. Resincronizar la copia de seguridad es la mejor opción.
Considerations
A partir del FCV 4.2, las implementaciones se respaldan con puntos de control de WiredTiger utilizando cursores de copia de seguridad. Las aplicaciones pueden continuar las operaciones de lectura y escritura en la base de datos mientras WiredTiger toma la snapshot.
Para implementaciones en producción con una compatibilidad de características entre versiones de 4.0 o anterior, para evitar la necesidad de resincronizaciones, asegúrate de que el oplog de copia de seguridad no quede rezagado respecto al oplog de la implementación. Esto requiere que:
Se provisionan recursos de máquina adecuados para el agente.
Reinicio de los agentes de Ops Manager a tiempo tras el mantenimiento u otro tiempo de inactividad.
Para proporcionar un margen para el mantenimiento y las ráfagas ocasionales de actividad, asegúrese de que el oplog en el primario sea lo suficientemente grande como para contener al menos 24 horas de actividad.
Debes resincronizar la base de datos principal después de que crear un índice de forma continua para garantizar que la base de datos principal tenga en cuenta el nuevo índice.
Tip
Para obtener más información sobre el oplog de respaldo, consulta las Preguntas frecuentes: copia de seguridad y restauración.