21
Directory Replication Concepts

In "Distributed Directories", you saw an overview of replication. This chapter provides a closer look. It contains these topics:

• Directory Replication Groups and Replication Agreements
• Oracle9i Replication
• Replication Architecture
• Change Log Purging
• Conflict Resolution in Replication
• The Replication Process

  See Also: "Replication" for a more general, conceptual discussion of replication Chapter 22, "Oracle Directory Replication Server Administration" for information on managing replication

Directory Replication Groups and Replication Agreements

The set of directory servers that participate in replication of a given naming context is called a directory replication group (DRG). A special directory entry, called a replication agreement, represents the replication relationship among the directory servers in a DRG.

It is possible for a directory server to be both a supplier and a consumer of change log information. Oracle Internet Directory uses this feature to support multimaster replication.

Figure 21-1 illustrates a directory replication group in which three nodes share updates with each other in a replication agreement.

Figure 21-1 Directory Replication Group

Text description of the illustration replgrp.gif

In Figure 21-1, each bullet represents a node of Oracle Internet Directory. The agreement is identical on each node except for local options such as partitioned naming contexts on the local directory server. The replication agreement on each node lists all the other nodes to which it delivers, and from which it receives, changes.

Oracle9i Replication

Transport of update information between nodes in a replication agreement is managed by Oracle9i Replication, a store-and-forward transport feature available in Oracle9i. It allows database tables to be kept synchronized across two Oracle databases.

Oracle9i Replication stores local changes and periodically propagates them in batches to consumer servers. The consumer replication servers apply the remote changes to the local directory server and then purge the applied remote changes from their local stores.

Oracle9i Replication environments allow read and update access to directory tables anywhere in the Oracle9i replication group. Typical Oracle9i Replication configurations use row-level replication with asynchronous data propagation.

Oracle9i Replication provides proven network tolerance and its data transfer can be controlled and monitored by Oracle Enterprise Manager. Such manageability allows a high degree of flexibility in how the data transfer is scheduled.

Replication Architecture

Supplier servers write their changes to change logs, and then regularly send batched directory changes to other consumer servers. Consumer servers receive the change log data, then reproduce the changes locally.

When you configure replication, you specify which nodes in a replication group share changes. Regardless of the number of nodes you introduce into the replication environment, the basic architecture for replication remains the same. Local changes are distributed to remote nodes and applied by replication server processing. To apply the changes on a remote node, the replication server, acting as a client, sends commands to the directory server that implements them.

The rest of this section discusses, in general terms, the replication process, both from the standpoint of the supplier, and from that of the consumer.

The Replication Process on the Supplier Side

The following graphic and its accompanying text explain what happens on the supplier side during the replication process.

Text description of the illustration oidag031.gif

1. An LDAP client issues a directory modification.
2. The Oracle directory server generates a change log object in the change log object store.
3. At a scheduled time, the Oracle directory replication server launches an outbound change log processing thread. This thread translates the change log object into a row--for example, Change entry--in the change log table.
4. When a change entry is committed to the change log table, Oracle9i Replication immediately copies the change into the deferred transaction queue.
5. After a scheduled interval, Oracle9i Replication pushes pending transactions from the deferred transaction queue across the network to the consumer change log table.

The Replication Process on the Consumer Side

The following graphic and its accompanying text explain the replication process on the consumer side.

Text description of the illustration oidag030.gif

1. A change arrives in the consumer change log table from the supplier.
2. The Oracle directory replication server launches a change log processing thread for each supplier, based on a scheduled replication cycle. This thread first consults the change status table for the last change applied from the supplier to the consumer.
3. The Oracle directory replication server then fetches and applies all the new changes from the change log table to the Oracle directory server.
4. The Oracle directory replication server then updates the change status table to record the last change applied from the supplier before exiting.
5. Oracle9i Replication copies the change status update into the deferred transaction queue.
6. After the scheduled Oracle9i Replication replication interval, Oracle9i Replication pushes pending change status updates from the deferred transaction queue to the supplier change status table.

Although, in the previous figures, the roles of supplier and consumer have been separated, in an actual multimaster replication environment, each directory server is both a supplier and a consumer. In such an environment, purging occurs regularly, removing entries that are already applied and entries that have been dropped as candidate changes. Remote change records in the local Changelog table are purged by the garbage collection thread if they have been applied locally. Local change records in the local Changelog table are purged by the garbage collection thread if they have been distributed to all the consumers.

Change Log Purging

Change log purging takes place in Oracle Internet Directory in two ways:

• Change number-based

  This is the default method. The replication server purges those changes that have already been applied to all the nodes in a DRG.

• Time-based

  You can run this method to augment change number-based purging. To use this additional method, you set a parameter specifying in hours the lifespan of change log objects. For example, you can set this parameter to purge all change log objects that are 24 hours old. Use this method to prevent the change log from becoming too large.

Conflict Resolution in Replication

Multimaster replication enables updates to multiple directory servers. Conflicts occur whenever the directory replication server attempts to apply remote changes from a supplier to a consumer and fails for some reason.

The following kinds of LDAP operations can lead to conflicts:

• Addition
• Deletion
• Modification
• Modification of either an RDN or a DN

This section contains these topics:

• Levels at Which Replication Conflicts Occur
• Typical Causes of Conflicts
• Automated Resolution of Conflicts

Levels at Which Replication Conflicts Occur

There are two types of conflicts:

• Entry-level conflicts
• Attribute-level conflicts

Entry-Level Conflicts

An entry-level conflicts is caused when the directory replication server attempts to apply a change to the consumer. Such a change could be one of the following types of changes to the consumer:

• Adding an entry that already exists
• Deleting an entry that does not exist
• Modifying an entry that does not exist
• Applying a modifyrdn operation when the DN does not exist

These conflicts can be difficult to resolve. For instance, it may be impossible to resolve a conflict because:

• The entry has been moved to a different location
• The entry has not yet arrived from a supplier
• The entry has been deleted
• The entry never existed on the consumer

If an entry exists and it should not, then it may be because it was added earlier, or that it recently underwent a modifydn operation.

Attribute-Level Conflicts

An attribute-level conflict is caused when two directories are updating the same attribute with different values at different times. If the attribute is single-valued, then the replication process resolves the conflict by examining the timestamps of the changes involved in the conflict.

Typical Causes of Conflicts

Conflicts usually stem from the timing of changes arising from the occasional slowness or transmission failure over wide-area networks. Also, an earlier inconsistency might continue to cause conflicts if it is not resolved in a timely manner.

Automated Resolution of Conflicts

The directory replication server attempts to resolve all conflicts that it encounters by following this process:

1. The conflict is detected when a change is applied.
2. The replication process attempts to reapply the change a specific number of times or repetitively for a specific amount of time after a specific waiting period.
3. If the replication process reaches the retry limit without successfully applying the change, it flags the change as a conflict, which it then tries to resolve. If the conflict cannot be resolved according to the resolution rules (described in the next section), the change is moved to a low-priority, human intervention queue. Changes are then applied according to the time unit specified in the orclHIQSchedule parameter in the replication agreement. Before it moves the change, the directory replication server writes the conflict into a log file for the system administrator.

   Note: There is no conflict resolution of schema, catalog, and group entries during replication. This is because attempting resolution of such large multi-valued attributes would have a significant negative impact on performance. Be careful to avoid updating such entries from more than one master at a time.

   See Also: For schema questions, Appendix C, "Schema Elements". For catalog questions, the The Catalog Management Tool section in Appendix A, "Syntax for LDIF and Command-Line Tools".

The Replication Process

This section describes how the automated replication process adds, deletes, and modifies entries, and how it modifies DNs and RDNs. It contains these topics:

• How the Replication Process Adds a New Entry to a Consumer
• How the Replication Process Deletes an Entry
• How the Replication Process Modifies an Entry
• How the Replication Process Modifies a Relative Distinguished Name
• How the Replication Process Modifies a Distinguished Name

How the Replication Process Adds a New Entry to a Consumer

When directory replication server successfully adds a new entry to a consumer, it follows this change application process:

1. The directory replication server looks in the consumer for the DN of the parent of the target entry. Specifically, it does this by looking for a global unique identifier (GUID) assigned to the DN of the parent.
2. If the parent entry exists, then the directory replication server composes a DN for the new entry and places the new entry under its parent in the consumer. It then places the change entry in the purge queue.

If the change entry is not successfully applied on the first try:

If the change entry is not successfully applied on all but the last retry:

If the change entry is not successfully applied on the last retry: