Restore logical backup to self-managed MongoDB | mongorestore - ApsaraDB for MongoDB

Prérequis

Vérifiez les conditions suivantes :

Vous disposez d'une instance ApsaraDB for MongoDB utilisant des SSD locaux.
La base de données MongoDB gérée par l'utilisateur exécute la même version que l'instance ApsaraDB for MongoDB.
Les outils MongoDB Database Tools (même version majeure) sont installés sur l'hôte de la base de données gérée par l'utilisateur (serveur local ou instance ECS). Install MongoDB

Important

L'outil mongorestore doit être compatible avec votre version de MongoDB. Une version antérieure de mongorestore ne prend pas en charge une version plus récente de MongoDB. Consultez la matrice de compatibilité mongorestore Compatibility.

Considérations relatives aux clusters fragmentés

Restauration vers une base de données gérée par l'utilisateur en cluster fragmenté

Pour les bases de données gérées par l'utilisateur en cluster fragmenté :

Définissez <hostname> sur l'endpoint mongos. Ne ciblez pas un shard individuel.
Ajoutez --nsExclude="config.*" à la commande mongorestore afin d'éviter les erreurs liées à la base de données config.

Restauration depuis une instance en cluster fragmenté

Pour les instances ApsaraDB for MongoDB en cluster fragmenté :

Téléchargez et importez les données de sauvegarde pour chaque shard séparément.
Les documents orphelins dans l'instance en cluster fragmenté peuvent générer des données corrompues dans la base de données gérée par l'utilisateur.
Lors de la restauration des fichiers de sauvegarde de plusieurs shards vers la même base de données en cluster fragmenté, ajoutez --drop uniquement pour le premier shard. Omettez --drop pour les shards suivants afin d'éviter de supprimer les données précédemment restaurées.

Étape 1 : Créer une sauvegarde logique

Connectez-vous à la console ApsaraDB for MongoDB.
Dans le volet de navigation de gauche, cliquez sur Replica Set Instances ou Sharded Cluster Instances.
Dans le coin supérieur gauche de la page, sélectionnez le groupe de ressources et la région de l'instance.
Cliquez sur l'ID de l'instance, ou cliquez sur dans la colonne Actions et sélectionnez Manage.
Dans le coin supérieur droit de la page des détails de l'instance, cliquez sur Back up Instance.
Dans le panneau Back up Instance, définissez Backup Method sur Logical Backup.
Cliquez sur OK et attendez la fin de la sauvegarde.

Étape 2 : Télécharger le fichier de sauvegarde

Télécharger les fichiers de sauvegarde.
Copiez le fichier de sauvegarde sur l'hôte exécutant la base de données MongoDB gérée par l'utilisateur ainsi que l'outil mongorestore.

Étape 3 : Exécuter `mongorestore`

Importez les données de sauvegarde dans la base de données gérée par l'utilisateur :

mongorestore -h <hostname> --port <server port> -u <username> -p <password> --drop --gzip --archive=<backupfile> -vvvv --stopOnError

Paramètres requis

Paramètre	Description
`<hostname>`	Adresse de l'hôte de la base de données MongoDB gérée par l'utilisateur. Utilisez `127.0.0.1` pour localhost. Pour les architectures en cluster fragmenté, définissez cette valeur sur l'endpoint `mongos`.
`<server port>`	Numéro de port de la base de données MongoDB gérée par l'utilisateur. Valeur par défaut : `27017`.
`<username>`	Compte disposant des autorisations de lecture et d'écriture sur toutes les bases de données. Utilisez le compte root.
`<password>`	Mot de passe du compte spécifié.
`<backupfile>`	Nom ou chemin d'accès du fichier de sauvegarde logique téléchargé.

Paramètres facultatifs

Paramètre	Description
`--drop`	Supprime chaque collection avant de la restaurer. Lors de la restauration de plusieurs shards vers la même base de données en cluster fragmenté, ajoutez ce paramètre uniquement pour le premier shard.
`--gzip`	Décompresse les données de sauvegarde compressées en gzip. Pris en charge à partir de MongoDB 3.1.4. mongo-tools changelog.
`-vvvv`	Niveau de verbosité le plus élevé. Chaque `v` supplémentaire ajoute plus de détails au journal de sortie.
`--stopOnError`	Arrête immédiatement la restauration en cas d'erreur.
`--nsExclude`	Exclut les espaces de noms correspondants de la restauration. Exemple : `--nsExclude="config.*"`. Requis pour les bases de données gérées par l'utilisateur en cluster fragmenté.

Optimisation des performances

Pour les grands ensembles de données, ajoutez ces paramètres pour améliorer les performances de restauration :

Paramètre	Description
`--numParallelCollections`	Nombre de collections à restaurer en parallèle. Valeur par défaut : `4`. Augmentez cette valeur si l'hôte cible dispose d'une capacité CPU et E/S suffisante.
`--numInsertionWorkersPerCollection`	Nombre de workers d'insertion simultanés par collection. Valeur par défaut : `1`. Augmentez cette valeur pour les imports volumineux en fonction des ressources serveur disponibles.

Exemple avec mise en parallèle :

mongorestore -h 127.0.0.1 --port 27017 -u root -p <password> \
  --drop --gzip --archive=<backupfile> \
  --numParallelCollections=4 \
  --numInsertionWorkersPerCollection=4 \
  -vvvv --stopOnError

Exemple

mongorestore -h 127.0.0.1 --port 27017 -u root -p ******** --drop --gzip --archive=hins1111_data_20190710.ar -vvvv --stopOnError

Vérifier les données restaurées

Vérifiez l'exhaustivité et l'exactitude des données restaurées.

Vérifier les nombres de documents

Comparez les nombres de documents entre la sauvegarde et la base de données restaurée :

// Connect to the self-managed database
use <database_name>

// Check the document count for each collection
db.getCollectionNames().forEach(function(c) {
    print(c + ": " + db.getCollection(c).countDocuments({}));
});

Comparez la sortie avec les nombres de documents de l'instance ApsaraDB for MongoDB source.

Exécuter des requêtes d'échantillonnage

Effectuez des contrôles ponctuels pour vous assurer que les documents, les champs et les valeurs sont intacts :

// Verify a specific document exists
db.<collection_name>.findOne({ _id: ObjectId("<known_id>") })

Vérifier les index

Confirmez que les index ont été correctement restaurés :

db.<collection_name>.getIndexes()

Comparez avec l'instance source pour vérifier que tous les index sont présents.

Liste de contrôle post-restauration

Après la vérification, confirmez les points suivants :

[ ] Les nombres de documents correspondent entre l'instance source et la base de données gérée par l'utilisateur
[ ] Les index sont présents et correspondent à l'instance source
[ ] Les requêtes d'échantillonnage renvoient les résultats attendus
[ ] La connectivité de l'application à la base de données gérée par l'utilisateur est confirmée
[ ] Pour les restaurations en cluster fragmenté, vérifiez la présence de documents orphelins et nettoyez les données corrompues