7.1.3 utils dbreplications status > Sync target server is not defined for the replicate

[Jason Aarons]

Hmmm, I have two nodes defined in CallManager. It was good. I shut them down for a week and relocated them.  Now second server isn’t showing. Trying a utils dbreplication repair all.

Admin:utils dbreplication status

admin:file view activelog cm/trace/dbl/sdi/ReplicationStatus.2010_04_12_14_28_47.out

SERVER                 ID STATE    STATUS     QUEUE  CONNECTION CHANGED

-----------------------------------------------------------------------

g_jv_cucm1_ccm7_1_3_20000_2    2 Active   Local           0

-------------------------------------------------

No Errors or Mismatches found.

Replication status is good on all available servers.

utils dbreplication status output

To determine if replication is suspect, look for the following:

        (1) Number of rows in a table do not match on all nodes.

        (2) Non-zero values occur in any of the other output columns for a table

Processing ccmdbtemplate_jv_cucm1_ccm7_1_3_20000_2_1_95_typedberrors with 991 rows group 1

Sync target server is not defined for the replicate ccmdbtemplate_jv_cucm1_ccm7_1_3_20000_2_1_95_typedberrors

command failed -- participants required for operation specified  (17)

end of the file reached

options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 - 19 of 19) :

[htluo]

Could you elaborate how you "relocate" them?

Did you change IP address/Hostname?  If yes, what document you followed to change it?

Changing IP address/hostname needs to be done very carefully.

Michael

http://htluo.blogspot.com

[William Bell]

Can you reach the subscriber (via ICMP/SSH)? On each node in the cluster, check the following:

1. "show network cluster" (see if IP addr/hostnames are what you expect)

2. "show tech network hosts". (see if IP addr/hostnames are what you expect)

3. Also, perform a "utils diagnose module validate_network". You should always validate the network before doing a dbreplication reset

You may also want to make sure that (a) each node has a copy of the db loaded and (b) the CM process nodes match what you expect for IP address or hostname. Use the following (on each node):

admin: run sql select name from processnode

I suspect you have something mixed up between the IP address and/or hostname. Note that when a system is booted, if it cannot communicate with its default gateway or resolve host names for the cluster (forward or reverse), certain services (like the database) will fail to start. You can see if you are in this state using the "utils service list". Look for things that are stuck in a "Starting" state or services that are "Stopped" AND aren't flagged with "Service Not Activated".

As an aside, the "validate_network" module is similar (may even be exact) to the process that CUCM uses when booting up to validate network connectivity (i.e. as a pre-req to starting services).

HTH.

Regards,

Bill

[at]

hi,

did you find out the reason of the error ?

regards

alex

[Jason Aarons]

This is pretty funny. The fix was to power on the MCS-7825.  Seems after it got moved it never got turned on!!! I was remote from it and had assumed the subscriber was powerd on. I should have tried to ssh to it and get it's view.

[jasunf]

Hello!  I want to piggy back off this old post instead of starting a new one.  I've gone over all Bill's recommendations and found that the run sql select on the subscribers still reflect the old addresses.

We actually changed addresses on our lab call managers thats all we did.  I changed their IPs through the web interface in ccmadmin then changed their IPs on the console through the CLI.  I then fixed the publisher settings through os admin webpage to reflect the new proublisher IP. 

Is there another area I'm missing that I need to get these subs talking back to the pub?  Connectivity seems to be fine on the subs