Inhalt

Einleitung

Schritte zur Diagnose der Datenbankreplikation

Schritt 1: Überprüfen, ob die Datenbankreplikation unterbrochen ist

Schritt 2: CM-Datenbankstatus von der Seite "Cisco Unified Reporting" auf dem CUCM erfassen

Schritt 3: Überprüfen Sie den Unified CM-Datenbankbericht für alle Komponenten, die als fehlerhaft gekennzeichnet sind.

Schritt 4: Überprüfen Sie die einzelnen Komponenten, die den utils diagnose-Testbefehl verwenden.

Schritt 5: Überprüfen Sie den Verbindungsstatus aller Knoten, und stellen Sie sicher, dass sie authentifiziert sind.

Schritt 6: Der Befehl utils dbreplication runtimestate zeigt den Status "Out-Sync" oder "Nicht angefordert" an.

Schritt 7. Reparieren aller/selektiver Tabellen für die Datenbankreplikation

Schritt 8: Datenbankreplikation von Grund auf zurücksetzen

Einleitung

In diesem Dokument wird beschrieben, wie Datenbankreplikationsprobleme diagnostiziert werden, und es werden die erforderlichen Schritte zur Fehlerbehebung und Behebung dieser Probleme beschrieben.

Schritte zur Diagnose der Datenbankreplikation

In diesem Abschnitt werden Szenarien beschrieben, in denen die Datenbankreplikation unterbrochen wird. Außerdem wird die Fehlerbehebungsmethode erläutert, die ein TAC-Techniker anwendet, um das Problem zu diagnostizieren und zu isolieren.

Schritt 1: Überprüfen, ob die Datenbankreplikation unterbrochen ist

Um festzustellen, ob die Datenbankreplikation beschädigt ist, müssen Sie die verschiedenen Zustände des Real Time Monitoring Tool (RTMT) für die Replikation kennen.

Wert

Bedeutung

Beschreibung

0

Initialisierungsstatus

Die Replikation wird gerade eingerichtet. Ein Setup-Fehler kann auftreten, wenn sich die Replikation länger als eine Stunde in diesem Zustand befindet.

1

Die Anzahl der Replikate ist falsch.

Die Einrichtung ist noch nicht abgeschlossen. Dieser Zustand ist in den Versionen 6.x und 7.x selten zu beobachten. In Version 5.x weist er darauf hin, dass das Setup noch läuft.

2

Replikation ist gut

Es werden logische Verbindungen hergestellt, und die Tabellen werden mit den anderen Servern im Cluster abgeglichen.

3

Nicht übereinstimmende Tabellen

Es werden logische Verbindungen hergestellt, es besteht jedoch eine Unsicherheit, ob die Tabellen übereinstimmen.

In den Versionen 6.x und 7.x können alle Server den Status 3 anzeigen, auch wenn ein Server im Cluster nicht verfügbar ist.

Dieses Problem kann auftreten, weil sich die anderen Server nicht sicher sind, ob eine Aktualisierung für die benutzerseitige Funktion (User Facing Feature, UFF) vorliegt, die nicht vom Subscriber an das andere Gerät im Cluster weitergeleitet wurde.

4

Setup fehlgeschlagen/abgebrochen

Der Server verfügt nicht mehr über eine aktive logische Verbindung, um Datenbanktabellen im Netzwerk zu empfangen. In diesem Zustand findet keine Replikation statt.

Führen Sie zum Überprüfen der Datenbankreplikation den Befehl utils dbreplication runtimestate aus der CLI des Publisherknotens aus, wie in diesem Bild dargestellt.

Stellen Sie in der Ausgabe sicher, dass der Cluster-Replikationsstatus nicht die alten Synchronisierungsinformationen enthält. Überprüfen Sie den Wert, und verwenden Sie den Zeitstempel.

Wenn die Broadcast-Synchronisierung nicht mit einem aktuellen Datum aktualisiert wird, führen Sie den Befehl utils dbreplication status aus, um alle Tabellen und die Replikation zu überprüfen. Wenn Fehler/Diskrepanzen erkannt werden, werden sie in der Ausgabe angezeigt, und der RTMT-Status ändert sich entsprechend, wie in diesem Bild dargestellt.

