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

Assured Replication

Before you read the following sections , you should have an understanding of basic replication concepts. You must know what a replication server is, as opposed to a directory server, and have an understanding of how replication servers work in a replicated topology. If this is not the case, read at least the Overview of the Directory Server Replication Architecture to obtain an understanding of how regular replication works in the directory server.

In a standard replicated topology, changes are replayed to other replicated servers in a “best effort” mode. A change made on an LDAP server is replayed on the other servers in the topology as soon as possible, but in an unsynchronized manner. This is convenient for performance but does not ensure that a change has been propagated to other servers when the initial LDAP client call is finished.

In some deployments this might be acceptable, that is, the time period between the change on the first server and the replay on peer servers might be short enough to fulfill the requirements of the deployment. For example, an international organization might store employee user accounts in a replicated topology across various geographical locations. If a new employee is hired and a new account is created for him on one LDAP server in a specific location, it might be acceptable that the replay of the creation occurs in other LDAP servers a few milliseconds after the LDAP client call terminates. The user is unlikely to perform a host login that would access one of the other LDAP servers in the same second that the user account is created.

However, there might be cases in which more synchronization is required from the replication process. If a specific host fails, it might be imperative that any changes made on that host have been propagated elsewhere in the topology. In addition, the deployment might require assurance that once the LDAP client call of a change is returned by a server, all of the peer servers in the topology have received that change. Any other clients that read the entry from anywhere in the topology would be sure to obtain the modification.

Assured replication is a method of making regular replication work in a more synchronized manner. The topics in this section describe how assured replication works, from an architectural perspective. For information about configuring assured replication, see Configuring Assured Replication in Sun OpenDS Standard Edition 2.0 Administration Guide.