Guide de l'administrateur NetBackup™ for MongoDB

Considérez une configuration avec un cluster MongoDB haute disponibilité partitionné contenant plusieurs processus mongos. Avant le lancement d'une opération de restauration et de récupération, seul le processus mongos à l'emplacement de restauration de l'image du jeu de répliques du serveur de configuration (CSRS) doit être en cours d'exécution.

Arrêtez manuellement tout autre processus mongos dans le cluster avant de lancer une opération de restauration et de récupération.

Une fois la récupération terminée, reconfigurez les services mongos pour qu'ils pointent vers le cluster récupéré.

Si le processus mongos n'est pas arrêté sur tous les nœuds sauf un, les autres processus mongos peuvent entrer en conflit avec l'opération de restauration. Les données restaurées seraient alors inaccessibles avec une connexion à mongos.

Si vous n'arrêtez pas les processus mongos avant le lancement de la restauration et de la récupération, vous devrez arrêter manuellement les processus mongos obsolètes après la récupération. Redémarrez ensuite tous les processus mongod et mongos récupérés sous le cluster.

Vous devez démarrer les processus MongoDB avec un chemin absolu vers les fichiers de configuration. et utiliser les chemins absolus des fichiers de certificat et du fichier d'autorité de certification. Vous devez également spécifier les chemins absolus du fichier d'autorité de certification, du fichier PEM et des fichiers de clé.

N/A

Si vous exécutez un travail de récupération nécessitant une authentification différente de celle utilisée pour les modifications de sauvegarde, il se peut que le processus de récupération échoue.

Assurez-vous d'utiliser le même type d'authentification pour la récupération et pour la sauvegarde.

Si vous renommez le groupe de volumes ou le volume logique après avoir exécuté une sauvegarde, la sauvegarde suivante risque d'échouer.

S/O

Lors de la récupération, veillez à sélectionner une seule image de sauvegarde complète et les images incrémentielles suivantes appropriées. Si vous sélectionnez plusieurs images, les données restaurées pourraient être endommagées et faire échouer la récupération.

N/A

Une fois le cluster MongoDB récupéré, seules les informations de cluster du nœud restauré sont disponibles.

Une fois le processus de récupération terminé, ajoutez manuellement les nœuds secondaires au cluster.

Pour plus d'informations, consultez l'article suivant :Ajouter des membres au jeu de répliques

Pendant le processus de sauvegarde, si l'opération d'importation MongoDB est en cours d'exécution, elle peut cesser de répondre. Évitez de procéder à l'opération d'importation MongoDB pendant le processus de sauvegarde ou de restauration.

S/O

Pendant le processus de restauration, le message La restauration a été lancée s'affiche, mais le travail de restauration ne démarre pas.

Ce problème se produit lorsque le serveur d'application spécifié est le même pour le Client source et le Client cible dans l'interface utilisateur Web.

Assurez-vous que le Client source et le Client cible sont spécifiés correctement. Le Client source doit correspondre au serveur d'application et le Client cible à l'hôte de sauvegarde.

Si votre environnement présente une configuration DNAT, assurez-vous que l'hôte de sauvegarde ou l'hôte de restauration ainsi que tous les nœuds MongoDB se trouvent dans le même réseau privé.

S/O

Le plug-in NetBackup for MongoDB ne prend pas en charge les options de ligne de commande bprestore-w et -print_jobid.

S/O

Les restaurations MongoDB ne sont pas prises en charge à partir des hôtes de sauvegarde. Toutes les opérations de restauration pour MongoDB doivent être lancées à partir du serveur principal NetBackup.

S/O

Si votre envoi de travail de restauration n'affiche pas le travail de restauration, vérifiez si un plug-in MongoDB est installé sur votre nœud cible.

S/O

Si vous restaurez la base de données MongoDB à un emplacement non LVM, et que vous tentez d'effectuer une sauvegarde à partir de cet emplacement non LVM, la sauvegarde échoue.

Restaurez les données à un emplacement LVM, puis tentez de sauvegarder les données restaurées.

Le plug-in NetBackup for MongoDB ne prend pas en charge les liens physiques ou virtuels dans les dossiers de chemin d'accès aux données. N'ajoutez aucun lien physique ou virtuel qui pointe vers des emplacements d'un volume logique ou non logique différent.

NetBackup ne peut pas garantir la cohérence des données au moment des sauvegardes si le dossier de chemin d'accès aux données contient des liens physiques ou virtuels. Pendant le processus de restauration, les liens physiques ou virtuels sont créés en tant que dossiers et non en tant que liens.

S/O

Lorsque vous annulez un travail de restauration enfant pendant le processus de restauration et de récupération MongoDB, le client léger (mdbserver) n'est pas supprimé immédiatement. Il sera supprimé après l'opération de restauration suivante.

S/O

La restauration MongoDB échoue et affiche l'erreur 2850.

