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
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
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
This section describe how schema replication is implemented. and is aimed at users who require an in-depth understanding of the schema replication architecture.
Schema describe the entries that can be stored in a directory server. Schema management is a core feature of the directory service. Replication is also a central feature of the directory service and is essential to a scalable, highly available service.
Any changes made to the schema of an individual directory server must therefore be replicated on all the directory servers that contribute to the same service.
Schema replication occurs when the schema is modified in any of the following ways:
By modifying the cn=schema suffix when the server is online
By using a dedicated task to perform dynamic schema updates by means of a file when the server is online
By modifying the underlying back-end files directly when the server is offline
Generally, schema modifications occur only when deploying new applications or new types of data. The rate of change for schema is therefore low. For this reason, the schema replication implementation favors simplicity over scalability.
Schema replication is enabled by default. In certain specific cases, it might be necessary to have different schema on different directory servers, even when the servers share all or part of their data. In such cases you can disable schema replication, or specify a restricted list of servers that participate in schema replication. For more information, see Configuring Schema Replication in Sun OpenDS Standard Edition 2.2 Administration Guide.