/ /

Restaurar clústeres fragmentados

Docs Home

/ /

Métodos de copia de seguridad

Restaurar clústeres fragmentados

Docs Home

Manual de base de datos

Implementaciones autogestionadas

Administración

Métodos de copia de seguridad

Restaurar clústeres fragmentados

Realiza una copia de seguridad de un clúster autogestionado con snapshots del sistema de archivos

Esta versión de la documentación se archivó y ya no se admite. Para actualizar tu implementación de 6.0, consulta el Procedimientos de actualización de MongoDB.7.0

Overview

Este documento describe un procedimiento para realizar una copia de seguridad de todos los componentes de un clúster particionado. Este procedimiento utiliza instantáneas del sistema de archivos para capturar una copia de los .mongod instancia.

Importante

Para respaldar un clúster, debe detener todas los guardados en el clúster.

Para obtener más información sobre las copias de seguridad en MongoDB y, en particular, sobre las copias de seguridad de clústeres fragmentados, consulta los Métodos de copia de seguridad para una implementación autogestionada y Copia de seguridad y restauración de un clúster fragmentado autogestionado.

Considerations

Transacciones entre fragmentos

Para realizar una copia de seguridad con una snapshot del sistema de archivos, primero debes detener el balanceador, detener las guardar y detener todas las operaciones de transformación del esquema en el clúster.

MongoDB proporciona operaciones de copia de seguridad y restauración que pueden ejecutarse con el balanceador y ejecutar transacciones a través de los siguientes servicios:

Motor de almacenamiento cifrado (solo MongoDB Enterprise)

Para los motores de almacenamiento cifrado que utilizan el modo de cifrado AES256-GCM, AES256-GCM requiere que cada proceso use un valor de bloque de contador único con la clave.

Para el motor de almacenamiento cifrado configurado con el cifrado AES256-GCM:

Restauración desde una copia de seguridad en caliente
A partir de la versión 4.2, si restaura desde archivos obtenidos mediante una copia de seguridad "en caliente" (es decir, mientras mongod está en ejecución), MongoDB puede detectar claves "sucias" en el inicio y cambiar automáticamente la clave de la base de datos para evitar la reutilización del IV (vector de inicialización).
Restauración desde una copia de seguridad en frío
Sin embargo, si restaura desde archivos obtenidos mediante una copia de seguridad "en frío" (es decir, mongod no está en ejecución), MongoDB no puede detectar las claves "sucias" en el inicio, y la reutilización de IV invalida las garantías de confidencialidad e integridad.
A partir de la versión 4.2, para evitar la reutilización de las claves después de restaurar desde un snapshot del sistema de archivos en frío, MongoDB agrega una nueva opción de línea de comandos --eseDatabaseKeyRollover. Al iniciarse con la opción --eseDatabaseKeyRollover, la instancia mongod cambia las claves de la base de datos configuradas con el cifrado AES256-GCM y se cierra.

Balanceador

Es esencial parar el balanceador antes de capturar una copia de seguridad.

Si el balanceador está activo mientras capturas copias de seguridad, los artefactos de la copia de seguridad pueden estar incompletos o tener datos duplicados, ya que los fragmentos pueden migrar mientras se graban las copias de seguridad.

Precisión

En este procedimiento, detendrás el balanceador de clúster y harás una copia de seguridad de la base de datos de configuración, y luego harás copias de seguridad de cada partición en el clúster utilizando una herramienta de snapshots del sistema de archivos. Si necesitas una instantánea exacta de un momento en el tiempo del sistema, deberás detener todas las escrituras antes de tomar las instantáneas del sistema de archivos; de lo contrario, la instantánea solo aproximará un momento en el tiempo.

coherencia

Para realizar una copia de seguridad de un clúster fragmentado, debe usar el fsync comando o db.fsyncLock() el método para detener las escrituras en el clúster. Esto ayuda a reducir la probabilidad de inconsistencias en la copia de seguridad.

Nota

Estos pasos solo pueden producir una copia de seguridad coherente si se siguen exactamente y no hay ninguna operación en curso cuando se empieza.

Snapshots con Amazon EBS en una configuración RAID 10

Si tu implementación depende del almacenamiento en bloque elástico (EBS) de Amazon con RAID configurado dentro de la instancia, es imposible obtener un estado coherente en todos los discos utilizando la herramienta de snapshot de la plataforma. Como alternativa, se puede realizar una de las siguientes acciones:

Establezca un bloqueo para vaciar todas las escrituras y bloquear el clúster contra nuevas escrituras para ayudar a reducir la probabilidad de que ocurra un estado inconsistente durante el proceso de respaldo.fsync
Si elige esta opción, consulte Realizar copias de seguridad de instancias con archivos de diario en un volumen separado o sin registro en diario.
Configure LVM para ejecutar y almacenar sus archivos de datos MongoDB sobre el RAID dentro de su sistema.
Si elige esta opción, realice la operación de copia de seguridad de LVM descrita en Crear una instantánea.