Tenez compte des solutions suivantes :

Après la récupération, le redémarrage manuel du nœud de partition MongoDB échoue et l'erreur suivante est consignée dans les journaux MongoDB :

NoSuchKey: Missing expected field "configsvrConnectionString"

Sur la partition MongoDB concernée par le problème, démarrez MongoDB en mode maintenance et exécutez la méthode suivante sur la collection system.version dans la base de données d'administration :

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

Dans le cas d'une opération de restauration contenant un ou plusieurs jeux de répliques, les membres du jeu de répliques sont restaurés sur le jeu de répliques à l'aide de la valeur par défaut "cfg.members[#].host" fournie par rs.config().

Si cette valeur par défaut a été précédemment modifiée, il sera peut-être nécessaire de la mettre à jour après la restauration et la récupération pour qu'elle corresponde à la configuration d'origine (en remplaçant le nom court par le nom de domaine complet, par exemple).

Solution de contournement :

Les travaux de sauvegarde échouent et les codes d'erreur suivants s'affichent :

Assurez-vous que les fenêtres de sauvegarde pour les sauvegardes incrémentielles sont différentes pour un même cluster MongoDB. Les fenêtres de sauvegarde d'un cluster MongoDB ne doivent pas se chevaucher pour les sauvegardes incrémentielles.

Assurez-vous que des autorisations sont définies pour l'emplacement mdbserver, l'emplacement oplog et l'emplacement de montage de snapshot. Pour plus d'informations, reportez-vous à la section Se reporter à Conditions requises pour l'utilisateur de l'hôte..

Dans un environnement de cluster MongoDB partitionné, une erreur 112 peut indiquer que le processus mongos n'est pas en cours d'exécution sur le client défini dans la politique de sauvegarde.

Une erreur 112 peut également indiquer que plusieurs hôtes de sauvegarde portant des noms d'hôte identiques sont ajoutés à la politique BigData. Utilisez un nom d'hôte unique pour chaque hôte de sauvegarde exécutant les opérations de sauvegarde.

Si vous tentez d'arrêter et de redémarrer les services mongod ou mongos (service mongod stop ou service mongod restart) après une opération de restauration et de récupération, les commandes échouent.

Cette erreur se produit lorsque les processus mongod ou mongos sont lancés en tant que services à l'aide des commandes service ou systemctl et non à l'aide d'une commande directe.

Solution de contournement :

Utilisez une autre méthode pour arrêter les services mongod ou mongos. Par exemple, mongod -f /etc/mongod.conf --shutdown ou kill <PID>. Une fois les services arrêtés, vous pourrez de nouveau utiliser les commandes service ou systemctl.

L'opération de sauvegarde échoue si une commande qui génère une sortie dans .bashrc est ajoutée.

La sauvegarde échoue avec l'erreur 6646 et affiche le message suivant :

Erreur : Impossible de communiquer avec le serveur.

Assurez-vous que .bashrc (echo ou toute autre commande générant des sorties) ne génère aucune sortie. La sortie ne doit pas renvoyer STDERR ou STDOUT si le shell n'est pas interactif.

Lorsque vous sélectionnez deux images de sauvegarde complète et que vous tentez de restaurer une image spécifique qui se trouve entre ces deux images de sauvegarde complète, la dernière image de sauvegarde complète est restaurée.

Solution de contournement :

Pendant l'opération de restauration, ne sélectionnez qu'une seule image de sauvegarde complète.

Pour une récupération spécifique, assurez-vous d'exécuter des sauvegardes incrémentielles différentielles plus courtes.

Impossible d'afficher la progression du travail de restauration dans le nœud Récupération.

Solution de contournement :

Pour un travail de restauration composé utilisant un serveur non principal comme hôte de restauration, recherchez l'enregistrement et l'état du travail dans la section Progression de la tâche du nœud Récupération. Cliquez sur Actualiser pour mettre à jour la liste de tâches.

La sauvegarde échoue avec l'erreur suivante :

(6625) L'hôte de sauvegarde n'est pas autorisé à exécuter l'opération ou il ne peut pas établir une connexion au serveur d'applications.

Solution de contournement :

Sur le serveur sur lequel MongoDB est installé, assurez-vous que PasswordAuthentication n'est pas désactivé dans le fichier /etc/ssh/sshd_config.

Exécutez la commande sudo service sshd restart.

La sauvegarde échoue avec l'erreur suivante :

(6646) Impossible de communiquer avec le serveur.

Solution de contournement :

Assurez-vous que l'hôte de sauvegarde peut accéder au port défini dans le fichier mongodb.conf ou au port mdbserver_port par défaut (11000).

L'erreur suivante est consignée dans les journaux mdbserver :

error-sudo: sorry, you must have a tty to run sudo

Solution de contournement :

