Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

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

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.

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:

  • MongoDB Atlas

  • MongoDB Cloud Manager

  • MongoDB Ops Manager

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
    Si restauras desde archivos tomados a través de una copia de seguridad en caliente mientras el mongod se está ejecutando, MongoDB detecta claves "sucias" al arrancar y rota automáticamente la clave de la base de datos para evitar la reutilización de IV (Initialization Vector).
  • Restauración desde una copia de seguridad en frío

    Sin embargo, si se restaura desde archivos obtenidos mediante una copia de seguridad "en frío" mientras mongod no se está ejecutando, MongoDB no detecta claves "sucias" al iniciarse, y la reutilización del IV anula las garantías de confidencialidad e integridad.

    Para evitar la reutilización de las claves después de restaurar desde una snapshot fría del sistema de archivos, MongoDB añade 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 sale.

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.

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.

Para respaldar un clúster, debes usar el comando fsync o el método db.fsyncLock() para detener los guardados 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.

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:

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

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

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.

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

1

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.

2

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

sh.stopBalancer()

Si una ronda de balanceo está actualmente en curso, la operación espera a que finalice el balanceo.

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

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

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, utiliza el método db.fsyncLock() en mongos y el primario mongod de los servidores de configuración:

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

Para confirmar el bloqueo, ejecuta la siguiente pipeline de agregación tanto en el mongos como en el primario mongod de los servidores de configuración. Asegúrate de que fysncLocked campo devuelve true y fsyncUnlocked campo devuelve 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 } ]
4

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 un filesystem snapshot en el servidor de configuración, siga el procedimiento de Crear un snapshot.

5

Realiza un snapshot del sistema de archivos en el miembro principal de cada partición, utilizando el procedimiento que se encuentra en Realiza una copia de seguridad de una implementación autogestionada con snapshots del sistema de archivos.

6

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, utiliza el método db.fsyncUnlock():

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

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

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 } ]
7

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

Copia de seguridad y restauración de clústeres compartidos

En esta página