DBreplication Fail - Replicate_State=0

Unanswered Question
Nov 13th, 2008


I have changed IP Address on both server callmanager (Publisher + 1 Subscriber version 6.1.2) and replicate state is not good. I first Replicate state =2 on publisher and =4 on subscriber. Then I've tried to follow the troubleshooting procedures with the CLI command, and restart server. Now I have Replicate_State=0 on both server. Can you help me ? Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
allan.thomas Fri, 11/14/2008 - 09:26

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.

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 if necessary.

Hope this all helps.


Pls rate helpful posts.

ribola Fri, 11/14/2008 - 15:44

Thanks for your response.

I have followed the the steps you outlined (dbreplication reset all) before writing to the forum.

Having obtained a negative result, I used the command "utils dbreplication dropadmindb". Then I had "Replicate_State = 0".

I resolved this morning the problem with your procedure (dbreplication stop on sub + publ and then reset all) only after the restart of the publisher.

...in past days I had just restarted the 2 services related to database...

best regards


allan.thomas Fri, 11/14/2008 - 16:56

The whole dbreplication can be a bit of a headache I know. Good working in get it sorted in the end :)



Pls rate helpful posts.


This Discussion