Hierarchy replication specifies what is replicated in the hierarchy. It has no effect on the stand-alone replication that you can set up between any two Notification Servers. Any data that is replicated down from a parent Notification Server has priority, and overwrites the corresponding data on its child servers.
Hierarchy replication is not supported from a 7.1 server to a 7.0 server or from a 7.0 server to 7.1 server.
The replicated configuration and management items received from a parent server are usually read-only so they cannot be modified. The read-only setting ensures that it is replicated unchanged down the hierarchy. If you want to allow additions to replicated items on child servers, you need to unlock the relevant items on the Notification Server computer on which they were created. For example, you may want to allow policies to be enabled and disabled on the child Notification Servers.
Hierarchy replication does not let you replicate the same data up and down the hierarchy. If you set up two rules that have the same resource type being replicated in both directions, a critical alert is raised and the replication rules are not executed.
Hierarchy has two modes of replication:
Replicates the objects and the data that have changed since the last replication. This mode is enabled by default and reduces the load and the bandwidth that hierarchy uses.
Replicates all objects and data. This mode is disabled by default.
To minimize the load on the network and to prevent data collisions, you should schedule hierarchy replication at a different time for each Notification Server in your hierarchy.
Hierarchy replication synchronizes different types of objects in the following ways:
Security objects, such as roles and privileges, always use complete replication. Differential replication is not an option for read-only objects such as these.
Items use differential replication, which is handled by hashing each item to check for changes and replicating those that have changed.
Resources use differential replication. Differential replication is based on the "last changed" timestamp on the source data. Any data that has changed since the last replication is replicated to the destination server. The data on the destination is then verified, if data verification has been enabled in the appropriate replication rule.
Data verification imposes significant processing load on Notification Server. To reduce this load, you can verify a specified percentage of data on the destination server with each replication. For example, if you verify 10% of the data for each replication, that ensures that all data has been verified after 10 replications.
Imported Document ID: HOWTO62750
Subscribing will provide email updates when this Article is updated. Login is required.