Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory
11g Release 1 (11.1.1)

Part Number E10029-02
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

6 Understanding Oracle Internet Directory Replication

This chapter provides an introduction to Oracle Internet Directory replication. Replication is the process of copying and maintaining the same naming contexts on multiple directory servers. It can improve performance by providing more servers to handle queries and by bringing the data closer to the client. It improves reliability by eliminating risks associated with a single point of failure.

Figure 6-1 shows a replicated directory.

Figure 6-1 A Replicated Directory

This illustration is described in the text.

This chapter contains the following topics:

See Also:

6.1 Why Use Replication?

There are many reasons to implement replication, including the following:

6.2 Replication Concepts

This section briefly introduces some basic concepts.

This section contains the following topics:

6.2.1 Content to be Replicated: Full or Partial

One decision you must make when setting up replication is how much of the DIT to replicate from one node to another. The choices are:

Table 6-1 Full or Partial Replication

Content to Replicate Description


Propagates the entire DIT to another node.


Propagates one or more subtrees, rather than the entire DIT, to another node.

Full replication involves propagating the entire DIT to another node. This type of replication ensures the high availability of the entire directory. You can also use it to distribute operations on the entire directory among different nodes. Full replication can be based on either LDAP or Oracle Database Advanced Replication.

Partial replication enables you to propagate one or more subtrees, rather than the entire DIT, to another node. Decentralizing a directory in this way enables you to balance the workload between servers and build a highly available distributed directory, complete with fault tolerance and failover. You can set up partial replication by using command-line tools or the Replication Wizard in Oracle Enterprise Manager. Partial replication is most often LDAP-based.

Figure 6-2 shows an example of partial replication.

Figure 6-2 Example of Partial Replication

This illustration is described in the text.

6.2.2 Direction: One-Way, Two-Way, or Peer to Peer

The direction of replication can be one-way, two-way or peer-to-peer:

Table 6-2 Direction of Replication

Direction Description


One node is configured as the supplier and the other as the consumer. The consumer is read-only.


Both nodes are both supplier and consumer. They are both read/write, or updatable.


All nodes in a replication group are both supplier and consumer to all other nodes

Sometimes the terms read-only and read/write are used to describe direction of replication. In a one-way replication agreement, the consumer node is said to be read-only. That is, you cannot propagate changes to other nodes by writing to that node. In a two-way replication agreement, both nodes are considered to be read/write. Another term for read/write is updatable.

Sometimes the term multimaster is used instead of peer-to-peer. Multimaster actually refers to the type of replication group, as described in "Directory Replication Group (DRG) Type: Single-master, Multimaster, or Fan-out".

6.2.3 Transport Mechanism: LDAP or Oracle Database Advanced Replication

Oracle Internet Directory supports two protocols you can use for replicating data from one node to another. The protocols are:

Table 6-3 Transport Protocols

Transport Mechanism Description


Uses the industry-standard Lightweight Directory Access Protocol Version 3. This is the recommended protocol to use for replication, unless you are also performing Oracle Single Sign-On replication.

Oracle Database Advanced Replication

Uses the replication feature of Oracle Database. Also called Advanced Replication. This replication protocol is currently required for Oracle Single Sign-On replication.

LDAP replication can be configured as peer-to-peer, one-way or two-way. Advanced Replication is usually peer-to-peer.

6.2.4 Directory Replication Group (DRG) Type: Single-master, Multimaster, or Fan-out

The directory servers that participate in the replication of a given naming context form a directory replication group (DRG). The relationship among the directory servers in a DRG is represented on each node by a special directory entry called a replication agreement. A replication agreement can be either one-way or two-way.

Each copy of a naming context contained within a server is called a replica. A server that sends the updates made to it to other servers is known as a supplier. A server that accepts those changes is called a consumer. A server can be both a supplier and a consumer.

A directory replication group can be single-master, multimaster, or fan-out as described in Table 6-4.

Table 6-4 Types of Directory Replication Groups

Group Description


Has only one supplier replicating changes to one or more consumers. Clients can update only the master node, and can only read data on any of the consumers. This type of group typically uses LDAP. It is also possible to configure Advanced Replication as single-master, by switching all nodes in a group except one to read-only mode.


Enables multiple sites, acting as equals, to manage groups of replicated data. In a multimaster replication environment, each node is both a supplier and a consumer node. Multimaster replication can use either LDAP or Advanced Replication as its transport mechanism. The full DIT is replicated on each node. Replication is always peer-to-peer.


Also called a point-to-point replication group, has a supplier replicating directly to a consumer. That consumer can then replicate to one or more other consumers. Fan-out uses LDAP as its transport mechanism. The replication can be either full or partial. It can be either one-way or two-way. Single-Master Replication Example

Figure 6-3, "Example of Single-Master Replication" shows a single-master replication environment.

Figure 6-3 Example of Single-Master Replication

Description of Figure 6-3 follows
Description of "Figure 6-3 Example of Single-Master Replication"