Compatibilidad de versiones

Este procedimiento requiere una versión de MongoDB que admita el bloqueo fsync desde mongos.

A partir de MongoDB 6.0.11 (también disponible a partir 5.0.22 de), los fsync comandos y se fsyncUnlock mongos pueden ejecutar en para bloquear y desbloquear un clúster fragmentado.

Stale Data

Las copias de seguridad proporcionan una snapshot del estado actual de la base de datos. Cuando restauras a partir de una copia de seguridad, la base de datos restaurada no incluye ningún cambio realizado después de que se haya hecho la copia de seguridad, lo que puede provocar pérdida de datos.

Pasos

Para realizar una copia de seguridad autogestionada de un clúster fragmentado, complete los siguientes pasos:

Encuentra una ventana de copia de seguridad

Las migraciones de fragmentos, el resharding y las operaciones de migración de esquemas pueden causar inconsistencias en las copias de seguridad. Para encontrar un buen momento para realizar una copia de seguridad, supervise el uso de su aplicación y base de datos y encuentre un momento en el que sea poco probable que ocurran estas operaciones.

Para obtener más información, consulte Programar ventana de copia de seguridad para un clúster autogestionado.

Detener el balanceador

Para evitar que las migraciones de fragmentos interrumpan la copia de seguridad, utilice el método para detener el sh.stopBalancer() equilibrador:

sh.stopBalancer()

Si hay una ronda de equilibrio en curso, la operación espera a que se complete el equilibrio.

Para verificar que el balanceador esté detenido, utiliza el método sh.getBalancerState():

use config
while( sh.isBalancerRunning().mode != "off" ) {
   print("waiting...");
   sleep(1000);
}

Bloquear el clúster

Las escrituras en la base de datos pueden causar inconsistencias en la copia de seguridad. Bloquee su clúster fragmentado para proteger la base de datos de las escrituras.

Para bloquear un clúster particionado, utiliza el método db.fsyncLock():

db.getSiblingDB("admin").fsyncLock()

Ejecuta el siguiente pipeline de agregación tanto en el mongos como en el primario mongod de los servidores de configuración. Para confirmar el bloqueo, asegúrate de que el campo fysncLocked devuelva true y el campo fsyncUnlocked devuelva false.

db.getSiblingDB("admin").aggregate( [
   {  $currentOp: { } },
   {  $facet: {
      "locked": [
         { $match: { $and: [
            { fsyncLock: { $exists: true } }
         ] } }],
       "unlocked": [
         { $match: { fsyncLock: { $exists: false } } }
       ]
   } },
   {  $project: {
      "fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] },
      "fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] }
   } }
 ] )

[ { fsyncLocked: true }, { fsyncUnlocked: false } ]

Realice una copia de seguridad del servidor de configuración principal

Nota

Realizar un respaldo de un servidor de configuración también respalda los metadatos del clúster particionado. Sólo necesitas respaldar un servidor de configuración, ya que todos contienen los mismos datos. Ejecuta esta acción contra el miembro primario del CSRS.

Para crear una instantánea del sistema de archivos del servidor de configuración, siga el procedimiento en Crear una instantánea.

Hacer respaldo de las particiones primarias

Realiza una snapshot del sistema de archivos contra el miembro primario de cada partición, utilizando el procedimiento que se encuentra en Respaldar y Restauración un Despliegue autogestionado con Snapshots del Sistema de Archivos.

Desbloquea el clúster

Después de que se complete la copia de seguridad, debes desbloquear el clúster para permitir que se reanuden las escrituras.

Para desbloquear el clúster, utilice el db.fsyncUnlock() método:

db.getSibling("admin").fsyncUnlock()

Ejecute la siguiente canalización de agregación en mongos mongod los servidores de configuración fysncLocked false y, que es el principal. Para confirmar el desbloqueo,fsyncUnlocked trueasegúrese de que el campo devuelva y el campo devuelva.

db.getSiblingDB("admin").aggregate( [
   {  $currentOp: { } },
   {  $facet: {
      "locked": [
         { $match: { $and: [
            { fsyncLock: { $exists: true } }
         ] } }],
       "unlocked": [
         { $match: { fsyncLock: { $exists: false } } }
       ]
   } },
   { $project: {
      "fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] },
      "fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] }
   } }
 ] )

[ { fsyncLocked: false }, { fsyncUnlocked: true } ]

Reiniciar el Balanceador

Para reiniciar el balanceador, utiliza el método sh.startBalancer():

sh.startBalancer()

Para confirmar que el balanceador está ejecutándose, use el método sh.getBalancerState():

sh.getBalancerState()

true

El comando devuelve true cuando el equilibrador está funcionando.

Volver

Restaurar clústeres fragmentados

Use Database Dumps