22
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 23, "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 22-1 illustrates a directory replication group in which three nodes share updates with each other in a replication agreement.

Figure 22-1 Directory Replication Group

Text description of the illustration replgrp.gif

In Figure 22-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.

See Also: "Managing Replication" for information about how to configure replication agreements

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.

See Also: Oracle9i Replication in the Oracle Database Documentation Library for information about Oracle9i Replication

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.

See Also: "Managing Replication" for information on configuring replication

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.

See Also: "Viewing and Modifying Replication Configuration Parameters by Using Oracle Directory Manager" "Modifying Replication Configuration Parameters by Using Command-Line Tools"

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 Catalog Management Tool Syntax section in Appendix A, "Syntax for LDIF and Command-Line Tools". For group entry questions, the section titled Managing Users, Groups, and Subscribers by Using the Delegated Administration Service.

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:

The directory replication server places the new change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The directory replication server checks to see if the new entry is a duplicate of an existing entry.

If the change entry is a duplicate entry:

The directory replication server applies the following conflict resolution rules:

• The entry with the older creation time stamp is used.

• If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change is applied, and the change entry is placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry:

The directory replication server places the change entry in the human intervention queue, and repeats the change application process at the interval you specified in the orclHIQSchedule parameter.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

How the Replication Process Deletes an Entry

When the directory replication server deletes an entry from a consumer, it follows this change application process:

1. The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.

2. If the matching entry exists in the consumer, then the directory replication server deletes it. It then places the change entry in the purge queue.

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

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

How the Replication Process Modifies an Entry

When the directory replication server modifies an entry in a consumer, it follows this change application process:

1. The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.

2. If the matching entry exists in the consumer, then the directory replication server compares each attribute in the change entry with each attribute in the target entry.

3. The directory replication server then applies the following conflict resolution rules:
   1. The attribute with the most recent modify time is used.

   2. The attribute with the most recent version of the attribute is used--for example, version 1, 2, or 3.

   3. The modified attribute on the host whose name is closest to the beginning of the alphabet is used.

4. The directory replication server applies the filtered modification, and places the change entry in the purge queue.

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

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

How the Replication Process Modifies a Relative Distinguished Name

When the directory replication server modifies the RDN of an entry in a consumer, it follows this change application process:

1. The directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.

2. If the matching entry exists in the consumer, then the directory replication server modifies the RDN of that entry and places the change entry in the purge queue.

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

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.

If the change entry is a duplicate entry:

The directory replication server applies the following conflict resolution rules:

• The entry with the older creation time stamp is used.

• If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry:

The directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

How the Replication Process Modifies a Distinguished Name

When the directory replication server modifies the DN of an entry in a consumer, it follows this change application process:

1. The directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.

   The directory replication server also looks in the consumer for the parent DN with a GUID that matches the GUID of the new parent specified in the change entry.

2. If both the DN and the parent DN of the target entry exist in the consumer, then the directory replication server modifies the DN of that entry and places the change entry in the purge queue.

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

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.

If the change entry is a duplicate entry:

The directory replication server applies the following conflict resolution rules:

• The entry with the older creation time stamp is used.

• If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry:

The directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.