Showing results for 
Search instead for 
Did you mean: 

New subscriber does not replicate with rest of cluster



I added two new subscribers to an exisitng 7.1.3B CUCM cluster. The new suscribers are on my WAN and are well within the 40 ms distance. The 1st subscriber came up with no issues. However, the 2nd subscriber does not complete the replication. In the cluster I have 2 TFTPs and 5 subs along with the Pub. Any idea how I can fix the DB replication on the 5th sub?


6 Replies 6


Hi There,

First off ensure you have entered the security password correctly.

The RTMT is the primary tool to use when troubleshooting database issues on CallManager 5.x and above. Under the
Performance tab, choose the Performance object, then choose the Number of Replications Created and
Replication_State categories to open them. The different states indicated by the Replication_State counter are

0: Replication is not started.
1: Replication has been started but has not completed.
2: Replication setup has completed and is currently working.
3: Replication is broken and the Database Layer Monitor service on the subscriber has been started at least once.

You can also use the command utils dbreplication status from the CLI to view the database replication status. This
command must be performed on the Publisher and will create a file on the server at a location printed to the screen. Use
the command file view activelog to view the file that was generated.

Use the command utils dbreplication repair all to re-create the first node to subsequent node database replication relationships.
This process can take longer than 30 minutes on a large deployment.

Kind Regards,


I will suggest you rebuild that subscriber and ensure you have the security password, the CCMadmin pass and OS admin password same as you have in the cluster. This is a long shot, otherwise you can try and do a utils dbreplication repair on it

Please rate all useful posts



When you say that the replication does not complete, what gives you that impression?  Does the RTMT or Unified Reports indicate a replication status of anything other than 2?

It is possible to reset the replication process for a given Subscriber, however it requires that the database replication is stopped on the Subscriber and also on the Publisher prior to restarting from the Publisher using the 'utils dbreplication reset ' command, it essentially rebuilds the replication on the subscriber/hostname specified.

The following commands are taken from CLI Guide for your reference, however I would stipulate that you have to stop the replication in order to restart the replication on the Publisher and would therefore recommend that you attempt to do this at a time that is suitable to your business and when you have sufficient time in order to troubleshoot any issues that arise:-

utils dbreplication reset

This command resets and restarts database replication. It can be used to tear down and rebuild replication when the system has not set up properly.

Command Syntax

utils dbreplication reset {all|hostname}

•all causes all subscriber servers in the cluster to have replication torn down and rebuilt.

•hostname specifies a particular subscriber server to have replication torn down and rebuilt.

Usage Guidelines

This is the best command to use when servers show an RTMT state of 4. If only one subscriber server is showing an RTMT state of 4, you may reset that server by specifying the hostname parameter.

utils dbreplication stop

This command stops the automatic setup of database replication. Use this command on the subscriber and publisher server prior to executing the CLI command utils dbreplication reset run this command on the subscriber before you run it on the publisher server.



Hope this helps, pls rate helpful posts.

even after this if you face the problem,

restart RIS Data collector and Database Layer Monitor service on all the servers,

run the command - utils dbreplication clusterreset

and then you have to reboot the cluster, starting with publisher, followed by subscribers

once everything is up run the command - utils dbreplication reset all on pub again

and wait for an hour or two . it should resolve the issue..


Thank you all for your good suggestions. It's just that I want to avoid doing dbreplication repair and break my other clusters too. I did rebuild the cluster with correct passwords etc.


Firstly, lets substaniate a few facts?

When you added the Subscriber did you initially add the server through the application administration before attempting the install?  I assume that there were no errors reported during install, especially when specifying the Publisher details?

One feature you can use to help ascertain the root problem is the Cisco Unified Reporting. It provides detailed reports including Database status, and highlights any inconsistencies within the various aspects assoiciated with replication, such host and sqlhosts files etc..

You can open or select this reporting facility from within the CUCM administration, open the drop down menu where you select the OS admin option, and there you will see 'Cisco Unified Reporting'.

When the Reporting page appears click on the 'System Reports', you will then see the numberous reports available, one of which is the 'Unified CM Database Status'.

Click on this report, and then click on generate report. This will take several minutes to complete. Once complete it will give a comprehensive report, and may highlight what could be possibly wrong.

On the right of the page is the option to download the report, can you download and attach the report?



Hope this helps, pls rate helpful posts.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers