Oracle Internet Directory Administrator's Guide
Release 2.0.6
A77230-01

Library
Product
Contents
Index

Prev Next

10
Managing Directory Replication

Replication is the mechanism that maintains exact duplicates of specified naming contexts on multiple nodes.

Note:

For Release 2.0.6, you can use Oracle Internet Directory replication only if you have installed Advanced Symmetric Replication, which ships with Oracle 8i Enterprise Edition. Advanced Symmetric Replication does not ship with Oracle 8i Standard Edition. 

This chapter addresses:

Installing and Configuring Replication

This section describes how to install and initialize Oracle Internet Directory replication server software on a node.

Each node in a group of DSAs holds an updatable copy, also called an updatable replica, of the same set of directory naming contexts. These naming contexts are synchronized with each other by replication processing. This group of nodes is called a Directory Replication Group (DRG).

Note:

The instructions in this section apply to setting up replication in a group of empty nodes. For instructions on adding a node to an existing DRG, see "Adding a Replication Node". 

To install and configure a replication group, follow the general steps listed below.

Step 1: Install Oracle Internet Directory on All Nodes in the DRG

Refer to Oracle Internet Directory Installation Guide. Note that the typical installation of the Oracle 8i Enterprise Edition, which is required for the Oracle Internet Directory, includes Oracle Advanced Symmetric Replication (ASR). By contrast, a typical installation of Oracle 8i Standard Edition does not include ASR.

Step 2: Configure Database Parameters for ASR on All Nodes

If you are going to run replication, you must change the values for three parameters by following these steps:

  1. Stop the database server

  2. Change the following parameters:

    • JOB_QUEUE_PROCESSES = 4

    • GLOBAL_NAMES = TRUE

    • OPEN_LINKS = 4

  3. Restart the database for the changes to take effect.

    See:

    Oracle8i Administrator's Guide 

Step 3: Decide Which Node Will Serve as the ASR Master Definition Site (MDS)

A Master Definition Site (MDS) is any of the Oracle Internet Directory databases from which the administrator is going to run the configuration scripts. You should be able to connect to the MDS database and all other nodes that constitute the DRG using Net8.

See Also:

"Prepare the Net8 Environment for Replication" 

Step 4: At the MDS, Set Up ASR for a Directory Replication Group

The following sections lead you through installing and configuring ASR through Oracle Internet Directory installation scripts. Advanced ASR users may prefer to configure ASR through the Oracle8i Replication Manager Tool.

See Also:

Oracle8i Server replication documentation and the online help for Oracle8i Replication Manager Tool for information on configuring ASR with the Oracle8i Replication Manager Tool 

Setting up the Oracle Advanced Symmetric Replication (ASR) environment to establish a Directory Replication Group (DRG) requires you to perform the two tasks described in the following sections:

Prepare the Net8 Environment for Replication

See Also:

Net8 Administrator's Guide. 

Execute the following steps on all nodes in the Directory Replication Group.

  1. Configure sqlnet.ora.

    The sqlnet.ora file in $ORACLE_HOME/network/admin should contain the following parameters at minimum: 

    names.directory_path = (TNSNAMES)
names.default_domain = domain
  2. Configure tnsnames.ora.

    The tnsnames.ora file in $ORACLE_HOME/network/admin must contain connect descriptor information in the following format for all Oracle Internet Directory databases: 

    net_service_name =
  (DESCRIPTION =
    (ADDRESS = 
      (PROTOCOL = TCP)
      (HOST = HOST_NAME_OR_IP_ADDRESS)
      (PORT = 1521))
    (CONNECT_DATA = (
       service_name = service_name))
    )

    Note:

    You may domain-qualify the net service name (for example, sales.com). If you domain-qualify it, be sure that the domain matches the domain specified by the NAMES.DEFAULT_DOMAIN parameter in the sqlnet.ora file. 

  3. For long transactions, create rollback table space and rollback segments. You may want to create multiple rollback segments. You can increase the size of the table spaces and segments to meet your system requirements.

    See Also:

    Oracle8i Administrator's Guide. for instructions on increasing size of the table spaces and segments 

    1. Create table space for rollback segments.

      Execute SQL*Plus by typing the following command: 

      sqlplus system/system_password@net_service_name

      At the SQL*Plus prompt, type: 

      create tablespace table_space_name 
