Estas preguntas frecuentes abordan preguntas comunes sobre Cloud Manager y cómo realiza copias de seguridad 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 FCV 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é 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 Cloud Manager el tamaño de los datos?
Cloud Manager utiliza las siguientes conversiones para medir el tamaño de la snapshot y medir la cantidad de datos de oplog que 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 función de copia de seguridad no admite implementaciones independientes?
Cloud Manager copia datos del oplog para proporcionar una copia de seguridad continua con recuperación puntual. Cloud Manager no admite la copia de seguridad de hosts autónomos 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
¿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 de 4.0 o anterior.
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 más recursos consume para las copias de seguridad, contra un miembro secundario del set de réplicas para limitar su impacto. Opcionalmente, puedes configurar el agente para que realice la sincronización inicial contra el primario del set de réplicas, aunque esto incrementa el impacto de la operación de sincronización inicial.
¿Mis datos están seguros?
Sí, Cloud Manager utiliza hardware de nivel empresarial ubicado en centros de datos seguros para almacenar todos los datos de los usuarios. La copia de seguridad transmite todos los datos mediante SSL. Los datos se almacenan y procesan en volúmenes cifrados. Cloud Manager requiere autenticación de dos factores para proporcionar los datos necesarios para las restauraciones.
¿Existe un límite para el tamaño de la copia de seguridad?
Actualmente, no existe ningún límite al tamaño total del almacenamiento de snapshots. La copia de seguridad funciona mejor para implementaciones cuyo tamaño total es inferior a 2 TB.
Si deseas utilizar la funcionalidad de copia de seguridad para una implementación más grande, por favor, contáctanos para obtener más información.
¿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. Sin embargo, algunas operaciones realizan cambios que no se replican: para estas operaciones,debe solicitar a Cloud Manager que resincronice 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
compactorepairDatabaseoperaciones, pero garantizará que la copia de los datos de Cloud Manager cambie de tamaño, lo que significa restauraciones más rápidas y menores costos.
¿Cuánto cuesta usar Cloud Manager copia de seguridad?
El precio de Cloud Manager Backup se basa en el tamaño de las instantáneas, la programación y la política de retención. Consulta los precios de las copias de seguridad.
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 respaldo?
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. Compruebe la configuración de red para ver las conexiones entre el agente y los hosts de MongoDB. Para obtener una lista de los puertos necesarios, consulte los puertos abiertos para los agentes.
Tiene al menos 2 núcleos de CPU y 3 GB de RAM por encima de los requisitos de la plataforma. Con cada trabajo de copia de seguridad que ejecuta, el Agente de Copia de Seguridad afecta 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 Backup y el de Monitoreo se ejecuten en un mismo sistema o host. Sin embargo, ambos agentes tienen requisitos de recursos, y ejecutarlos en un mismo sistema puede afectar su capacidad para soportar su implementación en Cloud Manager.
Los recursos requeridos por el Agente de Backup dependen de la velocidad y el tamaño de las nuevas entradas de oplog (es decir, el total de gigabytes/hora de oplog producidos). Los recursos que requiere el Monitoreo dependen de la cantidad de instancias monitoreadas mongod y la cantidad total de bases de datos proporcionadas por las mongod instancias.
¿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 ejecutes varios agentes de copias de seguridad, sólo un agente por Proyecto será el agente principal. El agente primario realiza las copias de seguridad. Los agentes restantes están completamente inactivos, salvo para registrar su estado como agentes en espera y preguntar periódicamente al Cloud Manager si deberían convertirse en los principales.
¿El agente de copia de seguridad modifica mi base de datos?
El Agente de Backup escribe un pequeño token, llamado punto de control, en el registro de operaciones de la base de datos de origen a intervalos regulares. Estos tokens proporcionan un latido para las copias de seguridad y no afectan la implementación de origen. Cada token tiene menos de 100 bytes.
Importante
Puede usar puntos de control para clústeres que ejecutan MongoDB con Feature Compatibility Version de 4.0 o anterior. Los puntos de control se eliminaron de las instancias de MongoDB con FCV 4.2 o posterior.
¿Cómo afecta la sincronización de 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.
¿La copia de seguridad admite TLS?
La copia de seguridad siempre se conecta a los servidores Cloud Manager mediante una conexión TLS (HTTPS).
La copia de seguridad puede conectarse a conjuntos de réplicas y clústeres compartidos configurados con TLS.
Filtros de namespaces
Nota
El filtrado de namespaces solo es compatible con las versiones 6.0.8 y posteriores de Cloud Manager. Tus implementaciones de MongoDB deben tener featureCompatibilityVersion valores de 4.0 y anteriores o 6.0.1 y posteriores.
¿Cómo puedo evitar que Cloud Manager haga una copia de seguridad de una colección?
Cloud Manager proporciona un filtro de namespaces que permite especificar qué colecciones o bases de datos hay que 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. En ese caso, Cloud Manager gestiona la resincronización.
Restauración de datos
Cloud Manager genera una copia de tus archivos de datos que puedes utilizar para iniciar una nueva implementación.
¿Cómo proporciona Cloud Manager restauraciones en un punto determinado del tiempo?
Cuando desencadena la restauración, el Gestor de la Nube crea un enlace a esta snapshot. Una vez hecho clic, Cloud 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.
Cloud Manager puede crear una restauración en cualquier momento dentro de un período de 24 horas reproduciendo el oplog hasta el momento deseado.
Para aprender a restaurar sets de réplicas y clústeres, consulta Restaurar implementaciones de MongoDB.
¿Puedo tomar instantáneas con una frecuencia mayor a cada 6 horas?
No. El gestor de la nube no admite un cronograma de snapshot más frecuente que cada 6 horas. Para obtener más información, consulta 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.
La personalización de la frecuencia de las instantáneas y las políticas de retención le brinda un mayor control sobre sus costos de respaldo.
¿Cuántas copias de mis datos almacena Cloud Manager?
Aunque sólo se le cobre por una única copia de los datos, Cloud Manager almacena al menos 3 copias de sus datos en al menos 2 ubicaciones geográficas para garantizar la redundancia.
¿Cuánto tiempo se tarda en crear una instantánea de restauración?
Cloud Manager transmite todas las copias de seguridad en una forma comprimida desde el host de Cloud Manager a su infraestructura.
Dentro de los Estados Unidos, Cloud Manager envía instantáneas a 50 a 100 Mbps. Suponiendo un factor de compresión de 4x y velocidades de transmisión de 50 Mbps, transmitir una snapshot de 250 GB toma 2.5 horas.
Además, las restauraciones en un punto en el tiempo dependen de la cantidad de entradas del registro de operaciones que su host debe aplicar a la instantánea recibida para avanzar al punto en el tiempo solicitado de la copia de seguridad.
¿La funcionalidad de copia de seguridad realiza alguna validación de datos?
La copia de seguridad realiza comprobaciones básicas de corrupción y envía una alerta si algún componente (por ejemplo, el agente) está caído o roto, pero no realiza una validación explícita de los datos. Cuando detecta corrupción, Cloud Manager actúa con precaución e invalida la copia de seguridad actual y envía una alerta.
¿Cómo restauro una instantánea?
Puede solicitar una restauración a través de Cloud Manager, donde podrá elegir qué instantánea restaurar y cómo desea que Cloud Manager la entregue. Todas las restauraciones requieren autenticación de dos factores. Si ha configurado el servicio de SMS, Cloud Manager le enviará un código de autorización por SMS. Debe introducir 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 una instantánea?
Cloud Manager entrega restauraciones como archivos tar.gz de archivos de datos de MongoDB.
Para obtener más información sobre las restauraciones, consulta Restaurar las implementaciones de MongoDB.
¿Cómo Cloud Manager revierte los datos respaldados?
Si la implementación de MongoDB experimenta un rollback, Cloud Manager también revierte los datos respaldados.
Cloud Manager detecta la reversión cuando un cursor de cola encuentra una discrepancia en las marcas de tiempo o hashes de las operaciones de escritura. Cloud Manager entra en estado de reversión y prueba tres puntos en el registro de operaciones del conjunto de réplicas principal para localizar un punto común en el historial. La reversión de Cloud Manager se diferencia de la reversión secundaria de MongoDB en que el punto común no tiene que ser necesariamente el más reciente.
Cuando Cloud Manager encuentra un punto común, el servicio invalida las entradas del registro de operaciones y las instantáneas posteriores a ese punto y revierte a la instantánea más reciente anterior al punto común. Cloud Manager reanuda entonces las operaciones de copia de seguridad normales.
Si Cloud Manager no puede encontrar un punto común, se requiere una resincronización.
¿Qué condiciones requieren una resincronizació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:
Tu aplicación genera periódicamente grandes cantidades de datos, reduciendo la oplog window del primario hasta el punto en que los datos se escriben en la oplog más rápido de lo que Cloud Manager puede procesarlos.
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 hay una reversión y Cloud Manager no puede encontrar un punto común en el registro de operaciones.
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.