CUCM 7.1.5 Publisher Hardware replacement

[Raymond Choi]

Hello,

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 in advance!

Cheers,
Ray

[Nick Lichatz · Accepted solution]

Why dont you just have the new pub ready to go before you put it on the network?  Create a Vlan on your switch for a PC and the new pub.

If you are restoring a CUCM from a disaster recovery file the database will be the same as the most recent backup you have done and wont have to worry about the subs connecting and replicating a

You could shut off the replicator service if its on your network but it will start on restart

A Cisco DB Replicator

[Raymond Choi]

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.

Cheers,

[matt.frenaux]

Hello,

I will restore a Publisher 8.5 in a production environment for a customer tomorrow.

My fair is to delete all the data on the subscribers's databases of course.

Could you confirm that all I need to do is to stop the "A Cisco DB Replicator" on the Subs ?

Then, I can rebuild the pub and restore it online ?

Kind regards

Matthieu

[Raymond Choi]

Hi Matt,

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.

Cheers,
Ray

[matt.frenaux]

Thank you raymond, the publisher has been restored during open hours without impacting the subscribers & the users.

I just had to deal with utils dbreplication stop/clusterreset/reset all in order to have the databases synchronized.

Cheers,

Matthieu