dbreplication issues with CUCM

Unanswered Question
Oct 27th, 2008

have a cluster across mpls wan.

there are occaisional planned system maintenance windows that obviously cause issues with the cluster.

Having said that every time there seems to be a dbreplication issue of some sort that i am unable to resolve until i reboot.

Not able to reboot that often as customer is 24x7x365 operation.

the advised procedure did not work and wondering if there is something i'm missing or something else that can be done to fix;

utils dbreplication status

utils dbreplication repair

utils dbreplication stop

utils dbreplication reset

Did this and still getting all 3's in dbreplication status in RTMT.

Any suggestions/thoughts?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
gogasca Mon, 10/27/2008 - 23:42

I would open a case with us to investigate/troubleshoot further.

allan.thomas Tue, 10/28/2008 - 02:49

There is a specific proceedure for stopping and resetting the dbreplication across all nodes within the cluster.

Firstly you stop the dbreplication on each subscriber and wait until it completes before stopping on another subscriber node.

Once the dbreplication has been stopped on each subscriber the proceed to stop in on the Publisher.

Only once the Publisher replication has been stopped should then attempt to reset. In your situation you should use 'utils dbreplication reset all'.

Was this the proceedure that you followed, or did you attempt the reset in a different manor?

Incidentally, depending on what version of CallManager you are running there is another command 'utils dbreplication clusterreset'.

You can use this command to reset replication on a cluster if utils dbreplication reset does not work.

However, if you still have concerns then do not hesitate to log it with TAC as suggested in the previous post.



pvarenholt Tue, 10/28/2008 - 05:36

the procedure was done exactly as noted above on the pub only.

TAC instructed me on how to do this and that is why i followed the instructions given.

If there are alternative ways to do this please advise and version of CUCM is stated in my original post i think but just in case CMCM

Thanks for your response.

allan.thomas Tue, 10/28/2008 - 09:08

I overlooked the version in subject matter, however the command that I mentioned is certainly available in release CUCM 6.x.

As I mentioned try this command if the dbreplication reset command fail to resolve the broken dbreplication.

Another excellent feature within CUCM 6.x 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, so you can effectively save the report and forward to Cisco TAC.



pvarenholt Tue, 10/28/2008 - 10:02

thanks much.

The TAC has asked for this on my current case.

with respect to the clusterreset commandline util is there anything that should preceed it or follow it or is that all you have to do is issue the command itself.

I have seen it there but since the TAC has not asked me to do it i've not used it.

also if used will this interrupt phone service?

thanks again.


allan.thomas Tue, 10/28/2008 - 11:11

The utils dbreplication clusterreset resets the database replication on an entire cluster.

Before you run this command, run the command utils dbreplication stop first on all subscribers servers, and then on the publisher server.

Also once the clusterreset has completed, initiate a 'reset all' from the publisher.

After the reset it is recommended to reboot each of the subscriber once the dbreplication status shows a status of 2 for each node.

Unfortunately I have experienced unpredicable results with dbreplication before, therefore I cannot guarantee that it will not be service affecting.

In prior versions of Cisco Unified Communications Manager, subscriber servers in the cluster use the publisher database for READ/WRITE access, and only use the local database for READ access when the publisher database cannot be reached.

With Cisco Unified Communications Manager Release 6.0, subscriber servers in the cluster READ the local database. DB WRITES happens in both the local database as well as the publisher database, depending on the type of data. DBMS (IDS) replication is used to synchronize the databases on the nodes of the cluster.

When recovering from a failover conditions such as loss of WAN connectivity for extended period of time, the Cisco Unified Communications Manager databases need to be synchronized with any changes that may have been made during the outage. This process happens automatically when database connectivity gets restored. This process may take longer over low bandwidth and/or higher delay links.

Therefore any changes to the local database will be synchronisation once the dbreplication is established.




This Discussion