/ /

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

Docs Home

Gestión

Copia de seguridad y restauración

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

Docs Home

Gestión

Copia de seguridad y restauración

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

Restauración de un clúster autogestionado

Este procedimiento restaura un clúster fragmentado a partir de una instantánea de respaldo existente, como Instantáneas del Administrador devolúmenes lógicos (LVM). El clúster fragmentado de origen y de destino debe tener el mismo número de fragmentos. Para obtener información sobre cómo crear instantáneas de LVM para todos los componentes de un clúster fragmentado, consulte "Realizar una copia de seguridad de un clúster fragmentado autoadministrado con instantáneas del sistema de archivos".

Nota

Para utilizar mongodumpymongorestorecomo estrategia de respaldo para clústeres fragmentados, consulte Realizar una copia de seguridad de un clúster fragmentado autoadministrado con un volcado de base de datos.

Los clústeres particionados también pueden utilizar uno de los siguientes procesos coordinados de copia de seguridad y restauración, que mantienen las garantías de atomicidad de las transacciones entre particiones:

Considerations

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.

Antes de comenzar

A partir de MongoDB 8.0, se puede utilizar el rol directShardOperations para realizar operaciones de mantenimiento que requieren ejecutar comandos directamente contra un fragmento.

Advertencia

Ejecutar comandos usando el rol de directShardOperations puede hacer que su clúster deje de funcionar correctamente y puede causar corrupción de datos. Utilice el rol de directShardOperations solo para fines de mantenimiento o bajo la orientación del soporte de MongoDB. Una vez que haya terminado de realizar las operaciones de mantenimiento, deje de usar el rol de directShardOperations.

A. (Opcional) Revisar configuraciones del set de réplicas

Este procedimiento inicia un nuevo conjunto de réplicas para el Conjunto de Réplicas del Servidor de Configuración (CSRS) y cada conjunto de réplicas de fragmentos con la configuración predeterminada. Para usar una configuración de conjunto de réplicas diferente para el CSRS restaurado y los fragmentos, debe reconfigurar los conjuntos de réplicas.

Si el clúster de origen se ejecuta correctamente y es accesible, conecte un shell al miembro principal del conjunto de mongo rs.conf() réplicas en cada conjunto de réplicas. A continuación, ejecute para ver el documento de configuración de la réplica.

Si no puede acceder a uno o más componentes del clúster fragmentado de origen, consulte la documentación interna existente para reconstruir los requisitos de configuración para cada conjunto de réplicas de fragmentos y el conjunto de réplicas del servidor de configuración.

B. Preparar el host de destino para la restauración

Requisitos de espacio de almacenamiento

Asegúrese de que el hardware del host de destino tenga suficiente espacio de almacenamiento disponible para los datos restaurados. Si el host de destino contiene datos existentes del clúster fragmentado que desea conservar, asegúrese de tener suficiente espacio de almacenamiento tanto para los datos existentes como para los restaurados.

Requisitos de LVM

Para las instantáneas de LVM, debe tener al menos un grupo de volúmenes administrados por LVM y un volumen lógico con suficiente espacio libre para los datos de la instantánea extraídos.

Requisitos de la versión de MongoDB

Asegúrese de que el host de destino y el host de origen tengan la misma versión de MongoDB Server. Para comprobar la versión de MongoDB disponible en un host, ejecute mongod --version desde la terminal o el shell.

Para obtener la documentación completa sobre la instalación, consulte Instalar MongoDB.

Apagar procesos MongoDB en ejecución

Si se restaura a un clúster existente, apague el mongod proceso o en el host de destino.mongos

Para los hosts que ejecutanmongos, conecte un shellmongoal mongos y ejecutedb.shutdownServer()desde la base de datos admin:

use admin
db.shutdownServer()

Para los hosts que ejecutan unmongod, conecte un shellmongoal mongod y ejecutedb.hello():

Si isWritablePrimary es falso, el mongod es un miembro secundario de un set de réplicas. Puede apagarse ejecutando db.shutdownServer() desde la base de datos admin.
Si es isWritablePrimary verdadero,mongod es el miembro principal de un conjunto de réplicas. Cierre primero los miembros secundarios del conjunto de réplicas. Use para identificar a los demás miembros del conjunto de rs.status() réplicas.
El servidor principal se desactiva automáticamente al detectar que la mayoría de los miembros están desconectados. Tras desactivarse (db.hello() isWritablePrimary: falsedevuelve), puede desactivar de forma segura.mongod

