3-41
Cisco Unified Communications Manager Managed Services Guide
OL-22523-01
Chapter 3 Managing and Monitoring the Health of Cisco Unified Communications Manager Systems
General Health and Troubleshooting Tips
This status command can be run on all servers by using utils dbreplication status all or on one
subscriber by using utils dbreplication status <hostname>.
The status report will tell you if any tables are suspect. If there are suspect tables, you will want to do a
replication repair CLI command to sync the data from the publisher server to the subscriber servers.
The replication repair can be done on all subscriber servers (using the all parameter) or on just one
subscriber server by using the following:
utils dbreplication repair usage:utils dbreplication
repair [nodename]|all
.
After running the replication repair, which can take several minutes, you can run another status command
to verify that all tables are now in sync. If tables are in sync after running the repair, you are successful
in fixing replication.
Note Only do Step 6 if one of the servers showed an RTMT status of 4, or had a status of 0 for more than four
hours.
Step 6 Generate and view the Cisco Unified CM Database Status report, which provides debugging
information for database replication. For each subscriber server that has a bad RTMT status, check that
the hosts, rhosts, sqlhosts, and services files have the appropriate information.
Generate and view the Cisco Unified CM Cluster Overview report. Verify that the subscriber servers
have the same version, verify that connectivity is good, and verify that time delay is within tolerances.
If the preceding conditions are acceptable, do the following to reset replication on that subscriber server:
a. At the subscriber server, perform the CLI command utils dbreplication stop.
Do this for all subscriber servers that have an RTMT value of 4.
b. At the publisher server, perform the CLI command utils dbreplication stop.
c. At the publisher server, perform the CLI command utils dbreplication reset <hostname> where
<hostname> is the hostname of the subscriber server that needs to be reset. If all subscriber servers
need to be reset, use command utils dbreplication reset all.
Database Replication Does Not Occur on Lost Node
Database replication does not occur when connectivity is restored on lost node recovery. You can verify
the state of replication by using the methods given in the topic Database Replication Fails Between the
Publisher and the Subscriber, page 3-39. Only use the following procedure if you have already tried to
reset replication on the node, and have been unsuccessful.
Possible Cause
The CDR check remains stuck in a loop, due to a delete on device table.
Recommended Action
Step 1 Run utils dbreplication stop on the affected subscribers. You can run them all at once.
Step 2 Wait until Step 1 completes, then, run utils dbreplication stop on the affected publisher server.
To Next Page
Loading...
Need help?
General