Cisco MCS-7825-H3-IPC1 Service Guide - Page 141

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 . 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 where 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. OL-22523-01 Cisco Unified Communications Manager Managed Services Guide 3-41