Este FAQ aborda preguntas comunes sobre Ops Manager y cómo respalda y restaura bases de datos y colecciones.
La introducción del MongoDB Agent y el nuevo proceso de copia de seguridad para MongoDB 4.2 con una compatibilidad de características entre versiones de 4.2 He cambiado algunas de estas respuestas. Esas respuestas cuentan con advertencias que explican el impacto de estas nuevas funcionalidades en las respuestas existentes.
Requisitos
¿Qué versión de MongoDB requiere la funcionalidad de copia de seguridad?
Serie de lanzamientos de Ops Manager | 1,6 a 1,8 | 2.0 a 3.2 | 3.4 | 3.6 | 4.0 | 4.2 |
|---|---|---|---|---|---|---|
Versión mínima de MongoDB 2.4 | 2.4.3 | 2.4.3 | 2.4.3 | 2.4.0 [1] | ||
Versión mínima de MongoDB 2.6 | 2.6.0 | 2.6.0 | 2.6.0 | 2.6.0 | 2.6.0 | 2.6.0 [2] |
Versión mínima MongoDB 3.0 | 3.0.0 | 3.0.0 | 3.0.0 | 3.0.0 | 3.0.0 | 3.0.0 [2] |
Versión mínima de MongoDB 3.2 | 3.2.0 | 3.2.0 | 3.2.0 | 3.2.0 | 3.2.0 | |
Versión mínima de MongoDB 3.4 | 3.4.0 | 3.4.0 | 3.4.0 | 3.4.0 | ||
Versión mínima de MongoDB 3.6 | 3.6.0 | 3.6.0 | 3.6.0 | |||
Versión mínima de MongoDB 4.0 | 4.0.0 | 4.0.0 | ||||
Versión mínima de MongoDB 4.2 | 4.2.0 |
| [1] | Solo supervisión |
| [2] | (1, 2) Solo supervisión y copia de seguridad |
¿Qué permisos de MongoDB requiere la copia de seguridad?
Si estás realizando un respaldo de una instancia de MongoDB que tiene la autenticación activada, el MongoDB Agent requiere los privilegios descritos para la función de copia de seguridad del MongoDB Agent.
¿Cómo mide el tamaño de los datos Ops Manager?
Ops Manager utiliza las siguientes conversiones para medir el tamaño de los snapshots y para medir cuántos datos de oplog se han procesado:
1 MB = 1024 2 bytes (1 MiB)
1 GB = 1024 3 bytes (1 GiB)
1 TB = 1024 4 bytes (1 TiB)
¿La copia de seguridad funciona con todo tipo de implementaciones?
Para MongoDB 4.2 y versiones posteriores, consulta Consideraciones de copia de seguridad para bases de datos.
Para cualquier MongoDB con compatibilidad de características entre versiones
4.0y bases de datos anteriores, Copia de seguridad no admite implementaciones independientes. Copia de seguridad tiene soporte completo para conjuntos de réplicas y clústeres fragmentados.
¿Por qué la funcionalidad de copia de seguridad no es compatible con las implementaciones autónomas?
Ops Manager copia los datos del oplog para proporcionar una copia de seguridad continua con recuperación a puntos en el tiempo. Ops Manager no admite la copia de seguridad de hosts independientes porque no tienen un oplog. Para admitir la copia de seguridad con una única mongod instancia, puedes ejecutar un set de réplicas de un solo miembro.
Operaciones
¿Cómo funciona la funcionalidad de copia de seguridad?
Para aprender sobre la funcionalidad de copia de seguridad, consulta Proceso de copia de seguridad.
¿Afectará la copia de seguridad a mis bases de datos de producción?
Nota
Esta respuesta se aplica solo a bases de datos que ejecutan MongoDB con compatibilidad de características entre versiones 4.0 y versiones anteriores
La funcionalidad de copia de seguridad generalmente tiene un impacto mínimo en las implementaciones de MongoDB en producción. Este impacto se comporta de manera similar a la de agregar un nuevo secundario a un set de réplicas.
Por defecto, el agente realiza su sincronización inicial, la operación que consume más recursos para las copias de seguridad, sobre un miembro secundario del set de réplicas para limitar su impacto. Opcionalmente, puedes configurar el agente de copias de seguridad para realizar la sincronización inicial contra la primaria del conjunto de réplicas, aunque esto aumenta el impacto de la operación de sincronización inicial.
¿Cómo mantengo un set de réplicas con la copia de seguridad habilitada?
La mayoría de las operaciones en un set de réplicas se replican a través del oplog y, por lo tanto, son capturadas por el proceso de copia de seguridad. Algunas operaciones, sin embargo, hacen cambios que no se replican: para estas operaciones, debe realizar que Ops Manager sincronice nuevamente desde su set de réplicas actual para incluir los cambios.
Las siguientes operaciones no se replican y, por lo tanto, requieren resincronización:
Renombrar o borrar una base de datos borrando los archivos de datos en el directorio de datos. Como alternativa, remueve bases de datos utilizando una operación que MongoDB replicará, como
db.dropDatabase()desdemongosh.Cambiar cualquier dato mientras la instancia se encuentra ejecutándose como un autónomo.
Creación de índices continua.
Utiliza
compactorepairDatabasepara recuperar una cantidad significativa de espacio.La resincronización no es estrictamente necesaria después de las operaciones
compactorepairDatabaseoperaciones, pero garantizara que la copia de los datos de Ops Manager se redimensione, lo que significa restauraciones más rápidas.
Agente de copia de seguridad heredado
La capacidad de copia de seguridad se ha trasladado al MongoDB Agent con la copia de seguridad activada. Esto reemplaza al Agente de copia de seguridad individual. Esta información cubre problemas únicos del antiguo agente de respaldo. Toda esta información se aplica a las bases de datos de MongoDB que ejecutan compatibilidad de características entre versiones 4.0 o una versión anterior.
¿Dónde debo ejecutar el agente de copia de seguridad?
Ejecuta el agente de copia de seguridad en un host:
Es independiente de tus instancias de MongoDB. Esto evita la disputa por recursos del sistema.
Puede conectarse a sus instancias de MongoDB. Verifica la configuración de la red para las conexiones entre el agente y los hosts de MongoDB. Para obtener una lista de los puertos necesarios, consulta puertos abiertos para agentes.
Cuenta con al menos 2 núcleos de CPU y 3 GB de RAM por encima de los requisitos de la plataforma. Con cada tarea de copia de seguridad que ejecuta, el agente de copias de seguridad impacta aún más el rendimiento del host.
¿Puedo ejecutar los agentes de copia de seguridad y supervisión en un solo sistema?
No existe ninguna restricción técnica que impida que el agente de copias de seguridad y la Supervisión funcionen en un solo sistema o host. Sin embargo, ambos agentes tienen requisitos de recursos, y ejecutarlos en un solo sistema puede afectar la capacidad de estos agentes para soportar tu implementación en Ops Manager.
Los recursos requeridos por el agente de copias de seguridad dependen de la velocidad y tamaño de las nuevas entradas de oplog (es decir, de la cantidad total de gigabytes de oplog producidos por hora). Los recursos que requiere la supervisión dependen del número de instancias mongod supervisadas y del número total de bases de datos proporcionadas por las instancias mongod.
¿Puedo ejecutar varios agentes de copia de seguridad para lograr una alta disponibilidad?
Puedes ejecutar varios agentes de copia de seguridad para alta disponibilidad. En ese caso, los agentes de copias de seguridad deben ejecutarse en diferentes hosts.
Cuando ejecutas varios agentes de copia de seguridad, solo un agente por proyecto es el agente principal. El agente principal realiza las copias de seguridad. Los agentes restantes están completamente inactivos, excepto para registrar su estado como reservas y para preguntar periódicamente al Ops Manager si deben convertirse en el principal.
¿El agente de copia de seguridad modifica mi base de datos?
El agente de copias de seguridad escribe un pequeño token llamado punto de control en el oplog de la base de datos de origen a intervalos regulares. Estos tokens proporcionan un latido para las copias de seguridad y no tienen ningún efecto en la implementación fuente. Cada token tiene menos de 100 bytes.
Importante
Puedes utilizar puntos de control para clústeres que ejecuten MongoDB con la compatibilidad de características entre versiones del 4.0 o anterior. Los puntos de control se eliminaron de las instancias de MongoDB con una compatibilidad de características entre versiones de 4.2 o superior.
¿Cómo afecta la sincronización de la copia de seguridad inicial al rendimiento de la base de datos?
El impacto de la sincronización inicial de la copia de seguridad debe ser similar a la sincronización de un nuevo miembro del set de réplicas secundarias. El agente de copias de seguridad no limita su actividad y trata de realizar la sincronizar lo más rápido posible.
Filtros de namespaces
Nota
El filtrado de namespace sólo es compatible con versiones de Ops Manager 6.0.8 y posteriores. Tus implementaciones de MongoDB deben tener featureCompatibilityVersion valores de 4.0 y anteriores o 6.0.1 y posteriores.
¿Cómo puedo evitar que Ops Manager respalde una colección?
Ops Manager proporciona un filtro de namespaces que te permite especificar qué colecciones o bases de datos respaldar.
¿Cómo puedo cambiar qué espacios de nombres se respaldan?
Para editar el filtro, consulta Editar la configuración de una copia de seguridad. Cambiar el filtro de namespace podría requerir una resincronización. Si es así, Ops Manager gestiona la resincronización.
¿Cómo puedo usar la copia de seguridad si las tareas de copia de seguridad fallan al vincularse?
La razón más común por la que las tareas no se vinculan a un daemon de copias de seguridad es que ningún demonio tiene espacio para una copia local del set de réplicas respaldado.
Para aumentar la capacidad y permitir que la tarea de copia de seguridad se asocie correctamente, puede:
añada un daemon de copias de seguridad adicional.
aumenta el tamaño del sistema de archivos que contiene el
head directory.En compatibilidad de características entre versiones 4.0 y anteriores, mueve los datos de
head databasea un nuevo volumen con más espacio y crea un symlink o configura los puntos de montaje del sistema de archivos para que el demonio pueda acceder a los datos usando la ruta original.FCV 4.2 y versiones posteriores no utilizan bases de datos principales.
¿Cómo resuelvo los errores applyOps durante las copias de seguridad?
Si notas errores coherentes en applyOps comandos en tus registros de copia de seguridad, esto puede indicar que el demonio se ha quedado sin espacio.
Para aumentar el espacio en un demonio y permitir operaciones continuas, puede:
aumenta el tamaño del sistema de archivos que contiene el
head directory.Para compatibilidad de características entre versiones 4.0 y anteriores, mueve los datos de
head databasea un nuevo volumen con más espacio y crea un enlace simbólico o configura los puntos de montaje del sistema de archivos para que el demonio pueda acceder a los datos usando la ruta original.FCV 4.2 y versiones posteriores no utilizan bases de datos principales.
Restauración de datos
Ops Manager realiza una copia de sus archivos de datos que puede utilizar para iniciar una nueva implementación.
¿Cómo proporciona Ops Manager restauración a un punto específico del tiempo?
Importante
Ops Manager 4.2.13 y versiones posteriores admiten esta funcionalidad con FCV 4.2 o posterior.
Cuando activas la restauración, Ops Manager crea un enlace a este snapshot. Una vez hecho clic, Ops Manager recupera fragmentos del almacenamiento de snapshot y los transmite al host de destino.
La utilidad de copia de seguridad y restauración de MongoDB que se ejecuta en ese host luego descarga y aplica las entradas del oplog para alcanzar el punto en el tiempo especificado.
La capacidad de Ops Manager para proporcionar una restauración a un punto específico del tiempo depende de la política de retención de los snapshots y de la ventana configurada de punto en el tiempo.
Para obtener más información sobre la política de retención y la ventana de punto en el tiempo, consulta Editar el cronograma de snapshots y la política de retención.
¿Puedo tomar snapshot con más frecuencia que cada 6 horas?
No. El Gestor de operaciones no es compatible con un cronograma de snapshots más frecuente que cada 6 horas. Para obtener más información, consulta la frecuencia de snapshot y política de retención.
¿Puedo establecer mi propia política de retención de snapshots?
Sí. Puedes cambiar el cronograma a través del Edit Snapshot Schedule opción de menú para una implementación respaldada. Los administradores pueden cambiar la frecuencia de snapshot y política de retención a través del recurso snapshotSchedule en la API.
¿Cuánto tiempo lleva crear una snapshot de restauración?
Ops Manager transmite todas las copias de seguridad en forma comprimida desde el host de Ops Manager a tu infraestructura.
Además, las restauraciones a un punto específico del tiempo dependen de la cantidad de entradas en el oplog que su host debe aplicar a la snapshot recibida para avanzar hacia el punto de copia de seguridad solicitado en el tiempo.
¿La funcionalidad de copia de seguridad realiza alguna validación de datos?
La copia de seguridad realiza verificaciones básicas de corrupción y proporciona una alerta si algún componente (por ejemplo, el agente) está apagado o roto, pero no realiza una validación explícita de los datos. Cuando se detecta corrupción, Ops Manager actúa con cautela e invalida la copia de seguridad actual y envía una alerta.
¿Cómo restauro una snapshot?
Puedes solicitar una restauración a través de Ops Manager, donde podrás elegir qué snapshot restaurar y cómo quieres que Ops Manager realice la restauración. Todas las restauraciones requieren autenticación de dos factores. Si tienes configurado el SMS, Ops Manager enviará un código de autorización por SMS. Debes ingresar el código de autorización en la interfaz de copia de seguridad para iniciar el proceso de restauración.
Nota
Desde la India, utiliza Google Authenticator para la autenticación de dos factores. Google Authenticator es más fiable que la autenticación con mensajes de texto SMS a números de teléfono móvil indios (por ejemplo, código de país 91).
¿Qué se entrega cuando restauro un snapshot?
Ops Manager realiza restauraciones como tar.gz ficheros de los archivos de datos de MongoDB.
Para obtener más información sobre las restauraciones, consulta Restaurar las implementaciones de MongoDB.
¿Cómo realiza Ops Manager el retroceso de los datos respaldados?
Importante
Para las implementaciones de MongoDB que ejecutan compatibilidad de características entre versiones 4.2 o posteriores, los rollbacks no afectan los datos respaldados en Ops Manager. Desde compatibilidad de características entre versiones 4.2 en adelante, el Gestor de Operaciones solo conserva snapshots con registros de tiempo hasta e incluyendo el punto de confirmación de mayoría.
Si su implementación de MongoDB experimenta un rollback, entonces Ops Manager también retrocede los datos respaldados.
Ops Manager detecta el rollback cuando un cursor a la cola encuentra una discrepancia en las marcas de tiempo o hashes de las operaciones de escritura. Ops Manager entra en un estado de rollback y prueba tres puntos en el oplog del primario de su set de réplicas para encontrar un punto común en la historia. La rollback de Ops Manager difiere de la rollback secundaria de MongoDB en que el punto en común no necesariamente tiene que ser el punto en común más reciente.
Cuando Ops Manager encuentra un punto común, el servicio invalida las entradas del oplog y los snapshots más allá de ese punto y retrocede al snapshot más reciente antes del punto común. Ops Manager luego reanuda las operaciones normales de copia de seguridad.
Si Ops Manager no puede encontrar un punto común, es necesario resincronizar.
¿Qué condiciones requieren una resynchronización?
Importante
Esta funcionalidad es incompatible con MongoDB 4.2 con compatibilidad de características entre versiones 4.2.
Si el cursor tailing del agente de copias de seguridad no puede seguir el ritmo del oplog de tu implementación, entonces debes sincronizar nuevamente tus copias de seguridad.
Este escenario podría ocurrir si:
Su aplicación genera periódicamente muchos datos, lo que reduce la oplog window del primario al punto de que los datos se escriben en el oplog más rápido de lo que Ops Manager puede consumirlos.
Si el agente de copias de seguridad se ejecuta en un sistema poco aprovisionado o sobreutilizado y no alcanza a mantenerse al día con la actividad del oplog.
Si el agente de copias de seguridad está caído durante un período de tiempo superior al que permite el tamaño del oplog. Si detienes tus agentes, por ejemplo por tareas de mantenimiento, reinícialos de manera oportuna. Para obtener más información sobre el tamaño del oplog, consulte oplog del set de réplicas en el manual de MongoDB.
Si borras todos los datos del set de réplicas y implementas un nuevo set de réplicas con el mismo nombre, como podría ocurrir en un entorno de prueba donde las implementaciones se desmontan y reconstruyen regularmente.
Si se produce una reversión y Ops Manager no puede encontrar un punto en común en el oplog.
Si un evento oplog intenta actualizar un documento que no existe en la copia de seguridad del set de réplicas, como podría ocurrir si se sincroniza desde un secundario que tiene datos inconsistentes con respecto al primario.