Slave DCR -- What Is The Deletion Logic If Master DCR Unavailable

GERARD PUOPLO · ‎09-11-2008

We have DFM and HUM on servers seperate from LMS and configure as DCR slaves.

Recently maintenance occured on the LMS, box and the DFM and HUM systems deleted devices from their local DCRs.

Then we had to take HUM and DFM out of DCR slave mode, put them back in and redo the whole DCR, DFM device import and HUM poller definitions.

I suspect there is nothing we can do to prevent this from happening ? if there is please let me know.

My understanding is that a Slave DCR will only delete devices from its local DCR when it knows for sure the devices are no longer in the Master DCR.

Say a master DCR system is down for a day. Can someone confirm that a slave DCR will not automatically delete devices after a period of a few hours if the Master DCR system is down ?

Thx

akemp · ‎09-11-2008

Its the design of the relationship of Master and slave servers that causes this automatic action.

The Slave DCR refers to a repository that is an exact replica of the Master.

DCR Slaves are slave instance of DCR in other servers and provide transparent access to applications installed in those servers.

Any change to the repository data occurs first in the Master, and those changes are propagated to multiple Slaves. There can be more than one Slave in a management domain.

"

The Slave:

â€¢Maintains an exact replica of the data managed by the Master for the management domain.

â€¢Has a mechanism to keep itself synchronized with the Master.

â€¢Will first update Master and then update its own repository data. This is in case of repository data updates. "

You need to first change the mode of the master and slaves to standalone then promote what was the master back to master, then you go to Common Services->Device and Credentials->Mode settings and turn the other servers back to slaves from stand alone using the check box "Add new devices to Master.

(Duplicate devices will not be added)"

akemp · ‎09-11-2008

I forgot to add that if a slave sees the master as unreachable (either isolated or down) it uses its own copy of the DCR that it incrementally updates. If/when the master becomes reachable again any updates from the master will be trickled down to the slaves remote copy of the dcr.