Cuando pierde el MongoDB Ops Manager primario, restaura sus bases de datos de respaldo desde el MongoDB Ops Manager secundario y luego inicia un nuevo MongoDB Ops Manager primario. Utilice este procedimiento después de un evento como una actualización fallida, una eliminación accidental de datos o una falla de infraestructura. Cuando el MongoDB Ops Manager primario se reinicia, entra automáticamente en modo de restauración para conciliar la configuración del agente antes de que se reanude la operación normal. Para obtener una descripción general de este patrón, consulte Copia de seguridad y restauración de MongoDB Ops Manager mediante una instancia secundaria. Para configurar este patrón, consulte Configurar un MongoDB Ops Manager secundario para realizar copias de seguridad de MongoDB Ops Manager.
Considerations
Restaurar orden
La secuencia de restauración de las bases de datos de respaldo y el inicio del Ops Manager primario es fundamental.
Advertencia
Restaure las bases de datos de respaldo antes de iniciar el MongoDB Ops Manager primario. Si inicia el MongoDB Ops Manager primario antes de restaurar sus bases de datos de respaldo, el MongoDB Ops Manager primario puede guardar un estado inconsistente y crear un escenario de división entre las implementaciones antiguas y nuevas.
Si el Ops Manager secundario también realiza una copia de seguridad del almacén de metadatos de snapshot y del almacén de metadatos de oplog, restaure las tres bases de datos de respaldo al mismo punto en el tiempo, o restaure los almacenes de metadatos a un punto en el tiempo ligeramente posterior al de la base de datos de la aplicación, antes de iniciar el Ops Manager principal. La restauración de los almacenes de metadatos a un punto anterior al de la base de datos de la aplicación hace que el Ops Manager principal rechace las tareas de restauración afectadas con HTTP 409 (“snapshot blocks missing”).
Punto de recuperación
Una restauración a un punto específico del tiempo recupera la base de datos de la aplicación hasta el punto específico del tiempo que seleccione, no hasta el momento del desastre. Es posible que las operaciones que la copia de seguridad no capturó en un oplog slice antes del desastre no se puedan recuperar. Seleccione un punto de restauración lo más cercano posible al desastre que permita su ventana de recuperación a un punto específico del tiempo.
Después de que se reinicia el MongoDB Ops Manager primario, la conciliación recupera la configuración de automatización de la implementación de los agentes de MongoDB. Otros cambios recientes en la base de datos de la aplicación reflejan el punto de restauración que seleccione.
Compatibilidad de versiones
Las versiones primaria y secundaria de MongoDB Ops Manager deben seguir siendo compatibles.
Advertencia
Restaure la base de datos de la aplicación a un MongoDB Ops Manager primario que ejecute la misma versión que, o una versión posterior a, el MongoDB Ops Manager primario original del que se tomó la snapshot. Si el binario de reemplazo es anterior a la versión registrada de la base de datos de la aplicación, MongoDB Ops Manager se niega a iniciarse con un error de "No se permiten las degradaciones".
Requisitos previos
El modo de restauración está habilitado por defecto en Ops Manager 8.0.24 y versiones posteriores. Si lo deshabilitó, vuelva a habilitarlo en el Ops Manager principal antes de restaurar. Para conocer los pasos, consulte Configurar un Ops Manager secundario para realizar copias de seguridad de Ops Manager.
Confirme que el Ops Manager secundario tiene un snapshot completado y una ventana de recuperación continua en un momento dado para las bases de datos de respaldo.
Confirme que ha conservado el estado por host necesario para la recuperación, incluido el archivo
gen.keyde la instalación principal original de MongoDB Ops Manager.
Conservar el estado por host
Una recuperación completa de MongoDB Ops Manager primario requiere más que la base de datos de la aplicación. Conserve el siguiente estado en cada host, además de la base de datos de la aplicación de la que realiza una copia de seguridad el MongoDB Ops Manager secundario:
Item | Ubicación | Descripción |
|---|---|---|
llave de cifrado |
| Cifra el contenido de la base de datos de la aplicación. Debe coincidir con la clave utilizada para la instalación original, o el Ops Manager primario no podrá descifrar la base de datos de la aplicación restaurada al iniciar. |
Configuración de MongoDB Ops Manager |
| Almacena URL de base de datos, configuración de almacenamiento en bloques, claves de licencia y certificados TLS. Sin él, debe reconfigurar el MongoDB Ops Manager primario manualmente. |
Configuración del agente |
| Almacena el |
Importante
Si el archivo gen.key falta o no coincide con la base de datos de la aplicación restaurada, el Ops Manager principal falla en su comprobación previa al inicio con un error que gen.key no coincide con la clave ya utilizada para esta instalación de Ops Manager. Mantenga gen.key en su copia de seguridad de recuperación ante desastres junto con los datos de la base de datos de la aplicación.
Restaurar el MongoDB Ops Manager primario
Restauración de las bases de datos de respaldo
En el MongoDB Ops Manager secundario, restaura la base de datos de la aplicación del MongoDB Ops Manager principal al punto en el tiempo que elegiste:
Haga clic en Continuous Backup y, a continuación, seleccione el set de réplicas de la base de datos de la aplicación.
Haga clic en el menú y, a continuación, haga clic en Restore.
Seleccione Point in Time y, a continuación, introduzca la fecha y la hora de destino.
Haga clic en Choose Cluster to Restore to, seleccione los host del set de réplicas de la base de datos de la aplicación y, a continuación, haga clic en Restore.
El MongoDB Agent secundario de Ops Manager detiene los procesos de la base de datos de la aplicación, reemplaza los datos con la snapshot restaurada, reproduce el oplog hasta la hora de destino y reinicia los procesos.
Advertencia
Si el MongoDB Ops Manager secundario también realiza una copia de seguridad de los almacenes de metadatos de snapshot y oplog, restáurelos en el mismo punto en el tiempo que la base de datos de la aplicación, o en un punto ligeramente posterior, antes de iniciar el MongoDB Ops Manager primario. La restauración de los almacenes de metadatos en un punto anterior hace que el MongoDB Ops Manager primario rechace las tareas de restauración afectadas con HTTP 409 ("faltan bloques de snapshot").
Si solo restauras la base de datos de la aplicación, el Ops Manager secundario deja los almacenes de metadatos sin cambios. Esto es seguro para el funcionamiento normal, pero las instantáneas de copia de seguridad que el Ops Manager principal tomó entre el punto de restauración y ahora podrían no estar disponibles.
Inicie el MongoDB Ops Manager primario
Inicie el MongoDB Ops Manager primario. El MongoDB Ops Manager primario se conecta a la base de datos de la aplicación restauración, lee el estado de restauración y comienza la recuperación. Para obtener más información, consulte Iniciar y detener la aplicación de MongoDB Ops Manager.
Deje que la conciliación se complete
El MongoDB Ops Manager principal entra en modo de restauración y concilia la configuración de implementación automáticamente. Mientras se ejecuta la conciliación, el MongoDB Ops Manager principal muestra un banner de modo de restauración. No se requiere ninguna acción manual. El MongoDB Ops Manager principal sale del modo de restauración cuando finaliza la conciliación.
Modo de restauración y conciliación
Después de restaurar la base de datos de la aplicación e iniciar el Ops Manager primario, el Ops Manager primario compara la versión de configuración de cada MongoDB Agent con la versión de configuración restaurada. Si un agente informa de una versión posterior, el Ops Manager primario entra en modo de restauración para ese proyecto y concilia la configuración automáticamente:
El Ops Manager principal aísla el proyecto. Muestra un banner de modo de restauración, devuelve una respuesta sin cambios a las encuestas de agentes y bloquea los cambios de implementación de la interfaz de usuario y la API hasta que se complete la conciliación.
El MongoDB Ops Manager principal recopila la versión de configuración de cada agente, selecciona el agente con la configuración más reciente y guarda esa configuración en la base de datos de la aplicación como la configuración autorizada.
El MongoDB Ops Manager primario sale del modo de restauración del proyecto y reanuda la operación normal. Las copias de seguridad se reanudan automáticamente.
Esta conciliación evita un escenario de división de cerebro. Converge todos los agentes en una única configuración autorizada antes de que cualquier agente reciba una nueva configuración.
Cuando se revierte la base de datos de la aplicación a un punto anterior en el tiempo, la configuración restaurada ya no incluye los cambios de implementación que realizó después del punto de restauración. Sin conciliación, los agentes reciben la configuración anterior y detienen los procesos a los que la configuración ya no hace referencia. El impacto depende del cambio de implementación:
Cambio de implementación | Riesgo sin reconciliación |
|---|---|
Nuevo nodo de set de réplicas | Los datos existen en otros nodos, por lo que no se pierde ningún dato. |
Nueva partición con fragmentos migrados | Los fragmentos migrados solo existen en la nueva partición. Detenerlo hace que esos datos sean inalcanzables, lo que provoca la pérdida de datos. |
Nueva versión del proceso | El proceso no se puede ejecutar en la versión binaria revertida, lo que provoca una deriva operativa. |
Nuevo índice | Las querys de índice se degradan hasta que MongoDB Ops Manager reconstruye el índice. |
La conciliación evita estos resultados. El MongoDB Ops Manager primario converge todos los agentes en la última configuración y pone en cola un snapshot on-demand antes de salir del modo de restauración, lo que le proporciona un punto de copia de seguridad coherente.
Validar el MongoDB Ops Manager restaurado
Confirme que el MongoDB Ops Manager primario restaurado está en buen estado:
Confirma que los agentes de MongoDB se vuelvan a conectar y se informen como correctos.
Confirme que la automatización, la copia de seguridad y la supervisión se reanudan para sus implementaciones gestionadas.
Confirme que el Ops Manager principal sale del modo de restauración. Para verificar el estado del modo de restauración, envíe una solicitud
GETal siguiente punto final como usuario con el rolProject Read Only. La respuesta muestra el estado actual, el motivo del activador y las marcas de tiempo del proyecto:GET /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
Recuperarse de una reconciliación atascada
Si el MongoDB Ops Manager primario se reinicia mientras está en modo de restauración, vuelve a activar la conciliación en la siguiente encuesta de MongoDB Agent. No es necesario que realice ninguna acción para el caso de reinicio.
Es posible que la conciliación no se complete, por ejemplo, porque los agentes no están disponibles. En ese caso, utilice uno de los siguientes puntos de conexión de la API como usuario con el rol Project Owner:
Para reintentar la conciliación, envíe una solicitud
POSTal siguiente endpoint. El reintento restablece el contador de errores de conciliación y vuelve a ejecutar la conciliación sin salir del modo de restauración:POST /api/public/v1.0/groups/{PROJECT-ID}/restorationMode/retry Para forzar al MongoDB Ops Manager primario a salir del modo de restauración y aceptar la configuración restaurada, envíe una solicitud
DELETEal siguiente punto final:DELETE /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
Advertencia
Cuando obliga al MongoDB Ops Manager primario a salir del modo de restauración, acepta la configuración restaurada sin conciliar las configuraciones posteriores del agente. Utilice este endpoint solo cuando la conciliación no pueda completarse. Después de la salida forzada, el MongoDB Ops Manager primario sirve la configuración restaurada a todos los agentes del proyecto y no volverá a entrar en el modo de restauración hasta que todos los agentes hayan convergido en ella.
Cut Over to the Restored Ops Manager
Este patrón restaura el MongoDB Ops Manager primario en su lugar. No promueve el MongoDB Ops Manager secundario para reemplazar el MongoDB Ops Manager primario.
Después de validar el Ops Manager primario restaurado, complete la migración:
Actualiza la configuración
URL to Access Ops Managery cualquier registro DNS para que apunten al MongoDB Ops Manager primario restaurado.Confirme que los agentes de MongoDB se conecten al MongoDB Ops Manager primario restaurado. Los agentes se vuelven a conectar sin volver a registrarse cuando el
mmsGroupIdy elmmsApiKeyde su configuración coinciden con los registros del proyecto restaurado.
Orientación operativa
Utilice las siguientes prácticas para operar y validar este patrón a lo largo del tiempo.
Pruebe la ruta de copia de seguridad y restauración
Una restauración no probada es un riesgo operativo. Pruebe esta ruta de copia de seguridad y restauración con regularidad. Trate el siguiente runbook como una práctica requerida, no como una orientación opcional:
Realice una restauración de prueba en un cronograma. Restaure las bases de datos de respaldo en un MongoDB Ops Manager de espacio aislado y confirme que se inicia y se concilia.
Confirma que los snapshots aparecen en el cronograma y que la ventana de recuperación de punto en el tiempo permanece continua.
Revisa los registros del MongoDB Ops Manager primario y del MongoDB Ops Manager secundario para detectar errores en la copia de seguridad y la restauración.
Supervisar el MongoDB Ops Manager secundario
Supervise el MongoDB Ops Manager secundario y las bases de datos de respaldo que respalda:
Utilice las alertas de copia de seguridad de Ops Manager para detectar snapshots perdidos o fallidos de las bases de datos de respaldo.
Confirme que la ventana de recuperación a un momento dado se mantiene continua y sigue avanzando.
Supervise el estado de la base de datos de la aplicación del Ops Manager secundario y del daemon de copias de seguridad.
Escenarios de falla
En la siguiente tabla se describe cómo se comporta este patrón en escenarios de error comunes:
Scenario | impacto | Recuperación |
|---|---|---|
MongoDB Ops Manager secundario no disponible temporalmente | Las nuevas copias de seguridad y restauración se pausan. El MongoDB Ops Manager primario y todos los agentes gestionados continúan ejecutándose. | Restaure el MongoDB Ops Manager secundario. Los agentes de copia de seguridad se reanudan automáticamente. |
MongoDB Ops Manager secundario falla después de una restauración | Ninguno. Después de restaurar la base de datos de la aplicación, la instancia primaria de MongoDB Ops Manager entra en modo de restauración y se concilia sin la instancia secundaria de MongoDB Ops Manager. | No se requiere ninguna acción. |
Pérdida de ambas instancias de MongoDB Ops Manager | Perderá la recuperación puntual de la base de datos de la aplicación del Ops Manager principal. | Reconstruya el MongoDB Ops Manager secundario y vuelva a importar la base de datos de la aplicación, o reconstruya el MongoDB Ops Manager primario y vuelva a importar sus clústeres manualmente. |
Rendimiento, almacenamiento y consideraciones de costo
Tenga en cuenta lo siguiente cuando ejecute un MongoDB Ops Manager secundario dedicado:
El tamaño del MongoDB Ops Manager secundario debe ser considerablemente menor que el de un MongoDB Ops Manager principal de producción. Solo gestiona las bases de datos de respaldo del MongoDB Ops Manager principal para la copia de seguridad y la restauración, y no gestiona sus clústeres de MongoDB.
Planifique la capacidad de almacenamiento de snapshot para las bases de datos de respaldo en función de su cronograma de snapshot y política de retención.
Tenga en cuenta la infraestructura extra y el costo operativo de ejecutar un MongoDB Ops Manager secundario dedicado.