2. The Directory Server Access Control Model
3. Understanding the Directory Server Schema
4. Directory Server Index Databases
5. Understanding Directory Server Plug-Ins
6. Directory Server Replication
Overview of the Directory Server Replication Architecture
Basic Replication Architecture
Directory Server Change Processing
Historical Information and Conflict Resolution
What is a Replication Conflict?
Purging Historical Information
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
Additional Differences Between the ECL and the Sun DSEE Retro Change Log
API for Compatibility With the LDAP Change Log Draft and the Sun DSEE Retro Change Log
Limitations of the Compability API
The schema replication architecture relies on the general replication architecture. You should therefore have an understanding of the general replication architecture before reading this section. For more information, see Overview of the Directory Server Replication Architecture.
Directory servers notify replication servers about any changes to their local schema. As in the case of data replication, the replication servers propagate schema changes to other replication servers, which in turn replay the changes on the other directory servers in the topology.
Schema replication shares the same replication configuration used for any subtree:
dn: cn=example,cn=domains,cn=Multimaster Synchronization,\ cn=Synchronization Providers,cn=config objectClass: top objectClass: ds-cfg-replication-domain cn: example ds-cfg-base-dn: cn=schema ds-cfg-replication-server: <server1>:<port1> ds-cfg-replication-server: <server2>:<port2> ds-cfg-server-id: <unique-server-id>
Schema replication differs from data replication in the following ways:
Entry Unique ID. A unique ID is required for data replication because entries can be renamed or deleted.
In the case of the schema, there is only one entry and that entry cannot be deleted or renamed. The unique ID used for the schema entry is therefore the DN of the schema entry.
Historical information. Historical information is used to save a history of relevant modifications to an entry. This information makes it possible to solve modification conflicts.
For schema replication, the only possible operations are adding values and deleting values. Historical information is therefore not maintained for modifications to the schema.
Persistent server state. When a directory server starts up, the replication plug-in establishes a connection with a replication server. The replication server looks for changes in its change log and sends any changes that have not yet been applied to the directory server.
In order to know where to start in the change log, the replication plug-in stores information that is persistent across server stop and start operations. This persistent information is stored in the replication base-dn entry.
The schema back end allows the specific operational attribute used to store the persistent state, ds-sync-state, to be modified.