datafile file_name_with_full_path SIZE 50M REUSE AUTOEXTEND ON NEXT 
10M MAXSIZE max_bulk_update transaction_size ex:500M;
    2. Create rollback segments.

      Execute SQL*Plus by typing the following command, 

      sqlplus system/system_password@net_service_name

      At the SQL*Plus prompt, type the following lines for each rollback segment: 

      create rollback segment rollback_segment_name
tablespace table_space_name storage (INITIAL 1M NEXT 1M OPTIMAL 2M 
MAXEXTENTS UNLIMITED);

      Repeat the commands above for each rollback segment entered in initsid.ora.

  4. Modify the parameters in file initsid.ora.

    Type the following lines in the initsid.ora file: 

    rollback_segments = (rollback_segment_name_1, rollback_segment_name_2 ...)
JOB_QUEUE_PROCESSES = number number of LDAP nodes - 1, at a minimum
SHARED_POOL_SIZE = 20000000

    Note:

    When setting the number of job queue processes, consider using a number high enough to accommodate any nodes you may want to add in the future. 

    Ensure that the total System Global Area (SGA) does not exceed 50% of system physical memory.

    Note:

    Every time a database is started, a System Global Area (SGA) is allocated and Oracle background processes are started. The SGA is an area of memory used for database information shared by the database users. The combination of the background processes and memory buffers is called an Oracle instance.

    For more information on SGA, see Oracle8i Concepts and Oracle8i Administrator's Guide. 

  5. Stop and restart the listener.

    To stop the listener for the Oracle Internet Directory database, use the listener control utility (lsnrctl). Type the following command at a command prompt: 

    lsnrctl> set password password
lsnrctl> stop [listener_name]

    SET PASSWORD is required only if the password is set in the listener.ora file. The password defaults to ORACLE. The default listener name is LISTENER.

    To restart the listener for the Oracle Internet Directory database, type the following command at the LSNRCTL command prompt: 

    lsnrctl> start [listener_name]
  6. Stop and restart the Oracle Internet Directory database.

    To stop and restart the Oracle Internet Directory database, you can use SQL*Plus.

Configure Oracle ASR For Directory Replication

To configure ASR at the MDS and all nodes in the replication group, complete the following steps from the MDS:

  1. Log on to the Oracle Internet Directory software owner account at the UNIX level.

  2. Change the directory to $ORACLE_HOME/ldap/bin.

    Note:

    Before proceeding to the next step, connect as system user to all nodes, including MDS, from MDS to ensure the following:

    • Oracle Internet Directory database is up and running

    • Oracle Internet Directory listener is up and running

    • Connect string is correct

    • System password is correct

    See Also:

     

  3. Run the following script from MDS: 

    ldaprepl.sh -asrsetup

    This script executes a number of operations.

    • It configures the Master Definition Site.

    • It configures the remote master sites. A remote master site is any site other than the Master Definition Site that participates in ASR replication.

    • It configures replication "Push" jobs at all sites.

    • It resumes replication at the Master Definition Site.

    • It verifies that all steps have completed successfully.

As the script runs, it asks for the information in Table 10-1, first for the Master Definition Site then for the master sites.

Table 10-1 ASR Setup Information
Information   Definition 

Host Name of MDS 

Name of the computer 

Global name 

Net service name of the MDS database, as listed in the file tnsnames.ora 

system password 

system password 

After you have provided the necessary information for the first master site, it asks if there is another master site. Enter Y or N. When you enter N, to indicate that you have identified all sites, it shows you a table of the information you have provided, and asks for confirmation. If it is not correct, press N. The script will start again at the beginning, asking about the Master Definition Site again.

