Basic replication error log

A replication error log holds information about each error that occurs during basic replication. To avoid stalling basic replication, the failed replication operation is taken off the replication queue so that replication can continue with the next operation. Depending on the error, the LDIF of the failed operation is set aside (added) to the error log.

There is one error log for each replica of a backend. The file name of the error log for a replica is specified by the ibm-slapdLog attribute in the replica entry for that replica within the backend. The file name must be unique across the LDAP server. If the attribute does not exist in the replica entry or the attribute has no value, no errors are logged or replication operations set aside during this backend's replication to that replica. In this case, basic replication to that replica stalls every time a failure occurs. The ibm-slapdReplMaxErrors attribute in the replica entry is set to control how many failed replication operations can be set aside each time the LDAP server is started before basic replication stalls for that replica.

In a sysplex environment, consider having the basic replication error log file shared by the LDAP servers which are sharing the replicating backend. Only the LDAP server that is the owner of the backend in the sysplex performs replication and writes to the replication error log if an error occurs. However, if that LDAP server stops, another LDAP server in the sysplex becomes owner and handles basic replication. If the error log file is shared, then the new owner can add error information to the same error log rather than beginning a new error log. This centralizes error information and eliminates the need to look for error logs on each server that might have become the backend owner.

The replication error log is used to correct basic replication in two ways:

Use the error information to determine why replication failed.
Use the ldapmodify utility to run the error log on the replica server, after resolving the basic replication problems. This performs the modifications that were set aside in the error log, therefore, bringing the backend in the replica to the same level as in the replicating server. You must bind as either the masterserverDN or peerserverDN, depending on the type of replica.

The following is an example of an error log entry:

#(051219 13:25:23.146587): modify operation failed for cn=IBMUSER01, o=ibm,c=us to
  dceimgtd.pdl.pok.ibm.com:390, rc=32
# R004071 Entry cn=IBMUSER01, o=ibm,c=us  does not exist 
  (tdbm_process_request:933)
# setting change aside.

dn: cn=IBMUSER01, o=ibm,c=us
changetype: modify
modify: uid
uid: IBMUSER1
-
modify: userpassword
userpassword:: Ym9i

The basic replication error log consists of three messages, each using one or more lines:

Message one indicates when the error occurred, the entry, and replica server.
Message two is the error message returned by the replica server.
Message three indicates what is being done. If the operation is set aside, this message is followed by the LDIF of the operation.

All non-LDIF information is prefixed with the comment character # so that the error log can be run through ldapmodify to synchronize the two servers.

Following is an example in which a replication error condition is logged but no set-aside of the modification is needed:

#(051219 14:13:12.366227): delete operation failed for cn=IBMUSER01, 
o=ibm,c=us to dceimgtd.pdl.pok.ibm.com:390, rc=32
# R004071 Entry cn=IBMUSER01, o=ibm,c=us does not exist 
 (tdbm_process_request:933)
# Entry is already deleted, ignoring request.

There is no LDIF. Notice the third message indicates that request is being ignored.