NetWorker: NMDA MySQL – Triage-Handbuch

Erste Schritte:

Notieren Sie die Problembeschreibung und/oder den Screenshot des Kunden sowie Ihre eigenen Notizen und Fehler:

• NetWorker-Serverbetriebssystemplattform
• NetWorker-Serverversion und Build-Nummer
• NetWorker-Server-daemon.raw (bevorzugt gerendert)
• NetWorker-Clientbetriebssystemplattform
• NetWorker-Clientversion und Build-Nummer
• NetWorker-Client-daemon.raw (bevorzugt gerendert)
• Bereitstellung der Betriebssystemplattform, Architektur und Version des Clients (uname aoutputonUnix/Linux)

NMDA-Informationen:

• Geben Sie die Versionsinformationen der NMDA-Binärdateien an.

• Geben Sie die NMDA-Konfigurationsdatei an, die im Feld "Backup Command" (z. B. nsrdasv z /nsr/apps/config/nmda_oracle<SID.cfg>) der Clientressource verwendet wird, die für die geplanten Backups konfiguriert ist, oder die in der Befehlszeile für manuelle Vorgänge bereitgestellt wird.
• Geben Sie die Clusterinformationen an (z. B. Namen virtueller Hosts, die am Cluster beteiligt sind, Clustertyp), wenn es sich um eine Clusterumgebung handelt. (Fragen Sie, ob der Kunde eine Kopie der Hostdatei auf dem Client bereitstellen kann.)
• Wenn die Fehlermeldung auf ein Problem in der NetWorker-Speicher- oder Wiederherstellungssitzung hinweist, stellen Sie NetWorker-spezifische Informationen wie folgt bereit:
• Gerätetyp (DDBoost, VTL,..)
• Handelt es sich um ein Client Direct- oder SN-Backup auf DD, handelt es sich um ein lokales oder Remote-SN, handelt es sich um ein Avamar-Backup usw.?
• Stellen Sie die gerenderten daemon.raw von SN aus demselben Zeitfenster bereit, in dem der Fehler aufgetreten ist.
• Geben Sie die Versionsinformationen der NMDA-Binärdateien an.
•  

Unix:

strings/usr/sbin/nsrdasv  | grep Build

strings  /usr/sbin/nsrdaprobe  | grep Build 

(nur wenn der Test fehlschlägt)strings/usr/lib/libnsrora.so | grep @(#) (oder libnsrora.a)

Windows:

Klicken Sie mit der rechten Maustaste auf die Datei %NW_install_path%\bin\nsrsbtcn.exe -> Eigenschaften -> Details unter Windows

• Wenn das NMDA-Oracle-Backup über den Assistenten konfiguriert ist, erstellen Sie eine Kopie des Ordners thensrdbfolder mit tar-/komprimierungsdatei

Aktivieren Sie das Debugging:

Legen Sie NSR_DEBUG_LEVEL=9 in der NMDA-Konfigurationsdatei oder in der Tabelle "Erweiterte Optionen" des Assistenten fest (wenn die Konfiguration vom Assistenten erstellt wird).

Bitten Sie den Nutzer nicht, NSR_DPRINTF=TRUE festzulegen, um zu vermeiden, dass Debug-Protokolle zu groß werden, es sei denn, die Fehlermeldung verweist auf ein Problem in der NMDA-Speicher- oder Wiederherstellungssitzung mit NetWorker oder dies wird ausdrücklich vom Techniker angefordert.(Mit anderen Worten: "NSR_DPRINTF=TRUE" kann Fehler der "unteren Ebene" wie Data Domain-Fehlercode erzeugen, aber der Nachteil ist die Ausführlichkeit der Protokolle.)

Hinweis: Die Gesamtgröße des Debug-Protokolls kann für NMDA 1.2 oder eine ältere Version ein Problem darstellen, wenn das Debugging in einer großen Datenbankumgebung aktiviert wird, in der der Fehler nach einigen Stunden auftritt. Es wird erwartet, dass die Größe des Debug-Protokolls in NMDA 1.5 auf bis zu %50 reduziert wird.

Sammeln von Informationen und Protokollen:

Das gesamte Verzeichnis von /nsr/apps/logs tarieren/zippen

Hinweis:  Dieses Verzeichnis enthält die Betriebsprotokolldatei nmda_<App>.messages.raw und Debug-Protokolldateien.  Der standardmäßige Speicherort der Debug-Protokolle kann geändert werden, indem Sie NSR_DIAGNOSTIC_DEST in der Konfigurationsdatei festlegen.Anmerkung:  Die Oracle RMAN-Ausgabe und NW-Server-Daemon.raw sind sehr wichtig für das Troubleshooting von Oracle-Backups (denken Sie daran, diese Informationen zu sammeln)

MySQL-Informationen:

• Überprüfen Sie die installierte MySQL-Version und die installierte MEB-Version anhand der Versionshinweise für die von Ihnen verwendete NMDA-Version und stellen Sie sicher, dass eine unterstützte Konfiguration vorhanden ist.  Wenn nicht, empfehlen wir ein Upgrade von NetWorker/NMDA auf dem Client oder die Installation der unterstützten MySQL- und/oder MEB-Version wie angewiesen.
• Bereitstellen einer Kopie der MySQL-Konfiguration

        Zum Beispiel.

        /etc/meine.cnf

       oder CNF-Datei (MYSQL_CFG_FILE in der NMDA-cfg-Datei). Siehe http://dev.mysql.com/doc/refman/5.5/en/option-files.html für weitere Informationen.

• Geben Sie eine Kopie der MySQL-Indexdatei für den Binärprotokoll an.

Standardmäßig hat diese den gleichen Basisnamen wie die binäre Logdatei, mit der Endung '.index' (z.B. /var/log/mysql/mysql-bin.index),

und seinen Speicherort, der durch den Parameter log-bin in der MYSQL-Konfigurationsdatei definiert ist. Sie können den Namen der binären Log-Indexdatei mit der Option --log-bin-index[=file_name] ändern. Sie sollten diese Datei nicht manuell bearbeiten, während mysqld ausgeführt wird. Dies würde mysqld verwirren.

• Geben Sie eine Kopie des MySQL-Fehlerprotokolls (instance.err) an.  Kann angeben, wo mysqld das Fehlerprotokoll mit der Option --log-error[=file_name] schreibt. Wenn die Option ohne file_name Wert angegeben wird, verwendet mysqld standardmäßig den Namen host_name.err. Der Server erstellt die Datei im Datenverzeichnis, es sei denn, es wird ein absoluter Pfadname angegeben, um ein anderes Verzeichnis anzugeben.
• Speicherabbild von mysqladmin-Variablen in eine Textdatei

          Zum Beispiel.

          mysqladmin-u root -h 127.0.0.1 --password=football1 variable

          ( displaydatabase-Parametereinstellungen)