Exit Print View

Sun OpenDS Standard Edition 2.0 Architectural Reference

Get PDF Book Print View

Document Information

The Directory Server Access Control Model

Understanding the Directory Server Schema

Index Databases

Understanding Directory Server Plug-Ins

Directory Server Replication

Overview of the Directory Server Replication Architecture

Basic Replication Architecture

Replication Servers

Replication Change Numbers

Replication Server State

Operation Dependencies

How Replication Works

Directory Server Change Processing

Change Replay

Auto Repair

Directory Server Crashes

Replication Server Crashes

Historical Information and Conflict Resolution

What is a Replication Conflict?

Resolving Modify Conflicts

Resolving Naming Conflicts

Purging Historical Information

Schema Replication

Schema Replication Architecture

Replication Status

Replication Status Definitions

Degraded Status

Full Update Status and Bad Generation ID Status

Replication Groups

Replication Server Selection

Replication Groups in a Multi-Data Center Deployment

Assured Replication

Assured Replication Modes

Safe Data Mode

Safe Read Mode

Safe Read Mode and Replication Groups

Assured Replication Connection Algorithm

Assured Replication and Replication Status

Assured Replication Monitoring

Root Users and the Privilege Subsystem

Supported Controls and Operations

Change Replay

The replay of changes on replicated directory servers is efficient on multi-core and multi-CPU systems. On a directory server, multiple threads read the changes sent by the replication server.

Dependency information is used to decide whether an operation can be replayed immediately. The server checks the server state and the list of operations on which the current operation depends to determine whether those operations have been replayed. If the operations have not been replayed, the server puts the operation in a queue that holds dependency operations. If the operation can be replayed, the server builds an internal operation from information sent by replication servers. The server then runs the internal replay operation.

Internal replay operations built from the operations that are sent by a replication server can conflict with prior operations. Such internal operations cannot therefore always be replayed as if they were taking place on the original directory server. The server checks for conflicts when processing the handleConflictResolution phase.

In the majority of cases, the internal replay operations do not conflict with prior operations. In such cases, the handleConflictResolution phase does nothing. The replication code is therefore optimized to return quickly.

When a conflict does occur, the handleConflictResolution code takes the appropriate action to resolve the conflict. For modify conflicts, the handleConflictResolution code changes the modifications to retain the most recent changes.

When conflict resolution is handled, historical information is updated as for local operations. The operation can then be processed by the core server. Finally, at the end of the operation, the server state is updated.

After completing an operation, the server thread processing the operation checks whether an operation in the dependency queue was waiting for the current operation to complete. If so, that operation is eligible to be replayed, so the thread starts the replay process for the eligible operation. If not, the thread listens for further operations from the replication server.