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
When a directory server connects to a replication server, the replication server must determine how up to date the directory server data is before the replication server can send changes that the directory server has not yet seen. This “up to date” state of the directory server is called the replication server state.
Server state is maintained as a vector. A server might have missed relatively old changes from another remote server, yet might already have seen and processed more recent changes from a server that is close by. Server state is therefore maintained by recording the last change number processed by each replica, according to the replica identifier.
Because administrators can stop and restart servers, the server state must be saved to stable storage. Ideally saving the server state would be done after each local or replicated change is made. Saving information to the database after each change would add significant overhead, however. Server state is therefore kept in memory and saved to the database on a regular basis, and when the server is properly shut down.
A drawback of this approach is that brutal interruptions such as kills and crashes can cause the server to lose track of changes that have already been processed. This can result in the need to fix inconsistencies when the server restarts. For an explanation of how crash recovery is managed, see Directory Server Crashes.