Troubleshoot CUCM Database Replication Issues

Publisher

Cisco Systems

URL

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200396-Steps-to-Troubleshoot-Database-Replicati.html

Published

2025-12-03

Updated

unknown

Accessed

2026-09-30

HTTP status

200

License

Cisco proprietary; all rights reserved; no-redistribution; short excerpts and locators only

Source notes citing this source

• If show network cluster reports nodes as unauthenticated, the technote tells you to confirm network connectivity and that the security password is the same on all nodes. in context
• The Unified CM Database Status report is generated at Cisco Unified Reporting > System Reports > Unified CM Database Status, and the technote advises downloading it so it can be given to a TAC engineer. in context
• When the database status report flags a hosts, rhosts or sqlhosts mismatch, the technote has you restart Cluster Manager and then A Cisco DB from the publisher CLI, generate a new report, and go to the reset step if the mismatch has cleared. in context
• The technote warns that incorrect activity is possible when an IP address changes or a hostname is updated, and points to the IP Address and Hostname Changes guide for the procedure. in context
• The technote states that the NTP stratum must be less than 5, otherwise the time source is deemed unreliable. in context
• Cisco's troubleshooting order puts non-destructive checks (services, network, DNS, NTP, cluster authentication, hosts-file equivalence) ahead of repair, and repair ahead of reset, so a reset is the last resort and not the first response to a state other than 2. inferred in context
• The technote says port 1515 must be allowed on the network between nodes, in the context of confirming that the Database Layer RPC (DBL RPC) hello succeeds. in context
• The technote uses utils dbreplication repair all when runtimestate shows errors or mismatched tables, and moves on to a full reset only if the status does not change. in context
• The technote sizes the replication timeout at 1 minute per server for servers 1 to 5, 2 minutes per server for servers 6 to 10, and 3 minutes per server beyond 10, giving 21 minutes for a 12-server cluster. in context
• To reset replication for a single subscriber, the technote runs utils dbreplication stop for that subscriber from the publisher, utils dbreplication dropadmindb on the affected subscriber, then utils dbreplication reset for that subscriber from the publisher. in context
• The technote's cluster-wide reset from scratch is: utils dbreplication stop all on the publisher only, utils dbreplication dropadmindb on each subscriber one by one and then the publisher, then utils dbreplication reset all on the publisher only. disputed in context
• The technote attributes one class of replication-related network diagnostic error to a failed reverse DNS lookup on a node, and checks it with utils network eth0 all and utils network host. in context
• When reading runtimestate, the technote tells you to check the timestamp so that the Cluster Replication State section is not read from old sync information. in context
• The TAC troubleshooting technote describes state 0 as an initialization state in which replication is being set up, and says a setup failure can have occurred if a node stays in that state for more than an hour. in context
• The TAC troubleshooting technote describes state 3 as mismatched tables: logical connections are established but it is uncertain whether the tables match. in context
• The TAC troubleshooting technote describes state 4 as setup failed or dropped: the server no longer has an active logical connection over which to receive database tables. in context
• The technote says to consult Cisco TAC before running its repair and reset steps (Steps 7 and 8) on clusters with more than 8 nodes. in context
• For Out of Sync or Not Requested statuses on nodes spread across a WAN, the technote says to ensure the nodes have network connectivity well under 80 ms. in context

Cite this source record

APA

WarmTransfer. (2025, December 3). Troubleshoot CUCM Database Replication Issues. WarmTransfer. https://warmtransfer.net/knowledge/sources/cisco-technote-200396-cucm-dbrepl-troubleshoot

BibTeX

@misc{warmtransfer-cisco-technote-200396-cucm-dbrepl-troubleshoot,
  title  = {Troubleshoot CUCM Database Replication Issues},
  author = {{WarmTransfer}},
  year   = {2025},
  url    = {https://warmtransfer.net/knowledge/sources/cisco-technote-200396-cucm-dbrepl-troubleshoot},
  note   = {Cisco Systems, accessed 2026-09-30}
}