04-20-2010 09:18 PM - edited 03-15-2019 10:23 PM
Hi,
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?
Thanks
04-21-2010 01:22 AM
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
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,
Stafford
04-21-2010 03:22 AM
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
04-21-2010 07:43 AM
Hi,
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
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.
Regards
Allan
Hope this helps, pls rate helpful posts.
04-21-2010 09:09 AM
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..
04-21-2010 12:00 PM
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.
04-21-2010 12:14 PM
Hi,
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?
Regards
Allan
Hope this helps, pls rate helpful posts.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide