Exit Print View

Sun OpenDS Standard Edition 2.2 Architectural Reference

Get PDF Book Print View
 

Document Information

1.  Introduction

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

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

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

Fractional Replication

Fractional Data Set Identification

Fractional Replication Filtering

Fractional Replication and Local Operations

External Change Log

How the External Change Log Works

Porting Applications that Rely on Other Change Logs

Differences Between the ECL and the LDAP Change Log Draft

Index Differences

DIT and Schema Differences

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

7.  Directory Server Root Users and the Privilege Subsystem

8.  Supported Controls and Operations

What is a Replication Conflict?

A conflict occurs when one or more entries are updated simultaneously on multiple servers and the changes are incompatible, or causes some interaction between the updates. Conflict occurs because no update operation is carried out simultaneously on every replica in the replication topology. Instead, updates are first processed on one server, then replicated to other servers.

The following example describes a conflict that occurs when an attribute is modified at the same time on two different directory servers.

Consider a topology with two read-write replicas. A modify operation changes the surname, sn, attribute of an entry to Smith on one server. Before the server that is processing the change can synchronize with the other server, the sn attribute value for that entry is replaced with the value Jones on the other server. Unless the conflict is managed, replication would replay the change (Smith) on the server that now contains the value Jones. At the same time, replication would replay the change (Jones) on the server that contains the value Smith. The servers would therefore end up with inconsistent values for the sn attribute on the modified entry.

The following list describes additional conflicts that can occur.

Conflicts that involve only modifications of the same entry are called modify conflicts. Conflicts that involve at least one operation other than modify are called naming conflicts.

All modify conflicts and the vast majority of naming conflicts can be solved automatically by replaying the operations in their order of occurrence. However, the following naming conflicts, which have very little chance of occurring, cannot be solved automatically.