After you have provided all the information, the script asks you to verify the correctness of the information. If the information is correct and you press Y, the script begins configuring the sites.

This process may take a long time, depending on your system resources and the size of your DRG. The script keeps you informed of its progress.

Note:

If for any reason you must interrupt the process before it is complete, you will have to start at the beginning. Interrupting the process will not negatively affect your re-installation. 

Troubleshooting Tip:

If the configuration process fails, do the following:

  • Check the
    $ORACLE_HOME/ldap/admin/logs/ldaprepl.log file to see the status.

  • In the directory $ORACLE_HOME/ldap/admin, check the status of replication jobs by running the following command: 

    sqlplus system/password@database_connect_string@ldaplogq.sql

Run the above command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the status [failed] and error messages, then this means that ASR set up failed. In this case, you may:

  • Determine a solution from error message information by consulting an expert in Advanced Symmetric Replication (ASR)

  • Consult the troubleshooting chapter in Oracle8i Replication,

  • Run the script from the beginning

 

Note:

If you have large initial data requirements, use the bulkload tool to load initial data on all the nodes in the DRG. You must stop the server before using bulkload, and bring it up again afterwards. For bulkload syntax and usage notes, see "bulkload". 

Step 5: Start Oracle Directory Server Instances on All the Nodes

Run the following command: 

oidctl connect=net_service_name_of_new_node server=oidldapd instance=instance_
number_of_ldap_server flags="-p port" start

See Also:

Chapter 5 for more information on starting an Oracle Directory Server instance 

Step 6: Configure Replication

You need to configure two different kinds of entries for replication, and these are described in the following sections:

Replication agreements are entries that list the member nodes within a replication group that share their changes. Replication agreements are referenced by Oracle Directory Replication Server configuration parameters that load when the replication server runs.

Because the Oracle Directory Replication Server configuration parameters are stored as special attributes in directory entries, you can configure replication parameters and replication agreements the same way you configure the Oracle Internet Directory--that is, you can alter the contents of the configuration entries and agreement entries through the command line tools, such as ldapadd and ldapmodify, or you can view and modify the agreements by using Oracle Directory Manager. This section explains both approaches.

Important:

When you install and configure replication the first time, you must inform the Oracle Directory Replication Server about the existence of the member nodes in the replication agreement. To do this, modify the orclDirReplGroupDSAs attribute in the replication agreement. This is explained in "Replication Agreement Parameters". 

Replication Server Configuration Parameters

The Oracle Directory Replication Server configuration parameters are stored in the replication server configuration set entry, which has the following DN: 

cn=configset0, cn=osdrepld, cn=subconfigsubentry

This entry contains replication attributes which control replication processing. You can modify some of these attributes. Note that the last parameter in the list specifies a replication agreement. In this release, only one replication agreement is possible.

Table 10-2 lists and describes the replication server configuration parameters.

Table 10-2 Replication Server Configuration Parameters
Parameter name  Description  Default Values  Modifiable? 

orclChangeRetryCount 

Single-valued attribute. The number of processing retry attempts for a change-entry before being dropped. You cannot use a negative value for this parameter. 

default: 10 

Yes 

orclPurgeSchedule 

Single-valued attribute. Removes entries that are already applied or have been dropped as candidate changes. This thread is initiated periodically based on the frequency that you set. Specifies purge (garbage collection) interval in minutes. You cannot use a negative value for this parameter. 

default: 10 minutes 

Yes 

orclThreadsPerSupplier 

Number of worker threads the Oracle Directory Replication Server provides for each supplier for change log processing. You cannot use a negative value for this parameter. 

5 

Yes 

orclDirReplGroupAgreement 

Multi-valued attribute. Identifies the symmetrical replication agreements for which this server is responsible. 

orclagreementid=000001,cn=orclreplagreements 

