In dit document wordt beschreven hoe u de uitgeversnode van Cisco Unified Communications Manager (CUCM) kunt terugzetten vanuit een abonneedatabase zonder voorafgaande back-up.
In vroege versies van CUCM werd de publisher node beschouwd als de enige gezaghebbende bron voor de Structured Query Language (SQL) DB. Als een uitgeversknooppunt verloren is gegaan als gevolg van een hardwarefout of een beschadiging van het bestandssysteem, was de enige manier om het te herstellen het opnieuw installeren en herstellen van de DB vanaf een Disaster Recovery System (DRS) back-up.
Sommige klanten hadden geen goede back-ups of hadden back-ups die verouderd waren, dus de enige optie was om de node van de publisher-server opnieuw op te bouwen en opnieuw te configureren.
In CUCM versie 8.6(1) werd een nieuwe functie geïntroduceerd om een uitgever-DB te herstellen uit een abonnee-database.
In dit document wordt beschreven hoe u van deze functie kunt profiteren om een uitgever-DB van de abonnee met succes te herstellen.
Cisco raadt u ten zeerste aan een volledige back-up van het Disaster Recovery Framework (DRF) van het hele cluster te behouden.
Aangezien dit proces alleen de CUCM DB-configuratie herstelt, worden andere gegevens, zoals certificaten, Music on Hold (MoH) en TFTP-bestanden, niet hersteld. Om deze problemen te voorkomen, moet u een volledige DRF-back-up van het cluster behouden.
Voordat u de uitgever opnieuw installeert, is het van cruciaal belang dat u de relevante details over de vorige uitgever verzamelt. Deze gegevens moeten overeenkomen met de oorspronkelijke installatie van de uitgever:
Als u de eerste drie items in de lijst wilt ophalen, voert u de opdracht Netwerkcluster weergeven in bij de CLI van de huidige abonneeknooppunt:
admin:show network cluster
172.18.172.213 cucm911ccnasub1 Subscriber authenticated
172.18.172.212 cucm911ccnapub Publisher not authenticated - INITIATOR
since Tue Dec 3 12:43:24 2013
172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
Sun Dec 1 17:14:58 2013
In dit geval is het IP-adres 172.18.172.212, de hostnaam is cucm911ccnapub, en er is geen domeinnaam geconfigureerd voor de uitgever.
De wachtwoordzin voor beveiliging (het vierde item in de lijst) wordt opgehaald uit de documentatie van de site.
Als u niet zeker bent over de wachtwoordzin, maak dan een best-effort gok en u kunt proberen deze te verifiëren en te corrigeren als dat nodig is op basis van de CUCM-versie.
Als de wachtwoordzin onjuist is, is een clusteruitval vereist om de situatie te corrigeren.
Om de exacte CUCM-versie en de geïnstalleerde COP-bestanden (de laatste twee items in de lijst) op te halen, verzamelt u de systeemuitvoer van de actieve opdracht versie weergeven:
admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.
In dit geval is versie 9.1.2.10000-28 geïnstalleerd zonder add-on COP-bestanden.
Wanneer de uitgever is geïnstalleerd, is het van cruciaal belang dat replicatie de huidige abonnee-DB's niet instelt en verwijdert. Om dit te voorkomen, voert u de opdracht deduplicatie stop op alle abonnees in:
admin:utils dbreplication stop
********************************************************************************
This command can delete the marker file(s) so that automatic replication setup
is stopped
It can also stop any replication setup currently executing
********************************************************************************
Deleted the marker file, auto replication setup is stopped
Service Manager is running
Commanded Out of Service
A Cisco DB Replicator[NOTRUNNING]
Service Manager is running
A Cisco DB Replicator[STARTED]
Completed replication process cleanup
Please run the command 'utils dbreplication runtimestate' and make sure all nodes
are RPC reachable before a replication reset is executed
Verzamel een opstartbaar image van de juiste versie en voer een installatie uit met een upgrade naar de juiste versie.
Installeer de uitgever en geef de juiste waarden op voor het eerder genoemde IP-adres, hostnaam, domeinnaam en beveiligingswachtwoord.
Om de knooppuntenlijst op te halen, voert u de opdracht SQL select name, description, nodeid from processnode uit bij de CLI van een huidige abonnee.
De naamwaarden kunnen hostnamen, IP-adressen of volledig gekwalificeerde domeinnamen (FQDN's) zijn.
Als u CUCM versie 10.5(2) of hoger uitvoert, moet de opdracht disaster_recovery prepare restore_pub_from_sub worden uitgevoerd op de CLI van de uitgever voordat u knooppunten kunt toevoegen aan Systeem > Server:

Nadat u de knooppuntenlijst hebt ontvangen, gaat u naar Systeem > Server en voegt u alle andere naamwaarden dan EnterpriseWideData toe aan de pagina Unified CM Administration van Publisher Server.
De waarden voor de naam moeten overeenkomen met het veld Hostnaam/IP-adres in het menu Systeem > Server.
admin:run sql select name,description,nodeid from processnode
name description nodeid
================== =============== ======
EnterpriseWideData 1
172.18.172.212 CUCM901CCNAPub 2
172.18.172.213 CUCM901CCNASub1 3
172.18.172.214 CUCM901CCNASub2 4


Als u de uitgever opnieuw wilt starten nadat de processnodewijzigingen zijn voltooid, voert u de opdracht System restart (Systeemherstart) in:
admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes
Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.
Shutting down Service Manager. Please wait...
\Service Manager shutting down services... Please Wait
Broadcast message from root (Tue Dec 3 14:29:09 2013):
The system is going down for reboot NOW!
Waiting .
Operation succeeded
Als u de wijzigingen correct hebt aangebracht en de wachtwoordzin correct is, moet het cluster zich in de geauthenticeerde staat bevinden nadat de uitgever opnieuw is gestart. Voer de opdracht Netwerkcluster tonen in om dit te verifiëren:
admin:show network cluster
172.18.172.212 cucm911ccnapub Publisher authenticated
172.18.172.213 cucm911ccnasub1 Subscriber authenticated using TCP since
Tue Dec 3 14:24:20 2013 172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
Tue Dec 3 14:25:09 2013
Als er geen eerdere back-up beschikbaar is, voert u een clusterback-up uit op de DRS-pagina.
Als er geen back-up beschikbaar is, voert u een nieuwe uit; als er al een back-up bestaat, kunt u deze sectie overslaan.
Gebruik het navigatiemenu om naar het Disaster Recovery System te navigeren en voeg een back-upapparaat toe.

Nadat het back-upapparaat is toegevoegd, start u een handmatige back-up.

Navigeer op de pagina Disaster Recovery System (Systeemherstel bij calamiteiten) naar Terugzetten > Wizard Terugzetten.
Als een huidige back-up beschikbaar was en u de vorige sectie hebt overgeslagen, schakelt u alle selectievakjes voor functies in de sectie Selecteer functies: Enterprise License Manager (ELM) indien beschikbaar, CDR_CAR, en Unified Communications Manager (UCM).
Als u een back-up gebruikt die in de vorige sectie is uitgevoerd, vinkt u alleen het selectievakje UCM aan:

Klik op Next (Volgende). Schakel het selectievakje node publisher (CUCM911CCNAPUB) in en kies de abonnee-DB van waaruit de terugzetbewerking plaatsvindt. Klik vervolgens op Terugzetten.

Wanneer de terugzetbewerking de CCMDB-component bereikt, moet de tekst Status worden weergegeven als Publisher terugzetten vanaf abonneeback-up:

Voordat u opnieuw opstart en replicatie instelt, is het een goede gewoonte om te controleren of de terugzetbewerking succesvol is en of de uitgever-database de vereiste informatie bevat.
Zorg ervoor dat deze query's dezelfde waarden op de nodes van de uitgever en abonnee retourneren voordat u doorgaat:
Voer na het herstel de opdracht System restart op elke node in. Begin met de uitgever gevolgd door elke abonnee.
admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes
Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.
Shutting down Service Manager. Please wait...
\ Service Manager shutting down services... Please Wait
Broadcast message from root (Tue Dec 3 14:29:09 2013):
The system is going down for reboot NOW!
Waiting .
Operation succeeded
Navigeer naar de Cisco Unified Reporting-pagina en genereer een Unified CM Database Status Report.
Het is waarschijnlijk dat replicatie nog niet kan zijn ingesteld, maar het is belangrijk om ervoor te zorgen dat de Unified CM Hosts, Unified CM Rhosts en Unified CM Sqlhosts-bestanden overeenkomen met de uitgever.
Als dat niet het geval is, moeten de knooppunten die niet overeenkomen opnieuw worden opgestart. Als deze bestanden niet overeenkomen, gaat u niet verder met de volgende stap of stelt u de replicatie opnieuw in.

Afhankelijk van de versie kan replicatie niet automatisch worden ingesteld. Om dit te controleren, wacht u tot alle services zijn gestart en voert u de opdracht runtimestate van de utils-duplicatie in. Een statuswaarde van 0 geeft aan dat de installatie wordt uitgevoerd, terwijl een waarde van 2 aangeeft dat replicatie met succes is ingesteld voor die node.
Deze uitvoer geeft aan dat de installatie van de replicatie wordt uitgevoerd (status wordt weergegeven als 0 voor twee van de knooppunten):

Deze uitvoer geeft aan dat de replicatie met succes is ingesteld:

Als er knooppunten worden weergegeven met een statuswaarde van 4, of als replicatie na enkele uren niet met succes is ingesteld, voert u de opdracht Dbreplication reset all van de publisher node in.
Als replicatie blijft mislukken, raadpleegt u het artikel Problemen oplossen met CUCM-databasereplicatie in Linux Appliance Model Cisco voor meer informatie over het oplossen van het probleem.
Aangezien de DB-herstelprocedure niet alle vorige onderdelen terugzet, moeten veel items op serverniveau handmatig worden geïnstalleerd of hersteld.
De DRF-herstelprocedure activeert geen services. Navigeer naar Tools > Serviceactivering en activeer alle noodzakelijke services die de uitgever moet uitvoeren, op basis van de sitedocumentatie op de pagina Unified Serviceability:

Als er geen volledige back-up beschikbaar was, moet u bepaalde handmatige configuraties reproduceren. Met name configuraties die betrekking hebben op certificaten en TFTP-functies:
In dit gedeelte worden verschillende scenario's beschreven die ertoe kunnen leiden dat deze procedure mislukt.
Als het cluster niet wordt geverifieerd, zijn de twee meest voorkomende oorzaken niet-overeenkomende beveiligingswachtwoorden en verbindingsproblemen op TCP-poort 8500.
Om te controleren of de wachtwoordgroepen voor clusterbeveiliging overeenkomen, voert u de opdracht rapportplatform maken in bij de CLI van beide knooppunten en controleert u de hashwaarde van het bestand platformConfig.xml. Deze moeten overeenkomen op de uitgever en abonnee knooppunten.
<IPSecSecurityPwCrypt>
<ParamNameText>Security PW for this node</ParamNameText>
<ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
12812AB2825C831812812AB2825C </ParamValue>
</IPSecSecurityPwCrypt>
Als deze overeenkomen, controleert u de TCP-connectiviteit op poort 8500. Als ze niet overeenkomen, kunnen er problemen zijn wanneer u probeert de wachtwoordzin te repareren vanwege verschillende defecten in de CUCM-code die de procedure omringen:
Als de CUCM-versie oplossingen bevat voor al deze problemen, is de eenvoudigste oplossing om de wachtwoordherstelprocedure te voltooien die is beschreven in de Cisco Unified Communications Operating System Administration Guide, release 10.0(1) op alle nodes.
Als de CUCM-versie de oplossingen voor deze problemen niet bevat, kan het Cisco Technical Assistance Center (TAC) een tijdelijke oplossing uitvoeren, afhankelijk van de situatie.
Als de DB-component niet wordt vermeld in de terugzetprocedure, is het mogelijk dat de back-up zelf geen DB-component bevat. Zorg ervoor dat de uitgever DB wordt uitgevoerd en query's kan accepteren en voer een nieuwe back-up uit.
Raadpleeg het artikel Problemen oplossen met CUCM-databasereplicatie in Linux Appliance Model Cisco om een replicatiefout op te lossen.
Aangezien bij het terugzetten van de database geen certificaten worden teruggezet, is de ondertekenaar anders als de uitgever de primaire TFTP-server is.
Als de TVS-certificaten (Subscriber Trust Verification Service) en TCP-poort 2445 zijn geopend tussen de telefoons en de TVS-servers, moet het probleem automatisch worden opgelost.
Daarom raadt Cisco u aan volledige DRF-back-ups van clusters te onderhouden.
CUCM-versies vóór versie 8.6 kunnen ook certificaatproblemen hebben, zelfs bij een eerdere succesvolle back-up, vanwege Cisco-bug-ID CSCtn50405.
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
3.0 |
27-May-2026
|
Bijgewerkte tekst, koppen en opmaak. |
2.0 |
19-Dec-2024
|
Eerste release, vaste alt-tekst, spelling, hyperlinks. |
1.0 |
11-Oct-2023
|
Eerste vrijgave |