DBReplication Failure state on RTMT

Unanswered Question
Apr 8th, 2010
User Badges:

I have a cluster of CUCM ver 7.0.1 which consist of 1 Publisher and 3 Subscriber.

If i see Database Summary in RTMT, the state of Replication is 3 (Bad).

Then in Cisco Unified Reporting, when i generate a report and see the database status. or with CLI commnad utils dbreplication status.

The state of Replication status is Good. But, i see in the table consist of one Hostname Server that we has been deleted from the CUCM Cluster configuration.

How to resolve this DBreplication Failure. ? and how to delete the hostname which still shown in the dbreplication status.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
William Bell Thu, 04/08/2010 - 19:20
User Badges:
  • Purple, 4500 points or more

The procedures for deleting a server from the CUCM cluster is provided the CUCM Administration Guide:


Note that you will want to read these release notes too as there was some documentation bugs that you want to navigate through:





Please remember to rate helpful posts.

Novriadi . Thu, 04/08/2010 - 19:55
User Badges:

Thanks Bill

i'll try to restart the publisher first.



Novriadi . Mon, 04/12/2010 - 15:36
User Badges:


I already restart the Publisher and also restarting 3 Subscriber, but the state of replication still BAD (3).

In release note CuCM (http://www.cisco.com/en/US/customer/docs/voice_ip_comm/cucm/rel_notes/7_0_2/cucm-rel_notes-702a.html#wp1170852) there is an option to repair the database by using utils dbreplication repair, is there any bad impact from this command with my database ?

my attachment show replication status after deleting node server and then restarting the cluster. we can see that g_idgn2ucmsub03 still exist in Cisco Unified Reporting and make the other server to try connecting to.

What will u suggest for this ?


David Hailey Mon, 04/12/2010 - 17:03
User Badges:
  • Purple, 4500 points or more

Note that if replication is bad and you reboot the cluster, it can take up to an hour or more (depending on DB size and other factors - such as hardware, etc) before replication fully completes and changes state.  However, there is no harm in running the DB repair command from CLI; however, make sure you follow instructions on how to do this.  If I remember correctly, you should issue a stop comand on each server before running the repair.  From there, you should watch replication via RTMT and remember that it will take some time for the cluster to repair itself.

Out of curiousity, when you removed the server from the cluster - did you delete the server and CM configuration within the CCM Admin page as well?


Please rate helpful posts!

William Bell Mon, 04/12/2010 - 18:23
User Badges:
  • Purple, 4500 points or more

Before doing the dbreplication reset. Do the following on each cucm node:

From the CLI on each server:

1. "run sql select name from processnode"

2. "show network cluster"

3. "show tech network hosts"

4. "utils diagnose module validate_network"

Look for inconsistencies in output data across each cluster node. Look for any data values in the output of each command that disagrees with other commands. Look for anything you weren't expecting or think is erroneous. Look for any failures in "validate_network". You are likely to see a failure related to the CUCM node that you removed. Any errors outside of that?

If you prefer, post the output but make sure you include all nodes.

A dbreplication reset may be necessary (sounds likely). You will want to validate_network (see above, command 4). A dbreplication stop on non-publisher nodes may be necessary but I have found mixed guidance from cco docs on this. Certainly it wouldn't hurt. Make sure you read up on the "utils dbreplication " commands first.





This Discussion