Preparar directorio de datos

Cree un directorio en el host de destino para los archivos de la base de datos restaurada. Asegúrese de que el usuario que ejecuta tenga permisos de lectura, escritura y ejecución para todos los archivos y subcarpetas de ese mongod directorio.

sudo mkdir /path/to/mongodb
sudo chown -R mongodb:mongodb /path/to/mongodb
sudo chmod -R 770 /path/to/mongodb

Sustituya /path/to/mongodb con la ruta al directorio de datos que creó. RHEL/CentOS, Amazon Linux y SUSE, el nombre de usuario predeterminado mongod es.

Preparar directorio de registros

Cree un directorio en el host de destino para los mongod archivos de registro. Asegúrese de que el usuario que ejecuta tenga permisos de lectura, escritura y ejecución para todos los archivos y subcarpetas de ese mongod directorio.

sudo mkdir /path/to/mongodb/logs
sudo chown -R mongodb:mongodb /path/to/mongodb/logs
sudo chmod -R 770 /path/to/mongodb/logs

Sustituya /path/to/mongodb/logs por la ruta al directorio de registro que creó. En RHEL/CentOS, Amazon Linux y SUSE, el nombre de usuario predeterminado mongod es.

Crear archivo de configuración

Este procedimiento supone iniciar un con un mongod archivode configuración.

Cree el archivo de configuración en la ubicación que prefiera. Asegúrese de que el usuario que ejecuta mongod tenga permisos de lectura y escritura en el archivo de configuración:

sudo touch /path/to/mongod.conf
sudo chown mongodb:mongodb /path/to/mongodb/mongod.conf
sudo chmod 644 /path/to/mongodb/mongod.conf

En RHEL/CentOS, Amazon Linux y SUSE, el nombre de usuario predeterminado mongod es.

Abre el archivo de configuración en tu editor de texto preferido y modifícalo según lo requiera tu implementación. De manera alternativa, si tienes acceso al archivo de configuración original de la mongod, cópialo a la ubicación de tu preferencia en el host de destino.

Importante

Valide que su archivo de configuración incluya las siguientes configuraciones:

storage.dbPath Debe configurarse en la ruta a su directorio de datos preferido.
systemLog.path debe configurarse en la ruta a su directorio de registro preferido
net.bindIp Debe incluir la dirección IP de la máquina host.
replication.replSetName tiene el mismo valor en cada miembro de cualquier conjunto de réplicas determinado.
sharding.clusterRole tiene el mismo valor en cada miembro de cualquier conjunto de réplicas determinado.
También debe especificar las mismas opciones de inicio para su nueva implementación que se especificaron en la instantánea.

C. Restaurar el conjunto de réplicas del servidor de configuración

Restaurar los `mongod` archivos de datos primariosCSRS.

Seleccione la pestaña que corresponde a su método de respaldo preferido:

Monte la instantánea de LVM en el host de destino. Los pasos específicos para montar una instantánea de LVM dependen de su configuración.
El siguiente ejemplo supone una instantánea de LVM creada mediante el paso Crear una instantánea del procedimiento Realizar copia de seguridad de una implementación autoadministrada con instantáneas del sistema de archivos.
```
lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb
```
Es posible que este ejemplo no se aplique a todas las configuraciones de LVM posibles. Consulte la documentación de LVM de su sistema para obtener instrucciones más completas sobre la restauración de LVM.
Copie los mongod archivos de datos del montaje de instantánea al directorio de datos creado en B. Prepare the Target Host for Restoration:
```
cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb
```
La opción -a copia recursivamente el contenido de la ruta de origen a la ruta de destino mientras conserva los permisos de carpeta y archivo.
Comenta u omite las siguientes configuraciones de archivo de configuración:
```
#replication:
#  replSetName: myCSRSName
#sharding:
#  clusterRole: configsvr
```
Para iniciar usando mongod --config un archivo de configuración, especifique la opción en la línea de comando especificando la ruta completa al archivo de configuración.
```
mongod --config /path/to/mongodb/mongod.conf
```
Si está restaurando desde una instantánea filtrada por espacio de nombres, especifique la --restore opción.
```
mongod --config /path/to/mongod/mongod.conf --restore
```
Si tiene configurado para ejecutarse como un servicio del sistema, inícielo utilizando el proceso recomendado para su administrador de servicios del mongod sistema.
Después de que se inicie, conéctese mongod mongo a él usando el shell.