No 
Viewing and Modifying Replication Configuration Parameters by Using Oracle Directory Manager

  1. In the navigator pane expand Server Management > Replication Server.

  2. Select the replication configuration set whose parameters you want to view or modify. The corresponding tab pages appear in the right pane:


Configuration parameters appear in the General and Debug Flags tab pages. You can use these tab pages to view replication configuration parameters, and modify many of them. The following tables describe the fields in each tab page.

Table 10-3 General Tab Page
Field  Description 

Change Retry Count 

The number of attempts that the conflict resolution process tries to apply each update before giving up and logging the incident. The default is 10. 

Purge Schedule 

The number of minutes in between running garbage collection. The replication garbage collection thread removes entries that are already applied or have been dropped as candidate changes. The default is 10. 

Orcl Threads Per Supplier 

Number of worker threads the Oracle Directory Replication Server provides for each supplier for change log processing. The default is 5. 

Set 

The configuration identifier 
Table 10-4 Debug Flags Tab Page
Field  Description 

Debug Level 

The level of debugging that is set for this replication server. This number will be 32768 for replication-specific tracing. 

Various debug flags 

The only values you should change are the Trace Function Calls or the Any check box. Click these flags if you want to see more data during debugging. 

Modifying Replication Configuration Parameters by Using Command Line Tools

To modify replication configuration parameters by using command line tools, use the commands explained in "ldapmodify".

Modifying the Garbage Collection Interval

To modify the interval for garbage collection in replication, run ldapmodify, referencing an LDIF-formatted file. Before running this command, prepare an input file using LDIF format.

The LDAP command to apply the input file is as follows: 

ldapmodify -h host -p port -f filename

Example: A typical input file (using LDIF format) to modify the garbage collection interval parameter consists of the following lines: 

dn: cn=configset0, cn=osdrepld, cn=subconfigsubentry
changetype:modify
replace:orclPurgeSchedule
orclPurgeSchedule:30

This procedure changes the garbage collection interval from the default of 10 minutes to 30 minutes.

Example: A typical input file (using LDIF format) to modify the retry counts parameter consists of the following lines: 

dn: cn=configset0, cn=osdrepld, cn=subconfigsubentry
changetype:modify 
replace:orclChangeRetryCount
orclChangeRetryCount:5

This procedure changes the number of retry attempts from the default of ten times to five times. Specifically, after attempting to apply an update five times, the update is dropped and logged in the replication log file.

Important Note:

To configure replication, you must modify the attribute orclDirReplGroupDSAs to contain the values of the nodes participating in symmetrical replication. For instructions on how to modify any of these parameters, see "Modifying Replication Agreement Parameters Using Command Line Tools: A Sample". 

Modifying the Number of Worker Threads Used in Change Log Processing

To modify the number of worker threads used in change log processing:

  1. Edit mod.ldif as follows: 

    Dn: cn=configset0, cn=osdrepld, cn=subconfigsubentry 
Changetype: modify
Replace: orclthreadspersupplier
orclthreadspersupplier: new_number_of_worker_threads
  2. Use ldapmodify to update the replication server configset0 parameter value as follows: 

    ldapmodify -h host -p port -f mod.ldif
  3. Restart the replication server.

    See Also:

    "Restarting Directory Server Instances" for instructions on restarting the replication server 

Replication Agreement Parameters

In the parameter DirectoryReplicationGroupDSAs, type all of the host names of the DSAs in the DRG. Make sure this information is identical in all the nodes.

Replication agreement parameters are stored in the replication agreement entries which have the following DN: 

orclAgreementID=id number, cn=orclreplagreements

This entry contains attributes that pertain only to the nodes participating in this agreement. You can create multiple replication agreements to manage replication between reciprocating nodes, but you can reference only one of them in your start-server message using Oracle Directory Manager. For Oracle Internet Directory Release 2.0.6, only one replication agreement can be used.

Table 10-5 lists and describes the replication agreement parameters.

.
Table 10-5 Replication Agreement Parameters
Field in Oracle Directory Manager  Parameter  Description  Default Values  Modifiable? 

Agreements ID 

orclAgreementID 

Unique identifier for a replication agreement.  

000001 

No 

Excluded Naming Contexts 

orclExcludedNamingcontexts 

Multi-valued attribute. Specifies naming contexts excluded from this replication agreement. 

 

Yes 

Replication Group Nodes 

orclDirReplGroupDSAs 

Multi-valued attribute. Specifies nodes participating in symmetrical replication agreement. Nodes that you specify here share updates. 

 

Yes 

Update Schedule 

orclUpdateSchedule 

Specifies replication update interval in minutes. 

1 

Yes 

Replication Protocol 

orclReplicationProtocol 

Specifies the replication protocol used in this replication agreement. The supported protocol is ASR. 

ODS_ASR_1.0 

No 

Note:

Before you modify replication agreement parameters, be sure that you have started the Oracle Internet Directory on all nodes. 

Viewing and Modifying Replication Agreement Parameters by Using Oracle Directory Manager

To view and modify replication agreement parameters by using Oracle Directory Manager:

  1. In the navigator panel expand Server Management > Replication Server. Select Default Configuration Set.

  2. In the right pane, select the Agreement tab to display the replication agreement:

    The fields in this tab page are described in Table 10-5. You can view the parameters and modify some of them by double-clicking the attributes.

  3. When you have finished making your changes, click the Apply button. If you want to go back to using the values that appeared when you first opened this pane, click the Revert button.

Modifying Replication Agreement Parameters Using Command Line Tools: A Sample

To add more nodes to the values in a replication agreement entry, run ldapmodify at the command line, referencing an LDIF-formatted file. Before running this command, prepare an input file using LDIF format.

The LDAP command to apply the input file is as follows: 

ldapmodify -h host -p port -f filename

A typical input file (using LDIF format) to add two more nodes to a replication agreement consists of the following lines: 

dn: orclagreementid=000001, cn=orclreplagreements
changetype:modify 
add:orcldirreplgroupdsas
orcldirreplgroupdsas:hollis
orcldirreplgroupdsas:eastsun-11

This procedure modifies the entry containing the replication agreement whose DN is orclagreementid=000001,cn=orclreplagreements. The input file adds the two nodes, hollis and eastsun-11, into the replication group governed by oraclagreementid 000001.

Because this release of the Oracle Directory Replication Server supports only one configuration set, you do not need to specify a configuration set.

Step 7: Start the Replication Servers on All the Nodes

Type the following command: 

oidctl connect=db_connection_string server=oidrepld instance=1

   flags="-h host -p port" start

See Also:

Chapter 5 for information on starting the replication servers 

Toggling the Change-Log Flag

You can turn off change-logging, which occurs in the Oracle Internet Directory server, by toggling the default value of the -l flag in the line-mode run command for Oracle Directory Server from true to false. This is useful if you suspect that the change-log file might not be emptying. However, turning change-logging off on a given node means that updates on that node cannot be replicated to other nodes in the DRG.

Toggling the Multi-Master Flag

You can turn off the multi-master flag, which occurs in the replication server, by toggling the default value of the -m flag in the line-mode run command for Oracle Directory Server from true to false. This is useful for reducing performance overhead if you are deploying a single master with read-only replica consumers. The multi-master option controls conflict resolution, which serves no purpose if you are deploying a single master.

Adding a Replication Node

There are two ways to add a new node to a replication network. The easier of the two procedures is described in this section. Use this procedure unless your directory is very large. If your directory has more than a million entries, use the method described in Appendix B.

Note:

Use the procedure in this section to add a new node to an existing replication group. To create a new replication group, follow the instructions in "Installing and Configuring Replication". 

Note:

Before you add a replication node, prepare the Net8 environment. For instructions, see "Prepare the Net8 Environment for Replication". 

To add a replication node to a directory with less than a million entries, follow these steps, each of which is more fully described in the next few pages.

Step 1: Stop the Replication Server on All Nodes

Run the following command against each node in the LDAP replication group: 

oidctl connect=db_connect_string server=oidrepld instance=1 stop

Step 2: Configure the New Node into the LDAP Replication Group on All the Existing Nodes

Create an LDIF file, such as add_node.ldif, as in the following example: 

dn: orclagreementid=000001, cn=orclreplagreements
changetype: modify 
replace: orcldirreplgroupdsas
orcldirreplgroupdsas: host_name_of_the_new_node
orcldirreplgroupdsas: host_name_of_old_node1
orcldirreplgroupdsas: host_name_of_old_node2
.
.
.
orcldirreplgroupdsas: host_name_of_old_noden

Run the following command against each node in the LDAP replication group: 

ldapmodify -h host_name_of_the_node -p port -f add_node.ldif

Step 3: Identify a Sponsor Node and Switch the Sponsor Node to Read-Only Mode

A sponsor node is one that will supply the data to the new node.

Edit change_mode.ldif to the following: 

dn:
changetype:modify
replace:orclservermode
orclservermode:r

Run the following commands against the identified sponsor node: 

ldapmodify -D "cn=orcladmin" -w welcome -h host_name_of_sponsor_node 		  -p port 
-f change_mode.ldif
oidctl connect= db_connection_string server=oidldapd restart

This restarts all running LDAP severs on the sponsor in read-only mode. It takes approximately fifteen seconds for a directory server to restart.

Note:

While the sponsor node is in read-only mode, you may not make any updates to it. You may, however, update any of the other nodes, but those updates are not replicated immediately.

Also, the sponsor node and the Master Definition Site may be the same node. 

Step 4: Back Up the Sponsor Node by Using ldifwrite

Because this may take a long time, you may start "Step 5: Perform ASR Add Node Setup" while backup is in process.

You can backup the sponsor node in one of two ways:

  • Using cold backup

    This method, described in Appendix B, cannot be fully automated, and cannot be reused for partial replication. However, cold backup takes much less time for a directory with one million entries.

    Step 5: Perform ASR Add Node Setup

    You can perform this step at the same time as you are performing "Step 4: Back Up the Sponsor Node by Using ldifwrite".

    From the MDS, run the following script: 

    ldaprepl.sh -addnode

    This script executes a number of operations.

    As the script runs, it asks for the information in Table 10-6, first for the Master Definition Site then for the existing master sites.

    When you have identified all the existing master sites, enter N. The script then asks for information regarding the new node. Once you have provided that information, the script shows you a table of the information you have provided, and asks for confirmation.

    If the information is not correct, press N. The script then starts again at the beginning, asking the same information. If the information is correct and you enter Y, the script begins configuring the sites.

    Table 10-6 lists and describes the information for which the script prompts you.

    Table 10-6 ASR Setup Information
    Information   Description 

    Host Name of MDS or master site 

    Name of the computer 

    Global name 

    Net service name of the MDS or master site database, as listed in tnsnames.ora 

    system password 

    system password 

    This process may take a long time, depending on your system resources and the size of your DRG. The script will keep you informed of its progress.

    Note:

    If for any reason you must interrupt the process before it is complete, you will have to start again at the beginning. 

    Troubleshooting Tip:

    If the process fails, do the following:

    • Check the
      $ORACLE_HOME/ldap/admin/logs/ldaprepl.log file to see the status.

    • Move to the directory $ORACLE_HOME/ldap/admin and check the status of replication jobs by running the following command: 

      sqlplus system/password@database_connect_string@ldaplogq.sql

    Run the above command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the status [failed] and error messages, then this means that ASR set up failed. In this case, you may:

    • Determine a solution from error message information by consulting an expert in Advanced Symmetric Replication (ASR)

    • Consult the troubleshooting chapter in Oracle8i Replication,

    • Run the script from the beginning

     

    Step 6: Switch the Sponsor Node to Updatable Mode

    Edit change_mode.ldif to the following: 

    dn:
