How to avoid DB Replication problem in lab

Hi All,

I need your help any any ideas if you have:

To avoid DB replication problem I follow the below procedure:

1. CUCM > servers: change to IP addresses.

2. CUCM > callmanager: put the exact names I see in "show myself" command for both sub and pub

3. CUCM OS admin > Add ntp server as specified in question.

4. Activate the services on pub and sub and get on with the sections.

What I noticed is sometimes in the middle of the lab, the sub will be out of sync. Using unified reporting is not good. Even though it shows good status with 2 and count as 412. If I change location bandwidth I do not see it get synced on sub by using show perf query class "Cisco Locations". Even the trace log will not work in troubleshooting section. I end up stopping replication services on sub and then pub and finally doing a forceddbsub on pub and restarting the subscriber. This is not good as I loose lot of time in lab. Few times I end with db reset for the cluster-wide.

Do anyone know of a better method to avoid this problem totally in real lab?

Thank you,

Rahm

 

 

Comments

  • Are you using INEs remote racks? I used to use my own eqipment (was constantly reverting VM snapshots) and never had the issue until I started using INEs racks...

     

    I have been doing the following and havn't had any issues:

    1 - (If you are using HQ as the NTP source or PSTN) Set that up and ensure CUCM can talk to it.

    2 - Go into OSadmin for CUCM and set up the NTP

    3 - Begin your lab strategy (for me I start with getting CUE online as it needs about 15 reboots with doing a factory restore + installing correct license)

    4 - I would then be typing 100% of the IOS commands in notepad for the routers copying anything possible between them

    5 - about 20 min into typing IOS commands, check NTP on the Publisher CUCM via ssh "utils ntp status", as soon as you see it synced up I bounce the entire Sub CUCM Node "utils system restart"

    6 - continue as your strategy is built

     

    I have been successfull the past 2 times I have done this and not had any replication issues. As Mark has mentioned in VODs, the way you do things in practice is how you will end up doing them naturally in the lab assuming you have preped enough. I plan to do the same on my next lab attempt.

  • Hi Brandon

    At the moment, I use my own homelab, I have everything except 3750 and no ether-modules in my routers. Your approach looks great, only concern is rebooting the subscriber. some of the experienced guys in IP telephony field told me not to reboot the servers in the real lab. At home lab I had no issues with rebooting the servers. May be doing utils ntp restart might help instead of rebooting the subscriber? Thanks for the tip on time management.

    Regards,

    Rahm

     

     

  • I agree rebooting the servers probably isn't the best thing.

     

    I tried the above method (restarting ntp) after syncing the pub up and replication still managed to break for me (I am 99% sure as I failed everything over to register to the pub everything started working......)

     

    I did the following and it seemed to get things back up:

     

    1) Issue "utils dbreplication stop" on both nodes (I do not know if it matters but I did this command on the pub then immediatly on the sub)

    -- Newer versions do have the command "utils dbreplication stop all" which you can issue on the pub but it seems like its not included on the version of CUCM in the labs

    2) I then issue "utils dbreplication reset all" on the pub and just give it time.........

  • Thanks Brandon. Today I came across a serious problem and several times in the past. I usually write all the IOS comands in a notepad and then fireup the VMware images and configure on the cucm, cuc, etc. when I start the lab and paste configs on routers and restart the servers and assign the NTP server in CUCM OS(all in my homelab). NO matter whatever commands I try the subscriber will be out of sync and the lab behaves strangely. I suspect the time gets bumped more than 8 hours ahead or backward and the cluster dbreplication fails and nothing helps. All the labs uses north american timezones, GMT etc and I should have built my vmware images in american timezone (mine is Australian eastern standard time).

    I tried the utils dbreplication stop on sub and then pub and do utils dbreplication forceddatasyncsub (on pub). It works sometimes and sometimes it will not. Never try utils dbreplication repair all. It might take hours and it is not worth it. I will try your above suggestion next time.

    Probably in the lab the vmware images are already synced to hardwared clock or something (real ntp) and then the NTP we associate is also to a real NTP server and dbreplication might not fail. It seems time drift when we hook up causes the problem. If I shutdown the whole lab and restart the next day all seems well. I think if there is a command which will totally erase all the database on sub and then sync with pub in a short time it will definitely help in passing the lab exam.

    Kind Regards,

    Rahm

     

  • I know the "forceddatasyncsub" command is an option but it is generally not suggested to go that route.

     

    I have been using my method of rebooting the sub CUCM node right after the pub synces and have yet to have a replication or NTP issue. I plan to try that on monday and let you know how it goes ;)

Sign In or Register to comment.