Haga que los archivos de datos almacenados en el medio de copia de seguridad seleccionado sean accesibles en el host. Esto puede requerir montar el volumen de copia de seguridad, abrir la copia de seguridad con una utilidad de software o usar otra herramienta para extraer los datos al disco. Consulte la documentación de su herramienta de copia de seguridad preferida para obtener instrucciones sobre cómo acceder a los datos incluidos en la copia de seguridad.
Copie los mongod archivos de datos desde la ubicación de los datos de respaldo al directorio de datos creado B. Prepare the Target Host for Restoration en:
```
cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb
```
La opción -a copia recursivamente el contenido de la ruta de origen a la ruta de destino mientras conserva los permisos de carpeta y archivo.
Comenta u omite las siguientes configuraciones de archivo de configuración:
```
#replication:
#  replSetName: myCSRSName
#sharding:
#  clusterRole: configsvr
```
Para iniciar usando mongod --config un archivo de configuración, especifique la opción en la línea de comando especificando la ruta completa al archivo de configuración.
```
mongod --config /path/to/mongodb/mongod.conf
```
Si se restaura desde una instantánea filtrada por espacio de nombres, especifique también la --restore opción.
```
mongod --config /path/to/mongod/mongod.conf --restore
```
Nota
Solo Cloud Manager o Ops Manager
Si realiza una restauración manual de una copia de seguridad de Cloud Manager u Ops Manager, debe especificar el parámetro de servidor disableLogicalSessionCacheRefresh antes del inicio.
mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true
Si tiene configurado para ejecutarse como un servicio del sistema, inícielo utilizando el proceso recomendado para su administrador de servicios del mongod sistema.
Después de que se inicie, conéctese mongod mongo a él usando el shell.

Eliminar la `local` base de datos.

Utilice para eliminar db.dropDatabase() la local base de datos:

use local
db.dropDatabase()

Inserte la lista de archivos filtrada en la base de datos local.

Este paso solo es necesario si está restaurando desde una instantánea filtrada por espacio de nombres.

Para cada fragmento, localice la lista de archivos filtrados con el siguiente formato de nombre: <shardRsID>-filteredFileList.txt. Este archivo contiene una lista de objetos JSON con el siguiente formato:

{
   "filename":"file1",
   "ns":"sampleDb1.sampleCollection1",
   "uuid": "3b241101-e2bb-4255-8caf-4136c566a962"
}

Agregue cada objeto JSON de cada archivo de fragmento a una nueva db.systems.collections_to_restore colección en su local base de datos. Puede ignorar las entradas con ns uuid campos o vacíos. Al insertar entradas, el uuid campo debe insertarse como UUID() tipo.

Ejecute el comando de restauración de archivo filtrado.

Este paso solo es necesario si está restaurando desde una instantánea filtrada por espacio de nombres.

Después de insertar todas las entradas, ejecute los siguientes comandos:

use admin
db.runCommand({"_configsvrRunRestore":1})

Para cualquier cambio de nombre de host de fragmento o de conjunto de réplicas planificado o completado, actualice los metadatos `config.shards` en.

Puede omitir este paso si se cumplen todas las siguientes condiciones:

Ningún hostname de máquina host de nodo de partición ha cambiado ni cambiará durante este procedimiento.
Ningún nombre del conjunto de réplicas de fragmentos ha cambiado ni cambiará durante este procedimiento.

Ejecute el siguiente find() método shards en la colección de la base de datos de configuración. Reemplace <shardName> por el nombre del fragmento. De forma predeterminada, el nombre del fragmento es el nombre de su conjunto de réplicas. Si agregó el fragmento con el addShard comando y especificó un name personalizado, debe especificar name de <shardName> a.

use config
db.shards.find( { "_id" : "<shardName>" } )

Esta operación devuelve un documento similar al siguiente:

{
   "_id" : "shard1",
   "host" : "myShardName/alpha.example.net:27018,beta.example.net:27018,charlie.example.net:27018",
   "state" : 1
}

Importante

El _id valor debe coincidir con el shardName valor del _id : "shardIdentity" documento del fragmento correspondiente. Al restaurar los fragmentos posteriormente en este procedimiento, verifique que el _id campo de coincida con shards el shardName valor del fragmento.

Utilice el método para actualizar updateOne() la hosts cadena y reflejar el nombre del conjunto de réplicas planificado y la lista de nombres de host para el fragmento. Por ejemplo, la siguiente operación actualiza la host cadena de conexión del fragmento "_id" : "shard1" con:

db.shards.updateOne(
  { "_id" : "shard1" },
  { $set : { "host" : "myNewShardName/repl1.example.net:27018,repl2.example.net:27018,repl3.example.net:27018" } }
)

Repita este proceso hasta que todos los metadatos del fragmento reflejen con precisión el nombre del conjunto de réplicas planificado y la lista de nombres de host para cada fragmento del clúster.

Nota

Si no conoce el nombre del fragmento, emita el método find() shards en la {}colección con un documento de filtro vacío:

use config
db.shards.find({})

Cada documento del conjunto de resultados representa un fragmento del clúster. Para cada documento, busque en el campo host una cadena de conexión que coincida con el fragmento en cuestión, es decir, un nombre de conjunto de réplicas y una lista de nombres de host de miembros coincidentes. Use el _id de ese documento en lugar de <shardName>.

Reinicie el como un nuevo conjunto de réplicas de nodo `mongod` único.

Apague el. Descomente o agregue las siguientes opciones del archivo de configuración:mongod

replication:
  replSetName: myNewCSRSName
sharding:
  clusterRole: configsvr

Si desea cambiar el nombre del conjunto de réplicas, debe actualizar el replSetName campo con el nuevo nombre antes de continuar.

Inicie el con el archivo de configuración mongod actualizado:

mongod --config /path/to/mongodb/mongod.conf

Si tiene configurado para ejecutarse como un servicio del sistema, inícielo utilizando el proceso recomendado para su administrador de servicios del mongod sistema.

Después de que se inicie, conéctese mongod mongo a él usando el shell.

Iniciar el nuevo conjunto de réplicas.

Inicie el conjunto de réplicas utilizando con la configuración rs.initiate() predeterminada.

rs.initiate()

Una vez completada la operación, utilice para comprobar que el miembro se ha convertido en rs.status() el principal.

Añadir miembros adicionales al set de réplicas.

Para cada miembro del conjunto de réplicas en el CSRS, inicie en su equipo host. Una vez iniciados correctamente mongod todos los miembros restantes del clúster, conecte un shell mongo rs.add() al miembro principal del conjunto de réplicas. Desde el principal, utilice el método para agregar cada miembro del conjunto de réplicas. Incluya el nombre del mongod conjunto de réplicas como prefijo, seguido del nombre de host y el puerto del proceso del miembro:

rs.add("config2.example.net:27019")
rs.add("config3.example.net:27019")

Si desea agregar el miembro con member configuraciones de réplica específicas, puede pasar un documento a rs.add() que defina el nombre de host del miembro y cualquier configuración que requiera su members implementación.

