La copia de seguridad y la restauración de Ops Manager con una instancia secundaria de Ops Manager se encuentra en Vista previa. Esta función y su documentación pueden cambiar en cualquier momento durante el período de vista previa.
Cuando pierde el Administrador de operaciones principal, restaura su Realice copias de seguridad de las bases de datos desde el Administrador de operaciones secundario y, a continuación, inicie un nuevo Administrador de operaciones principal. Utilice este procedimiento tras un evento como una actualización fallida, la eliminación accidental de datos o un fallo de la infraestructura. Cuando el Administrador de operaciones principal se reinicie, entrará automáticamente en el modo de restauración para conciliar la configuración del agente antes de reanudar el funcionamiento normal. Para obtener una descripción general de este patrón,consulte Copia de seguridad y restauración del Administrador de operaciones mediante una instancia secundaria. Para configurar este patrón, consulte Configurar un Administrador de operaciones secundario para realizar copias de seguridad del Administrador de operaciones.
Considerations
Restablecer el orden
La secuencia de restauración de las bases de datos de respaldo y el inicio del Administrador de operaciones principal es fundamental.
Advertencia
Restaure las bases de datos de respaldo antes de iniciar el Administrador de operaciones principal. Si inicia el Administrador de operaciones principal antes de restaurar sus bases de datos de respaldo, este podría escribir información inconsistente y generar un escenario de división de clúster entre las implementaciones antiguas y nuevas.
Si el Administrador de operaciones secundario también realiza copias de seguridad del almacén de metadatos de instantáneas 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 Administrador de operaciones principal. Restaurar los almacenes de metadatos a un punto anterior al de la base de datos de la aplicación provoca que el Administrador de operaciones principal rechace los trabajos de restauración afectados con HTTP 409 ("faltan bloques de instantáneas").
Punto de recuperación
Una restauración puntual recupera la base de datos de la aplicación hasta el momento que usted seleccione, no hasta el momento del desastre. Es posible que las operaciones que Backup no registró en un fragmento del oplog antes del desastre no se puedan recuperar. Seleccione un punto de restauración lo más cercano posible al momento del desastre, dentro del margen de tiempo que permita la ventana de recuperación puntual.
Tras reiniciar el Administrador de operaciones principal, la reconciliación recupera la configuración de automatización de la implementación desde los agentes de MongoDB. Otros cambios recientes en la base de datos de la aplicación reflejan el punto de restauración que usted seleccione.
Compatibilidad de versiones
Las versiones principal y secundaria de Ops Manager deben seguir siendo compatibles.
Advertencia
Restaure la base de datos de la aplicación en un Ops Manager principal que ejecute la misma versión o una versión posterior a la del Ops Manager principal original del que se tomó la instantánea. Si el binario de reemplazo es anterior a la versión registrada en la base de datos de la aplicación, Ops Manager no se iniciará y mostrará el error "No se permiten reversiones".
Requisitos previos
El modo de restauración está habilitado de forma predeterminada en Ops Manager 8.0.24 y versiones posteriores. Si lo deshabilitó, vuelva a habilitarlo en el Ops Manager principal antes de restaurar. Para obtener más información, consulte Configurar un Ops Manager secundario para realizar copias de seguridad de Ops Manager.
Confirme que el Administrador de operaciones secundario tenga una instantánea completa y una ventana de recuperación continua en un punto específico en el tiempo para las bases de datos de respaldo.
Confirme que ha conservado el estado requerido por host para la recuperación, incluyendo el
gen.keyarchivo de la instalación principal original de Ops Manager.
Preservar el estado por huésped
Una recuperación completa del Ops Manager principal 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 Ops Manager secundario:
Item | Ubicación | Descripción |
|---|---|---|
Clave 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; de lo contrario, el Administrador de operaciones principal no podrá descifrar la base de datos de la aplicación restaurada al iniciarse. |
Configuración de Ops Manager |
| Almacena las URI de la base de datos, la configuración del almacén de bloques, las claves de licencia y los certificados TLS. Sin él, deberá reconfigurar manualmente el Administrador de operaciones principal. |
Configuración del agente |
| Almacena los valores |
Importante
Si el archivo gen.key no existe o no coincide con la base de datos de la aplicación restaurada, el Administrador de operaciones principal falla en su comprobación previa al inicio con un error que indica que gen.key no coincide con la clave ya utilizada para esta instalación del Administrador de operaciones. Conserve 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 administrador de operaciones principal
Restaurar las bases de datos de respaldo
En el Administrador de operaciones secundario, restaure la base de datos de la aplicación del Administrador de operaciones principal al punto en el tiempo que haya seleccionado:
Haga clic Continuous BackupLuego, seleccione el conjunto de réplicas de la base de datos de la aplicación.
Haz clic en el Restore menú y luego en.
Seleccione Point in Time y, a continuación, introduzca la fecha y hora de destino.
Haga clic en Choose Cluster to Restore to, seleccione los hosts del conjunto de réplicas de la base de datos de la aplicación y, a continuación, haga clic en Restore.
El agente MongoDB del administrador de operaciones secundario detiene los procesos de la base de datos de la aplicación, reemplaza los datos con la instantánea restaurada, reproduce el oplog hasta la hora de destino y reinicia los procesos.
Advertencia
Si el Administrador de operaciones secundario también realiza copias de seguridad de los almacenes de metadatos de instantáneas y oplog, restáurelos al mismo punto en el tiempo que la base de datos de la aplicación, o a un punto ligeramente posterior, antes de iniciar el Administrador de operaciones principal. Restaurar los almacenes de metadatos a un punto anterior provoca que el Administrador de operaciones principal rechace las tareas de restauración afectadas con el código HTTP 409 ("faltan bloques de instantáneas").
Si restaura únicamente la base de datos de la aplicación, el Administrador de operaciones secundario deja los almacenes de metadatos sin cambios. Esto es seguro para el funcionamiento normal, pero es posible que las instantáneas de copia de seguridad que el Administrador de operaciones principal tomó entre el punto de restauración y la actualidad no estén disponibles.
Inicie el administrador de operaciones principal.
Inicie el Administrador de operaciones principal. El Administrador de operaciones principal se conecta a la base de datos de la aplicación restaurada, lee el estado restaurado e inicia la recuperación. Para obtener más información, consulte Iniciar y detener la aplicación Administrador de operaciones.
Que se complete la reconciliación
El administrador de operaciones principal entra en modo de restauración y concilia automáticamente la configuración de la implementación. Mientras se ejecuta la conciliación, el administrador de operaciones principal muestra un banner de modo de restauración. No se requiere ninguna acción manual. El administrador de operaciones principal sale del modo de restauración cuando finaliza la conciliación.
Modo de restauración y reconciliación
Después de restaurar la base de datos de la aplicación e iniciar el Administrador de operaciones principal, este compara la versión de configuración de cada agente de MongoDB con la versión restaurada. Si un agente informa una versión posterior, el Administrador de operaciones principal entra en modo de restauración para ese proyecto y sincroniza la configuración automáticamente.
El administrador de operaciones principal aísla el proyecto. Muestra un banner de modo de restauración, devuelve una respuesta sin cambios a las consultas del agente y bloquea los cambios de implementación desde la interfaz de usuario y la API hasta que se complete la conciliación.
El administrador de operaciones principal recopila la versión de configuración de cada agente, selecciona el agente con la configuración más reciente y escribe esa configuración en la base de datos de la aplicación como la configuración autorizada.
El administrador de operaciones principal sale del modo de restauración del proyecto y reanuda el funcionamiento normal. Las copias de seguridad se reanudan automáticamente.
Esta reconciliación evita un escenario de división de cerebro. Hace converger a todos los agentes en una única configuración autorizada antes de que cualquier agente reciba una nueva configuración.
Al revertir 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 realizados después del punto de restauración. Sin la reconciliació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 miembro del conjunto de réplicas | Los datos ya existen en otros miembros, por lo que no perderás ningún dato. |
Nuevo fragmento con piezas migradas | Los fragmentos migrados solo existen en el nuevo shard. Si se detiene el proceso, esos datos se vuelven inaccesibles, lo que provoca la pérdida de datos. |
Nueva versión del proceso | El proceso no puede ejecutarse en la versión binaria revertida, lo que provoca una desviación operativa. |
Nuevo índice | Las consultas de índice se degradan hasta que Ops Manager reconstruye el índice. |
La reconciliación evita estos resultados. El administrador de operaciones principal sincroniza todos los agentes con la configuración más reciente y genera una instantánea bajo demanda antes de salir del modo de restauración, lo que proporciona un punto de copia de seguridad coherente.
Validar el Administrador de operaciones restaurado
Confirme que el Administrador de operaciones principal restaurado funciona correctamente:
Confirme que los agentes de MongoDB se vuelven a conectar e informan que funcionan correctamente.
Confirme que la automatización, las copias de seguridad y la monitorización se reanudan para sus implementaciones gestionadas.
Confirme que el administrador de operaciones principal salga del modo de restauración. Para comprobar el estado del modo de restauración, envíe una
GETsolicitud al siguiente punto final como usuario con elProject Read Onlyrol. La respuesta muestra el estado actual, el motivo del desencadenante y las marcas de tiempo del proyecto:GET /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
Cómo recuperarse de una reconciliación estancada
Si el Administrador de operaciones principal se reinicia mientras está en modo de restauración, se vuelve a activar la conciliación en la siguiente consulta del agente de MongoDB. No es necesario realizar ninguna acción en caso de reinicio.
Es posible que la reconciliación no se complete, por ejemplo, porque los agentes no están disponibles. En ese caso, utilice uno de los siguientes puntos finales de la API como usuario con el Project Owner rol:
Para volver a intentar la conciliación, envíe una solicitud
POSTal siguiente punto final. 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 administrador de operaciones principal 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 se fuerza al Administrador de operaciones principal a salir del modo de restauración, este acepta la configuración restaurada sin conciliar las configuraciones de los agentes posteriores. Utilice este punto final solo cuando la conciliación no pueda completarse. Tras la salida forzada, el Administrador de operaciones principal proporciona 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 la hayan adoptado.
Cambiar al Administrador de operaciones restaurado
Este patrón restablece al administrador de operaciones principal en su lugar. No promueve al administrador de operaciones secundario para que reemplace al administrador de operaciones principal.
Después de validar el Administrador de operaciones principal restaurado, complete la transición:
Actualice la configuración
URL to Access Ops Managery cualquier registro DNS para que apunten al Administrador de operaciones principal restaurado.Confirme que los agentes de MongoDB se conectan al administrador de operaciones principal restaurado. Los agentes se reconectan sin necesidad de volver a registrarse cuando los valores
mmsGroupIdymmsApiKeyde 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.
Prueba la ruta de copia de seguridad y restauración.
Una restauración no probada supone un riesgo operativo. Pruebe esta ruta de copia de seguridad y restauración con regularidad. Considere el siguiente manual como una práctica obligatoria, no como una recomendación opcional:
Realice una restauración de prueba según un cronograma. Restaure las bases de datos de respaldo en un Ops Manager de entorno aislado y confirme que se inicia y se sincroniza correctamente.
Confirme que las instantáneas aparecen según lo programado y que la ventana de recuperación a un punto en el tiempo se mantiene continua.
Revise los registros del Administrador de operaciones principal y del Administrador de operaciones secundario para detectar errores de copia de seguridad y restauración.
Supervisar al administrador de operaciones secundarias
Supervise el Administrador de operaciones secundario y las bases de datos de respaldo que este respalda:
Utilice las alertas de copia de seguridad de Ops Manager para detectar instantáneas faltantes o fallidas de las bases de datos de respaldo.
Confirme que la ventana de recuperación en un momento dado se mantiene continua y sigue avanzando.
Supervise el estado de la base de datos de la aplicación del Administrador de operaciones secundario y del demonio de copia de seguridad.
Escenarios de falla
La siguiente tabla describe cómo se comporta este patrón en escenarios de fallo comunes:
Scenario | impacto | Recuperación |
|---|---|---|
El administrador de operaciones secundarias no está disponible temporalmente. | Las nuevas copias de seguridad y restauraciones se pausan. El administrador de operaciones principal y todos los agentes administrados continúan en funcionamiento. | Restaurar el Administrador de operaciones secundario. Los agentes de copia de seguridad se reanudan automáticamente. |
El administrador de operaciones secundario falla después de una restauración. | Ninguno. Después de restaurar la base de datos de la aplicación, el Administrador de operaciones principal entra en modo de restauración y realiza la conciliación sin el Administrador de operaciones secundario. | No es necesario realizar ninguna acción. |
Pérdida de ambas instancias de Ops Manager. | Se pierde la capacidad de recuperación a un punto específico en el tiempo para la base de datos de la aplicación del Administrador de operaciones principal. | Reconstruya el Administrador de operaciones secundario y vuelva a importar la base de datos de la aplicación, o bien reconstruya el Administrador de operaciones principal y vuelva a importar los clústeres manualmente. |
Consideraciones sobre rendimiento, almacenamiento y costes
Tenga en cuenta lo siguiente al ejecutar un Administrador de operaciones secundario dedicado:
El tamaño del Administrador de operaciones secundario debe ser considerablemente menor que el del Administrador de operaciones principal de producción. Este solo gestiona las bases de datos de respaldo del Administrador de operaciones principal para copias de seguridad y restauración, y no gestiona los clústeres de MongoDB.
Planifique la capacidad de almacenamiento de instantáneas para las bases de datos de respaldo en función de su calendario de instantáneas y su política de retención.
Tenga en cuenta la infraestructura adicional y el coste operativo que supone gestionar un gestor de operaciones secundario dedicado.