Replication and the Retro Change Log Plug-In

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.

The retro changelog receives updates from all master replicas in the topology. The updates from each master replica are combined in the retro changelog. The retro changelog provides a way for applications to track changes so that they can be synchronized. Directory Server enables you to access a coherent version of the retro changelog on any master in a multi-master topology. You can also update your application to manage its state according to change numbers. This makes it possible to fail over between retro changelogs on different servers.

The global retro changelog contains all of the changes. If two changes occur on the same entry in two different locations, the retro changelog provides an ordered change description. If you query the retro changelog from any server, it will contain similar information.

For information about how to use the retro change log, see Using the Retro Change Log in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition.

Retro Change Log and Multi-Master Replication

The following figure illustrates the retro change log on two servers in a multi-master topology.

Figure 7–1 Retro Change Log and Multi-Master Replication

The retro change log uses the following attributes during replication:

changeNumber (cN)

Identifies the order in which an update is logged to the retro change log

replicationCSN (CSN)

Identifies the time when an update is made to a given replica

replicaIdentifier (RI)

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.

Failover of the Retro Change Log

The following figure illustrates a simplified replication topology where a client reads a retro change log on a consumer server.

Figure 7–2 Simplified Topology for Replication of the Retro Change Log

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.

Figure 7–3 Failover of the Retro Change Log

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 RI1 corresponds to cN4 on RCL2

• CSN 2 from RI2 corresponds to cN5 on RCL2

• CSN 3 from RI3 corresponds to cN7 on RCL2

• CSN 1 from RI4 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.

Replication Conflicts and the Retro Change Log

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 Oracle Fusion Middleware Man Page Reference for Oracle Directory Server Enterprise Edition.

Restrictions on Using the Retro Change Log

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.