CUCM Database replication not in syc

[clark white]

Dears,

I have deleted one of the subscriber from the CUCM publisher and the database replication showing me as such, how the tables will be sync and how the commonphoneconfigxml tables will move further

admin:utils dbreplication runtimestate

DB and Replication Services: ALL RUNNING

DB CLI Status: No other dbreplication CLI is running...

Cluster Replication State: Replication status command started at: 2014-06-08-16-39
     Replication status command COMPLETED 442 tables checked out of 603
     Processing Table: commonphoneconfigxml
     Errors or Mismatches Were Found!!!

     Use 'file view activelog cm/trace/dbl/sdi/ReplicationStatus.2014_06_08_16_39_01.out' to see the details

DB Version: ccm9_1_2_11900_12
Repltimeout set to: 900s
PROCESS option set to: 1

Cluster Detailed View from PUB01DC (3 Servers):

                                PING            CDR Server      REPL.   DBver&  REPL.   REPLICATION SETUP
SERVER-NAME     IP ADDRESS      (msec)  RPC?    (ID) & STATUS   QUEUE   TABLES  LOOP?   (RTMT) & details
-----------     ------------    ------  ----    --------------  -----   ------- -----   -----------------
PUB01DC    10.x.x.x.      0.036   Yes     (2)  Connected   0      match   Yes     (2) PUB Setup Completed
SUB01DC    10.x.x.x.      0.474   Yes     (5)  Connected   0      match   Yes     (2) Setup Completed
sub03dc    10.x.x.x.     3.863   Yes     (8)  Connected   0      match   Yes     (2) Setup Completed

[Manish Gogna · Accepted solution]

Hi,

Please try the following:

Execute the utils dbreplication stop command on all subscribers.

Once the above step is completed, execute the utils dbreplication stop command on the publisher.

At the publisher server, issue the utils dbreplication reset all

HTH

Manish

[clark white]

Dear Manish,

Do we require these commands ??? , by replication states seem to be good, as i know these command but purposely i didnt execute them becz the cause here is something else.

thanks

[Manish Gogna]

Hi,

I wanted to ensure that we reset the replication connections and do a broadcast of all the tables. Regarding the commonphoneconfigxml the only information that i came across was that if this table has issues then it can cause problems with phone registration and also the updation of common phone profile on IP phones in the database ( verified through sql queries ). Here is an important bug which affects 8.6 , 9.1 and 10.0 cucm versions

https://tools.cisco.com/bugsearch/bug/CSCul13413/?reffering_site=dumpcr

HTH

Manish

[Brian Meade]

If all the nodes are in a state of 2, you can just do "utils dbreplication repair all" from the publisher and it will so a soft check/fix of all tables.

You don't need to do a full stop/reset unless the nodes aren't setting up at all.

[Manish Gogna]

I agree with you Brian.

Manish

[scott.cannady]

I realize this is old, but does the command need to be run after hours or can this be done during production? 

[Brian Meade]

It depends on the environment.  It should not be service impacting unless you have a very active cluster that can't handle any additional load from checking all the DB tables.  I'd compare it to a task like running a backup.  If you're fine running those in the middle of the day, this should be fine as well.

[scott.cannady]

Thanks, if I do a manual back up I reserve it for early morning activity.  I'll run in before the rooster wakes.  Thanks for the quick response.