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
Historical Information and Conflict Resolution
What is a Replication Conflict?
Purging Historical Information
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
The External Change Log (ECL) provides an alternative view of the replication change log. The following sections describe the architectural details of the ECL:
For information about how to use the ECL, see Using the External Change Log in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
The ECL is built online from the replication change log and does not use an additional database for its storage. It is not a regular JEB backend, therefore no index needs to be configured.
The ECL is available by default on any server instance that includes both a directory server and a replication server. The ECL is not available on a server instance that is configured as either a dedicated directory server or a dedicated replication server (as described in Configuring Large Replication Topologies in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory).
The ECL is based on the LDAP change log draft (http://tools.ietf.org/html/draft-good-ldap-changelog-04) but does not strictly support this change log. The LDAP change log draft uses an integer as the key to browse the change log whereas the ECL uses a cookie.
On the client side, the cookie mechanism has the following advantages:
Ability to fail-over from one ECL instance to another
Ability to load balance request over several ECL instances
On the server side, the cookie mechanism has the following advantages:
Easier implementation in a multi-master environment
Cheaper in terms of resources required on the server
Smaller performance impact for other applications that generate changes
Note - The Oracle Directory Server Enterprise Edition (ODSEE) Retro Change Log (RCL) supports the LDAP change log draft, with some specific additions.
The following sections describe the differences between the two change logs, which will assist you in porting client applications.
The LDAP change log draft specifies the change log index as an integer (changenumber attribute). This works well when the change log is served by a single server (which was the case at the time that the LDAP change log draft specification was written.) When the change log service supports more than one server and when failover is supported from one server to another, the integer format is not appropriate.
The LDAP change log draft specifies the DN for entries in the change log as changenumber=changenumer,cn=changelog. The ECL uses the following DN for entries in the change log:
replicationcsn=replicationCSN,replication-domain-DN,cn=changelog
The ECL schema is based on the LDAP change log draft schema, however, Oracle Unified Directory manages an index in the ECL through a cookie that is opaque to the application, rather than through the changenumber attribute. The schema differ as follows:
|
The Oracle Directory Server Enterprise Edition RCL specifies that the target entry unique ID is stored in the targetuniqueid attribute. The format of this attribute value is specific to Oracle Directory Server Enterprise Edition. The replicationcsn attribute also has a value that is specific to Oracle Directory Server Enterprise Edition.
The Oracle Directory Server Enterprise Edition RCL supports the following attributes in the root DSE entry:
The firstchangenumber attribute, which contains the first (oldest) change log index as an integer change number.
This value is updated when the change log is purged. Before connecting to the change log server, an application reads the first change log index and compares it with the change log index that it stored. If the first change log index is more recent than the last change log index stored by the application, the application knows that the changes from the application index to the first change log index will never be returned by the server. They can only be obtained by reading the entries (full resync).
With the Oracle Unified Directory ECL, this procedure is not required of the application. Instead the Oracle Unified Directory server does the check and rejects the request when the cookie is too old. For more information, see Using the External Change Log in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
The lastchangenumber attribute, which contains the latest (newest) change log index as an integer change number.
The Oracle Unified Directory ECL supports the equivalent feature with the lastExternalChangelogCookie attribute. For more information, see Using the External Change Log in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
In the Oracle Directory Server Enterprise Edition RCL, the external change log and the regular replication change log are different databases. In Oracle Unified Directory, the two change logs are in the same database. This design decision has several advantages. An additional consequence of this design decision is that Oracle Directory Server Enterprise Edition can have two different trim policies (purge delays), while in Oracle Unified Directory the trim policy is the same.
Oracle Unified Directory provides an additional API that is compatible with the LDAP draft change log and supports most of the additional features of the Oracle Directory Server Enterprise Edition Retro Change Log. The use of this API has a performance impact in terms of CPU and database (disk) space on the server side, and some computation for the application that fails over from one ECL server to another one.
The use of this compatible API (compatible mode) is configured when the server receives a request on the ECL with no change log cookie. The server returns entries with a changenumber attribute, the value of which is an incremental integer.
The client can search the ECL by providing a filter on the changenumber. The target entry unique ID is stored in an attribute called targetuniqueid with a format compatible with the Oracle Directory Server Enterprise Edition Retro Change Log. The first and last changenumber are present as attributes of the root DSE entry.
Because Oracle Unified Directory does not store the ECL in a dedicated database, it does not support all the features supported by a JEB back end, such as specific indexes.
In addition, in order to support the changenumber-based ordering that is specified by the LDAP change log draft, Oracle Unified Directory must store a mapping from the changenumber to the replication state. When the server processes a request, it must try to retrieve the replication state from the changenumber that is provided in the request filter. If this cannot be achieved, the request is rejected.