Le dossier des journaux nbaapireq_handler n'est pas créé sur un conteneur Flex, même après l'exécution de la commande mklogdir.

Solution de contournement :

Lorsqu'une appliance Flex est mise à niveau de la version 8.1.2 vers la version 8.2 et que le serveur de médias Flex est utilisé comme hôte de sauvegarde, le plug-in MongoDB crée le répertoire des journaux suivant :

/usr/openv/netbackup/logs/nbaapireq_handler

La taille de snapshot décrite par le paramètre free_space_percentage_snapshot doit être définie selon la taille de cluster MongoDB et doit être suffisamment grande. Si ces critères ne sont pas remplis, la sauvegarde échoue et l'erreur suivante s'affiche :

invalid command parameter (20)

Validez la valeur free_space_percentage_snapshot avec le cluster MongoDB.

La sauvegarde échoue avec l'erreur suivante :

(13) échec de lecture du fichier pour le média

Assurez-vous que :

Le paramètre mdb_progress_loglevel n'est pas disponible dans l'outil de configuration MongoDB.

Pour modifier le paramètre mdb_progress_loglevel, mettez à jour le fichier mongodb.conf une fois que l'outil de configuration MongoDB l'a créé.

Pour plus d'informations, consultez le Guide de l'administrateur MongoDB.

Les snapshots ne sont pas supprimés et des instances mdbserver obsolètes sont affichées. Ce scénario peut entraîner des erreurs Cannot lstat lors des sauvegardes et des sauvegardes partiellement réussies.

Modifiez les paramètres de configuration pour les paramètres suivants dans le fichier mongodb.conf :

Définissez les valeurs de sorte que les snapshots et instances obsolètes de mdbserver soient effacés avant la planification de sauvegarde complète ou incrémentielle suivante.

Si la version de NetBackup installée sur l'hôte de sauvegarde est antérieure à la version 8.3 alors que le serveur principal et le serveur de médias disposent de la dernière version, les codes d'erreur suivants peuvent s'affichent pour différents scénarios :

13302, 13303, 13304, 13305, 13306, 13307, 13308, 13309, 13310, 13311, 13312, 13313, 13314, 13315

Solution de contournement :

Si des codes d'erreur non valides s'affichent, consultez la liste suivante de codes d'erreur réels pour découvrir les scénarios réels et les actions recommandées :

Pour en savoir plus et découvrir les actions recommandées, consultez le Guide de référence des codes d'état NetBackup.

Le bouton Restaurer de l'interface utilisateur Web NetBackup peut être désactivé pour les images de sauvegarde MongoDB importées.

Solution de contournement :

Si vous importez les images sur le serveur principal NetBackup sur lequel elles ont été initialement sauvegardées, appliquez l'une des méthodes suivantes :

Si vous importez les images sur un serveur principal NetBackup autre que celui sur lequel elles ont été initialement sauvegardées, utilisez la commande bprestore pour exécuter l'opération de restauration.

L'opération de récupération échoue sur un autre cluster MongoDB partitionné. L'erreur suivante s'affiche :

Impossible de trouver le paramètre de configuration. (6661)

Ce problème se produit lors de la récupération vers un autre cluster, car la vérification de prérécupération ne trouve pas le port mongos de l'autre cluster dans le fichier mongodb.conf. Il s'agit d'un problème lié à la manière dont l'outil de configuration MongoDB crée le fichier mongodb.conf lorsque vous ajoutez les détails de l'autre cluster MongoDB à l'aide de l'option Mettre à jour de l'outil.

Solution de contournement :

Avant de démarrer le processus de récupération, mettez à jour le fichier mongodb.conf afin de séparer l'autre cluster du cluster d'origine.

Par exemple :

Fichier mongodb.conf existant :

 "application_servers":
   {
    "original.mongodb.cluster.com:26050":
		 {
     "alternate_config_server":
			  [
       {
         "hostname:port": "alt.mongodb.cluster.com:26000",
         "mongos_port": "26001"
       }
      ],
    "mongos_port": "26051"
    }
   }

Suggestion de mise à jour du fichier mongodb.conf :

"application_servers": 
   {
    "original.mongodb.cluster.com:26050":
   {
      "mongos_port": "26051"
   },
      "alt.mongodb.cluster.com:26000":
   {
   "mongos_port": "26001"
   }
   }

L'outil MUI affiche l'erreur suivante :

Impossible de supprimer la configuration.

Action recommandée :

Solution de contournement :

Supprimez manuellement le fichier <hostname-port>.conf de /usr/openv/var/global.

En cas d'authentification basée sur un certificat activée sur MongoDB, les sauvegardes incrémentielles différentielles échouent avec l'erreur 6709 : Impossible d'exécuter la commande.

Solution de contournement :

Recherchez le code d'erreur et les détails de la commande dans les journaux mdbserver. Effectuez ensuite l'une des opérations suivantes :