Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1) |
2. The Directory Server Access Control Model
3. Understanding the Directory Server Schema
4. Directory Server Index Databases
5. Directory Server Replication
Overview of the Directory Server Replication Architecture
Basic Replication Architecture
Directory Server Change Processing
Replication Server Selection Algorithm
Replication Server Load Balancing
Schema Replication Architecture
Replication Status Definitions
Full Update Status and Bad Generation ID Status
Safe Read Mode and Replication Groups
Assured Replication Connection Algorithm
Assured Replication and Replication Status
Assured Replication Monitoring
Fractional Data Set Identification
Fractional Replication Filtering
Fractional Replication and Local Operations
How the External Change Log Works
Porting Applications That Rely on Other Change Logs
Differences Between the ECL and the LDAP Change Log Draft
Limitations of the Compability API
The topics in this section describe how historical information is retained and used to resolve replication conflicts.
A conflict occurs when one or more entries are updated simultaneously on multiple servers and the changes are incompatible, or causes some interaction between the updates. Conflict occurs because no update operation is carried out simultaneously on every replica in the replication topology. Instead, updates are first processed on one server, then replicated to other servers.
The following example describes a conflict that occurs when an attribute is modified at the same time on two different directory servers.
Consider a topology with two read-write replicas. A modify operation changes the surname, sn, attribute of an entry to Smith on one server. Before the server that is processing the change can synchronize with the other server, the sn attribute value for that entry is replaced with the value Jones on the other server. Unless the conflict is managed, replication would replay the change (Smith) on the server that now contains the value Jones. At the same time, replication would replay the change (Jones) on the server that contains the value Smith. The servers would therefore end up with inconsistent values for the sn attribute on the modified entry.
The following list describes additional conflicts that can occur.
An entry is deleted on one server while one of its attribute values is modified on another server.
An entry is renamed on one server while one of its attribute values is remodified on another server.
An entry is deleted and another entry with the same Distinguished Name (DN) is added on one server while one of its attribute values is modified on another server.
A parent entry is deleted and a child of that entry is created on another server, either through an add operation or a rename operation.
Two different entries with the same DN are added at the same time on two different servers.
Two different values are used to replace a single-valued attribute on the same entry on different servers at the same time.
Conflicts that involve only modifications of the same entry are called modify conflicts. Conflicts that involve at least one operation other than modify are called naming conflicts.
All modify conflicts and the vast majority of naming conflicts can be solved automatically by replaying the operations in their order of occurrence. However, the following naming conflicts, which have very little chance of occurring, cannot be solved automatically.
Two entries with the same DN are created at the same time on different servers, either by adding new entries or by renaming existing entries.
A parent entry is deleted and a child of the parent entry is created at the same time. The child entry can be created either when a new entry is added or when an existing entry is renamed.
Modify conflicts only occur with modification operations.
Operations are globally and logically ordered to determine the outcome of a given set of operations. Change numbers are used to define the order.
The replication conflict resolution functionality ensures that all servers eventually reach the same state, as if all operations were replayed everywhere in the order defined by the change numbers. This remains true even though changes might be replayed in a different order on different servers. In the modify conflict example with the sn values of Smith and Jones, described previously, assume that the value was set to Jones on the second server after it was set to Smith on the first server. The resulting attribute value should be Jones on both servers, even after the replace modification of Smith is replayed on the second server.
Historical information about each entry is retained to check whether a conflicting operation has already been played using a change number newer than that of a current conflicting operation. For each modify operation, historical information is used, first to check if there is a conflict, and, if there is a conflict, to determine the correct result of the operation.
When a modify conflict occurs, the server determines whether the current attribute values must be retained or whether the modification must be applied. The current attribute values alone are not sufficient to make this assessment. The server also determines when (at which change number) prior modifications were made. Historical information therefore includes the following elements:
The date when the attribute was last deleted
The date when a given value was last added
The date when a given value was last deleted
When an attribute is deleted or fully replaced, older information is no longer relevant. At that point the older historical information is removed.
Historical information undergoes the following processing:
Saved in the ds-sync-hist attribute (This attribute can only be viewed by an administrator.)
Updated (but not used) for normal operations
Updated and used for replicated operations
Conflict resolution is carried out when operations are replayed, after the pre-operation during the handleConflictResolution phase.
Conflict resolution is carried out by changing the List<Modification> field of the modifyOperation to match the actual modifications required on the user attributes of the entry, and to change the ds-sync-hist attribute that is used to store historical information.
Naming conflicts only happen for replayed operations. The server uses the following methods to resolve naming conflicts:
Uses unique IDs to identify entries, including entries that have been renamed
Tries to replay each operation first and only takes action if a conflict occurs
Checks during the pre-operation phase for conflicts that cannot be detected when operations are replayed
Retains no tombstone entries, which are entries that have been marked for deletion but not yet removed
Because directory entries can be renamed, the DN is not an immutable value of the entry. DNs cannot therefore be used to identify the entry for replication purposes. A unique and immutable identifier is therefore generated when an entry is created, and added as an operational attribute of the entry. This unique ID is used, instead of the DN, to identify the entry in changes that are sent between directory servers and replication servers.
A replication context is attached to the operation. The replication context stores private replication information such as change number, entry ID, and parent entry ID that is required to solve the conflict.
Historical information is stored in the server database. Historical information therefore consumes space, I/O bandwidth, and cache efficiency. Historical information can be removed as soon as more recent changes have been seen from all the other servers in the topology.
Historical information is purged in the following ways:
When a new change is performed on the entry.
By a purge process that can be triggered at regular intervals. The purge process saves space, at the cost of more CPU for processing the purge. The purge process is therefore configurable. For more information, see Changing the Replication Purge Delay in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.