|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
 Previous |
 Next |
|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
|
Previous |
Next |
This chapter describes Oracle Internet Directory replication. It contains these topics:
This section briefly introduces some of the basic concepts of replication. Subsequent sections in this chapter explain these concepts in further detail.
Replication is the process of copying and maintaining the same naming contexts on multiple directory servers. It improves performance by providing more servers to handle queries, and reliability by eliminating risks associated with a single point of failure.
Replication can be either full or partial. Full replication involves propagating the entire DIT to another node. Partial replication involves propagating one or more subtrees, rather than the entire DIT, to another node.
The directory servers that participate in the replication of a given naming context form what is called 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.
Each copy of a naming context contained within a server is called a replica. Replicas can be read-only, updatable, or both. 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 24-1.
Table 24-1 Types of Directory Replication Groups
| Group | Description |
|---|---|
|
Single-master |
Has only one supplier replicating changes to one or more consumers. Only the supplier can be updated, and consumers are read-only. |
|
Also called peer-to-peer or n-way replication, 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, and the entire directory is replicated on each node. |
|
|
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. The replication can be either full or partial. |
In a directory replication group, the protocol for transferring data between nodes can be based on either Oracle Database Advanced Replication or LDAP.
This section contains these topics:
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 Oracle Database Advanced Replication or LDAP.
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. Because it brings data closer to the client, partial replication reduces response time and improves performance. You can configure partial replication by using the Replication Environment Management Tool.
Partial replication is LDAP-based only. It does not use Oracle Database Advanced Replication.
Figure 24-1, "Example of Partial Replication" shows an example of partial replication.
In a partial replication scenario, one or more naming contexts, but not the entire directory, are replicated. For example, in Figure 24-1, "Example of Partial Replication", Server 1 contains three naming contexts: A, B, and C. Naming contexts B and C are replicated to Server 2, but naming context A is not.
Table 24-2 compares the two types of replication.
Table 24-2 Comparison of Full and Partial Replication
| Full Replication | Partial Replication |
|---|---|
|
Propagates an entire directory to other nodes |
Propagates just part of the directory—for example, one or more, but not all, naming contexts—to other nodes |
|
In a multimaster environment, allows a consumer to receive changes from more than one supplier |
In a single-master environment, allows a consumer to receive changes from only one supplier |
This section contains these topics:
In a directory replication group, the protocol for transferring data can be based on either Oracle Database Advanced Replication or LDAP. Table 24-3 shows how each type handles various features of replication and points to sections of this chapter with more details.
Table 24-3 Types of Data Transfer Between Nodes in a Directory Replication Group
| Feature | LDAP-Based Replication | Advanced Replication | More Information |
|---|---|---|---|
|
Change propagation |
Change propagation from supplier to consumer happens over LDAP |
Change propagation from supplier to consumer happens by using Advanced Replication |
"Change Logs in Directory Replication" |
|
Replica type supported |
Read-only full replica Read-only partial replica |
Read/write full replica |
"Partial Directory Replication" |
|
Configuration supported |
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. |
"Single-Master Replication Groups" "Multimaster Replication Groups" |
A single-master replication group has only one supplier replica supplying changes to one or more consumers. Clients can update only the master replica, and can only read data on any of the consumers.
Figure 24-2, "Example of Single-Master Replication" shows a single-master replication environment.
Figure 24-2 Example of Single-Master Replication
In Figure 24-2, 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.
A multimaster replication group, also called a peer-to-peer or n-way replication group, has two or more nodes acting as equals to manage groups of replicated data. In a multimaster replication group, each directory server is both a supplier and a consumer of changes, and the entire directory is replicated on each node.
The example in Figure 24-3 shows three nodes—A, B, and C—that update each other in a multimaster replication group.
Figure 24-3 Example of Multimaster Replication
In Figure 24-3, each node is read/write, and the data transfer protocol is based on Advanced Replication.
|
Note: Multimaster replication is the only replication mechanism supported in Oracle Application Server Single Sign-On as described in the section "Configuring Oracle Application Server Single Sign-On for Replication" in the chapter on high availability in the Oracle Application Server Single Sign-On Administrator's Guide |
A fan-out replication group, also called a point-to-point replication group, has a supplier replicating directly to a consumer. That consumer can then supply the same data to one or more other consumers. The replication can be either full or partial.
Figure 24-4 shows a fan-out replication environment.
Figure 24-4 Example of Fan-Out Replication
In Figure 24-4, 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. Both consumer nodes B and C are read-only.
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.
In fan-out replication, nodes transfer data by using LDAP.
Table 24-4 compares multimaster, single-master, and fan-out replication.
Table 24-4 Multimaster. Single-Master, and Fan-Out Replication Compared
| Multimaster Replication | Single-Master Replication | Fan-out Replication |
|---|---|---|
|
Uses only Advanced Replication |
Uses LDAP-based replication or Advanced Replication (by switching all masters in a multimaster configuration except one to read-only mode). |
Uses LDAP-based replication |
|
Updates can be made on any node, whether supplier or consumer. |
Updates can be made on the supplier only. Changes to a consumer can be propagated to other fan-out consumers, but not back to the supplier. |
Updates can be made on the supplier only. Changes to a consumer can be propagated to other fan-out consumers, but not back to the supplier. This is also true when the LDAP-based replica node is read/write. |
Beginning with Oracle Internet Directory 10g (9.0.4), Oracle Internet Directory enables any node in a multimaster replication group to supply all or part of its data to a read-only consumer. This consumer can, in turn, supply data to other consumers in a fan-out configuration. Within the multimaster replication agreement, data transfer between the nodes occurs by way of Oracle Database Advanced Replication. Within the fan-out replication agreement, data transfer from supplier to consumer occurs by way of LDAP.
|
Note: If an LDAP-based replica is read/write, then changes on this node propagate to consumers, but not to suppliers. |
Figure 24-5 shows an example of multimaster replication used in conjunction with fan-out replication.
In the example in Figure 24-5, nodes A, B, and C form a multimaster replication group. They transfer data among them by using Advanced Replication.
Node B supplies changes to Node D, a read-only 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 read-only replicas of the entire directory. Similarly, Node E is a one-way full replica of Node C. Node E, in turn supplies changes to Node H, a read-only replica of the entire directory, and Node I, a read-only partial replica, by using LDAP-based replication.
In LDAP-based replication, you can include a given naming context for replication and exclude one or more of the subtrees within that naming context from replication. You can also exclude from replication one or more of the attributes in that naming context.
In Oracle Database Advanced Replication, you can only exclude naming contexts.
In LDAP-based replication, only naming contexts explicitly specified as included are replicated. In Oracle Database Advanced Replication, however, all naming contexts are included by default. To exclude a naming context from replication in Oracle Advanced Replication, specify it using the orclexcludednamingcontext attribute of the Oracle-Advanced-Replication-based-replication agreement entry orclagreementid=000001.
Figure 24-6 and the accompanying text further exemplify the use of the naming context container and its objects.
In Figure 24-6, the naming context included for replication is c=us. Within that naming context, one subtree, namely cn=user1,cn=hr, c=us is excluded from replication. Moreover, two of the attributes of the c=us naming context are excluded from replication—namely, userPassword and telephonenumber.
A replication agreement is a special entry containing information about the relationship among servers in a DRG. In Oracle Internet Directory, all such entries reside under the container entry cn=replication configuration located at the root DSE. This entry resides on each node in a DRG, and contains all replication information for that node.
There are two kinds of replication agreements: those for Oracle Database Advanced Replication groups, and those for LDAP-based replication groups.
This section contains these topics:
For a multimaster replication group, replication agreements are based on Advanced Replication. The replication agreement on each node lists all of the nodes in the group. It is identical on each node except for local options such as partitioned naming contexts on the local directory server.
The entry for this kind of replication agreement resides immediately below the cn=replication configuration container entry. For example, the DN of such an agreement can look like this: orclagreementID=000001,cn=replication configuration.
Unlike multimaster replication groups, in fan-out replication groups there is one replication agreement for each supplier-consumer relationship.
The entry for this kind of replication agreement resides immediately below the replica subentry of the node that serves as the supplier. Thus, the DN of the replication agreement as found on a supplier node is:
orclagreementID=unique_identifier_of_the_replication_agreeement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration
Similarly, the DN of the replication agreement as found on a consumer node is:
orclagreementID=unique_identifier_of_the_replication_agreeement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration
In a fan-out replication agreement, you can tell which node the agreement entry is associated with by looking at its parent. For example, look at the following replication agreement entry.
orclagreementID=000002,orclReplicaID=node_A,cn=replication configuration
In this example, you can determine that the replication agreement represented by orclagreementID=000002 is associated with node A. This is because the parent of orclagreementID=000002 is orclReplicaID=node_A.
|
Note: The container entrycn=replication configuration is replicated on all nodes, but may not be identical on all nodes.
|
|
Note: Theorclreplicadn attribute of an LDAP-based replication agreement specifies the associated consumer node.
|
This section describes the objects in the directory that contain replication configuration information. It contains these topics:
All replication information for a node resides in the container cn=replication configuration located at the root DSE. This entry resides on each node in a DRG. The following is a sample replication configuration container entry:
dn: cn=replication configuration orclaci: access to entry by * (browse) orclaci: access to attr=(*) by * (search,read) orclnormdn: cn=replication configuration cn: replication configuration description: Replication agreement Container object objectclass: top objectclass: orclcontainerOC
This subentry is created at installation under the replication configuration container. It contains attributes that identify and define the characteristics of the node it represents.
This subentry is associated with the object class orclReplicaSubentry. It contains the attribute orclreplicaID whose value specifies the name of the replica subentry. It is unique to each directory node. The local replica entry's orclreplicaID matches that of the orclreplicaID attribute at the root DSE. For example, inFigure 24-9 , a replica subentry is represented by orclReplicaID=UID_of_node_D,cn=replication configuration. The following is a sample replica subentry:
dn: orclreplicaid=myhost1_repl1,cn=replication configuration objectclass: top objectclass: orclreplicasubentry orclreplicaid: myhost1_repl1 orclreplicauri: ldap://myhost1:3060/ orclreplicasecondaryuri: ldap://myhost1.mycompany.com:3060/
|
See Also: ""Replication Schema Elements" in Oracle Identity Management User Reference for descriptions of the attributes of the replica subentry. |
This entry contains attributes that define the replication agreement between the two or more nodes and is associated with the orclReplAgreementEntry objectclass. There are two kinds of agreement:
Oracle Database Advanced Replication Agreement. The replication agreement for Oracle Database Advanced Replication nodes resides under the replication configuration entry. For example: In Figure 24-8, an Oracle Database Advanced Replication agreement entry is represented by orclagreementID=000001.
LDAP-based replication agreement. The replication agreement for LDAP nodes resides under the supplier's replica subentry. For example, in Figure 24-9, an LDAP-based replication agreement entry is represented by orclagreementID=000003, orclReplicaID=UID_of_node_D,cn=replication configuration.
The following is a sample replication agreement entry:
dn: orclagreementid=000002,orclreplicaid=myhost1_repl1, cn=replication configuration orclagreementid: 000002 orclupdateschedule: 1 orclreplicationprotocol: ODS_LDAP_1.0 orcllastappliedchangenumber: 0 orclhiqschedule: 10 orclreplicadn: orclreplicaid=myhost2_repl2,cn=replication configuration orclldapconnkeepalive: 1 objectclass: orclReplAgreementEntry objectclass: top
|
See Also: "Replication Schema Elements" in Oracle Identity Management User Reference for descriptions of the attributes of the replication agreement entry |
This entry contains all the LDAP naming context objects.
This entry has the RDN cn=replication namecontext, and it is created below the orclagreementID entry during replication configuration. The following is a sample replication naming context container entry:
dn: cn=replication namecontext,orclagreementid=000002, orclreplicaid=myhost1_repl1,cn=replication configurationobjectclass: top objectclass: orclcontainerOC cn: replication namecontext
This entry contains all the LDAP naming context objects. These objects specify what is to be either included in or excluded from replication to an LDAP-based partial replica.
This entry is created below the naming context container entry during replication configuration. It is configurable. For example, in Figure 24-9 , the replication naming context object is cn=namingcontext001,cn=replication namecontext,orclagreementID=000003,orclReplicaID=UID_of_node_D,cn=replication configuration
A replication naming context contains these attributes:
orclincludednamingcontexts—The root of the naming context to be replicated
orclexcludednamingcontexts—Within the included naming context, the root of a subtree to be excluded from replication
orclexcludedattributes—Within the included naming context, an attribute to be excluded from replication
|
See Also: "Replication Schema Elements" in Oracle Identity Management User Reference for descriptions of the attributes in the replication naming context entry |
The following is a sample replication naming context object entry.
dn: cn=includednamingcontext000001,cn=replication namecontext, orclagreementid=000002,orclreplicaid=myhost1_repl1,cn=replication configuration objectclass: orclreplnamectxconfig objectclass: top orclincludednamingcontexts: c=us orclexcludednamingcontexts: cn=groups,c=us orclexcludedattributes: userPassword orclexcludedattributes: telephonenumber cn: includednamingcontext000001
The examples of replication objects in this section rely on the replication environment shown in Figure 24-7.
In Figure 24-7, nodes A, B, and C form a multimaster replication group. Node C replicates to a fourth node, D, which, in turn, fans out to Node E.
The replication agreements in this environment are as follows:
Node A has one replication agreement representing its multimaster relationship with nodes B and C.
Node B has one replication agreement representing its multimaster relationship with nodes A and C.
Node C has two replication agreements, the first representing its multimaster relationship with nodes A and B, the second representing its relationship to node D in which it serves as the supplier and node D is the consumer.
Node D has two replication agreements, one representing its relationship to the supplier node C, from which it consumes changes, the other representing its relationship to consumer node E for which it is the supplier.
Figure 24-8 shows the replication objects in the DIT that pertain to node C in Figure 24-7 .
For node C, the entry cn=replication configuration at the root DSE contains these RDNs:
orclagreementID=000001: The multimaster replication agreement in which node C participates with nodes A and B.
orclReplicaID=UID_of_node_C: Unique identifier of node C that contains information about it.
orclagreementID=000002: Unique identifier of the relationship between supplier node C and consumer node D. You know that, in this case, orclagreementID=000002 is the replication agreement of the supplier node C because node C is its parent.
This entry contains the attribute orclreplicaDN. Its value is the replica entry DN of consumer node D, with which node C has the replication agreement.
cn=replication DN: The bind DN that the directory replication server on node C uses to bind to the directory server.
cn=replication namecontext: Container of information about naming contexts that are included in replication.
cn=namingcontext001 and cn=namingcontext002: The actual objects that are included in or excluded from replication. In the naming context included for replication, you can specify one or more subtrees to be excluded from replication. In that same included naming context, you can specify particular attributes to be excluded from replication.
Figure 24-9 shows the replication agreement entry in the DIT that pertains to node D in Figure 24-7.
For node D, the entry cn=replication configuration at the root DSE contains these RDNs:
orclReplicaID=UID_of_node_D: Unique identifier of node D and contains information about it.
orclagreementID=000003: Unique identifier of the relationship between supplier node D and consumer node E. You know that, in this case, orclagreementID=000003 is the replication agreement of the supplier node D because node D is its parent.
This entry contains the attribute orclreplicaDN, the value of which is the DN of consumer node E with which node D has the replication agreement.
cn=replication DN: Bind DN that the directory replication server on node D uses to bind to the directory server.
cn=replication namecontext: Container of information about naming contexts that are included in replication.
cn=namingcontext001 and cn=namingcontext002: Objects specifying naming contexts to be included in replication. In the naming context included in replication, you can specify one or more subtrees or particular attributes to be excluded from replication.
This section contains these topics:
Authentication is the process by which the Oracle directory replication server establishes the true identity of itself when connecting to the directory server. It occurs when an LDAP session is established by means of an ldapbind operation.
It is important that the directory replication server be properly authenticated before it is allowed access to the directory.
The directory replication server uses a unique identity and a password to authenticate with the directory server. The identity of the directory replication server is of the form cn=replication dn,orclreplicaid=unique_identifier_of_node,cn=replication configuration.
When it starts, the directory replication server reads its identity and password from an Oracle Internet Directory secure wallet, and uses these credentials for authentication. If you want to change the password for the replication bind DN, then you must use the -pchgpwd, -presetpwd, or -pchgwalpwd option of the Replication Environment Management Tool. The wallet for replication identity is located at $ORACLE_HOME/ldap/admin/oidpwdrOracle_SID.
|
Note: In earlier releases, the replication server required the directory server to allow anonymous bind. The replication server no longer requires that. |
You can deploy Oracle Internet Directory replication with or without SSL. Replication automatically detects if the target Oracle Internet Directory instance is running at an SSL port. When the replication server binds to the SSL port of an Oracle Internet Directory instance, it will automatically work on top of the Secure Sockets Layer.
|
Note: In Oracle Internet Directory 10g Release 2 (10.1.2), the Oracle directory replication server cannot communicate directly with an SSL-enabled LDAP server that supports two way (mutual) authentication. The replication server startup will fail and hang if the LDAP server is configured for SSL mutual authentication. |
To configure LDAP-based replication to use SSL encryption, in the orclReplicaURI attribute, which contains the supplier contact information, specify the port number of the SSL port.
To configure Advanced Replication to use SSL encryption, use Oracle Advanced Security.
|
See Also: Oracle Advanced Security Administrator's Guide for information on how to configure Advanced Replication to use SSL encryption |
Oracle Internet Directory records each change as an entry in the change log store. The directory replication server of the consumer retrieves changes residing in the change log store of the supplier and applies them to the consumer.
Each entry in the change log store—that is, each change log object—has a unique change number. The consumer keeps track of the change number of the last change it applied, and it retrieves from the supplier only those changes with numbers greater than that of the last change it applied.
In an LDAP-based replication agreement, the directory replication server stores the last change number it applied in the orlclastappliedchangenumber attribute of the replication agreement entry.
In a replication agreement based on Advanced Replication, the directory replication server stores the last change number it applied in the changenumber attribute of the changestatus entry. This entry looks like this: changenumber=last_applied_change_number, supplier=supplier_node,consumer=consumer_node. For example, if the last change a consumer applied had a number of 250, then subsequent changes it retrieves from that supplier would need to have numbers greater than 250.
Change logs are purged by the garbage collector after they have been consumed by the replication server.
This section gives a detailed look at multimaster replication. A multimaster directory replication group has multiple nodes acting as equals to manage groups of replicated data. This section contains these topics:
In Oracle Database Advanced Replication, the transport of update information between nodes in a replication agreement is managed by Oracle Database Advanced Replication, a store-and-forward transport feature. Advanced Replication enables you to synchronize database tables across two Oracle databases.
Oracle Database Advanced Replication:
Stores local changes and periodically propagates them in batches to consumers. The consumer replication servers apply the remote changes to their own local directory servers, and then purge the applied remote changes from their local stores.
Enables read and update access to directory tables anywhere in the Oracle replication group. Typical Advanced Replication configurations use row-level replication.
Provides proven network tolerance. Data transfer can be controlled and monitored by Oracle Enterprise Manager 10g Application Server Control Console. Such manageability allows a high degree of flexibility in how the data transfer is scheduled.
|
Note: The Oracle Application Server Single Sign-On database schema that resides in the same database as Oracle Internet Directory is also replicated by using Advanced Replication. |
|
See Also:
|
Typical Oracle Database Advanced Replication configurations use asynchronous data propagation—that is, suppliers write their changes to change logs, and then regularly send batched changes to other consumers. Consumers 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 a remote master site (RMS), where 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.
Figure 24-10 and its accompanying text explain what happens on the supplier side during the multimaster replication process.
An LDAP client issues a directory modification.
The Oracle directory server generates a change log object in the change log object store.
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.
When a change entry is committed to the change log table, Advanced Replication immediately copies the change into the deferred transaction queue.
After a scheduled interval, Advanced Replication pushes pending transactions from the deferred transaction queue across the network to the consumer change log table.
|
Note: All changes made to Oracle Application Server Single Sign-On tables by the single sign-on administrator application are also replicated by Advanced Replication. |
Figure 24-11 and its accompanying text explain the multimaster replication process on the consumer side.
A change arrives in the consumer change log table from the supplier.
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.
The Oracle directory replication server then fetches and applies all the new changes from the change log table to the Oracle directory server.
The Oracle directory replication server then updates the change status table to record the last change applied from the supplier before exiting.
Advanced Replication copies the change status update into the deferred transaction queue.
After the scheduled Advanced Replication interval, Oracle Database Advanced 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 those that are dropped as candidate changes. Remote change records in the local change log table are purged by the garbage collection thread if they have been applied locally. Local change records in the local change log table are purged by the garbage collection thread if they have been distributed to all the consumers.
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, for some reason, fails.
There are times when the replication process may not be able to apply a change. For example, suppose that Supplier Node A sends the consumer a change, and, immediately after that, Supplier Node B sends the consumer an update to the same entry. Then, suppose that a problem delays the transmission of the entry from Supplier Node A, but that no such problem delays transmission of the update from Supplier Node B. The result can be that the update from Supplier Node B arrives at the consumer ahead of the entry it is modifying. In this case, the replication server makes a specified number of retries to apply the change. If it fails to apply the change once that number is reached, then it moves the change to the human intervention queue, and attempts to apply the change at regular, less frequent intervals that you specify.
LDAP operations that can lead to conflicts include:
Addition
Deletion
Modification
Modification of either an RDN or a DN
There are two types of conflicts:
Entry-level conflicts
Attribute-level conflicts
Table 24-5 Types of Replication Conflict
| Level of Replication Conflict | Description |
|---|---|
|
Entry-level conflicts |
Caused when the directory replication server attempts to apply a change to the consumer. One of the following types of changes to the consumer could occur:
These conflicts can be difficult to resolve. For instance, it may be impossible to resolve a conflict because:
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 |
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. |
Conflicts usually stem from differences in 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.
The directory replication server attempts to resolve all conflicts that it encounters by following this process:
The conflict is detected when a change is applied.
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.
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 multivalued 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:
|
This section gives a more detailed look at fan-out and partial replication.
In fan-out replication, a consumer replicates data directly from a supplier. That consumer can then be a supplier to one or more other consumers.
Figure 24-12 and its accompanying text explain the fan-out replication process.
As Figure 24-12 shows:
An LDAP client issues a directory modification request to the directory on the supplier node.
The Oracle directory server on the supplier node performs the required modification in the directory store and simultaneously updates the change log store.
The directory replication server on the consumer node retrieves changes from the directory server on the supplier node and applies them to the directory server on the consumer.
At the same time, the directory server on the consumer does the following:
It makes the required modification, replicating the change in its directory store
If the orcldiprepository attribute of its root DSE is TRUE it generates a shadow change log object in its change log store. This attribute is set to TRUE if the objects in this change log store are to be propagated to other fan-out consumers. It is also set to TRUE if the objects are to be propagated to other third party applications by the Oracle Directory Integration Platform server.
It updates the value of the orcllastappliedchangenumber attribute in the replication agreement entry to correspond to the number of the last change from the supplier node that it has applied
|
See Also: "Change Logs in Directory Replication" for more information about theorcllastappliedchangenumber attribute
|
The following naming contexts cannot be replicated:
DSE root-specific entry
orclagreementid=000001,cn=replication configuration
cn=subconfigsubentry
cn=Oracle Internet Directory
cn=subregistrysubentry
The following naming contexts cannot be excluded from replication:
cn=catalogs
cn=subschemasubentry
cn=oracleschemaversion
cn=replication configuration
This section describes rules and best practices to follow when specifying naming contexts in partial replication. The discussion in this section relies on the sample naming context illustrated in Figure 24-13. A partial list of user attributes is shown under cn=user1, cn=user2, and cn=user1000.
|
See Also: "Replication Schema Elements" in Oracle Identity Management User Reference for descriptions of the attributes in the replication naming context entry |
When two or more naming context objects are configured for replication, the filtering rules are as follows:
The overall included naming context is the union of all included naming contexts defined in each naming context object.
The overall excluded naming contexts is the union of all excluded naming contexts defined in each naming context object.
The attribute exclusions in a naming context object are specific only to that naming context object.
If there is a conflict between an included naming context and an excluded naming context, the excluded naming context overrules the included naming context. For example, if an included naming context in naming context object A is a subtree of an excluded naming context specified in another naming context object, B, the subtrees specified in orclexcludednamingcontexts of naming context object B will not be replicated. That is, replication filtering in naming context object A will be ignored.
The following examples show how these rules work:
Scenario A: The Included Naming Context in One Naming Context Object Is a Subtree of the Included Naming Context in Another Naming Context Object
In this scenario, the included naming context in naming context object #2 is a subtree of the included naming context in object #1.
Naming Context Object #1
dn:cn=namectx001, cn=replication namecontext, orclagreementid=unique_identifier_of_the_replication_agreement, orclreplicaid=unique_identifier_of_the_supplier, cn=replication configuration
orclincludednamingcontexts: cn=mycompany
Naming context object #1 includes the entire DIT under cn=myCompany, as shown in Figure 24-14.
Naming Context Object #2
dn:cn=namectx002, cn=replication namecontext, orclagreementid=unique_identifier_of_the_replication_agreement, orclreplicaid=unique_identifier_of_the_supplier, cn=replication configuration
orclincludednamingcontexts: cn=hr,c=us,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #2 includes the DIT under cn=hr,c=us,cn=mycompany, but excludes cn=user1 and the attribute userPassword, as shown in Figure 24-15.
The result of combining naming context objects #1 and #2 is shown in Figure 24-16.
In this scenario, the naming context that is replicated is the highest one specified in the orclincludednamingcontexts attribute. Any excluded naming contexts are not replicated. All changes under the subtree cn=mycompany are replicated, except for cn=user1,cn=hr,c=us,cn=mycompany and the attribute userPassword under cn=hr,c=us,cn=mycompany, which are excluded. The attribute userPassword under the rest of the DIT, however, is not excluded from replication because exclusion of userPassword was specified only for naming context object #2, which only included the DIT under cn=hr.
Scenario B: The Included Naming Context in One Naming Context Object Is a Subtree of An Excluded Naming Context in Another Naming Context Object
In this scenario, the excluded naming context in naming context object #4 is a subtree of the excluded naming context defined in naming context object #3.
Naming Context Object #3
dn:cn=namectx001,cn=replication namecontext, orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts: cn=us,cn=mycompany
Naming context object #3 excludes everything under c=us,cn=mycompany, as shown in Figure 24-17
Naming Context Object #4
dn:cn=namectx002,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier, cn=replication configuration
orclincludednamingcontexts: cn=hr, c=us,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #4 includes the DIT under cn=hr,c=us,cn=mycompany but excludes user1, as well as the userPassword attribute for all users, as shown in Figure 24-18
The result of combining naming context objects #3 and #4 is shown in Figure 24-19.
In this scenario, the included naming context specified in naming context object #4 is not replicated. That naming context is a subtree of a specified excluded naming context in naming context object #3. In this case, naming context object #4 is ignored, and no changes under cn=hr,c=us,cn=mycompany are replicated.
The following naming contexts cannot be replicated:
DSE root-specific entry
orclagreementid=000001,cn=replication configuration
cn=subconfigsubentry
cn=Oracle Internet Directory
cn=subregistrysubentry
The following naming contexts cannot be excluded from replication:
cn=catalogs
cn=subschemasubentry
cn=oracleschemaversion
cn=replication configuration
The following attributes cannot be excluded from replication whether they are mandatory or optional. Even if you specify attributes in this list for exclusion from replication, they will always be replicated.
orclguid
creatorsname
createtimestamp
cn
dn
attributetypes
objectclasses
objectclass
orclindexedattribute
orclproductversion
You cannot exclude mandatory attributes from replication. For example, suppose that you have an object class named my_object_class, which includes the following attributes: mandatory_attribute_1, optional_attribute_1, and optional_attribute_2. In this case, you cannot exclude from replication mandatory_attribute_1.
If you attempt to exclude from replication an attribute that is required for the LDAP operation to be executed, replication will not occur.
If you are configuring partial replication from specific naming contexts in an Oracle Internet Directory node to fan-out replication nodes, then do not change the names of these naming context entries in the source node.
Partial replication will not replicate changes to the root entry of a naming context made by using ldapmoddn.
You must plan partial replication carefully to avoid degrading the performance of the replication process. For best performance, use as few naming context objects as possible. For example, the combined use of naming context objects #5 and #6 fulfills the same requirement as the use of naming context object #7, but using naming context object #7 provides better performance.
This section contains these examples:
Naming Context Object #5
cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts: c=europe,cn=mycompany orclexcludedattributes: userPassword
Naming context object #5 is shown it Figure 24-20. It includes the DIT under cn=mycompany, but excludes everything under c=europe. It also excludes the attribute userPassword.
Naming Context Object #6
cn=namectx002,cn=replication namecontext,orclagreementid=<id>,orclreplicaid=<supplier>,cn=replication configuration orclincludednamingcontexts: cn=hr, c=us,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #6 is shown in Figure 24-21. It includes the DIT under cn=hr, c=us, cn=mycompany but excludes user1 and the attribute userPassword.
If naming context objects #5 and #6 are combined, then all changes under cn=mycompany are replicated, except for cn=europe,c=mycompany, cn=user1,cn=hr,c=us,cn=mycompany, and the attribute userPassword.
You could fulfill the same requirement, however, by using naming context object #7. Using a single naming context object provides better partial replication performance.
Naming Context Object #7
cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts: c=europe,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #7 is shown in Figure 24-22.
