The retro change log is a plug-in used by LDAP clients for maintaining application compatibility with earlier versions of Directory Server. The retro change log is stored in a separate database from the Directory Server change log, under the suffix cn=changelog.
A retro change log can be enabled on a standalone server or on each server in a replication topology. When the retro change log is enabled on a server, updates to all suffixes on that server are logged by default.
For information about how to use the retro change log, see Using the Retro Change Log in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.
When a retro change log is enabled with replication, the retro change log receives updates from all master replicas in the topology. The updates from each master replica are combined in the retro change log. The following figure illustrates the retro change log on two servers in a multi-master topology.
The retro change log uses the following attributes during replication:
Identifies the order in which an update is logged to the retro change log
Identifies the time when an update is made to a given replica
Identifies the replica that is updating the retro change log
The diagram shows that the retro change logs, RCL1 and RCL2, contain the same list of updates, but that the updates do not have the same order. However, for a given replicaIdentifier, updates are logged in the same order on each retro change log. The order in which updates are logged to the retro change log is given by the changeNumber attribute.
The following figure illustrates a simplified replication topology where a client reads a retro change log on a consumer server.
All of the updates made to each master replica in the topology are logged to each retro change log in the topology.
The client application reads the retro change log of Directory Server 3 and stores the last CSN for each replica identifier. The last CSN for each replica identifier is given by the replicationCSN attribute.
The following figure shows the client redirecting its reads to Directory Server 2 after the failure of Directory Server 3.
After failover, the client application must use the retro change log (RCL2) of Directory Server 2 to manage its updates. Because the order of the updates in RCL2 is not the same as the order in RCL3, the client must synchronize its updates with RCL2.
The client examines RCL2 to identify the cN that corresponds to its record of the last CSN for each replica identifier. In the example in Failover of the Retro Change Log, the client identifies the following correspondence between last CSN and cN:
CSN 1 from R1 corresponds to cN4 on RCL2
CSN 2 from R2 corresponds to cN5 on RCL2
CSN 3 from R3 corresponds to cN7 on RCL2
CSN 1 from R4 corresponds to cN6 on RCL2
The client identifies the update corresponding to the lowest cN in this list. In the example in Failover of the Retro Change Log, the lowest cN in the list is cN4. To ensure that the client processes all updates, it must process all updates logged to RCL2 after cN4. The client does not process updates logged to RCL2 before cN4 nor does it process the update corresponding to cN4.
When a replication conflict occurs, Directory Server performs operations to resolve the conflict. When the retro change log is running and the changeIsReplFixupOp attribute is set to true, the following information about the operations is logged in the changeHasReplFixupOp attribute:
Target DN of the operation
The type of update
The change made
For more information about these attributes, see the Sun Java System Directory Server Enterprise Edition 6.1 Man Page Reference.
Observe the following restrictions when you use the retro change log:
A master replica running this version of Directory Server cannot be a supplier to a consumer replica running Directory Server 4.x.
In a replicated topology, the retro change logs on replicated servers must be up-to-date with each other. This allows switchover of the retro change log. Using the example in Failover of the Retro Change Log, the last CSN for each replica ID on RCL3 must be present on RCL2.