changetype:modify
replace:orclservermode
orclservermode:rw

    Run the following commands on the sponsor node: 

    ldapmodify -D "cn=orcladmin" -w welcome -h host_name_of_sponsor_node
    
    -p  port  -f change_mode.ldif
oidctl connect=db_connection_string server=oidldapd restart

    Note:

    Step 6 is very similar to Step 3. The only difference is that the orclservermode in change_mode.ldif is rw instead of just r. 

    Step 7: Start the Replication Server on All Nodes Except the New Node

    Do this by entering the following command: 

    oidctl connect=db_connection_string server=oidrepld instance=1
    
flags="-h host -p port" start

    Verify that no processes are running on the new node.

    Step 8: Load Data into the New Node by Using bulkload

    Do this by entering the following command: 

    bulkload.sh -connect db_connect_string_of_new_node -generate -load
    
-restore absolute_path_to_the_ldif_file_generated_by_ldifwrite

    Step 9: Start LDAP Server on the New Node

    Do this by entering the following command: 

    oidctl connect=db_connect_string_of_new_node server=oidldapd
    
instance=1 flags="-p port" start

    Step 10: Configure the LDAP Replication Agreement on the New Node

    Create an LDIF file, such as add_node.ldif, as in the following example: 

    dn: orclagreementid=000001, cn=orclreplagreements
changetype: modify 
add: orcldirreplgroupdsas
orcldirreplgroupdsas: host_name_of_the_new_node
orcldirreplgroupdsas: host_name_of_old_node1
orcldirreplgroupdsas: host_name_of_old_node2
.
.
.
orcldirreplgroupdsas: host_name_of_old_noden

    Run the following command against the new node: 

    ldapmodify -h host_name_of_the_new_node -p port -f add_node.ldif

    Step 11: Start the Replication Server on the New Node

    Do this by running the following command: 

    oidctl connect=db_connect_string_of_new_node server=oidrepld instance=1
    
flags="-h host_name_of_new_node -p port" start

    Conflict Resolution

    Multi-master replication enables updates to multiple directory servers. Conflicts are detected whenever the replication server attempts to apply remote changes from a supplier to a consumer that holds conflicting data.

    Four kinds of LDAP operations can lead to conflicts:

    These kinds of operations can be grouped into two categories described in the following sections:

    Entry-Level Conflicts

    Entry-level conflicts are caused when the replication server attempts to apply a change to the consumer directory. Such a change could be one of the following:

    These conflicts can be difficult to resolve because the reasons for their existence may be complex. For instance, if an entry does not exist, and this causes a replication conflict to log, that may mean:

    If an entry exists and it should not, that may mean:

    Attribute-Level Conflicts

    Attribute-level conflicts are caused when two directories are updating the same attribute with different values at different times. If the attribute is single-valued, the replication process resolves the conflict by examining the timestamps of the changes involved in the conflict.

    Typical Causes of Conflicts

    Conflicts usually stem from the timing of changes arising from the occasional slowness or transmission failure over wide-area networks. Also, an earlier inconsistency might continue to cause conflicts if it is not resolved in a timely manner.

    Automated Resolution of Conflicts

    The Oracle Directory Server replication application attempts to resolve all conflicts that it encounters, utilizing the following logic:

    1. The conflict is detected when a change is applied, and an error is encountered.

    2. The replication process attempts to reapply the change a configurable number of times or repetitively for a configurable amount of time after a configurable waiting period.

    3. The replication process reaches the retry limit without successfully applying the change. It then flags the change as a conflict and moves the change to a low-priority, human intervention queue. Changes are applied according to the time unit you specified in the orclupdateschedule parameter in the replication agreement multiplied by 100. Before it moves the change, the 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 large multi-valued variables would have a significant negative impact on performance. System Administrators must be careful to avoid updating from more than one master at a time. 

    Manual Resolution of Conflicts

    If a conflict has been written into the log file, the system is not able to resolve it following its resolution procedure. To avoid further replication change conflicts arising from earlier unapplied changes, it is important to monitor the log files regularly.

    To monitor replication change conflicts, examine the contents of the replication log file. New conflict records are written to the file. You can distinguish between messages by the timestamp.

    Sample Conflict Resolution Messages

    Conflict resolution messages, samples of which are shown below, are logged in file oidrepld00.log. The result of each attempt to resolve the replication conflict is displayed at the end of each conflict resolution message. 

    1999/08/03::10:59:05:  ************ Conflict Resolution Message ************
1999/08/03::10:59:05:  Conflict reason: Attempted to modify a non-existent 
entry.
1999/08/03::10:59:05:  Change number:1306.
1999/08/03::10:59:05:  Supplier:eastlab-sun.
1999/08/03::10:59:05:  Change type:Modify.
1999/08/03::10:59:05:  Target 
DN:cn=ccc,ou=Recruiting,ou=HR,ou=Americas,o=IMC,c=US.
1999/08/03::10:59:05:  Result: Change moved to low priority queue after failing 
on 10th retry.

1999/08/03::10:59:05:  ************ Conflict Resolution Message ************
1999/08/03::10:59:05:  Conflict reason: Attempted to add an existing entry.
1999/08/03::10:59:05:  Change number:1209.
1999/08/03::10:59:05:  Supplier:eastlab-sun.
1999/08/03::10:59:05:  Change type:Add.
1999/08/03::10:59:05:  Target DN:cn=Lou Smith, ou=Recruiting, ou=HR, 
ou=Americas, o=IMC, c=US.
1999/08/03::10:59:05:  Result: Deleted duplicated target entry which was created 
later than the change entry. Apply the change entry again.

1999/08/03::10:59:06:  ************ Conflict Resolution Message ************
1999/08/03::10:59:06:  Conflict reason: Attempted to delete a non-existent 
entry.
1999/08/03::10:59:06:  Change number:1365.
1999/08/03::10:59:06:  Supplier:eastlab-sun.
1999/08/03::10:59:06:  Change type:Delete.
1999/08/03::10:59:06:  Target DN:cn=Lou 
Smith,ou=recruiting,ou=hr,ou=americas,o=imc,c=us.
1999/08/03::10:59:06:  Result: Change moved to low priority queue after failing 
on 10th retry.

    The Replication Process

    This section describes how the automated replication process adds, deletes, and modifies entries, and how it modifies DNs and RDNs. It covers topics in the following subsections:

    Adding a New Entry

    When it successfully adds a new entry to a consumer, the replication server follows this change application process:

    1. The replication server looks in the consumer directory for the DN of parent of the target entry. Specifically, it does this by looking for a global unique identifier (GUID) assigned to that parent's DN.

    2. If the parent entry exists, the replication server composes a DN for the new entry and places the new entry under its parent in the consumer directory. It then places the change in the Purge Queue.

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

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

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

    If the change is not successfully applied after it has been placed in the Human Intervention Queue:

    Deleting an Entry

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

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

    2. If the matching entry exists in the consumer, the replication server deletes it. It then places the change in the Purge Queue.

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

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

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

    If the change is not successfully applied after it has been placed in the Human Intervention Queue:

    Modifying an Entry

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

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

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

    3. The replication server then applies the following conflict resolution rules:

      1. Most recent modify time wins.

      2. Most recent version of the attribute wins.

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

    4. The replication server applies the filtered modification, and places the change entry in the Purge Queue.

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

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

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

    If the change is not successfully applied after it has been placed in the Human Intervention Queue:

    Modifying a Relative Distinguished Name

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

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

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

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

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

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

    If the change is not successfully applied after it has been placed in the Human Intervention Queue:

    Modifying a Distinguished Name

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

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

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

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

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

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

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

    If the change is not successfully applied after it has been placed in the Human Intervention Queue:

    • Prev Next
    		Oracle
    Copyright © 1999 Oracle Corporation.
    All Rights Reserved.

    Library
    Product
    Contents
    Index