In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie die PostgreSQL-Datenbank zwischen Peers zwischen Clustern in Instant Messaging (IM) und Presence (IM&P) verschoben wird.
Mitgegeben von Joel Burleigh und herausgegeben von Joseph Koglin, Cisco TAC Engineers
Cisco empfiehlt, dass Sie über eine Umgebung verfügen, die diese Bedingungen erfüllt.
Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen und Komponenten:
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Um Verwirrung zu vermeiden, werden diese Begriffe für den Verweis auf die IM&P-Cluster und die PostgreSQL-Datenbank verwendet.
Warnung: Diese Schritte sollten nur ausgeführt werden, wenn Sie keine weiteren Optionen haben. Bevor Sie mit diesen Schritten fortfahren, besprechen Sie bitte intern, um sicherzustellen, dass dies die beste Lösung ist.
Hinweis: Es ist zu beachten, dass, wenn der permanente Chat korrekt für Peers zwischen Clustern eingerichtet wurde. Jeder Knoten in jedem Cluster sollte über eine eigene Datenbankinstanz in PostgreSQL verfügen. Die einzige Ausnahme ist, wenn die Version 11.5 und höher ist.
Schritt 1: Geben Sie zuerst den CLI-Befehl aus dem IM&P Publisher ein, in dem Ihre Datenbank derzeit gehostet wird (Cluster1).
run sql select * from tcaliases
Notieren Sie sich die dynamisch erstellte Konferenz-ID und den manuell erstellten Alias, der dem lokalen Cluster zugeordnet ist.
Ein Beispiel für eine dynamische Konferenz-ID ist conference-2-StandAloneCluster2c2aa.jburleig.local. Sie können erkennen, dass dies die primäre Konferenz-ID ist, da die primäre Konferenz-ID auf true festgelegt ist und im Feld "fkprocessingNode" (fkprozessor-Knoten) einen Wert hat.
Ein Beispiel für einen Chat-Knoten-Alias ist pchat1.jburleig.local. Sie können dies angeben, da der primäre Wert auf false festgelegt ist, in der Spalte fkprocessingNode jedoch der gleiche Pid-Wert wie die primäre Konferenz-ID vorhanden ist.
Beispielausgabe:
admin:run sql select * from tcaliases pkid tcalias isprimary fkprocessnode peerclusterid ==================================== ================================================== ========= ==================================== ============== 50a4cf3b-0474-4723-ba50-4cd2cc1dd277 conference-2-StandAloneCluster2c2aa.jburleig.local t 2c2aa1f6-cc7a-470a-a0ba-c8a892db68ca NULL 9eca651d-5a67-3116-a57b-1eb2ab0911bd pchat1.jburleig.local f 2c2aa1f6-cc7a-470a-a0ba-c8a892db68ca NULL 838e900a-0d2f-4843-be00-ac0a6c803ab5 conference-2-StandAloneClustercbea5.jburleig.local f NULL 2202
Schritt 2: Erstellen Sie eine Sicherung der aktuellen Datenbank (PostgreSQL).
Hinweis: Dies sollte von Ihrem Datenbankadministrator entsprechend den Anforderungen Ihrer Organisationen durchgeführt werden.
Schritt 3: Erstellen Sie anschließend eine neue Datenbankinstanz (PostgreSQL).
Hinweis: Die Encoded-Methode der Datenbank kann anders sein als UTF8.
CREATE DATABASE cluster2 WITH OWNER tcuser ENCODING 'UTF8'
Schritt 4: Sie müssen einen neuen Eintrag hinzufügen, um dem Benutzer Zugriff auf die in Schritt 2 erstellte neue Datenbank zu ermöglichen.
Wenn sich die neue Konfiguration der externen Datenbank im IM&P-Cluster in einem neuen IP-Subnetz befindet, sollten Sie das Subnetz des Eintrags in der Datei pg.hba.conf (PostgreSQL) aktualisieren.
host DBName DBUsere Subnet password
host cluster2 tcuser 10.10.1.0/24 password
Schritt 5: Als Nächstes müssen Sie eine neue externe Datenbank im IM&P-Cluster erstellen, in die die Konfiguration verschoben wird (Cluster 2).
Schritt 6: Deaktivieren Sie jetzt den permanenten Chat auf dem aktuellen IM&P, der die Persistent Chat-Konfiguration hostet, und heben Sie die Zuweisung der externen Datenbank für die Persistent Chat-Konfiguration (Cluster1) auf.
Schritt 7: Löschen Sie anschließend die Konfiguration der externen Datenbank (Cluster 1).
Schritt 8: Löschen Sie anschließend den benutzerdefinierten Alias für den persistenten Chat, der auf dem aktuellen Cluster (Cluster1) konfiguriert wurde.
Schritt 9: Nachdem die Konfiguration des persistenten Chat und der externen Datenbank vollständig entfernt wurde (Cluster1) starten Sie den Cisco XCP-Router (Cluster1) neu
Schritt 10: Aktivieren Sie anschließend den persistenten Chat auf (Cluster 2), und weisen Sie eine externe Datenbank zu, die in Schritt 5 erstellt wurde.
Schritt 11: Überprüfen Sie, ob der Verbindungstest für die externe Datenbank aktiviert ist (Cluster2), nachdem Sie den persistenten Chat aktiviert haben. Fahren Sie dann fort, wenn alle grünen Häkchen angezeigt werden.
Schritt 12: Erstellen Sie einen benutzerdefinierten Alias auf (Cluster2) Achten Sie darauf, den exakten Namen des Alias zu verwenden, den Sie aus dem alten Cluster gelöscht haben. In der Ausgabe von Schritt 1 finden Sie den Namen des Alias.
Schritt 13: Starten Sie den XCP-Router (Cluster 2) neu.
Schritt 14: Sobald der Cisco XCP-Router erfolgreich neu gestartet wurde (Cluster 2), fahren Sie fort und beenden Sie den Cisco Text Conferencing Manager (Cluster 2).
Schritt 15: Führen Sie eine Datenbankwiederherstellung mit der PostgreSQL-Sicherung durch, die in Schritt 2 durchgeführt wurde. Stellen Sie sicher, dass die Sicherung in der neuen Datenbankinstanz wiederhergestellt wird, die in Schritt 3 (PostgreSQL) erstellt wurde.
Schritt 16: Starten Sie anschließend den PostgreSQL-Dienst (PostgreSQL) neu.
Schritt 17: Starten Sie als Nächstes den Text Conferencing Manager auf Cluster 2.
Schritt 18: Führen Sie diese Befehle in der PostgreSQL-Befehlszeile aus, um die alte Konferenz-ID auf den in Schritt 12 erstellten neuen Alias zu aktualisieren. (PostgreSQL)
Hinweis: Sie müssen diese Befehle anpassen, um Ihre Cluster1-Konferenz-ID und die von Ihnen konfigurierte Alias-ID enthalten zu können.
Updates for tc_rooms
update tc_rooms set room_jid = replace(room_jid, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
Updates for tc_users
update tc_users set room_jid = replace(room_jid, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
update tc_users set nick_jid = replace(nick_jid, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
update tc_users set initiator_jid = replace(initiator_jid, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
Updates for tc_messages
update tc_messages set room_jid = replace(room_jid, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
update tc_messages set msg = replace(msg, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
Updates for tc_msgarchive
update tc_msgarchive set to_jid = replace(to_jid, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
update tc_ msgarchive set nick_jid = replace(nick_jid, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
update tc_ msgarchive set message_string = replace(message_string, ‘conference-2-StandAloneCluster2c2aa.jburleig.local’, ‘pchat1.jburleig.local’);
Schritt 19: Starten Sie anschließend den PostgreSQL-Dienst (PostgreSQL) neu.
Schritt 20: Starten Sie anschließend den Text Conferencing Manager (Cluster 2) neu.
Schritt 21: An dieser Stelle sollten Jabber-Clients in der Lage sein, sich bei IM&P anzumelden und alle Räume auf der Registerkarte All Rooms (Alle Räume) abzurufen.