I'm looking to perform a Pub hardware replacement however need to ensure that the Sub's don't try to replicate its DB until the new server is ready to be placed in production (restored). There are 5 Subs that will need to maintain there existing DB for device registration and call processing during the publisher restore period.
Can anyone recommend the best way to achieve this with minimal disruption of service.
ACL's are to be placed to restrict the Subs from getting to the Pub but one of the Sub's is in the same subnet/vlan.
'utils dbreplication stop all' to be performed on Pub but a restart of the new server will try to setup replication again.
Any other suggestions will be greatly appreciated!
Thanks for your reply Nick. The Pub is in a datacentre in another part of the country and takes a week or two for delivery/installation as such I sent a vanilla Pub to be restore for a backup.
The CUCM Publisher hardware replacement was perform successfully a few days ago without any interruption to Sub services.
After further review of the implementation procedure, it was concluded that the 'A Cisco DB Replicator' service was to be stopped on each Sub server causing RPC to go offline thus stopping replication with the Pub. The ACL's were not activated on the interface, as during the Pub restore, the Subs were required to be contactable. A warning was received on the CCMDB restore as the Sub's RPC/Replicator services were offline.
After the restore and restart of the Pub, the 'A Cisco DB Replicator' service was started on each Sub followed by a 'utils dbreplication restart all' on the Pub and after approx 1.5 - 2 hours, dbreplication was 2-good across the cluster.
thanks again for your response Nick, turning off the Cisco DB Replicator service was the correct answer as my main concern was empty tables being replicated onto the active Subs.
Yes, once the 'A Cisco DB Replicator' is stopped, the Sub will use its own local DB until the replication to the Pub is restored.
You may want to confirm that all devices are registered to the Sub and all gateway (SIP, H323, VG's, etc) dial-peers, sccp registrations, etc including Media Resouce Group List (in CUCM Admin) don't use Pub resources as the first choice so call processing should not be impacted and no user impact should be experienced. Also confirm if any IP Phone services point to the Pub, if they do you might want to let the users know of service outages.
During the restore the Pub will be required to contact the Sub and you will receive an warning about the replication status but that will be because the DB Replicator is stopped.
Once the Pub has finished restoring and has been reset, restart the 'A Cisco DB Replicator' on the Sub and you may need to initiate a 'utils dbreplication restart all' to get the cluster back to 2-good replication.
I hope this helps and your implementation goes successfully.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...