NetWorker : guide de tri NMDA MySQL (en anglais)
Résumé: Cet article décrit les informations qui doivent être fournies pour examiner un problème MySQL NMDA.
Instructions
Mise en route :
Notez la description et/ou la capture d’écran du problème du client, ainsi que vos propres remarques et erreurs :
- Plate-forme du système d’exploitation du serveur NetWorker
- Version et numéro de build de NetWorker Server
- NetWorker Server daemon.raw (rendu de préférence)
- Plate-forme de système d’exploitation client NetWorker
- Version et numéro de build de NetWorker Client
- Client NetWorker daemon.raw (rendu de préférence)
- Indiquez la plate-forme du système d’exploitation, l’architecture et la version du client (uname aoutputonUnix/Linux).
Renseignements sur la NMDA :
-
Fournissez les informations de version des fichiers binaires NMDA.
- Fournissez le fichier de configuration NMDA utilisé dans le champ Commande de sauvegarde (par exemple, nsrdasv z /nsr/apps/config/nmda_oracle<SID.cfg>) de la ressource client configurée pour les sauvegardes planifiées ou fourni dans la ligne de commande pour les opérations manuelles.
- Fournissez les informations sur le cluster (par exemple, noms d’hôtes virtuels impliqués dans le cluster, type de cluster), s’il s’agit d’un environnement de cluster. (Demander au client s’il peut fournir une copie du fichier d’hôtes sur le client)
- Si le message d’erreur pointe vers un problème dans la session de sauvegarde ou de restauration NetWorker, fournissez des informations spécifiques à NetWorker comme suit :
- Type de périphérique (DDBoost, VTL,..)
- S’agit-il d’une sauvegarde Client Direct ou SN vers DD, d’une sauvegarde SN locale ou distante, d’une sauvegarde Avamar, etc. ?
- Fournir le daemon.raw rendu à partir du SN de la même fenêtre horaire que celle où la panne s’est produite
- Fournissez les informations de version des fichiers binaires NMDA.
Unix :
strings/usr/sbin/nsrdasv | grep Build
strings /usr/sbin/nsrdaprobe | grep Build
(uniquement en cas d’échec de la sonde)strings/usr/lib/libnsrora.so | grep @(#) (ou libnsrora.a)
Windows :
Cliquez avec le bouton droit de la souris sur le fichier %NW_install_path%\bin\nsrsbtcn.exe -> Propriétés -> Détails sous Windows
- Si la sauvegarde NMDA Oracle est configurée via l’assistant, compressez une copie du dossier srdbfolder ou compressez-le.
Activez le débogage :
Définissez NSR_DEBUG_LEVEL=9 dans le fichier de configuration NMDA ou dans le tableau Advanced Option de l’assistant (si la configuration est créée par l’assistant).
Ne demandez pas à l’utilisateur de définir NSR_DPRINTF=TRUE pour éviter que les logs de débogage n’atteignent une taille importante, sauf si le message d’erreur pointe vers un problème dans la session de sauvegarde ou de restauration NMDA avec NetWorker, ou si cela est explicitement demandé par l’ingénierie.(En d’autres termes, l’option NSR_DPRINTF=TRUE peut générer des « erreurs de couche inférieure » telles que le code d’erreur Data Domain, mais l’inconvénient est le caractère détaillé des journaux)
Remarque : La taille totale du journal de débogage peut être préoccupante pour NMDA 1.2 ou une version antérieure lors de l’activation du débogage dans un environnement de base de données de grande taille où la défaillance se produit après quelques heures. La taille du journal de débogage devrait être réduite jusqu’à 50 % dans NMDA 1.5.
Collecte d’informations et de journaux :
Compressez l’ensemble du répertoire de /nsr/apps/logs.
Remarque : Ce répertoire contient le fichier log opérationnel nmda_<application>.messages.raw et les fichiers log de débogage. L’emplacement par défaut des logs de débogage peut être modifié en définissant NSR_DIAGNOSTIC_DEST dans le fichier de configuration.Note: La sortie Oracle Rman et le Daemon.raw du serveur NW sont très importants pour le dépannage de la sauvegarde Oracle (n’oubliez pas de collecter ces informations)
Informations MySQL :
- Vérifiez la version MySQL et la version MEB installée par rapport aux notes de mise à jour correspondant à la version de NMDA que vous utilisez et assurez-vous que nous disposons d’une configuration prise en charge. Si ce n’est pas le cas, recommandez de mettre à niveau NetWorker/NMDA sur le client ou d’installer la version prise en charge de MySQL et/ou MEB comme indiqué.
- Fournir une copie de la configuration MySQL
Par ex.
/etc/mon.cnf
ou le FIIC (MYSQL_CFG_FILE dans le fichier cfgde de l’ADNM). Voir la section http://dev.mysql.com/doc/refman/5.5/en/option-files.html pour plus de détails.
- Fournissez une copie du fichier d’index des journaux binaires MySQL.
Par défaut, il a le même nom de base que le fichier journal binaire, avec l’extension '.index' (par exemple /var/log/mysql/mysql-bin.index),
et son emplacement défini par le paramètre log-bin dans le fichier de configuration de MYSQL. Vous pouvez modifier le nom du fichier d’index de log binaire à l’aide de l’option --log-bin-index[=file_name]. Vous ne devez pas modifier manuellement ce fichier pendant que mysqld est en cours d’exécution ; Cela perturberait MySQLD.
- Fournissez une copie du journal des erreurs MySQL (instance.err). Peut spécifier wheremysqldécrit le journal des erreurs avec l’option --log-error[=file_name]. Si l’option est donnée sans valeur file_name, mysqld utilise le nom host_name.err par défaut. Le serveur crée le fichier dans le répertoire de données, sauf si un nom de chemin absolu est donné pour spécifier un autre répertoire.
- Vidage des variables mysqladmin dans un fichier texte
Par ex.
mysqladmin-u root -h 127.0.0.1 --password=football1 variable
(paramètres displaydatabase)