Las copias de seguridad dependen de con qué versión de MongoDB es compatible tu base de datos. Esta compatibilidad de características entre versiones va desde la versión actual hasta una versión anterior. Para MongoDB 4.2, la compatibilidad de características entre versiones puede ser 4.0 o 4.2. Para implementaciones con FCV 4.2 o posteriores, Ops Manager requiere abrir un $backupCursor en el host fuente de copia de seguridad para copiar archivos de datos y capturar una snapshot. Esto requiere al menos un MongoDB Agent con un módulo de copia de seguridad habilitado y ubicado en los servidores que contienen datos por partición o conjunto de réplicas. El agente abre un $backupCursor a nivel del motor de almacenamiento para permitir la copia de archivos de la base de datos en un estado coherente, mientras sigue aceptando guardados.
Se requiere un seguimiento de Oplog del nodo primario para las copias de seguridad. Esta tarea normalmente es realizada por el MongoDB Agent con un módulo de copia de seguridad activado en el nodo primario de la partición de datos o el set de réplicas.
El proceso de copia de seguridad toma una snapshot del directorio de datos en su intervalos de instantáneas programadas. Este proceso copia los archivos de datos en una implementación de MongoDB, enviándolos a través de la red mediante Ops Manager a tu almacenamiento de instantáneas existente. Tu implementación aún puede gestionar operaciones de lectura y escritura durante el proceso de copia.
El proceso de copia de seguridad funciona de esta manera independientemente de cómo se almacenen los snapshots.
Nota
Con el nuevo proceso de copia de seguridad, ya no hay sincronización inicial. Como resultado de no tener sincronizaciones iniciales, Ops Manager puede dar soporte a un arreglo más amplio de clientes, como aquellos que hacen un uso intensivo de renameCollection.
Una vez que se haya iniciado la copia de seguridad, Ops Manager respalda los datos como un proceso continuo y sostenido. Este proceso continúa creando instantáneas siempre que la base de datos principal permanezca sincronizada con la base de datos.
Este proceso funciona como la sincronización de datos del set de réplicas.
El proceso de copia de seguridad:
Realiza una sincronización inicial para respaldar todos tus datos existentes en su estado actual. En clusters particionados, esto ocurre en cada partición y en los servidores de configuración.
Nota
Condiciones o acciones que reinician la sincronización inicial
Durante el proceso de sincronización inicial, ciertas acciones o condiciones pueden reiniciar el proceso de sincronización inicial. Evite las siguientes acciones y condiciones:
Acciones a Evitar durante la Sincronización Inicial:
Reiniciar, apagar o cambiar la versión o Valor compatibilidad de características entre versiones de la base de datos de origen.
Renombrar la colección de la base de datos de origen.
Cambio del valor $out en la Pipeline de agregación de la base de datos fuente.
Reiniciando o apagando la aplicación Ops Manager o el daemon de copias de seguridad.
Reiniciar, apagar o actualizar el MongoDB Agent.
Condiciones a evitar durante la sincronización inicial:
Directorio principal está lleno.
La conectividad de red entre los componentes de Ops Manager es inestable.
Toma instantáneas del directorio
dataen una implementación tan a menudo como lo especifica tu programa de instantáneas y luego transfiere las instantáneas a un sistema de almacenamiento.Nota
Los clústeres fragmentados también pueden habilitar puntos de control para permitir restauraciones en puntos en el tiempo entre snapshots. Para aprender cómo los clústeres particionados utilizan puntos de control, consulta puntos de control.
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.
Monitoriza el oplog constantemente y añade nuevas operaciones de base de datos a la última copia de seguridad para mantener la copia local de Ops Manager de los datos actualizada.
El proceso de copia de seguridad funciona de esta manera independientemente de cómo se almacenen los snapshots.
Definición de copia de seguridad y estados operativos
Cada copia de seguridad se define como un tarea. Cada tarea define cuánto y con qué frecuencia se realizan copias de seguridad de los datos. Las tareas de copia de seguridad se definen por proyecto.
Estados operativos
La siguiente tabla muestra los estados de una tarea de copia de seguridad:
Estado | Conservar snapshots antiguos | Crea nuevas snapshots |
|---|---|---|
| Sí | Sí |
| Sí | No |
| No | No |
| Sí | No |
Nota
El estado Misconfigured solo se aplica a copia de seguridad regional.
Estado | Conservar snapshots antiguos | Crea nuevas snapshots | Aplicar Oplogs |
|---|---|---|---|
| Sí | Sí | Sí |
| Sí | No | No |
| No | No | No |
Cambiar estados operativos
Una vez que las tareas de copia de seguridad estén activas para un proyecto, se ejecutarán sin intervención adicional hasta que se detengan o finalicen. El operador puede cambiar el estado de una copia de seguridad de las siguientes maneras:
Estado inicial | Estado deseado | Método |
|---|---|---|
| Active | Haga clic en Start. |
| Stopped | Haga clic en Stop. |
| Active | Haga clic en Restart. |
| Inactive | Haga clic en Terminate. ADVERTENCIA: Terminate elimina todas las copias de seguridad retenidas. |
Estado inicial | Estado deseado | Método |
|---|---|---|
| Active después | Haga clic en Start. |
| Stopped | Haga clic en Stop. |
| Active después | Haga clic en Restart. |
| Inactive | Haga clic en Terminate. ADVERTENCIA: Terminate elimina todas las copias de seguridad retenidas. |
Importante
Puede recibir una alerta de Backup requires a resync para sus tareas de copia de seguridad. Esto puede requerir que resincronices una copia de seguridad. Esto no es un estado diferente, sino el inicio de un nuevo flujo del proceso de copia de seguridad. Una vez que Initial
Sync finalice, la tarea de copia de seguridad se convierte en Active de nuevo.
Flujos de procesos de copia de seguridad
Una vez creado, una tarea de copia de seguridad pasa por el siguiente flujo de proceso:
Cuando el clúster está listo para su snapshot programada, determina el nodo disponible óptimo para tomarla. En la mayoría de los casos,
mongoddetermina que el miembro secundario de menor prioridad es el nodo de snapshot preferido. Se pueden considerar otras métricas para determinar el nodo preferido, como el nivel de actualización del secundario respecto al primario y al nodo del snapshot previamente elegido.Una vez que el proceso
mongoddetermina el nodo de origen para el snapshot, el proceso de copia de seguridad abre un$backupCursoren el nodo seleccionado.El
$backupCursor, un mecanismo a nivel de motor de almacenamiento, permite que los archivos de la base de datos en almacenamiento se copien en un estado coherente, mientras aún se aceptan escrituras.La función de copia de seguridad del Agente de MongoDB copia y procesa estos archivos de datos.
La función de copia de seguridad de MongoDB Agent envía los archivos de datos a Ops Manager.
El proceso de copia de seguridad recopila y transfiere estos archivos al almacenamiento de snapshot que elijas para almacenar tu copia de seguridad. Dependiendo del almacenamiento de snapshot que elijas para guardar tu snapshot, un snapshot puede ser escrito como:
Bloques a un almacenamiento en bloques. Fragmentos binarios escritos en una base de datos MongoDB en el host de Ops Manager.
Se bloquea a un bucket de AWS S3 . Los metadatos de esos bloques se escriben en una base de datos MongoDB en el host de Ops Manager.
Archivos snapshot en un file system store. El daemon de copias de seguridad que posee la tarea de copia de seguridad para la réplica crea una snapshot completa combinando los bloques modificados y los nuevos con los bloques no cambiados de la última snapshot. Si el daemon de copias de seguridad que posee la tarea de copia de seguridad está inactivo, necesitas recuperar el daemon de copias de seguridad o mover la base de datos principal a otro demonio.
Nota
Para obtener más información sobre las características de cada método de almacenamiento, consulte Opciones de configuración de copia de seguridad.
Copia de seguridad inicial
El agente MongoDB habilitado para respaldo se conecta y se autentica con las bases de datos asociadas a la tarea de copia de seguridad.
La sincronización inicial comienza y entra en su fase
starting. La sincronización inicial es un estado de transición entre Inactive y Active. La Sincronización inicial pasa por una serie de fases que se muestran en la página Backup para mostrar el progreso. La copia de seguridad transmite los datos existentes a Ops Manager en paquetes comprimidos de documentos de 10 MB llamados "slices" (rebanadas). La copia de seguridad crea fragmentos en el momento en que se creó la snapshot. Ops Manager captura los datos insertados en la instancia por separado una vez que se inicia la snapshot.La fase
transferringcomienza cuando los fragmentos se transmiten y almacenan en el Oplog Store temporalmente en nombre del daemon de copias de seguridad. El servicio daemon de copias de seguridad no puede dedicarse exclusivamente a procesamiento el gran flujo de fragmentos de sincronización inicial en detrimento del procesamiento de otras tareas de copia de seguridad. La Oplog Store almacena los fragmentos hasta que el daemon de copias de seguridad pueda recuperarlos. La Oplog Store se crea cuando se genera el primer almacenamiento de snapshot.Mientras la copia de seguridad está en transmisión de los datos, sigue el oplog. Este seguimiento recopila cualquier diferencia entre el estado de la base de datos de implementación cuando comenzó la copia de seguridad y el estado actual de la base de datos de implementación. Las entradas del Oplog se envían en paquetes comprimidos de documentos de 10 MB llamados segmentos de Oplog. Estos dos flujos de porciones se recopilan en paralelo para reducir el tiempo necesario para construir una snapshot completa.
La fase
buildingcomienza una vez que Ops Manager recibe el primer lote de segmentos de sincronización inicial. En esta fase, Ops Manager crea una versión local de la base de datos respaldada llamada base de datos principal en el host que ejecuta el servicio daemon de copias de seguridad.Ops Manager utiliza el servicio de daemon de copias de seguridad para insertar los documentos almacenados en Oplog Store en la base de datos principal.
La fase
applying oplogscomienza cuando Ops Manager aplica las entradas finales del Oplog en la base de datos principal.Durante la fase
fetching missing documents, Ops Manager ejecuta una query en la base de datos de implementación en busca de documentos que se hayan omitido durante la inserción de documentos. Ops Manager inserta los documentos faltantes encontrados en la base de datos de la implementación en la base de datos principal.Después de insertar los documentos que faltan, comienza la fase
creating indexes, ya que Ops Manager crea todos los índices encontrados en las bases de datos de la implementación en la base de datos principal. Cuando finalizan los índices, termina la sincronización inicial y la fase cambia acomplete.Dependiendo del almacenamiento de snapshot que elijas para almacenar tu snapshot, un snapshot puede ser escrita como:
Bloques a un almacenamiento en bloques.
Se bloquea a un bucket de AWS S3 . Los metadatos de esos bloques se escriben en una base de datos MongoDB en el host de Ops Manager.
Archivos de snapshot a un almacenamiento del sistema de archivos.
Nota
Las características de cada método de almacenamiento se abordan en Opciones de configuración de copia de seguridad.
Copias de seguridad posteriores
La base de datos principal funciona como una copia completa de la base de datos de implementación. Necesita que se le apliquen logs de operación de forma regular para mantener sus datos sincronizados con la base de datos de la implementación. Las snapshots se generan a partir de los datos almacenados en la base de datos principal de acuerdo con tu cronograma de snapshots.
Una vez que se completa la primera copia de seguridad completa, cada tarea de copia de seguridad activa sigue este proceso:
La copia de seguridad sigue el registro de operaciones (oplog) de la implementación.
Copia de seguridad agrupa de forma rutinaria las nuevas entradas de oplog en fragmentos de oplog y las transfiere a Ops Manager.
Ops Manager almacena las entradas del oplog en el almacén de Oplog.
Ops Manager aplica las nuevas entradas de oplog de las particiones de oplog a la base de datos principal que almacena la copia de seguridad de la implementación.
Ops Manager crea una nueva snapshot y la almacena en el almacenamiento de snapshot según lo especificado en tu cronograma de snapshots.
Copia de seguridad regional
Puedes asignar tareas de copia de seguridad a regiones de implementación para promover el aislamiento de datos. Cuando asignes una tarea de copia de seguridad a una región de implementación, Ops Manager escribe todos los snapshots, logs op y datos de sincronización que genera la tarea en el almacenamiento relevante configurado para esa región. La copia de seguridad regional está disponible para sets de réplicas y clústeres. Para activar las copias de seguridad regionales en un clúster fragmentado, debes asignar regiones de implementación e iniciar tareas de copia de seguridad para cada partición por separado.
Para determinar si la copia de seguridad regional está habilitada en tu implementación, puedes comprobar lo siguiente en el tablero de Continuous Backup.
Backup Region en la esquina superior derecha se muestra la región de implementación del grupo por defecto y, si el proyecto está habilitado para copia de seguridad regional, se muestra la leyenda Multi-Region.
Regional Backup columna se muestra en el tablero.