Things to consider before configuring advanced replication

Before setting up an advanced replication configuration, there are some administrative responsibilities that must be considered. In order to ensure that replication is operating smoothly and that your replicas are staying up-to-date, an administrator must take some periodic actions to monitor the replication status. After advanced 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.

Detailed status and error information is available to an LDAP administrator by querying the operational attributes in the replication agreement entries. See Monitoring and diagnosing advanced replication problems for a description of the information available. Configuring multiple master servers adds to the potential error cases that an LDAP 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 advanced replication topology. The advanced replication conflict resolution support is designed to detect and resolve conflicts that might occur. See Replication conflict resolution for more information about replication conflict resolution.

Consider the following when planning an advanced replication environment:
  1. Determine if an existing Directory Information Tree (DIT) subtree is to be introduced into a replication topology or if a new subtree is to be added to the server after the replication topology is established. It is suggested that all servers that serve as a supplier server are put into maintenance mode until the replication topology entries are loaded on all servers. This ensures that external updates to the subtree are not lost while configuring advanced replication. See Advanced replication maintenance mode for more information.
    1. If using an existing subtree for advanced replication:
      1. Modify the subtree to add the auxiliary objectclass ibm-replicationContext. If the ibm-replicationContext auxiliary objectclass is added to a non-suffix level entry in the directory, explicit aclEntry and entryOwner attribute values are required. The entryOwner attribute value must start with an access-id:.
      2. Unload the entire subtree to an LDIF file by using the ds2ldif utility. See ds2ldif utility for additional information about the ds2ldif utility
      3. For each server participating in the replication topology, add the unloaded entries to the server by using the ldapadd or ldif2ds utilities. See z/OS IBM Tivoli Directory Server Client Programming for z/OS for more information about the ldapadd utility. See ldif2ds utility for additional information about the ldif2ds utility.
    2. If using a new subtree for advanced replication, verify that the subtree has an auxiliary objectclass of ibm-replicationContext. For each server participating in the replication topology, add the same entries to all servers by using the ldapadd or ldif2ds utilities. See z/OS IBM Tivoli Directory Server Client Programming for z/OS for more information about the ldapadd utility. See ldif2ds utility for additional information about the ldif2ds utility.
  2. For each consumer server in the replication topology, load master bind and referral information under the cn=configuration suffix in the CDBM backend. Consumer server credential entries with an objectclass of ibm-slapdSupplier or ibm-slapdReplication must be added. If using a consumer server credentials entry with an objectclass of ibm-slapdSupplier, the replication context must be added to the ibm-slapdReplicaSubtree attribute value. See Consumer server entries for more information.
  3. For each supplier server in the replication topology, supplier server credential entries must be added for each unique consumer server in the replication context. A supplier server credential entry enables the supplier server to authenticate with the consumer server by using a simple or SASL EXTERNAL bind. If the objectclass of the supplier server credentials entry is ibm-replicationCredentialsSimple, a simple bind is used. If the objectclass of the supplier server credentials entry is ibm-replicationCredentialsExternal, a SASL EXTERNAL bind is used.
Note: There are no requirements for placing supplier server credential entries within a specific subtree. If supplier server credential entries are not replicated, use the cn=localhost subtree that does not allow the replication of entries. If supplier server credential entries are replicated outside the scope of the replication context being configured, consider using the cn=ibmpolicies subtree. When the cn=ibmpolicies subtree is configured for advanced replication, schema modifications are also replicated. See Replication of schema and password policy updates for more information about schema replication.
The following steps are used to deploy the replication topology on all servers:
  1. On a supplier server in the topology, use the ldapadd utility with the Server Administration and the Do Not Replicate controls to add the replication topology entries. The replication topology entries are the following:
    1. Replication context with an objectclass of ibm-replicationContext. See Replication contexts for more information.
    2. Replica group with an objectclass of ibm-replicaGroup. See Replica groups for more information.
    3. Replica subentry with an objectclass of ibm-replicaSubentry. See Replica subentries for more information.
    4. Replication agreement with an objectclass of ibm-replicationAgreement. See Replication agreements for more information.
  2. On the replication context added in the previous step, use the Replication topology extended operation in the ldapexop utility. This synchronizes all replication topology entries for each consumer server in the replication context. See ldapexop utility for more information about the ldapexop utility.

When these steps are complete, the supplier servers are moved out of maintenance mode.