rs.add(
 {
   "host" : "config2.example.net:27019",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

Cada nuevo miembro realiza una sincronización inicial para alcanzar al principal. Dependiendo de factores como la cantidad de datos a sincronizar, la topología y el estado de la red, y la potencia de cada equipo host, la sincronización inicial puede tardar un tiempo considerable.

El conjunto de réplicas puede elegir un nuevo principal mientras se agregan miembros adicionales. Use para identificar cuál es rs.status() rs.add() el principal actual. Solo puede ejecutar desde el principal.

Configure cualquier configuración de replicación adicional necesaria.

El método actualiza rs.reconfig() reconfig() la configuración del conjunto de réplicas según un documento de configuración pasado como parámetro. Debe ejecutar en el miembro principal del conjunto de réplicas.

Haga referencia a la salida del archivo de configuración original del conjunto de réplicas como se identifica en el paso A. Review Replica Set Configurations y aplique la configuración según sea necesario.

D. Restaurar cada conjunto de réplicas de fragmentos

Restaurar los `mongod` archivos de datos primarios del fragmento.

Seleccione la pestaña que corresponde a su método de respaldo preferido:

Monte la instantánea de LVM en el host de destino. Los pasos específicos para montar una instantánea de LVM dependen de su configuración.
El siguiente ejemplo supone una instantánea de LVM creada mediante el paso Crear una instantánea del procedimiento Realizar copia de seguridad de una implementación autoadministrada con instantáneas del sistema de archivos.
```
lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb
```
Es posible que este ejemplo no se aplique a todas las configuraciones de LVM posibles. Consulte la documentación de LVM de su sistema para obtener instrucciones más completas sobre la restauración de LVM.
Copia los archivos de datos mongod desde el montaje de la snapshot al directorio de datos creado en B. Prepare the Target Host for Restoration:
```
cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb
```
La opción -a copia recursivamente el contenido de la ruta de origen a la ruta de destino mientras conserva los permisos de carpeta y archivo.
Comenta u omite las siguientes configuraciones de archivo de configuración:
```
#replication:
#  replSetName: myShardName
#sharding:
#  clusterRole: shardsvr
```
Para iniciar usando mongod --config un archivo de configuración, especifique la opción en la línea de comando especificando la ruta completa al archivo de configuración:
```
mongod --config /path/to/mongodb/mongod.conf
```
Si está restaurando desde una instantánea con un filtro de espacio de nombres, especifique la opción --restore.
```
mongod --config /path/to/mongod/mongod.conf --restore
```
Si tiene configurado para ejecutarse como un servicio del sistema, inícielo utilizando el proceso recomendado para su administrador de servicios del mongod sistema.
Después de que se inicie, conéctese mongod mongo a él usando el shell.

Haga que los archivos de datos almacenados en el medio de copia de seguridad seleccionado sean accesibles en el host. Esto puede requerir montar el volumen de copia de seguridad, abrir la copia de seguridad con una utilidad de software o usar otra herramienta para extraer los datos al disco. Consulte la documentación de su herramienta de copia de seguridad preferida para obtener instrucciones sobre cómo acceder a los datos incluidos en la copia de seguridad.
Copie los mongod archivos de datos desde la ubicación de los datos de respaldo al directorio de datos creado B. Prepare the Target Host for Restoration en:
```
cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb
```
La opción -a copia recursivamente el contenido de la ruta de origen a la ruta de destino mientras conserva los permisos de carpeta y archivo.
Comenta u omite las siguientes configuraciones de archivo de configuración:
```
#replication:
#  replSetName: myShardName
#sharding:
#  clusterRole: shardsvr
```
Para iniciar usando mongod --config un archivo de configuración, especifique la opción en la línea de comando especificando la ruta completa al archivo de configuración:
```
mongod --config /path/to/mongodb/mongod.conf
```
Nota
Solo Cloud Manager o Ops Manager
Si realiza una restauración manual de una copia de seguridad de Cloud Manager u Ops Manager, debe especificar el parámetro de servidor disableLogicalSessionCacheRefresh antes del inicio:
mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true
Si tiene configurado para ejecutarse como un servicio del sistema, inícielo utilizando el proceso recomendado para su administrador de servicios del mongod sistema.
Después de que se inicie, conéctese mongod mongo a él usando el shell.

Crea un usuario temporal con el `__system` rol.

Durante este procedimiento, modificará los documentos de la colección. En admin.system.version los clústeres que aplican autenticación,solo el rol otorga permiso para modificar esta colección. Puede omitir este paso si el clúster no aplica __system autenticación.

Advertencia

El __system rol permite a su titular realizar cualquier acción contra cualquier objeto de la base de datos. Este procedimiento incluye instrucciones para eliminar al usuario creado en este paso. No mantenga a este usuario activo más allá del alcance de este procedimiento.

Considere crear este usuario con la clientSource restricción de autenticación configurada de modo que solo los hosts especificados puedan autenticarse como usuario privilegiado.

Autenticarse como usuario con el rol en userAdmin la admin base de datos o userAdminAnyDatabase el rol:
```
use admin
db.auth("myUserAdmin","mySecurePassword")
```
Cree un usuario con el __system rol:
```
db.createUser(
  {
    user: "mySystemUser",
    pwd: "<replaceMeWithAStrongPassword>",
    roles: [ "__system" ]
  }
)
```
Las contraseñas deben ser aleatorias, largas y complejas para garantizar la seguridad del sistema y para prevenir o retrasar el acceso malicioso.
Autenticarse como usuario privilegiado:
```
db.auth("mySystemUser","<replaceMeWithAStrongPassword>")
```

Eliminar la `local` base de datos.

Utilice para eliminar db.dropDatabase() la local base de datos:

use local
db.dropDatabase()

Eliminar el `minOpTimeRecovery` documento de la `admin.system.versions` colección.

Para actualizar los componentes internos de fragmentación, emita el siguiente deleteOne() método system.version en la colección en la admin base de datos:

use admin
db.system.version.deleteOne( { _id: "minOpTimeRecovery" } )

Nota

La system.version colección es interna y del sistema. Solo debe modificarse cuando se le den instrucciones específicas como estas.

Opcional: Para cualquier cambio en el hostname CSRS o en el nombre del set de réplicas, actualiza los metadatos de partición en el documento de identidad de cada partición.

Puede omitir este paso si se cumplen todas las siguientes condiciones:

Los nombres de host de cualquier host CSRS no cambiaron durante este procedimiento.
El nombre del conjunto de réplicas CSRS no cambió durante este procedimiento.

La colección de system.version la admin base de datos contiene metadatos relacionados con el fragmento, incluida la cadena de conexión CSRS. Si el nombre de CSRS o algún nombre de host miembro cambió al restaurar CSRS, debe actualizar estos metadatos.

Emita el siguiente find() método system.version en la colección en la admin base de datos:

use admin
db.system.version.find( {"_id" : "shardIdentity" } )

El método devuelve un documento similar al find() siguiente:

{
  "_id" : "shardIdentity",
  "clusterId" : ObjectId("2bba123c6eeedcd192b19024"),
  "shardName" : "shard1",
  "configsvrConnectionString" : "myCSRSName/alpha.example.net:27019,beta.example.net:27019,charlie.example.net:27019" }

El siguiente método actualiza el documento de modo que updateOne() la host cadena represente la cadena de conexión CSRS más actual:

db.system.version.updateOne(
  { "_id" : "shardIdentity" },
  { $set :
    { "configsvrConnectionString" : "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"}
  }
)

Importante

El shardName valor debe coincidir con el _id valor de la colección del CSRS. Verifique que los metadatos del CSRS coincidan con los del fragmento. Consulte el shards subpaso 3 C. Restore Config Server Replica Set de la sección de este procedimiento para obtener instrucciones sobre cómo visualizar los metadatos del CSRS.

Reinicie el como un nuevo conjunto de réplicas de nodo `mongod` único.

Apague el. Descomente o agregue las siguientes opciones del archivo de configuración:mongod

replication:
  replSetName: myNewShardName
sharding:
  clusterRole: shardsvr

Si desea cambiar el nombre del conjunto de réplicas, debe actualizar el replSetName campo con el nuevo nombre antes de continuar.

Inicie el con el archivo de configuración mongod actualizado:

mongod --config /path/to/mongodb/mongod.conf

Si tiene configurado para ejecutarse como un servicio del sistema, inícielo utilizando el proceso recomendado para su administrador de servicios del mongod sistema.

Después de que se inicie, conéctese mongod mongo a él usando el shell.

Iniciar el nuevo conjunto de réplicas.

Inicie el conjunto de réplicas utilizando con la configuración rs.initiate() predeterminada.

rs.initiate()

Una vez completada la operación, utilice para comprobar que el miembro se ha convertido en rs.status() el principal.

Añadir miembros adicionales al set de réplicas.

Para cada miembro del conjunto de réplicas del conjunto de réplicas de fragmentos, inicie en mongod su equipo host. Una vez iniciados correctamente todos los miembros restantes del clúster, conecte un shell al miembro principal mongo del conjunto de réplicas. Desde el principal, utilice el rs.add() método para agregar cada miembro del conjunto de réplicas. Incluya el nombre del conjunto de réplicas como prefijo, seguido del nombre de host y el puerto del mongod proceso del miembro:

rs.add("repl2.example.net:27018")
rs.add("repl3.example.net:27018")

rs.add(
 {
   "host" : "repl2.example.net:27018",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

Configure cualquier configuración de replicación adicional necesaria.

Remueva el usuario temporal con privilegios.

Para los clústeres que aplican la autenticación, elimine el usuario privilegiado creado anteriormente en este procedimiento:

Autenticarse como usuario con el rol en userAdmin la admin base de datos o userAdminAnyDatabase el rol:
```
use admin
db.auth("myUserAdmin","mySecurePassword")
```
Eliminar el usuario privilegiado:
```
db.removeUser("mySystemUser")
```

E. Reinicie cada uno `mongos`

Reinicie cada en el mongos clúster.

mongos --config /path/to/config/mongos.conf

Incluya todas las demás opciones de línea de comandos según lo requiera su implementación.

Si el nombre del conjunto de réplicas CSRS o el nombre de host de algún miembro cambió, actualice la mongos configuración del sharding.configDB archivo con la cadena de conexión del servidor de configuración actualizada:

sharding:
  configDB: "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"

F. Validar la accesibilidad del clúster

Conecte un shellmongoa uno de losmongosprocesos del clúster. Usesh.status()para comprobar el estado general del clúster. Sish.status()indica que el balanceador no se está ejecutando, usesh.startBalancer()para reiniciarlo. [1]

Para confirmar que todas las particiones son accesibles y que se están comunicando, inserta datos de prueba en una colección particionada temporal. Confirme que los datos se están dividiendo y migrando entre cada partición de su clúster. Puedes conectar un shell mongo a cada primario de partición y usar db.collection.find() para validar que los datos fueron particionados como se esperaba.

[1] A partir de MongoDB,6.0.3 la división automática de fragmentos no se realiza. Esto se debe a mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no realizan ninguna operación. En versiones de MongoDB anteriores 6.0.3 a, sh.startBalancer() también habilita la división automática para el clúster fragmentado.

Volver

Programar ventana de copia de seguridad para clústeres fragmentados

Recuperación de una instancia autónoma después de un apagado inesperado

Nota

Considerations

Antes de comenzar

Advertencia

A. (Opcional) Revisar configuraciones del set de réplicas

B. Preparar el host de destino para la restauración

Importante

C. Restaurar el conjunto de réplicas del servidor de configuración

Restaurar los mongod archivos de datos primariosCSRS.

Nota

Solo Cloud Manager o Ops Manager

Eliminar la local base de datos.

Inserte la lista de archivos filtrada en la base de datos local.

Ejecute el comando de restauración de archivo filtrado.

Para cualquier cambio de nombre de host de fragmento o de conjunto de réplicas planificado o completado, actualice los metadatos config.shards en.

Importante

Nota

Reinicie el como un nuevo conjunto de réplicas de nodo mongod único.

Iniciar el nuevo conjunto de réplicas.

Añadir miembros adicionales al set de réplicas.

Configure cualquier configuración de replicación adicional necesaria.

D. Restaurar cada conjunto de réplicas de fragmentos

Restaurar los mongod archivos de datos primarios del fragmento.

Nota

Solo Cloud Manager o Ops Manager

Crea un usuario temporal con el __system rol.

Advertencia

Eliminar la local base de datos.

Eliminar el minOpTimeRecovery documento de la admin.system.versions colección.

Nota

Opcional: Para cualquier cambio en el hostname CSRS o en el nombre del set de réplicas, actualiza los metadatos de partición en el documento de identidad de cada partición.

Importante

Reinicie el como un nuevo conjunto de réplicas de nodo mongod único.

Iniciar el nuevo conjunto de réplicas.

Añadir miembros adicionales al set de réplicas.

Configure cualquier configuración de replicación adicional necesaria.

Remueva el usuario temporal con privilegios.

E. Reinicie cada uno mongos

F. Validar la accesibilidad del clúster

Restaurar los `mongod` archivos de datos primariosCSRS.

Eliminar la `local` base de datos.

Para cualquier cambio de nombre de host de fragmento o de conjunto de réplicas planificado o completado, actualice los metadatos `config.shards` en.

Reinicie el como un nuevo conjunto de réplicas de nodo `mongod` único.

Restaurar los `mongod` archivos de datos primarios del fragmento.

Crea un usuario temporal con el `__system` rol.

Eliminar la `local` base de datos.

Eliminar el `minOpTimeRecovery` documento de la `admin.system.versions` colección.

Reinicie el como un nuevo conjunto de réplicas de nodo `mongod` único.

E. Reinicie cada uno `mongos`