Puede implementar una segunda instancia de MongoDB Ops Manager, denominada MongoDB Ops Manager secundario, para realizar una copia de seguridad de un MongoDB Ops Manager primario y sus bases de datos de respaldo. El Ops Manager secundario también sirve como ruta de recuperación si pierde el Ops Manager principal.
Este patrón protege los datos operativos que Ops Manager almacena en su base de datos de la aplicación y almacenes de metadatos. Utilice esta guía para diseñar, configurar y operar la recuperación ante desastres para el propio Ops Manager.
Esta guía está dirigida a los administradores de MongoDB Ops Manager que gestionan copias de seguridad y recuperación ante desastres, y a los equipos que diseñan topologías de alta disponibilidad y recuperación ante desastres para MongoDB Ops Manager.
Cómo funciona la copia de seguridad secundaria de MongoDB Ops Manager
En este patrón, dos instancias de MongoDB Ops Manager tienen responsabilidades distintas:
El MongoDB Ops Manager primario gestiona sus implementaciones de MongoDB y sus copias de seguridad, como de costumbre.
El Ops Manager secundario gestiona y realiza copias de seguridad únicamente de las bases de datos de respaldo del Ops Manager principal. El Ops Manager secundario no gestiona los clústeres de su aplicación.
El MongoDB Agent se ejecuta en cada host de la base de datos de la aplicación del Ops Manager principal y se registra con el Ops Manager secundario. El Ops Manager secundario realiza copias de seguridad continuas y puntuales de esas bases de datos de respaldo.
Si pierdes el Ops Manager principal, restauras sus bases de datos de respaldo desde el Ops Manager secundario y luego inicias un nuevo Ops Manager principal. El Ops Manager principal se vuelve a conectar a las bases de datos de respaldo restauradas y reanuda la gestión de tus implementaciones de MongoDB.
Cuando los agentes de MongoDB se vuelven a conectar después del reinicio, informan una versión de configuración más reciente que la base de datos restaurada. El MongoDB Ops Manager principal detecta la falta de coincidencia, ingresa automáticamente en el modo de restauración para el proyecto afectado, converge todos los agentes en la configuración restaurada y bloquea los cambios de implementación hasta que se complete la conciliación.
Arquitectura
La siguiente tabla describe los componentes de este patrón y sus responsabilidades:
Componente | Responsabilidad |
|---|---|
MongoDB Ops Manager primario | Gestiona las implementaciones de MongoDB y sus copias de seguridad. Almacena sus propios datos operativos en su base de datos de la aplicación, el almacén de metadatos de snapshot y el almacén de metadatos de oplog. |
MongoDB Ops Manager secundario | Ejecuta un daemon de copias de seguridad que guarda en un almacenamiento en bloques compatible con S3para snapshots de bases de datos de aplicaciones y segmentos de oplog. Realiza copias de seguridad continuas de las bases de datos de respaldo del Ops Manager principal. No gestiona los clústeres de la aplicación. |
base de datos de la aplicación | Almacena los datos operativos del Ops Manager principal, incluida la configuración del proyecto, el estado de automatización y los metadatos de copia de seguridad. Debe realizar una copia de seguridad de la base de datos de la aplicación. |
Almacenes de metadatos de snapshot y oplog | Almacene los índices de bloque y oplog para las implementaciones de las que el Ops Manager principal realiza copias de seguridad. Realice también una copia de seguridad de estos almacenes. |
MongoDB Agent | Se ejecuta en cada host de la base de datos de respaldo y se registra en el Ops Manager secundario para realizar copias de seguridad y restauraciones. |
El Ops Manager secundario almacena las copias de seguridad de las bases de datos de respaldo del Ops Manager principal en su propio almacenamiento en bloques compatible con S3, separado del almacenamiento de copias de seguridad del Ops Manager principal.
Variantes de implementación
Implemente el MongoDB Ops Manager secundario en un dominio de error independiente del MongoDB Ops Manager principal para evitar que un único error afecte a ambas instancias. Las variantes comunes incluyen:
Regiones diferentes
Implemente el MongoDB Ops Manager secundario en una región de la nube diferente a la del MongoDB Ops Manager principal. Esta variante protege contra la pérdida de una región.
Diferentes centros de datos
Implemente el MongoDB Ops Manager secundario en un centro de datos diferente al MongoDB Ops Manager primario. Esta variante protege contra la pérdida de un centro de datos.
Red de copia de seguridad independiente
Coloque el Ops Manager secundario en una red independiente dedicada al tráfico de copias de seguridad. Esta variante aísla el tráfico de copias de seguridad de la red de la aplicación.
Importante
Implemente el MongoDB Ops Manager secundario en un dominio de error independiente, como un rack, una zona de disponibilidad, una región o un segmento de red diferentes, del MongoDB Ops Manager primario. Si ambas instancias comparten un dominio de error, un solo error puede interrumpir tanto el MongoDB Ops Manager primario como su ruta de recuperación.
Versiones compatibles y limitaciones
Antes de usar este patrón, revise los siguientes requisitos y limitaciones.
Versiones compatibles
Tanto la instancia principal como la secundaria de MongoDB Ops Manager deben ejecutar MongoDB Ops Manager 8.0.24 o posterior.
El MongoDB Ops Manager secundario debe ejecutar la misma versión o una posterior que el MongoDB Ops Manager principal. No ejecute un MongoDB Ops Manager secundario que sea una versión anterior a la del MongoDB Ops Manager principal.
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".
Limitaciones
Este patrón realiza una copia de seguridad de las bases de datos de respaldo del Ops Manager principal. No realiza copias de seguridad de clústeres arbitrarios de MongoDB. El Ops Manager principal continúa gestionando las copias de seguridad de sus implementaciones de MongoDB.
La copia de seguridad y la conciliación del almacén de metadatos de snapshot y del almacén de metadatos de oplog es un procedimiento manual. Ops Manager no selecciona automáticamente un punto de restauración para estos almacenes. Como resultado, los metadatos de la copia de seguridad pueden ser inconsistentes después de una restauración, y algunas copias de seguridad pueden no ser restaurables. Ops Manager valida una snapshot antes de restaurarla y falla con un error en lugar de realizar una restauración insegura.
El modo de restauración no se aplica a las implementaciones gestionadas externamente, como las implementaciones que gestiona un operador de Kubernetes. Después de restaurar la base de datos de la aplicación, los agentes de estos proyectos reciben la configuración restaurada directamente en su siguiente sondeo y convergen sin entrar en el modo de restauración. No se requiere ninguna acción para estos proyectos.
Una snapshot puede volverse irrecuperable si sus bloques de datos ya no están en el almacenamiento de snapshot. Antes de una restauración, el MongoDB Ops Manager primario verifica que existan los bloques de la snapshot. Si faltan bloques, la restauración falla con un error y deja el set de réplicas sin modificar, en lugar de borrarlo y fallar a mitad de camino.
Una restauración no probada es un riesgo operativo. Valide la ruta de copia de seguridad y restauración con regularidad. Consulte el manual de validación en Restauración de Ops Manager desde un Ops Manager secundario.
Próximos pasos
Para configurar y operar este patrón, consulte las siguientes páginas: