| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
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.
This chapter contains the following topics:
This section briefly introduces some basic concepts. Later sections describe these concepts in more detail.
This section contains the following topics:
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 29-1 Full or Partial Replication
| Content to Replicate | Description |
|---|---|
|
Propagates the entire DIT to another node. |
|
|
Partial |
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 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. You can configure partial replication by using the Replication Environment Management Tool. Partial replication is most often LDAP-based.
Figure 29-1 shows an example of partial replication.
The direction of replication is a property of the replication agreement you set up between nodes. It can be:
Table 29-2 Direction of Replication
| Direction | Description |
|---|---|
|
One-Way |
One node is configured as the supplier and the other as the consumer. The consumer is read-only. |
|
Two-Way |
Both nodes are both supplier and consumer. They are both read-write, or updateable. |
|
Peer-to-Peer |
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 updateable.
Oracle Internet Directory supports two protocols you can use for replicating data from one node to another. The protocols are:
Table 29-3 Transport Protocols
| Transport Mechanism | Description |
|---|---|
|
Oracle Advanced Database Replication |
Uses the replication feature of Oracle Database. Also called Advanced Replication. |
|
LDAP |
Uses the industry-standard Lightweight Directory Access Protocol Version 3 |
Advanced Replication is usually peer-to-peer. LDAP replication can be configured as either one-way or two-way
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 29-4.
Table 29-4 Types of Directory Replication Groups
| Group | Description |
|---|---|
|
Single-master |
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. In 10g (10.1.4.0.1), multimaster replication requires 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. |
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:
In a directory replication group, the protocol for transferring data can be based on either Oracle Database Advanced Replication or LDAP. Table 29-5 shows how each type handles various features of replication and points to sections of this chapter with more details.
Table 29-5 Types of Data Transfer Between Nodes in a Directory Replication Group
| Feature | LDAP-Based Replication | Advanced Replication |
|---|---|---|
|
Change propagation |
Change propagation from supplier to consumer uses LDAP |
Change propagation from supplier to consumer uses Advanced Replication |
|
Content replicated |
Full replica Partial replica |
Full replica (usually) |
|
Direction of replication |
One-way Two-way |
Peer-to-peer |
|
Deployment Configuration |
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. |
A single-master replication group has only one supplier replica supplying changes to one or more consumers. All replication agreements are one-way, from the supplier to the consumer. Clients can update only the master replica, and can only read data on any of the consumers.
Figure 29-2, "Example of Single-Master Replication" shows a single-master replication environment.
Figure 29-2 Example of Single-Master Replication
In Figure 29-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 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 29-3 shows three nodes—A, B, and C—that update each other in a multimaster replication group. Replication between nodes is two-way.
Figure 29-3 Example of Multimaster Replication
In Figure 29-3, all replication is two-way, 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 and either one-way or two-way.
Figure 29-4 shows a fan-out replication environment.
Figure 29-4 Example of Fan-Out Replication
In Figure 29-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.
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.
Table 29-6 compares multimaster, single-master, and fan-out replication.
Table 29-6 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, and will be propagated to all other nodes |
Updates can be made on the master node (supplier) only and will be replicated to all other read-only/consumer replicas. |
For one-way fan-out, updates can only be made on the supplier replica and will be replicated to the consumer replica.For two-way fan-out, updates can only be made on either replica and will be replicated to the other replica. |
Oracle Internet Directory enables any node in a multimaster replication group to also participate in an LDAP-based replication agreement. The node it connects to using LDAP can, in turn, supply data to other nodes 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. The LDAP replication agreements can be either one-way or two-way.
|
Note: If an LDAP-based replica is read/write, then changes on this node propagate to consumers, but not to suppliers. |
Figure 29-5 shows an example of multimaster replication used in conjunction with fan-out replication.
In the example in Figure 29-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 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.
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. Table 29-7 describes the attributes of the replica subentry.
Table 29-7 Attributes of the Replica Subentry
| Attribute | Description |
|---|---|
|
|
Naming attribute for the replica subentry. Its value is unique to each directory server node that is initialized at installation. The value of this attribute, assigned during installation, is unique to each directory node, and matches that of the orclreplicaID attribute at the root DSE. You cannot modify this value. |
|
|
Contains information in ldapURI format that can be used to open a connection to this replica. |
|
|
Contains the set of |
|
|
Defines the type of replica such as read-only or read/write. Possible values are:
|
|
|
Defines the state of the replica. See Appendix H, "LDAP Replica States" for more information. |
In Figure 29-8 , 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/ orclreplicastate: 1
|
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 29-7, 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 29-8, an LDAP-based replication agreement entry is represented by orclagreementID=000003, orclReplicaID=UID_of_node_D,cn=replication configuration.
Table 29-8 shows the attributes in the replication agreement.
Table 29-8 Attributes of the Replication Agreement Entry
| Attribute | Description |
|---|---|
|
|
Naming attribute for the replication agreement entry. You cannot modify this attribute. |
|
|
For LDAP-based replication only. Specifies the DN of the replica to identify a consumer in the replication agreement. You cannot modify this attribute. |
|
|
Define the replication protocol for change propagation to replica. Values:
You cannot modify this attribute. |
|
|
For Advanced Replication-based groups, the orclreplicaid values of all the nodes in this replication group. This list must be identical on all nodes in the group. You can modify this attribute. This attribute is not applicable for LDAP-based agreement. |
|
|
Replication update interval for new changes and those being retried. The value is in minutes. You can modify this attribute. |
|
|
The interval, in minutes, at which the directory replication server repeats the change application process. You can modify this attribute. |
|
|
Attribute determining whether the connections from the directory replication server to the directory server is kept active or established every time the changelog processing is done based on various schedules. You can modify this field. |
|
|
This is the last change number transported or applied at the consumer replica. For LDAP-based agreements, this attribute contains subtypes that specify the phase of changelog processing and the direction of replication that this change number represents The format is: orcllastappliedchangenumber; status_type$supplier_replicaID$consumer_replicaID: Number The status_type indicates the phase of changelog processing represented by this
The supplier_replicaID and consumer_replicaID indicate the direction of LDAP data flow represented by this
This attribute is applicable to Advanced Replication-based agreements, but only the base type is used.You cannot modify this attribute. |
|
|
The value for this multivalued attribute specifies one or more subtrees to be excluded from replication. This attribute is applicable to Advanced Replication-based agreements. LDAP replication uses the Replication Naming Context Entry, described, in Table 29-9. You can modify this attribute. |
|
|
Unique identifier of a one-way, two-way, or peer-to-peer replication group |
|
|
Identifier of replication agreement. There are three kinds of replication agreement:
|
|
|
Reserved for future use |
|
|
Batch size limit for the number of changelogs to be processed at a time |
For 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.
For LDAP-based replication, there are separate replication agreements for each supplier-consumer relationship. For one-way replication, there is a single, one-way replication agreement.
The entry for an LDAP-based 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_agreement, 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. |
For two-way replication, there can be either a single, two-way replication agreement or two one-way agreements for each supplier-consumer relationship. The following is a sample two-way replication agreement entry:
dn: orclagreementid=000002, orclreplicaid=stadd58, cn=replication configuration orclagreementid: 000002 orclreplicationprotocol: ODS_LDAP_1.0 orclreplicadn: orclreplicaid=stadd57,cn=replication configuration orclldapconnkeepalive: 1 orclagreementtype: 1 orclreplicationid: 000002 orcllastappliedchangenumber;transport$stadd57$stadd58: 106 orcllastappliedchangenumber;transport$stadd58$stadd57: 2421 orcllastappliedchangenumber;apply$stadd57$stadd58: 106 orcllastappliedchangenumber;apply$stadd58$stadd57: 2421 orclupdateschedule: 0 orclhiqschedule: 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 the replication filtering policy, that is, what to include in or exclude from replication to an LDAP-based partial replica.
|
Note: You cannot include naming contexts or exclude attributes in Advanced Replication-based agreements. Advanced Replication agreements use the base attributeorclexcludednamingcontexts described in Table 29-8. |
This entry is created below the naming context container entry during replication configuration. It is configurable. For example, in Figure 29-8 , the replication naming context object is cn=namingcontext001,cn=replication namecontext,orclagreementID=000003,orclReplicaID=UID_of_node_D,cn=replication configuration
Table 29-9 Attributes of the Replication Naming Context Entry
| Attribute | Description |
|---|---|
|
The root of the naming context to be replicated. This attribute has subtypes that specify the replication direction in which the naming context should be included. The format is: orclincludednamingcontexts ; supplier_replicaID$consumer_replicaiD: DN
This is a single valued attribute. For each naming context object, you can specify only one unique subtree in each direction. In partial replication, except for subtrees listed in the orclexcluednamingcontexts attribute, all subtrees in the specified included naming context are replicated. You can modify this attribute. |
|
|
The root of a subtree, located within the included naming context, to be excluded from replication.This attribute has subtypes that specify the replication direction in which the naming context should be excluded. The format is: orclexcludednamingcontexts; supplier_replicaID$consumer_replicaiD : DN This is a multivalued attribute. From within the naming context specified in the orclincludednamingcontexts attribute, you can specify one or more subtrees to be excluded from the partial replication in each direction. You can modify this attribute. |
|
|
An attribute, located within the included naming context, to be excluded from replication. orclexcludedattributes; supplier_replicaID$consumer_replicaiD: attribute_name This is a multivalued attribute. You can modify this attribute |
The following is a sample replication naming context object entry:
dn:cn=namectx001, cn=replication namecontext, orclagreementid=unique_identifier_of_the_replication_agreement, orclreplicaid=replica_id_of_node_A, cn=replication configuration orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts; replica_id_of_node_A$ replica_id_of_node_B : c=us,cn=mycompany orclexcludedattributes; replica_id_of_node_B$ replica_id_of_node_A : userPassword
The example specifies the following replication filtering:
The naming context cn=mycompany is included for replication in both directions for node A and node B.
The naming context c=us,cn=mycompany is excluded for replication from node A to node B only.
The userPassword attribute is excluded for replication from node B to node A
Table 29-10 lists and describes the attributes of the replication server configuration set entry, which has the following DN:
cn=configset0,cn=osdrepld,cn=subconfigsubentry
Table 29-10 Directory Replication Server Configuration Parameters
| Parameter Name | Description |
|---|---|
|
|
Time of entry creation or modification. You cannot modify this parameter. |
|
|
Name of person creating or modifying the entry You cannot modify this parameter. |
|
|
Single-valued attribute. The number of processing retry attempts for a change-entry before being moved to the human intervention queue. The value for this parameter must be equal to or greater than 1 (one). The default is 10. You can modify this parameter. |
|
|
Number of worker threads spawned at each supplier for transporting or applying change logs. This parameter has two subtypes. The format is: orclthreadspersupplier; work_type: Number
The possible values of work_type are:
The default is one worker thread for transport and five worker threads for apply. You can modify this parameter. |
The examples of replication objects in this section rely on the replication environment shown in Figure 29-6.
In Figure 29-6, 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 two replication agreements, the first representing its multimaster relationship with nodes A and C, the second representing its relationship to node F. The replication agreement between B and F is two-way.
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. This is a one-way replication agreement in which C serves as the supplier and node D is the consumer.
Node D has two replication agreements. Both of its replication agreements are one-way. One represents its relationship to the supplier node C, from which it consumes changes, the other represents its relationship to consumer node E for which it is the supplier.
Node E has a one-way replication agreement with Node D. Node E is the consumer.
Node F has two replication agreements, one representing its relationship to the node B, the other representing its relationship to node G.Both are two-way replication agreements.
Node G has a one-way replication agreement with Node F. Node G is the consumer.
Figure 29-7 shows the replication objects in the DIT that pertain to node C in Figure 29-6 .
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 29-8 shows the replication agreement entry in the DIT that pertains to node D in Figure 29-6.
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 (10.1.4.0.1), 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 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.
Each entry in the change log store—that is, each change log object—has a unique change number. The consumer retrieves from the supplier only those changes with numbers greater than that of the last change it applied.
In an LDAP-based replication agreement, change log processing consists of two phases, transporting the change log and applying the change log. For each LDAP-based agreement, there are two change log processing statuses, one for the each phase. The directory replication server stores the last change number it transported in the transport subtype of the orlcllastappliedchangenumber attribute of the replication agreement entry. The directory replication server stores the last change number it applied in the apply subtype of the orllclastappliedchangenumber attribute of the replication agreement entry. The format of the orlcllastappliedchangenumber attribute is shown in Table 29-8, "Attributes of the Replication Agreement Entry".
In a replication agreement based on Advanced Replication, the directory replication server stores the last change number it transported in the changenumber attribute of the changestatus entry. The changenumber attribute 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 Oracle Database Advanced Replication. This section contains these topics:
|
See Also: |
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 where the replication server, acting as a client, sends commands to the Oracle Internet Directory server that implements them.
Figure 29-9 and its accompanying text provides an overview of the Oracle Advanced Database Replication process.
The events are as follows:
A change request is made on the Oracle Internet Directory server of Replica A.
The change is accepted and committed to storage in the Oracle Internet Directory Database.
2' A new change log is generated for the operation, and stored in the ods_chg_log table, where server = Replica A.
The replication server on Replica A queries for new outbound change logs from the local ods_chg_log table. The filter used for the query is:
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_A) )
A control is also passed along with this search operation with the value of orclreplicationid specified in the processing agreement. The value 1 is reserved for Advanced Replication agreements.
Last_Applied_ChgNum_From_A_TO_A is the outbound change log processing status.
The new change log retrieved from ods_chg_log is copied to local asr_chg_log.
The replication server requests Oracle Internet Directory server to update the Change log retry_cnt status properly.
5' Oracle Internet Directory server updates the retry_cnt of the change log in the ods_chg_log table.
The new change log is pushed From Replica A to Replica B through Oracle Advanced Database replication.
The replication server on Replica B queries for new inbound change logs from its local asr_chg_log table. The filter used is:
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))
The replication server applies the new change at Replica B.
Oracle Internet Directory server at Replica B accepts and commits the change to storage in the Oracle Database.
9' If the local replica has any LDAP-based consumer replicas, a change log is regenerated in the ods_chg_log table at Replica B, with the following regenerating rules:
server = server of local replica,
ReplicaB orclreplicationid/chg_rid = 1
Modifiersname = Replbind_DN_of_A
orclreplicatid/chg_rid is set to the value of orclreplicationid of the processing agreement. In this case, because the change is replicated and processed through Advanced Replication, it is set to 1 because 1 is reserved for Advanced Replication.
The replication server request Oracle Internet Directory server to update the shadow change log retry_cnt status properly.
10' Oracle Internet Directory server updates the retry_cnt of the shadow change log in the database.
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.
|
See Also: Chapter 31, "Oracle Internet Directory Replication Monitoring and Management" for information on configuring replication |
This section gives a more detailed look at LDAP replication. Data flow in LDAP replication consists of two phases, transport and apply.
Figure 29-10 and its accompanying text explain the fan-out replication process.
An LDAP change request is made on the Oracle Internet Directory server of Replica A.
The change is accepted and committed to Oracle Internet Directory database storage.
2'. A new change log is generated for the operation and stored in the ods_chg_log table, where:
server = Replica A
orclreplicationid/chg_rid = 0 (The value 0 is for user operations)
Modifiersname = user DN of the Modifier (by default)
The replication server on Replica B queries for new inbound change logs from the supplier replica, Replica A's ods_chg_log table]. The filter used for the query is:
(& (objectclass=changelogentry) (changeNumber>=Last_Transported_ChgNum_From_A_TO_B) (! (modifiersname=ReplicaID_of_B)) (! (orclreplicatonid = Orclreplicationid_Attribute_Value_of_Processing_Agreement)) (!(targetdn=*,excluded_naming_ctx_dn ) (….) (….) ….) (targetdn=cn=catalogs) (targetdn=cn=subschemasubentry) (targetdn=cn=oracleschemaversion) (targetdn=*,included_naming_ctx_dn) (targetdn=….) …)
A control is also passed along with this search operation with the value of orclreplicationid specified in the processing agreement.
The replication Server at B requests that the Oracle Internet Directory at Replica B store the new change log as a shadow change log.
4'. The Oracle Internet Directory server at Replica B stores the shadow change log in the asr_chg_log table at Replica B.
Steps 3, 3', and 4 correspond with the transport part of LDAP-based change log processing
The replication server at Replica B queries for new change logs from Replica A from the local change log store asr_chg_log. The filter for the query is:
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))
The replication server at Replica B request that the Oracle Internet Directory server at Replica B apply the retrieved change to storage.
Oracle Internet Directory server at Replica B accepts and commits the change to Oracle Internet Directory database storage.
7' If the local replica is the source of any other replicas, a change log is regenerated in ods_chg_log table at Replica B, which follows the following changelog regeneration rules:
server = server of local replica, ReplicaB
orclreplicationid/chg_rid = N
Modifiersname = Replbind_DN_of_A
orclreplicatid/chg_rid is set to the orclreplicationid value of the processing agreement.
The replication server requests that the server update the shadow change log retry_cnt status properly.
Oracle Database Advanced Replication and two-way LDAP-based replication enable 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 29-11 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:
|
As of 10g (10.1.4.0.1), Oracle Internet Directory supports failover of LDAP replicas from one supplier to another. Administrator intervention is required. Figure 29-11 shows a typical failover scenario.
This scenario has the following features:
Apple, Banana and Candy are multimaster replicas in the same DRG.
Damson is a read-only fan-out replica of Banana. That is, it is a partial replica using one-way LDAP replication.
Eggplant is an updateable fan-out replica of Banana. That is, it is a partial replica using two-way LDAP replication.
If Banana goes down, replication between the multimaster DRG and its fan-out replicas is broken.
An administrator can switch Eggplant and Damson to a new supplier, Candy.
Only two failover topology types are supported:
The consumer is connected to the old supplier with an LDAP-based agreement and the old supplier is in the same Advanced Replication group as the new supplier. This is shown in Figure 29-12. Node 2 and Node 3 are in the same Advanced Replication DRG. Node 2 is the original supplier for Node 4. When Node 4 fails, you can fail over Node 4 to a new supplier, Node 3.
The consumer and new supplier are both connected to the old supplier with LDAP-based replication agreements. This is shown in Figure 29-13. Node 1 and Node 3 both have LDAP replication agreements with Node 2. Node 2 is the original supplier for Node 1. When Node 2 fails, you can fail over Node 1 to a new supplier, Node 3.
In Advanced Replication, you can only exclude naming contexts.
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 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 29-14 and the accompanying text further exemplify the use of the naming context container and its objects.
In Figure 29-14, 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.
This section describes the rules for Oracle Database Advanced Replication filtering.
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 LDAP partial replication. It contains the following topics:
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 discussion in this section relies on the sample naming context illustrated in Figure 29-15. 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 |
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 29-16.
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 29-17.
The result of combining naming context objects #1 and #2 is shown in Figure 29-18.
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: c=us,cn=mycompany
Naming context object #3 excludes everything under c=us,cn=mycompany, as shown in Figure 29-19.
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 29-20.
The result of combining naming context objects #3 and #4 is shown in Figure 29-21.
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 29-22. 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 29-23. 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 c=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 29-24.