In Figure 6-3, each bullet represents a node of Oracle Internet Directory. Node A is a supplier that replicates consumer nodes B and C. Node A is read/write, and Nodes B and C are read-only. The data transfer protocol is LDAP. Multimaster Replication Example

The example in Figure 6-4 shows three nodes—A, B, and C—that update each other in a multimaster replication group. Replication between nodes is two-way.

Figure 6-4 Example of Multimaster Replication

Description of Figure 6-4 follows
Description of "Figure 6-4 Example of Multimaster Replication"

In Figure 6-4, all replication is two-way.


Multimaster replication is the only replication mechanism supported in Oracle Single Sign-On, as described in the section "Configuring Oracle Single Sign-On for Replication" in the chapter on high availability in the Oracle Application Server Single Sign-On Administrator's Guide in the 10g ( library. Fan-out Replication Example

Figure 6-5 shows a fan-out replication environment.

Figure 6-5 Example of Fan-Out Replication

Description of Figure 6-5 follows
Description of "Figure 6-5 Example of Fan-Out Replication"

In Figure 6-5, supplier A replicates to two consumers, B and C. Consumer node B contains a partial replica of A, whereas consumer node C contains a full replica of A.

Each of these nodes, in turn, serves as a supplier that replicates data to two other consumers: Node B partially replicates to nodes D and E, and node C fully replicates to nodes F and G. Nodes D and F are read-only.

In fan-out replication, nodes transfer data by using LDAP.

6.2.5 Loose Consistency Model

Directory replication architecture is based on a loose consistency model: Two replicated nodes in a replication agreement are not guaranteed to be consistent in real time. This increases the overall flexibility and availability of the directory network, because a client can modify data without all interconnected nodes being available. Suppose, for example, that one node is unavailable or heavily loaded. With multimaster replication, the operation can be performed on an alternate node, and all interconnected nodes synchronize in due course.

6.2.6 How the Replication Concepts Fit Together

Table 6-5 shows each of the two transport mechanisms, LDAP and Oracle Database Advanced Replication, and describes how each type can be combined with other replication concepts.

Table 6-5 Types of Data Transfer Between Nodes in a Directory Replication Group

Concept LDAP-Based Replication Oracle Database Advanced Replication-Based Replication

Content replicated

Full replica

Partial replica

Full replica (usually)

Direction of replication





DRG Type

Multimaster replication

Single-master replication

Fan-out replication

Multimaster replication

Single-master replication, by switching all masters in a multimaster configuration except one to read-only mode.

6.2.7 Multimaster Replication with Fan-Out

Oracle Internet Directory enables any node in a multimaster replication group to also participate in a fan-out replication agreement. Within the multimaster replication agreement, data transfer between the nodes occurs by way of Oracle Database Advanced Replication or LDAP. Within the fan-out replication agreement, data transfer from supplier to consumer occurs by way of LDAP and can be either one-way or two-way.

Figure 6-6 shows an example of multimaster replication used with fan-out replication.

Figure 6-6 Example of Multimaster Replication with Fan-Out

This illustration is described in the text.

In the example in Figure 6-6, nodes A, B, and C form a multimaster replication group. They transfer data among them by using either LDAP or Advanced Replication.

Node B supplies changes to Node D, a replica of the entire directory. Node D, in turn, supplies changes to Nodes F and G by using LDAP-based replication. Both Nodes F and G are replicas of the entire directory. Similarly, Node E is a full replica of Node C. Node E, in turn supplies changes to Node H, a replica of the entire directory, and Node I, a partial replica, by using LDAP-based replication. Nodes F and H are read-only.

See Also:

"LDAP-Based Replication" on page 29-23 for more information about fan-out replication

6.3 What Kind of Replication Do You Need?

The type of replication you need depends on the features that are important in your enterprise. This section discusses the types of replication to use to achieve three features: local availability, load balancing, and high availability

Local Availability

Local availability is important in the following situations:

If the local site does not update the data, use one-way replication from master node to local nodes

If the local site does need to update the data and the updates must be replicated back to the master site, use two-way replication between master node and local nodes.

Load Balancing

Load Balancing is important in the following situations:

You can use LDAP multi-master replication to replicate the data between two or more nodes. If Oracle Single Sign-On10g ( or later is also installed and Oracle Single Sign-On schema must be replicated for load balancing, use Oracle Database Advanced Replication-based multimaster replication. Otherwise, you can use LDAP-based multimaster replication.


When you configure a load balancer for use with replication, use sticky routing and not round-robin routing. Replication is asynchronous in nature, so changes made on one node are not available immediately on the other nodes.

High Availability

High availability is important in the following situations:

Usually, you can use LDAP-based multimaster replication to replicate the data between two or more nodes. If Oracle Single Sign-On 10g ( or later is also installed along with Oracle Internet Directory, however, then use Oracle Database Advanced Replication-based multimaster replication.