Nachdem Sie den Befehl ausgeführt haben, werden alle Tabellen auf Konsistenz überprüft, und es wird ein genauer Replikationsstatus angezeigt.

Hinweis: Lassen Sie alle Tabellen überprüfen, und fahren Sie dann mit der Fehlerbehebung fort.

Wenn ein genauer Replikationsstatus angezeigt wird, überprüfen Sie das Replikations-Setup (RTMT) und die Details, wie in der ersten Ausgabe dargestellt. Sie müssen den Status für jeden Knoten überprüfen. Wenn ein Knoten einen anderen Zustand als 2 aufweist, fahren Sie mit der Fehlerbehebung fort.

Schritt 2: CM-Datenbankstatus von der Seite "Cisco Unified Reporting" auf dem CUCM erfassen

1. Wenn Sie Schritt 1 abgeschlossen haben, wählen Sie die Option Cisco Unified Reporting aus der Dropdown-Liste Navigation im CUCM-Publisher aus, wie in diesem Bild dargestellt.

2. Navigieren Sie zu Systemberichte, und klicken Sie auf Unified CM Database Status (Unified CM-Datenbankstatus), wie in dieser Abbildung dargestellt.

3. Erstellen Sie einen neuen Bericht mit der Option "Neuen Bericht erstellen", oder klicken Sie auf das Symbol "Neuen Bericht erstellen", wie in diesem Bild dargestellt.

4. Speichern Sie den Bericht nach dem Generieren und Herunterladen, damit er einem TAC-Techniker bereitgestellt werden kann, falls ein Serviceticket (SR) erstellt werden muss.

Schritt 3: Überprüfen Sie den Unified CM-Datenbankbericht für alle Komponenten, die als fehlerhaft gekennzeichnet sind.

Wenn die Komponenten Fehler enthalten, sind diese mit einem roten X gekennzeichnet, wie in dieser Abbildung gezeigt.

- Stellen Sie sicher, dass auf lokale Datenbanken und Publisher-Datenbanken zugegriffen werden kann.

- Überprüfen Sie im Fehlerfall die Netzwerkverbindung zwischen den Knoten. Überprüfen Sie, ob der Cisco DB-Dienst A über die CLI des Knotens ausgeführt wird und den Befehl utils service list verwendet.

- Wenn der Cisco DB-Dienst ausgefallen ist, führen Sie den Befehl utils service start A Cisco DB aus, um den Dienst zu starten. Wenn dies fehlschlägt, wenden Sie sich an das Cisco TAC.

- Stellen Sie sicher, dass die Replikationsserverliste (cdr list serv) für alle Knoten ausgefüllt ist.

Dieses Bild stellt eine ideale Ausgabe dar.

Wenn die Liste von Cisco Database Replicator (CDR) für einige Knoten leer ist, finden Sie weitere Informationen in Schritt 8.

- Stellen Sie sicher, dass die Unified CM-Hosts, Rhosts und SqlHosts auf allen Knoten gleich sind.

Dies ist ein wichtiger Schritt. Wie in diesem Bild gezeigt, sind die Unified CM-Hosts, die Rhosts und die SqlHosts auf allen Knoten gleich.

Die Host-Dateien stimmen nicht überein:

Es besteht die Möglichkeit einer falschen Aktivität, wenn sich eine IP-Adresse ändert oder auf den Hostnamen auf dem Server aktualisiert.

Verwenden Sie diesen Link, um die IP-Adresse in den Hostnamen für den CUCM zu ändern.

Änderungen an IP-Adresse und Hostname

Starten Sie diese Dienste über die CLI des Publisher-Servers neu, und überprüfen Sie, ob die Inkongruenz behoben ist. Falls ja, fahren Sie mit Schritt 8 fort. Falls nein, wenden Sie sich an das Cisco TAC. Erstellen Sie bei jeder Änderung in der GUI/CLI einen neuen Bericht, um zu überprüfen, ob die Änderungen übernommen wurden.

Cluster Manager ( utils service restart Cluster Manager)

A Cisco DB ( utils service restart A Cisco DB)

Die Rhosts-Dateien stimmen nicht überein:

Wenn die Rhosts-Dateien nicht mit den Host-Dateien übereinstimmen, befolgen Sie die Schritte unter Die Host-Dateien sind nicht identisch. Wenn nur die Rhosts-Dateien nicht übereinstimmen, führen Sie die Befehle in der CLI aus:

A Cisco DB ( utils service restart A Cisco DB )

Cluster Manager ( utils service restart Cluster Manager)

Generieren Sie einen neuen Bericht, und überprüfen Sie, ob die Rhost-Dateien auf allen Servern gleich sind. Falls ja, fahren Sie mit Schritt 8 fort. Falls nein, wenden Sie sich an das Cisco TAC.

Die Sqlhosts stimmen nicht überein:

Wenn die Sqlhosts nicht mit den Host-Dateien übereinstimmen, befolgen Sie die Schritte unter Die Host-Dateien stimmen nicht überein. Wenn nur die Sqlhosts-Dateien nicht übereinstimmen, führen Sie den Befehl in der CLI aus:

utils service restart A Cisco DB

Generieren Sie einen neuen Bericht, und überprüfen Sie, ob die Sqlhost-Dateien auf allen Servern gleich sind. Falls ja, fahren Sie mit Schritt 8 fort. Falls nein, wenden Sie sich an das Cisco TAC

- Stellen Sie sicher, dass die Datenbank-Layer-RPC-Hello-Nachricht erfolgreich ist, wie in diesem Bild gezeigt.

Wenn die RPC-Hello-Funktion für einen bestimmten Knoten nicht funktioniert:

- Stellen Sie die Netzwerkverbindung zwischen dem jeweiligen Knoten und dem Publisher sicher.

- Stellen Sie sicher, dass die Portnummer 1515 im Netzwerk zulässig ist.

Unter diesem Link finden Sie weitere Informationen zur Verwendung des TCP/UDP-Ports:

Verwendung von Cisco Unified Communications Manager TCP- und UDP-Ports

- Stellen Sie sicher, dass die Netzwerkverbindung zwischen den Knoten erfolgreich ist, wie in diesem Bild gezeigt:

Wenn die Netzwerkverbindung für die Knoten ausfällt:

- Stellen Sie sicher, dass die Netzwerkerreichbarkeit zwischen den Knoten gewährleistet ist.

- Stellen Sie sicher, dass die entsprechenden TCP/UDP-Portnummern im Netzwerk zulässig sind.

Erstellen Sie einen neuen Bericht, und prüfen Sie, ob eine Verbindung erfolgreich hergestellt wurde. Bei einer nicht erfolgreichen Verbindung fahren Sie mit Schritt 8 fort.

Schritt 4: Überprüfen Sie die einzelnen Komponenten, die den utils diagnose-Testbefehl verwenden.

Der Befehl utils diagnose test überprüft alle Komponenten und gibt einen übergebenen/fehlerhaften Wert zurück. Die für das ordnungsgemäße Funktionieren der Datenbankreplikation wesentlichen Komponenten sind:

- Netzwerkverbindungen:

Der Befehl validate_network überprüft alle Aspekte der Netzwerkverbindung mit allen Knoten im Cluster. Bei Verbindungsproblemen wird häufig ein Fehler auf dem Domain Name Server/Reverse Domain Name Server (DNS/RDNS) angezeigt. Der Befehl validate_network schließt den Vorgang in 300 Sekunden ab. Die häufigsten Fehlermeldungen, die bei Netzwerkverbindungstests beobachtet wurden:

1. Fehler: Die clusterinterne Kommunikation ist unterbrochen, wie in diesem Bild dargestellt.

- Ursache

Dieser Fehler wird verursacht, wenn bei einem oder mehreren Knoten im Cluster ein Netzwerkverbindungsproblem vorliegt. Stellen Sie sicher, dass alle Knoten über Ping-Erreichbarkeit verfügen.

- Wirkung

Wenn die clusterinterne Kommunikation unterbrochen ist, treten Probleme mit der Datenbankreplikation auf.

2. Fehler bei der umgekehrten DNS-Suche.

- Ursache

Dieser Fehler wird verursacht, wenn die umgekehrte DNS-Suche auf einem Knoten fehlschlägt. Sie können jedoch überprüfen, ob der DNS konfiguriert ist und ordnungsgemäß funktioniert, wenn Sie die folgenden Befehle verwenden:

utils network eth0 all - Shows the DNS configuration (if present)

utils network host <ip address/Hostname> - Checks for resolution of ip address/Hostname

- Wirkung

Wenn der DNS nicht ordnungsgemäß funktioniert, kann es bei der Definition der Server und der Verwendung der Hostnamen zu Problemen mit der Datenbankreplikation kommen.

- NTP-Erreichbarkeit:

Das NTP ist dafür verantwortlich, die Uhrzeit des Servers mit der Referenzuhr zu synchronisieren. Der Publisher synchronisiert die Uhrzeit immer mit dem Gerät, dessen IP-Adresse als NTP-Server aufgeführt ist, während die Subscriber die Uhrzeit mit dem Publisher synchronisieren.

Es ist äußerst wichtig, dass das NTP voll funktionsfähig ist, um Datenbankreplikationsprobleme zu vermeiden.

Es ist wichtig, dass die NTP-Schicht (Anzahl der Hops zum übergeordneten Referenzuhr) kleiner als 5 ist, da sie sonst als unzuverlässig gilt.

Führen Sie die folgenden Schritte aus, um den NTP-Status zu überprüfen:

1. Verwenden Sie den Befehl utils diagnose test, um die Ausgabe zu überprüfen, wie in diesem Bild dargestellt.

2.  Außerdem können Sie den folgenden Befehl ausführen:

utils ntp status

Schritt 5: Überprüfen Sie den Verbindungsstatus aller Knoten, und stellen Sie sicher, dass sie authentifiziert sind.

1. Wenn nach Abschluss von Schritt 4 keine Probleme gemeldet werden, führen Sie den Befehl utils network connectivity auf allen Knoten aus, um zu überprüfen, ob die Verbindung zu den Datenbanken erfolgreich ist, wie in diesem Bild dargestellt.

2. Wenn Sie TCP/UDP-Pakete nicht senden als Fehlermeldung empfangen, überprüfen Sie Ihr Netzwerk auf Neuübertragungen, oder blockieren Sie die TCP/UDP-Ports. Der Befehl show network cluster prüft die Authentifizierung aller Knoten.

3. Wenn der Status des Knotens nicht authentifiziert ist, stellen Sie sicher, dass die Netzwerkverbindung und das Sicherheitskennwort auf allen Knoten identisch sind, wie in diesem Bild gezeigt.

Unter den Links können Sie die Sicherheitskennwörter ändern/wiederherstellen:

Zurücksetzen von Kennwörtern auf CUCM

Kennwortwiederherstellung für CUCM-Betriebssystemadministrator

Schritt 6: Der Befehl utils dbreplication runtimestate zeigt den Status "Out-Sync" oder "Nicht angefordert" an.

Es ist wichtig zu verstehen, dass die Datenbankreplikation eine netzwerkintensive Aufgabe ist, da sie die eigentlichen Tabellen an alle Knoten im Cluster weiterleitet. Stellen Sie Folgendes sicher:

- Die Knoten befinden sich im gleichen Rechenzentrum/Standort: Alle Knoten sind mit einer niedrigeren Round-Trip Time (RTT) erreichbar. Wenn der RTT-Wert ungewöhnlich hoch ist, überprüfen Sie die Netzwerkleistung.

- Die Knoten sind über das Wide Area Network (WAN) verteilt: Stellen Sie sicher, dass die Knoten über Netzwerkverbindungen mit deutlich unter 80 ms verfügen. Wenn einige Knoten dem Replikationsprozess nicht beitreten können, erhöhen Sie den Parameter wie dargestellt auf einen höheren Wert.

utils dbreplication setprocess <1-40>

Hinweis: Wenn Sie diesen Parameter ändern, verbessert er die Performance der Replikations-Einrichtung, beansprucht jedoch zusätzliche Systemressourcen.

- Das Replikations-Timeout basiert auf der Anzahl der Knoten im Cluster: Das Replikations-Timeout (Standard: 300 Sekunden) ist die Zeit, die der Publisher auf alle Subscriber wartet, um ihre definierten Nachrichten zu senden. Berechnet das Replikations-Timeout auf Basis der Anzahl der Knoten im Cluster.

Server 1-5 = 1 Minute Per Server Servers 6-10  = 2 Minutes Per Server Servers >10 = 3 Minutes Per Server.

Example: 12 Servers in Cluster : Server 1-5 * 1 min = 5 min, + 6-10 * 2 min = 10 min, + 11-12 * 3 min = 6 min,

Repltimeout should be set to 21 Minutes.

Befehle zum Überprüfen/Festlegen des Replikations-Timeouts:

show tech repltimeout ( To check the current replication timeout value )

utils dbreplication setrepltimeout ( To set the replication timeout )

Die Schritte 7 und 8 müssen ausgeführt werden, wenn die Checkliste erfüllt ist:

Checkliste:

- Alle Knoten haben die Verbindung zueinander. Siehe Schritt 5.

- RPC ist erreichbar. Siehe Schritt 3.

- Konsultieren Sie das Cisco TAC, bevor Sie mit den Schritten 7 und 8 fortfahren, falls der Knoten größer als 8 ist.

- Führen Sie den Vorgang außerhalb der Geschäftszeiten durch.

Schritt 7. Reparieren aller/selektiver Tabellen für die Datenbankreplikation

Wenn der Befehl utils dbreplication runtimestate anzeigt, dass fehlerhafte/nicht übereinstimmende Tabellen vorhanden sind, führen Sie den folgenden Befehl aus:

Utils dbreplication repair all

Führen Sie den Befehl utils dbreplication runtimestate aus, um den Status erneut zu überprüfen.

Fahren Sie mit Schritt 8 fort, wenn sich der Status nicht ändert.

Schritt 8: Datenbankreplikation von Grund auf zurücksetzen

Informationen zum Zurücksetzen der Datenbankreplikation und zum Starten des Prozesses von Grund auf finden Sie in der Sequenz.

utils dbreplication stop all  (Only on the publisher)

utils dbreplication dropadmindb (First on all the subscribers one by one then the publisher)

utils dbreplication reset all ( Only on the publisher )

Führen Sie zum Überwachen des Prozesses den Befehl RTMT/utils dbreplication runtimestate aus.

Informationen zum Zurücksetzen der Datenbankreplikation für einen bestimmten Knoten finden Sie in der folgenden Sequenz:

utils dbreplication stop <sub name/IP> (Only on the publisher)

utils dbreplcation dropadmindb (Only on the affected subscriber)

utils dbreplication reset <sub name/IP> (Only on the publisher )

Falls Sie das Cisco TAC für weitere Unterstützung erreichen, stellen Sie sicher, dass die folgenden Ergebnisse und Berichte bereitgestellt werden:

utils dbreplication runtimestate

utils diagnose test

utils network connectivity

Berichte:

- Der Cisco Unified Reporting CM-Datenbankbericht (siehe Schritt 2)

- Der Befehl utils create report database wird über die CLI aufgerufen.  Laden Sie die TAR-Datei herunter, und verwenden Sie einen SFTP-Server.

Weitere Informationen finden Sie unter den folgenden Links:

Die Ausgabe von utils dbreplication runtime-state für CUCM

Fehlerbehebung CUCM-Datenbankreplikation Linux-Appliance-Modell