Oracle Database Advanced Replication-based replication agreement. The LDAP-based replication agreement. The replication agreement for LDAP nodes
40-10 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory
Figure 40–1 Example: Multimaster Replication and Fan-Out Replication
In Figure 40–1
, 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.
A
C B
D F
E Multimaster
Replication
G Fan-Out
Replication
Multimaster Replication-based Replica Partial Replica
One-Way Replication Two-Way Replication
Multimaster Replication
Managing Replication Configuration Attributes 40-11
Figure 40–2 shows the replication objects in the DIT that pertain to node C in
Figure 40–1 on page 40-10.
Figure 40–2 Example: Replication Configuration Entries for Node C
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=includednamingcontext000001 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 40–3 shows the replication agreement entry in the DIT that pertains to node D
in Figure 40–1
on page 40-10.
orclReplicaID= UID_of_Node_C
cn=replication DN cn=replication configuration
Root DSE
orclagreementID=000002 orclagreementID=000001
cn=replication namecontext cn=namingcontext001
cn=namingcontext002
40-12 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory
Figure 40–3 Example: Replication Configuration Entries for Node D
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.
Configuring Replication Configuration Attributes by Using Fusion Middleware Control
This section provides a summary of the replication configuration attributes that correspond with fields you can configure by using Oracle Enterprise Manager Fusion
Middleware Control. For more specific procedures, see Chapter 41, Managing and
Monitoring Replication.
Configuring Attributes on the Shared Properties, Replication Tab
You can configure some of the replication attributes by using the Oracle Internet Directory Shared Properties page of Fusion Middleware Control. Select
Administration , then Shared Properties, then select Replication from the Oracle
Internet Directory menu. After changing the configuration, choose Apply. The
correspondence is as follows:
orclReplicaID= UID_of_Node_D
cn=replication DN cn=replication configuration
Root
orclagreementID=000003 cn=replication namecontext
cn=includednamingcontext000001 cn=namingcontext002
Managing Replication Configuration Attributes 40-13
Configuring Replication Wizard Parameters
Some of the values you select or enter in the Oracle Enterprise Manager Fusion Middleware Control replication wizard control specific configuration attributes. For
example, your selections on the Schedule page of the replication wizard control the attributes listed in
Replication Schedule AttributesTable 40–6 .
The wizard sets other attributes appropriately when you configure replication. For example, the attribute orclreplicauri is formed by concatenation of the fields on
the Replicas page of the wizard.
Table 40–5 Configuration Attributes on Shared Properties, Replication Tab
Field or Heading Configuration Attribute
Change Retry Count orclchangeretrycount
Maximum Number of Workers orclreplmaxworkers
Autotune Replication orclreplautotune
Number of Apply Threads Per Supplier orclthreadspersupplier;apply
Number of Transport Threads per Supplier orclthreadspersupplier;transport
Maximum Number of Entries to Process per Replication Cycle
orclsizelimit Automatically Resolve Replication Conflicts
orclconflresolution Generate Stack Dump
orclsdumpflag SASL for Replication Bind
orclreplusesasl;digest-md5 Maximum Log File Size MB
orclmaxlogfilesize Maximum number of log files to keep in rotation
orclmaxlogfiles Conflict resolution for modify operations
orclreplattrconflict DebugLevel
orcldebuglevel Replication Status
orclreplicationstate ActivateInactivate
orclactivatereplication Replica ID
orclreplicaid Replica Primary URI
orclreplicauri Replica Secondary URI
orclreplicasecondaryuri Replica State
orclreplicastate Replica Type
orclreplicatype
Table 40–6 Replication Schedule Attributes
Field or Heading Configuration Attribute
LDAP Connection orclldapconnkeepalive
Replication Frequency orclupdateschedule
HIQ Schedule orclhiqshecule
40-14 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory
Managing Replication Configuration Attributes From the Command Line
You can modify most attributes from the command line by using ldapmodify. The command line syntax is:
ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile The contents of the LDIF file depends on the DN and the operation being performed.
For examples of LDIF files for changing replication configuration attributes, see Managing and Monitoring Replication by Using the Command Line
on page 41-14.
41
Managing and Monitoring Replication 41-1
41
Managing and Monitoring Replication
This chapter tells you how to monitor and manage replication in Oracle Internet Directory. For more information about replication configuration attributes, see
Chapter 40, Managing Replication Configuration Attributes. This chapter contains the following sections:
■
Introduction to Managing and Monitoring Replication
■
Managing and Monitoring Replication by Using ODSM and Fusion Middleware Control
■
Managing and Monitoring Replication by Using the Command Line
■
Comparing and Reconciling Inconsistent Data by Using oidcmprec
Introduction to Managing and Monitoring Replication
After you have installed and configured replication, you can view or modify the default values for replication-related attributes. The attributes and their containers are
described in Chapter 40, Managing Replication Configuration Attributes.
This introduction includes the following topics:
■
Managing Worker Threads
■
Change Logs in Directory Replication
■
The Human Intervention Queue
■
Pilot Mode
■
Conflict Resolution in Oracle Replication
Note: Some changes do not take effect until the replication server
is restarted.
See Also:
■
Chapter 6, Understanding Oracle Internet Directory Replication
■
Chapter 38, Setting Up Replication
■
Appendix C, Setting Up Oracle Database Advanced Replication-Based Replication
■
Appendix D, How Replication Works
41-2 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory
Modifying What Is to Be Replicated in LDAP-Based Partial Replication
In LDAP-based partial replication, you can change what is or is not replicated by modifying replica naming context objects. The parameters for these objects are stored
in entries that have this DN:
cn=namingcontext_ID,cn=replication namecontext, orclAgreementID=numeric_identifier_of_replication_agreement,
orclReplicaId=unique_identifier_of_replica, cn=replication configuration
See Viewing and Modifying Replica Naming Context Objects
on page 41-8 and Modifying Replica Naming Context Object Parameters by Using ldapmodify
on page 41-18.
Managing Worker Threads
The replication server is a multithreaded process. You can control the number of worker threads per supplier that are dedicated to:
■
Transporting the changelogs from supplier to consumer
■
Applying the transported changelogs at consumer You can set the number of transport threads and the number of apply threads per
supplier. Alternatively, you can configure the replication server to auto tune, that is, to dynamically vary the number of threads assigned to these two tasks based on load. If
you set the server to auto tune, you must specify the number of maximum number of threads to be shared between these tasks.
Table 41–1 shows the Oracle Enterprise Manager Fusion Middleware Control
parameters and configuration attributes that control worker threads. These are attributes of the replication configuration set.
You must tune these numbers based on load. In Oracle Enterprise Manager Fusion Middleware Control, you configure threads by using the Shared Properties page,
Replication tab. From the command line, you use ldapmodify.
Note: Because the directory replication server reads replica
naming context objects from the agreement located at the supplier, you must apply all modifications against naming context objects at
the supplier and, optionally, at the consumer.
Table 41–1 Configuration Attributes Controlling Worker Threads
Fusion Middleware Control Parameter Configuration Attribute
Maximum Number of Workers orclreplmaxworkers
Autotune Replication orclreplautotune
Number of Apply Threads Per Supplier orclthreadspersupplier;apply
Number of Transport Threads per Supplier orclthreadspersupplier;transport
Managing and Monitoring Replication 41-3
Change Logs in Directory Replication
Oracle Internet Directory records each change as an entry in the change log store. Each entry 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, 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 40–2, Attributes of the Replication Agreement Entry
on page 41-5.
■
In a replication agreement based on Oracle Database 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.
The Human Intervention Queue
The Replication Process on page D-8 describes the roles of the human intervention
queue, the purge queue, and the retry queue in replication. Conflict Resolution in
Oracle Replication on page 41-4 provides information about the role of these queues
in conflict resolution.
Managing the Queues
The human intervention queue tools, ManageHiq.retry and ManageHiq.purge, enable you to move changes from the human intervention queue to the retry queue or
the purge queue, respectively. See Managing the Human Intervention Queue
on page 41-24.
See Also:
■
Configure Replication Attributes by Using Fusion Middleware Control
on page 41-11
■
Configuring Attributes of the Replication Configuration Set by Using ldapmodify
on page 41-21
■
Table 40–4, Replication Configuration Set Attributes on
page 40-8
41-4 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory
Queue Statistics
You can view queue statistics by using the replication wizard in Oracle Enterprise Manager Fusion Middleware Control or the command line. See
Viewing Queue Statistics by Using Fusion Middleware Control
on page 41-13and Viewing Change
Logs by Using ldapsearch on page 41-15.
The Number of Entries the Human Intervention Queue Tools Can Process
If the number of entries in the Human Intervention Queue is greater than the maximum number of changelogs the replication server can process at a time, some
entries are never processed.
The maximum number of changelogs the replication server can process at a time is the minimum of two configuration attributes:
■
orclsizelimit in the replication configuration set
■
orclsizelimit in the instance-specific configuration entry of the OID component where replication is active
The default value of orclsizelimit in the replication configuration set is 1000. If you set it to 0, it takes the default value of 1000.
The orclsizelimit attribute in the Oracle Internet Directory instance-specific entry specifies the maximum number of entries to be returned by a search. Its default value
is 10000.
To increase the number of changelogs processed at a time, you must set both attributes to the same value, a value greater than 1000.
Setting the Oracle Internet Directory server instance parameter orclsizelimit very high impacts server performance, because orclsizelimit in the Oracle Internet
Directory server instance also controls the maximum number of entries to be returned by a search.
Pilot Mode
Pilot mode is used to test an application before deploying it in production. Typically, you set pilot mode on the local node, with one-way replication from the production
node. While the replica is in pilot mode, all the LDAP changes occurring at the local node are tracked. When you end pilot mode, those changes are written to an LDIF file.
When the application is deployed in production, all the entries added or modified in the pilot replica can be added to the production node using the ldif file.
Conflict Resolution in Oracle Replication
Oracle Database Advanced Replication-based replication and two-way and multimaster LDAP-based replication enable updates to multiple directory servers.
See Also:
■
Managing the Number of Entries the Human Intervention Queue Tools Can Process
on page 41-25
■
Table 40–4, Replication Configuration Set Attributes on
page 40-8
See Also:
Specifying Pilot Mode for a Replica by Using remtool on
page 41-17
Managing and Monitoring Replication 41-5
Conflicts occur whenever the directory replication server attempts to apply remote changes from a supplier to a consumer and, for some reason, fails.
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.
In partial replication, when a naming context is changed from included to excluded, the replication server deletes the naming context at the consumer. Similarly, if the
naming context is changed from excluded to included, the replication server synchronizes the entire naming context from supplier to consumer.
LDAP operations that can lead to conflicts include:
■
Addition
■
Deletion
■
Modification
■
Modification of either an RDN or a DN
Levels at Which Replication Conflicts Occur
There are two types of conflicts:
■
Entry-level conflicts
■
Attribute-level conflicts
Table 41–2 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:
■
Adding an entry that already exists
■
Deleting an entry that does not exist
■
Modifying an entry that does not exist
■
Applying a modifyrdn operation when the DN does not exist
These conflicts can be difficult to resolve. For instance, it may be impossible to resolve a conflict because:
■
The entry has been moved to a different location
■
The entry has not yet arrived from a supplier
■
The entry has been deleted
■
The entry never existed on the consumer If an entry exists and it should not, then it may be because it
was added earlier, or that it recently underwent a modifydn operation.
Attribute-level conflicts 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 and the attribute version number. The attribute
orclReplAttrConfl in the replication configuration set entry determines which is honored first. If
orclReplAttrConfl is 0 the default timestamp is honored first. If it is 1, attribute version is honored first.
41-6 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory
Automatic Conflict Resolution
In 11g Release 1 11.1.1, you can enable automatic conflict resolution. When this feature is enabled, conflicts in the Human Intervention Queue are automatically
moved to the purge queue if the suppliers schema and consumers schema match.
You can use either Oracle Enterprise Manager Fusion Middleware Control or the ldapmodify command to enable or disable automatic conflict resolution. To use
Oracle Enterprise Manager Fusion Middleware Control, change the replication configuration parameter Automatically Resolve Replication Conflicts. on the
Replication tab of the Shared Properties page. To use the command line, change the value of orclconflresolution in the replication configuration set.
How Automated Conflict Resolution Works
The directory replication server attempts to resolve all conflicts that it encounters by following this process:
1.
The conflict is detected when a change is applied.
2.
The replication process attempts to reapply the change a specific number of times or repetitively for a specific amount of time after a specific waiting period.
3.
If the replication process reaches the retry limit without successfully applying the change, it flags the change as a conflict, which it then tries to resolve. If the conflict
cannot be resolved according to the resolution rules described in the next section, the change is moved to a low-priority, human intervention queue. Changes are
then applied according to the time unit specified in the orclHIQSchedule parameter in the replication agreement. Before it moves the change, the directory
replication server writes the conflict into a log file for the system administrator.
See Also:
■
Replication Configuration Set Attributes on page 40-8
■
Configure Replication Attributes by Using Fusion Middleware Control
on page 41-11
■
Configuring Attributes of the Replication Configuration Set by Using ldapmodify
on page 41-21
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.
Managing and Monitoring Replication 41-7
Managing and Monitoring Replication by Using ODSM and Fusion Middleware Control
You can manage and monitor replication by using Oracle Enterprise Manager Fusion Middleware Control. This section contains the following topics:
■
Enabling or Disabling Change Log Generation by Using Fusion Middleware Control
■
Viewing the Local Change Logs by Using Oracle Directory Services Manager
■
Viewing and Modifying Replica Naming Context Objects
■
Viewing or Modifying a Replication Setup by Using the Replication Wizard
■
Deleting an LDAP-Based Replication Agreement by Using the Replication Wizard
■
Configure Replication Attributes by Using Fusion Middleware Control
■
Activating or Inactivating a Replication Server by Using Fusion Middleware Control
■
Configuring the Replication Debug Level by Using Fusion Middleware Control
■
Configuring Replica Details by Using Fusion Middleware Control
■
Viewing Queue Statistics by Using Fusion Middleware Control
■
Managing Changelog Processing by Using Fusion Middleware Control
■
Monitoring Conflict Resolution Messages by Using Fusion Middleware Control
Enabling or Disabling Change Log Generation by Using Fusion Middleware Control
You can enable and disable change log generation by using Oracle Enterprise Manager Fusion Middleware Control, as follows: