Things to consider before configuring replication

Edit online

Before setting up an LDAP replication configuration, there are some administrative responsibilities that you need to consider. You can make use of the information and links provided here to know more about it.

In order to ensure that replication is operating smoothly and that your replicas are staying up-to-date, the administrator needs to take some periodic actions to monitor the replication status.After replication is correctly configured, it continues to automatically propagate updates to all defined replica servers.However, if errors occur, human intervention might be required to fully correct the problem.

Interfaces are provided to allow you to view information about updates queued for replication, and to take actions like suspending or resuming replication to a specific replica.See Managing queues for details.These replication queues should be checked periodically for errors.Read Viewing server errors to understand how to check for errors that may have occurred during replication to a specified consumer server.

Detailed status and error information is also available to the administrator by reading operational attributes on the replication agreements.See Monitoring replication status for a description of the information available.

Configuring multiple master servers adds to the potential error cases that an administrator must be aware of.If the same entry is updated at two different master servers at approximately the same time, those updates are likely to conflict when they are replicated to other servers in the topology.The replication algorithm is designed to detect and resolve any replication conflicts between adds or modifies. See Replication conflict resolution.

You can use a time synchronization product to keep your LDAP servers synchronized. Such a utility is not provided by IBM® Security Verify Directory.

Attention: When you create a new directory server instance, be aware of the information that follows. If you want to use replication, you must synchronize the encryption keys of the server instances to obtain the best performance.
If you are creating a directory server instance that must be cryptographically synchronized with an existing directory server instance, you must synchronize the encryption keys on the server instances before you do any of the following steps because the server will generate server encryption keys:
  • Start the second server instance
  • Run the idsbulkload command from the second server instance
  • Run the idsldif2db command from the second server instance
See Synchronizing two-way cryptography between server instances for information about synchronizing directory server instances.

The server does not allow subtree deletion if the subtree contains replication agreements. Because the order of entries to be deleted is not fixed, deleted entries can be replicated randomly. For example, if a replication agreement is deleted first in a subtree, then the delete operation cannot be replicated.This restriction works only when a context is deleted with the -s option. If you want to delete the subtree, you must first delete the replication agreements.

Note: You must synchronize the replication topology entries before starting replication. Set up the servers in the network.

When you are configuring a replica server, ensure that you set the master DN to an ID that is not the same as the admin DN on the replica server. If the DN IDs are the same, it is possible to bind to the replica with the combined adminDN-masterDN ID and make updates directly to the replica. The replica servers can become unsynchronized with the master server. This causes errors on the master and leads to data inconsistencies on the servers. All changes to the replica must be made by the master server binding with the masterDN. Attempted changes to a replica server are referred to the master server for the update process to take place.