|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
 Previous |
 Next |
|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
|
Previous |
Next |
Replication is the mechanism that maintains exact duplicates of specified naming contexts on multiple nodes. This chapter tells you how to install, configure, and manage replication in Oracle Internet Directory.
This chapter contains these topics:
This section tells you how to install and configure multimaster replication groups, and how to resolve conflicts manually in them. It contains these topics:
Rules for Configuring Directory Replication Based on Oracle Database Advanced Replication
Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)
Resolving Conflicts Manually in a Multimaster Replication Group
|
See Also:
|
The following nine rules apply to replication based on Advanced Replication (sometimes referred to as ASR):
In this type of Directory Replication Group (DRG), there must be one node identified as the Master Definition Site (MDS): this is the group master. All other nodes taking part in the replication are replicas, which in database replication are termed "Remote Master Sites" (RMS). The MDS must be created as a master node, not as a replica, that is, neither as an Advanced Replication-based replica nor as an LDAP-based replica.
|
Note: Even though it is not the central master, an Advanced Replication-based replica is sometimes called a remote master site (RMS), due to two facts. The first is that in Advanced Replication, when information is moved from one site to another, the recipient of the transferred information is called a "remote master site." The second fact is that independent changes made directly to an Advanced Replication-based replica are also replicated to all members of its group, making it a "master" during that interaction. Such a group, in which changes to any member are replicated to all other members, is called a multimaster replication group. |
|
See Also:
|
When you install and configure Multimaster replication, the master node for a Directory Replication Group (DRG) and each node that is to become an Advanced Replication-based replica must be initially empty, that is, a new Oracle Internet Directory installation.
|
Note: If the Master node is not a new installation, use the procedure described in "Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)" to add replicas. That procedure will also initialize the replication group. |
When you add an Oracle Database Advanced Replication-based replica, the new replica must be empty. That is, Oracle Internet Directory must be newly installed.
The sponsor node for each Advanced Replication-based replica can be any of the following:
A master node
An Advanced Replication-based replica of an existing multi-master DRG
A supplier of an LDAP replica that is not a consumer LDAP replica of any other LDAP replica
An Advanced Replication-based replica cannot be a consumer of an LDAP replica.
In Oracle Internet Directory 10g Release 2 (10.1.2), a node cannot be part of more than one multimaster replication group.
The data replicated between servers in a directory replication group does not include DSE root-specific data, server configuration data, and replication agreement data.
When an multimaster replication group is configured, the Oracle Application Server Single Sign-On database schema is automatically configured in replication.
You cannot add an Oracle Internet Directory 10g Release 2 (10.1.2) node to an Oracle Internet Directory 10g (9.0.4) DRG. Instead, upgrade all 10g (9.0.4) nodes to 10g Release 2 (10.1.2), then add the new 10g Release 2 (10.1.2) node to the DRG.
This section discusses the general tasks you perform when installing and configuring a multimaster replication group. It contains these topics:
Preliminary Information for Installing and Configuring a Multimaster Replication Group
Task 1: Install Oracle Internet Directory as a Master on the Master Definition Site (MDS)
Task 2: Install the Oracle Internet Directory as a Replica, on the Remote Master Sites (RMS)
Task 3: Set Up Oracle Database Advanced Replication for a Directory Replication Group
Task 4 (Optional): Load Data into the Directory
Task 5: Ensure that Oracle Directory Server Instances are Started on All the Nodes
Task 6: Start the Replication Servers on All Nodes in the DRG
Task 7: Test Directory Replication
|
Note:
|
This section describes the types of installation you need to perform to configure a multimaster replication group. It also introduces the Replication Environment Management Tool that enables you to perform various configuration tasks.
When you install Oracle Internet Directory as part of Oracle Application Server on any node, you are prompted to select a product. Choose the Oracle Application Server Infrastructure.
Later in the installation process, you are prompted to choose an installation type.
For multimaster replication, you need a single master definition site (MDS). For that, follow the directions in the section entitled "If you are installing Oracle Internet Directory as a Master".
Each other site is a replica, either an Advanced Replication-based replica or an LDAP replica.
Oracle Database Advanced Replication-based replicas do true multimaster replication: changes made to the master are replicated to the replicas and changes made to any replica are replicated to the master and all other replicas.
Although a site that will be used as an Advanced Replication-based replica can be initially installed as a master, Oracle recommends against that option. Oracle recommends installing each intended replica as a replica right from the start.
Therefore, to create an Advanced Replication-based replica, follow the directions in the section entitled "If you are installing Oracle Internet Directory as a Replica", and choose "Advanced Replication" when that choice appears.
LDAP replicas are one-way and read-only: only changes made to the master are replicated to the replica, not from the replica to the master. LDAP replicas can also be used to replicate a portion of the directory information tree rather than the entire directory information tree. In partial replication, you determine what is or is not replicated by defining replica naming context objects.
To create an LDAP replica, follow the directions in the section entitled "If you are installing Oracle Internet Directory as a Replica", and choose "LDAP replica" when that choice appears.
|
See Also: Detailed explanations and examples of setting up and using naming contexts appear in later sections of this chapter. |
Follow the installation procedure documented in the chapter "Installing Oracle Internet Directory in Replicated Mode" in the Oracle Application Server Installation Guide. When the Oracle Universal Installer prompts you to select a product to install, choose the Oracle Application Server Infrastructure.
For the Installation Type, select as follows:
If you do not have (or will not be using) an existing Oracle Application Server Metadata Repository, choose Identity Management and Oracle Application Server Metadata Repository.
If you wish to use an existing Oracle Application Server Metadata Repository, choose Identity Management.
Ensure that Oracle Internet Directory is checked on the Select Configuration Options screen.
When installing a master, do not check High Availability and Replication in the Select Configuration Options screen for replication. When you do not check High Availability and Replication, Oracle Universal Installer will perform a default Oracle Internet Directory install, that is, it will install a new Oracle Internet Directory as a master node. (You may still check High Availability and Replication in the Select Configuration Options screen for configuring Virtual Host or OracleAS Clusters though.)
Complete the installation as described in "Installing Oracle Internet Directory in Replicated Mode" in the Oracle Application Server Installation Guide.
Follow the installation procedure documented in the chapter "Installing Oracle Internet Directory in Replicated Mode" in the Oracle Application Server Installation Guide. When the Oracle Universal Installer prompts you to select a product to install, choose the Oracle Application Server Infrastructure.
For the Installation Type, select as follows:
If you do not have (or will not be using) an existing Oracle Application Server Metadata Repository, choose Identity Management and Oracle Application Server Metadata Repository.
If you wish to use an existing Oracle Application Server Metadata Repository, choose Identity Management.
For Configuration Options, ensure that both Oracle Internet Directory and High Availability and Replication are checked.
Because you checked High Availability and Replication in the Select Configuration Options screen, you will see the Select High Availability or Replication Option screen. Select Replication.
Next, you will see the Oracle Internet Directory Replication Mode screen. Choose the type of replica you want to create:
For Advanced Replication-based (multimaster) replication, select Advanced Replication.
For read-only or partial replication, select LDAP.
On the screen labeled Oracle Internet Directory Master Node, specify the hostname and port for the supplier node to be replicated by this node presently being created. If connecting with that node requires SSL protocol, check that box on this screen.
Complete the installation as described in Oracle Application Server Installation Guide.
During installation and configuration, you use the Replication Environment Management Tool to perform various tasks. This tool assists you in:
Configuring a replication group
Adding and deleting replicas
Managing the directory replication group
Modifying or resetting the replication Bind DN password
Modifying the database replication user REPADMIN password
Displaying various errors and status information for change log propagation
|
Note: You do not need Advanced Replication to perform partial—that is, LDAP-based—replication.Even in a directory replication group whose nodes have different patchset versions of Oracle Database 10g, you can replicate if they have the same version of Oracle Internet Directory. However, if the nodes in a directory replication group are running different versions of Oracle Internet Directory, there is a constraint on modifying directory servers on those nodes: Do not replicate changes generated on a newer version of Oracle Internet Directory to a node that has not yet upgraded to that version. If you do, the changes can contain information that the earlier version cannot properly interpret. |
|
See Also: The "remtool" command-line tool reference in Oracle Identity Management User Reference for more information about the Replication Environment Management Tool |
You must be able to use Oracle Net Services to connect to the master definition site database and all other nodes in the DRG.
|
Note: During installation, make sure that each Oracle Internet Directory database instance name is unique on each machine. |
To do the actual installation, as a master, use the instructions in the section entitled "If you are installing Oracle Internet Directory as a Master".
|
See Also: Installing Oracle Internet Directory in Replicated Mode" in Oracle Application Server Installation Guide. |
Oracle recommends that the sites to be used as Advanced Replications-based replicas be installed initially as replicas, and not as masters.
To do the actual installation, as a replica, use the instructions in the section entitled "If you are installing Oracle Internet Directory as a Replica".
Although Oracle recommends starting with empty replicas, you can set up replication using machines initially configured as masters rather than replicas. To use a machine initially configured as a master as an RMS, you must first migrate its metadata to the MDS, as follows:
Make sure the Oracle Internet Directory server is up and running on both the MDS and each such desired replica so that the process (remtool –backupmetadata) can succeed.
From the newly created node, run the following command:
remtool –backupmetadata –master "master_host:master_port/master_repl_dn_pwd" \ –replica "new_node_host:new_node_port/new_node_repldn_pwd"
where master_host:master_port/master_repdn_pwd are the hostname, port number, and replication DN password for the desired replica's supplier.
Apart from loading the metadata into master replica, this tool creates a file named ocbkup.new_replica_id.TO.master_replicaid.timestamp.dat containing the metadata as backup. This file is created under the $ORACLE_HOME/ldap/log directory. This file contains the changes made to master replica in LDIF format, a copy of SSO container entry [orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext] and DAS URL container entry [cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext].
If the metadata backup succeeded, it displays a message in the terminal:
Backup of metadata will be stored in $ORACLE_HOME/ldap/log/ocbkup.new_replica_id.TO.master_replica_id.timestamp.dat. Metadata copied successfully.
The message will contain the actual path of ORACLE_HOME.
If an error occurs during this operation, remtool reports the error in the terminal from which it was invoked. The error messages are also logged in $ORACLE_HOME/ldap/log/remtool.log file.
After successfully migrating the master's metadata to the MDS, you can now safely continue with "Task 3: Set Up Oracle Database Advanced Replication for a Directory Replication Group" .
The following sections lead you through installing and configuring Advanced Replication by using the Replication Management Tool.
|
See Also: Oracle Database Advanced Replication in the Oracle Database Documentation Library, and the online Help for the Replication Management Tool, for information on configuring Oracle Database Advanced Replication. |
To establish a directory replication group (DRG), you must configure the Advanced Replication environment by performing the tasks discussed in these topics:
On All Nodes, Prepare the Oracle Net Services Environment for Replication
From the MDS, Configure Oracle Database Advanced Replication For Directory Replication
For each node in the directory replication group, perform the steps listed here. (Each step is described more fully in the subsections that directly follow this list.)
To prepare the Oracle Net Services environment for replication:
The sqlnet.ora file should contain the following parameters at minimum:
names.directory_path = (TNSNAMES)
names.default_domain = global_database_domain
On UNIX, the sqlnet.ora file is in $ORACLE_HOME/network/admin.
On Microsoft Windows, the sqlnet.ora file is in %ORACLE_HOME%\network\admin.
On each node in the DRG, define all Oracle Internet Directory database instances in the DRG. Each tnsnames.ora file must contain connect descriptor information in the following format for each Oracle Internet Directory database:
net_service_name = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = HOST_NAME_OR_IP_ADDRESS) (PORT = port_no_of_listener)) (CONNECT_DATA =(service_name = service_name_of_database)))
where net_service_name is the global name of the database. For example, if the database global name is mds.sales.com, then your net_service_name must be mds.sales.com. Ensure that your database global name and your net_service_name are domain-qualified. In this example, the global name and net_service_name are domain-qualified with sales.com.
|
Note:
|
|
See Also: Oracle Database Net Services Reference for more information ontnsnames.ora syntax.
|
On UNIX, the tnsnames.ora file is in $ORACLE_HOME/network/admin.
On Microsoft Windows, the tnsnames.ora file is in %ORACLE_HOME%\network\admin.
|
Note: You must domain-qualify the net service name (for example,sales.com), but be sure that the domain component matches the one specified in the NAMES.DEFAULT_DOMAIN parameter in the sqlnet.ora file.
|
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 the LSNRCTL command prompt:
SET PASSWORD password 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:
START [listener_name]
quit
Test Oracle Net connections to all nodes from each node in the DRG.
IMPORTANT: Try to connect using both of these commands:
sqlplus ods/ods_password@net_service_name_without_domain_name sqlplus ods/ods_password@net_service_name_with_domain_name
If you cannot connect, then replication will not work.
To do this:
From the MDS console, connect as the system user on all nodes, including the MDS. Ensure the following on all nodes:
The Oracle Internet Directory database is running
The Oracle Internet Directory listener is running
The connect string is correct
The system password is correct
Ensure the following wallets exist on the remote sites:
A wallet for storing the password to the database designated for Oracle Internet Directory. This wallet is named oidpwdlldap1 and is located in the directory $ORACLE_HOME/ldap/admin.
A wallet for storing the password of the replication administrator. This wallet is named oidpwdroracle_sid, and is located in the directory $ORACLE_HOME/ldap/admin. (The oracle_sid is obtained not from the environment variable SID but from the connected database.)
Check the prerequisites in the attached Note. Then, at a command prompt in the MDS, use remtool (the Replication Environment Management Tool) to configure Advanced Replication by running the following script:
$ORACLE_HOME/bin/remtool -asrsetup
|
Note:
|
|
Note: If you encounter errors, then clean up the environment by using the -asrcleanup option of the Replication Environment Management Tool. Then repeat Step 3.
|
|
Note: As part of "Task 3: Set Up Oracle Database Advanced Replication for a Directory Replication Group", the Replication Environment Management Tool (remtool) sets default values for the replication configuration parameters, which enables you to simply start the replication servers. If you wish to change the replication configuration parameters, see "Managing Replication".
|
You can choose either of two ways to load data into the directory:
To add just a small number of entries to the DRG, you can wait until you have completely configured the DRG. Then use ldapadd to load the data to one of the nodes. The entries will then be replicated to the other nodes at the specified time.
To add a large amount of data to load into the DRG, use the bulkload utility:
Stop the LDAP server at all nodes of the DRG by typing:
opmnctl stopproc ias-component=OID
On the node that is part of the DRG and where you have the ldif file to be loaded onto the directories enter:
bulkload.sh -connect connect_string -check \ -generate file_with_absolute_path_name
|
Note: If data is extracted from Oracle Internet Directory usingldifwrite, then, in addition to other options, use the -restore option to restore the operational attributes.
|
On the same node, enter:
bulkload.sh -connect connect_string_1 -load
Repeat step c on the same node, each time replacing connect_string_1 with the connect string of another node in the DRG, until you have loaded the data onto all the nodes in the DRG. For example, enter:
bulkload.sh –connect connect_string_2 -load
then enter
bulkload.sh –connect connect_string_3 –load
and so on, until you loaded the data onto all the nodes in the DRG.
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
|
See Also: The "bulkload" command-line tool reference in Oracle Identity Management User Reference for syntax and usage notes |
The out-of-box configuration has Oracle Internet Directory LDAP Server instance #1 configured with change logging set to TRUE. This default instance of Oracle Internet Directory LDAP Server can be started using opmn as follows:
opmnctl startproc ias-component=OID
|
Note: Do not use theopmnctl startall command at this point. If you do, the HTTP server and the Oracle Internet Directory server will start, but the command will hang while trying to start the OC4J server. The OC4J server can be started only after Task 6 is complete. Once the replication server has been started on all nodes of the DRG and replication has propagated to all nodes, you may safely use the opmnctl startall command.
|
|
See Also: Chapter 3, "Post-Installation Tasks and Information" for more information on starting an Oracle directory server instance. |
To start replication servers on all nodes, type the following command on each node:
oidctl connect=connect_string server=oidrepld instance=1 \ flags='-h host_on_which_the_directory_server_is_running -p port' start
Note that the instance number need not be unique across the entire DRG.
Once the Oracle Internet Directory replication server has been started using oidctl, any opmnctl command to stop or start the Oracle Internet Directory component will ensure that the Oracle Internet Directory replication server process is also stopped or started.
|
See Also: "Process Control of Oracle Internet Directory Components" for information on Oracle Internet Directory process control. "Conflict Resolution in Multimaster Replication" Chapter 5, " Oracle Directory Server Administration" for information on starting the replication servers |
Use Oracle Directory Manager to verify that the directory replication servers are running, and then test directory replication by doing the following:
Log in to Oracle Directory Manager as orcladmin.
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Entry Management.
Create a single entry on the MDS node.
The identical entry appears in approximately 1 to 10 minutes on the RMS. You can adjust the timing in the replication server configuration set entry. If entries are modified on any nodes in the DRG, then the changes will be replicated.
|
Note: If you want to configure replication for Oracle Application Server Single Sign-On, then follow the post-installation steps specific to Oracle Application Server Single Sign-On. These are found in the replication installation section of the Oracle Application Server Single Sign-On Administrator's Guide. |
|
Note: A new node that you add to an existing multimaster replication group must have an Oracle Application Server Infrastructure installed on it. During its installation, the installation type selected had to have been Oracle Application Server with Metadata Repository. For more information, see "Task 2: Install the Oracle Internet Directory as a Replica, on the Remote Master Sites (RMS)". |
You can add a node to a master node, or to an LDAP-based supplier replica that is not a consumer of any other LDAP based replicas, to form a multimaster DRG. When you do so, the steps in this section will automatically perform an initial install and configuration of Advanced Replication.
To add a new replication node to a live, functioning replication group or to a master node of any significant size, perform the following steps:
Task 7: Start the Directory Replication Server on All Nodes Except the New Node
Task 10: Start the Directory Replication Server on the New Node
|
Note: Commands shown in the following tasks require the following types of items to be stored as follows:
Before beginning "Task 2: Identify a Sponsor Node and Install Oracle Internet Directory as a Replica on the Remote Site", be sure that all three of these types of items are in the path. |
The process that prepares this environment is described in Section 25.1.2.4.1, "On All Nodes, Prepare the Oracle Net Services Environment for Replication".
To stop the directory replication server, run the following command on each node in the LDAP replication group, type:
oidctl connect=db_connect_string server=oidrepld instance=1 stop
|
Note: The instance number might not be 1. Check the running process to discover the instance number in use here. |
You must identify a sponsor node for this Task. It is the node that will supply the data to the new node.
For the RMS, Oracle recommends that you install the new instance of Oracle Internet Directory as an Advanced Replication replica. (You could use an existing master node as the RMS, but extra manual steps are required.)
To install a new Oracle Internet Directory as an Advanced Replication replica for RMS, use the instructions in "If you are installing Oracle Internet Directory as a Replica" and choose Advanced Replication when that choice appears.
If an existing master is used as RMS, you need to follow the instructions in "If an Existing Master is Used as a Remote Master Site" to migrate the master's metadata to the sponsor node. After successfully migrating the master's metadata to the MDS, you can now safely continue with "Task 3: Switch the Sponsor Node to Read-Only Mode".
A sponsor node is the node that supplies the data to the new node. To switch the sponsor node to read-only mode:
Create a new file, change_mode.ldif, containing the following:
dn: changetype: modify replace: orclservermode orclservermode: r
Run the following command against the identified sponsor node:
ldapmodify -D "cn=orcladmin" -w adminPassword -h host_name_of_sponsor_node \ -p port -f change_mode.ldif
This command changes the Oracle directory server name_of_sponsor_node from sponsor mode to read-only mode.
|
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 MDS may be the same node. |
Because this may take a long time, you may start "Task 5: Perform Advanced Replication Add Node Setup" while backup is in process.
On the sponsor node, enter the following command:
ldifwrite -c connect_string \ -b "orclAgreementID=000001,cn=replication configuration" \ -f output_ldif_file
This backs up the directory of the sponsor node.
|
Note: Oracle Net Service must be configured properly on all nodes for replication. See: "On All Nodes, Prepare the Oracle Net Services Environment for Replication". |
You can perform the Advanced Replication add node setup at the same time that you perform "Task 4: Back up the Sponsor Node by Using ldifwrite".
On the sponsor node, enter this command:
remtool -addnode
The Replication Environment Management Tool adds the node to the DRG.
|
Notes: When you run When you use If you encounter errors, then use the |
|
See Also: The "remtool" command-line reference in Oracle Identity Management User Reference for instructions on using the-addnode option of the Replication Environment Management Tool
|
To 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 adminDN -w adminPassword -h host_name_of_sponsor_node \ -p port -f change_mode.ldif
This command changes the Oracle directory server host_name_of_sponsor_node from sponsor mode back to read/write mode.
|
Note: Task 6 is very similar to Task 3. The only difference is that theorclservermode parameter in change_mode.ldif is being set back to rw, that is, read/write, in this step.
|
To start the directory replication server, type the following command on all nodes except the new node:
oidctl connect=db_connection_string server=oidrepld instance=1 \ flags='-h host -p port' start
To ensure that no directory or replication processes are running on the new node, type:
opmnctl stopproc ias-component=OID
To load data, type the following command on the new node:
bulkload.sh -connect db_connect_string_of_new_node -check -generate -load \ -restore absolute_path_to_the_ldif_file_generated_by_ldifwrite
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
To start the directory server, type the following command on the new node:
oidctl connect=db_connect_string_of_new_node server=oidldapd \ instance=1 flags='-p port' start
To start the directory replication server, type the following command on the new node:
opmnctl startproc ias-component=OID
|
Note: Once a directory server instance is participating in a replication agreement, do not use the bulkload tool to add data into the node. Instead, use ldapadd.If Oracle Application Server Single Sign-On is desired in replication, then follow the Oracle Application Server Single Sign-On Administrator's Guide in the replication installation section for the post-installation steps specific to Oracle Application Server Single Sign-On. |
At times, you may want to delete a node from a DRG (for example, if the addition of a new node did not fully succeed as a result of system errors).
To delete a replication node, perform the tasks described in these topics:
To stop the directory replication server, run the following command on each node in the DRG:
oidctl connect=connect_string server=oidrepld instance=1 stop
|
Note: The instance number may vary. |
On the node to be deleted, shut down Oracle Internet Directory using opmn.
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OID
|
See Also: The "opmn" command-line tool reference in Oracle Identity Management User Reference for more information about shutting down Oracle Internet Directory. |
From the MDS, run the following script:
remtool -delnode
The Replication Environment Management Tool deletes the node from the replication group.
|
See Also: The "remtool" command-line tool reference in Oracle Identity Management User Reference for instructions on using the-delnode option of the Replication Environment Management Tool
|
This process can take a long time, depending on your system resources and the size of your DRG. If you use the -v option, the tool keeps you informed of its progress.
|
Note: If you encounter errors, then use the-asrverify option first. If it reports errors, then rectify them by using the -asrrectify option. Both -asrverify and -asrrectify list all nodes in the DRG. If the node to be deleted is in the list, then delete it by running the Replication Environment Management tool again, using the -delnode option.
|
This section contains these topics:
If a conflict has been written into the log, then it means that the system is not able to resolve it by following its resolution procedure. To avoid further replication change conflicts arising from earlier unapplied changes, it is important to monitor the logs regularly.
To monitor replication change conflicts, examine the contents of the replication log. You can distinguish between messages by their respective timestamps.
Conflict resolution messages, examples of which are shown in this section, are logged in the file oidrepld00.log. The path for this file is $ORACLE_HOME/ldap/log. The result of each attempt to resolve the replication conflict is displayed at the end of each conflict resolution message.
Example 25-1 An Attempt to Modify a Non-Existent Entry
2000/08/03::10:59:05: ************ Conflict Resolution Message ************ 2000/08/03::10:59:05: Conflict reason: Attempted to modify a non-existent entry. 2000/08/03::10:59:05: Change number:1306. 2000/08/03::10:59:05: Supplier:eastlab-sun. 2000/08/03::10:59:05: Change type:Modify. 2000/08/03::10:59:05: Target DN:cn=ccc,ou=Recruiting,ou=HR,ou=Americas,o=IMC,c=US. 2000/08/03::10:59:05: Result: Change moved to low priority queue after failing on 10th retry.
Example 25-2 An Attempt to Add an Existing Entry
2000/08/03::10:59:05: ************ Conflict Resolution Message ************ 2000/08/03::10:59:05: Conflict reason: Attempted to add an existing entry. 2000/08/03::10:59:05: Change number:1209. 2000/08/03::10:59:05: Supplier:eastlab-sun. 2000/08/03::10:59:05: Change type:Add. 2000/08/03::10:59:05: Target DN:cn=Lou Smith, ou=Recruiting, ou=HR, ou=Americas, o=IMC, c=US. 2000/08/03::10:59:05: Result: Deleted duplicated target entry which was created later than the change entry. Apply the change entry again.
Example 25-3 An Attempt to Delete a Non-Existent Entry
2000/08/03::10:59:06: ************ Conflict Resolution Message ************ 2000/08/03::10:59:06: Conflict reason: Attempted to delete a non-existent entry. 2000/08/03::10:59:06: Change number:1365. 2000/08/03::10:59:06: Supplier:eastlab-sun. 2000/08/03::10:59:06: Change type:Delete. 2000/08/03::10:59:06: Target DN:cn=Lou Smith,ou=recruiting,ou=hr,ou=americas,o=imc,c=us. 2000/08/03::10:59:06: Result: Change moved to low priority queue after failing on 10th retry.
The Human Intervention Queue Manipulation Tool enables you to move changes from the human intervention queue to either the retry queue or the purge queue. Moving the change to the purge queue means that there are no further attempts to re-apply the changelog entry. To address changes in the human intervention queue, follow these general steps:
Shut down the directory replication server.
Analyze the replication log.
Use the Human Intervention Queue Manipulation Tool to move the changes to either the retry queue or the purge queue as described in the following sections.
|
Note: The Oracle Internet Directory server parameterorclSizeLimit, which is 1000 by default, limits the number of entries that the Human Intervention Queue Manipulation Tool can process. If you have more than 1000 entries in the human intervention queue, you must increase orclSizeLimit, or some entries will never be processed. Setting the parameter orclSizeLimit very high will impact server performance, because orclSizeLimit also controls the maximum number of entries to be returned by a search.
|
|
See Also: The "hiqretry.sh" command-line tool reference in Oracle Identity Management User Reference for instructions on how to use the Human Intervention Queue Manipulation Tool |
When the directory replication server encounters inconsistent data, you can use the Oracle Internet Directory Reconciliation Tool to synchronize the entries on the consumer with those on the supplier. When you do this, perform the following general steps:
Set the supplier and the consumer to read-only mode.
Ensure that the supplier and the consumer are in a tranquil state—that is, that neither is supplying or applying changes. If they are not in a tranquil state, then wait until they have finished updating.
Identify the inconsistent entries or subtree on the consumer.
Use the OID Reconciliation Tool to fix the inconsistent entries or subtree on the consumer.
Set the participating supplier and consumer back to read/write mode.
|
See Also:
|
This section contains these topics:
Installing and Configuring an LDAP Replica with Default Settings
Installing and Configuring an LDAP-Based Replica with Customized Settings
Table 25-1, "Determining What Is to Be Replicated in LDAP-Based Partial Replication"
|
See Also: "Supplementary Procedures for Configuring LDAP-Based Replicas" in Oracle Application Server Administrator's Guide |
The following rules apply to both full and partial LDAP-based replication:
An LDAP-based replica cannot have two suppliers.
In LDAP-based replication, only the naming contexts listed in the namingcontexts attribute of the root DSE can be replicated to the consumer.
|
See Also: The discussion of namingcontexts in |
The supplier of an LDAP-based replica can be a master node that is a standalone node, a member of a multimaster replication group, or another LDAP-based replica.
|
See Also: For instructions on installing on a standalone node, see "If you are installing Oracle Internet Directory as a Master" |
An LDAP-based replica can be a consumer for another LDAP-based replica. That consumer is then called a fan-out replica.
You can add an Oracle Internet Directory 10g Release 2 (10.1.2) LDAP replica to an Oracle Internet Directory 10g (9.0.4) master. You can also upgrade a 10g (9.0.4) LDAP replica of a 10g (9.0.4) master to 10g Release 2 (10.1.2).
|
Note: Make sure the schemas are synchronized. Otherwise, the replication server might not be able to apply changes to the consumer replica. |
The new consumer node must be empty. That is, Oracle Internet Directory must be newly installed.
Use the ldifwrite utility to back up LDAP data with operational attributes preserved. Once this is done, the bulkload utility is then used to load data to all replicas in a group.
Use bulkload with the -check, -generate, and -restore arguments once, and then with the -load argument once for each replica. When using the -load argument on each replica, preserve the operational attributes by using the same intermediate files generated by using the -generate argument.
Backup using this method can take a long time for a directory with one million entries.
|
See Also: "Oracle Identity Management Command-line Tool Reference" in Oracle Identity Management User Reference presents the syntax and multiple examples for both ldifwrite and bulkload. |
This section discusses default namingcontext configuration settings as one way to configure LDAP- based replication from the supplier replica to the consumer replica, with all namingcontexts included. That is, replication is configured so that the entire DIT of the supplier replica will be replicated to the consumer.
When you install and configure an LDAP replica with default settings, automated bootstrap performs the initial data synchronization from the supplier to the consumer. After the installation of a new LDAP replica is completed, LDAP based replication will be configured and the replication process will be started automatically.
|
Note: When you install an LDAP replica using default settings, the installer automatically migrates the consumer replica's metadata to the supplier replica. It is assumed all metadata are under the naming contextcn=oraclecontext. If you need to use a different naming context, such as a realm-specific naming context, see the next section, "Installing and Configuring an LDAP-Based Replica with Customized Settings" .
|
Identify the supplier for an LDAP-based replica. The supplier can be:
A standalone directory
A node of a multimaster replication group
Another LDAP-based replica
Make sure the Oracle Internet Directory server is started on the Supplier node. To start the directory server, type the following command:
opmnctl startproc ias-component=OID
Use the instructions in "If you are installing Oracle Internet Directory as a Replica" and in step 5 choose LDAP replica.
When you install an LDAP replica with the default settings, Oracle Universal Installer automatically invokes bootstrap to migrate data from the supplier to the consumer.
|
Note: Bootstrapping may take a long time to complete. |
Do not update the Oracle Internet Directory schema on the supplier when bootstrapping is in progress. If you do, replication bootstrap might fail. If it fails, verify that the Oracle Internet Directory schema at the consumer is synchronized with that of the supplier before you try to bootstrap again.
If you update the supplier Oracle Internet Directory during bootstrapping, the Oracle Internet Directory replication server will log a warning message. Changes you make to the supplier will be replicated to the consumer. Some of the changes, however, might be moved to the human intervention queue.
Once installation is complete, LDAP replication will be configured. The replication server on the consumer will replicate changes from the supplier.
You can check replication activity by viewing the replication log file on the new LDAP replica.
To establish customized settings, you must first install the new node as a Master node (standalone). To do so, follow the instructions in "If you are installing Oracle Internet Directory as a Master" .
After configuring LDAP base replication with remtool, you can customize the namingcontext defining what will be replicated for that LDAP-based node.
|
See Also: The discussion of naming contexts in "Determining What Is to Be Replicated in LDAP-Based Partial Replication" |
There are two ways to install and configure an LDAP-based replica with customized setting, based on how you will migrate the data from the directory:
Use the command-line tools. Use ldifwrite to backup the data from the supplier replica, then use bulkload to restore the data to the consumer replica
Use automatic bootstrapping. This is a replication server feature that automatically bootstrap the data from the supplier replica to the consumer replica, based upon replication configuration.
Table 25-1 compares these two methods.
Table 25-1 Data Migration Using ldifwrite/bulkload versus Automatic Bootstrapping
| Migration Using ldifwrite/bulkload | Migration Using Automatic Bootstrapping |
|---|---|
|
Manual procedure Faster performance Good for a large amount of data |
Automatic procedure Uses the filtering capability of partial replication Good for a smaller number of entries |
If automatic bootstrapping is your chosen data migration method, customize your LDAP-based replica using "Configuring an LDAP-Based Replica by Using Automatic Bootstrapping" .
If ldifwrite/bulkload is your chosen data migration method, configure your LDAP-based replica using "Configuring an LDAP-Based Replica by Using the ldifwrite Tool" .
The following eight tasks enable you to configure an LDAP-based replica by using automatic bootstrapping. They are explained in the paragraphs that follow this list.
Task 1: Identify and Start the Directory Server on the Supplier Node
Task 2: Create the New Consumer Node by Installing Oracle Internet Directory as a Master
Task 4: Add an LDAP-Based Replica by Using the Replication Environment Management Tool
Task 5: On the Consumer, Configure the Consumer Replica for Automatic Bootstrapping
Task 7: Start the Directory Replication Server on the Consumer Replica
Identify the supplier for an LDAP-based replica. The supplier can be
A standalone directory
A node of a multimaster replication group
Another LDAP-based replica
Make sure the Oracle Internet Directory server is started on the Supplier node. To start the directory server, type the following command:
opmnctl startproc ias-component=OID
To install and configure an LDAP-based replica with customized setting, you must install the new consumer node as a master. To install a new Oracle Internet Directory as a master, follow the directions in "If you are installing Oracle Internet Directory as a Master" .
Before configuring the new node as an LDAP-based replica with customized settings, you must first migrate its metadata to the supplier node, as follows:
Make sure the Oracle Internet Directory server is up and running on both the supplier node and the new node created in Task 2, so that the backup process (remtool –backupmetadata) can succeed.
From the newly created node, run the following command:
remtool –backupmetadata \
–replica "new_node_host:new_node_port/new_node_repldn_pwd" \
–master "master_host:master_port/master_repl_dn_pwd"
where master_host:master_port/master_repdn_pwd are the hostname, port number, and replication DN password for the desired replica's supplier.
|
See Also: The "remtool" command-line tool reference in Oracle Identity Management User Reference for more information aboutremtool options, including -backupmetadata.
|
Apart from loading the metadata into master replica, this command creates a file named ocbkup.new_replica_id.TO.master_replicaid.timestamp.dat containing the metadata as back up. This file is created under the $ORACLE_HOME/ldap/log directory. This file contains the changes made to master replica in LDIF format, a copy of the SSO container entry [orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext] and DAS URL container entry [cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext].
If the metadata backup succeeds, it shows the following message in the terminal:
Backup of metadata will be stored in $ORACLE_HOME/ldap/log/ocbkup.new_replica_id.TO.master_replicaid.timestamp.dat. Metadata copied successfully.
The message will contain the path of your ORACLE_HOME.
If the metadata backup is unsuccessful, the $ORACLE_HOME/ldap/log/remtool.log file will contain error messages. If you invoked remtool from a terminal, error messages appear on that terminal.
To add a replica, enter the following:
remtool -paddnode [-v] [-bind supplier_host_name:port/replication_dn_password]
|
See Also: The "remtool" command-line tool reference in Oracle Identity Management User Reference for more information about the Replication Environment Management Tool |
To use the automatic bootstrap capability, on the consumer, set the orclReplicaState attribute of the consumer replica subentry to 0 as follows:
Edit the sample file mod.ldif as follows:
Dn: orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration
Changetype:modify
add:orclReplicaState
OrclReplicaState: 0
Use ldapmodify at the consumer to update the consumer replica's subentry orclreplicastate attribute.
ldapmodify –D "cn=orcladmin" –w administrator_password -h consumer_host \ -p port -f mod.ldif
|
See Also: "Managing Replication" for more information about the bootstrap capability of the LDAP-based replication |
You can change the default parameters for replication agreements and for the replica subentry.
On the consumer, start the Oracle Internet Directory replication server by typing:
oidctl connect=db_connect_string_of_consumer_node \ server=oidrepld instance=1 \ flags='-h consumer_host -p consumer_port' start
When the replication server is started, it will start to bootstrap the data from the supplier to the consumer. Once the bootstrap has completed successfully, the replication server will automatically change to ONLINE mode to process changes from the supplier to the consumer.
The entries for DAS and SSO must refer to the local instances of these services. However, the initial replication download from the supplier to the consumer creates these entries with values replicated from the supplier. If these services are in fact configured on the consumer node, then these values need to be replaced by the correct information appropriate to the consumer node.
If the Delegated Administration Service (DAS) is configured on the consumer node, it must be restored using the following steps:
In the ocbkup.new_replicaid.TO.master_replicaid.timestamp.dat file created by Task 3, locate and copy the DAS URL. The DN of the DAS URL container entry is "cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext". It is usually the next-to-last entry in the file.
Create an LDIF file called change_das_url.ldif with the following contents:
dn: cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext
changetype: modify
replace: orcldasurlbase
orcldasurlbase: copy_paste_the_URL_from_backup_file
Execute the following command to change the DAS URL:
ldapmodify –p consumer_port -h consumer_host -D super_user_DN \ –w super_user_password -f change_das_URL.ldif
Similarly, if Single Sign-on (SSO) is configured on the consumer node, it must be restored using the following steps:
In the ocbkup.timestamp.dat file created by Task 3, locate and copy the SSO container entry. Copy only the attributes shown in step 2. The DN of the SSO container entry is "orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext". It is usually the last entry in the file.
Create an LDIF file add_SSO_container.ldif with the following contents:
dn: orclApplicationCommonName=ORASSO_SSOSERVER,
cn=SSO,cn=Products,cn=OracleContext
orclapplicationcommonname: ORASSO_SSOSERVER
orclappfullname: ORASSO_SSOSERVER
orclversion: 10.1.2.0.0
objectclass: orclApplicationEntity
objectclass: top
userpassword: userpassword_copied_from_backup_file
|
Note: Do not copy theauthpassword;oid, createtimestamp, creatorsname, modifiersname, modifytimestamp, or orclguid attributes.
|
Execute the following command to add the SSO container entry:
ldapadd –p consumer_port -h consumer_host -D super_user_DN \ –w super_user_password -f add_SSO_container.ldif
Create an LDIF file mod.ldif with the following contents:
dn: cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext changetype:modify add: uniquemember uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO,cn=Products,cn=OracleContext dn: cn=verifierServices, cn=Groups,cn=OracleContext changetype:modify add: uniquemember uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO,cn=Products,cn=OracleContext
Execute the following command to apply mod.ldif:
ldapmodify -p consumer_port -h consumer_host -D super_user_DN \ –w super_user_password -f mod.ldif
Restart OC4J security for the change to take effect:
$ORACLE_HOME/opmn/bin/opmnctl stopproc process-type=OC4J_SECURITY $ORACLE_HOME/opmn/bin/opmnctl startproc process-type=OC4J_SECURITY
Using a browser, test the Oracle Delegated Administration Services and OracleAS Single Sign-On pages.
To test Oracle Delegated Administration Services, try to log in as the admin user "orcladmin" on the Oracle Delegated Administration Services page, http(s)://new_node_hostname:new_node_http_port/oiddas/. If you cannot log in, see the troubleshooting appendix in Oracle Identity Management Guide to Delegated Administration.
To test OracleAS Single Sign-On, try to log in as the super admin user "orcladmin" on the OracleAS Single Sign-On page, http(s)://new_node_hostname:new_node_http_port/pls/orasso/. If you cannot log in, see the troubleshooting appendix in Oracle Application Server Single Sign-On Administrator's Guide.
This section discuss the general tasks you perform when configuring an LDAP-based replica by using the ldifwrite tool. It contains these topics:
Task 1: Start the Directory Server on Both the Supplier and the Consumer Nodes
Task 3: Change the Directory Server at the Supplier to Read-Only Mode
Task 4: Add an LDAP-Based Replica by Using the Replication Environment Management Tool
Task 7: Change the Directory Server at the Supplier to Read/Write Mode
Task 11: Start the Directory Replication Server on the Consumer Replica
Identify the supplier for an LDAP-based replica. The supplier can be:
standalone directory
A node of a multi-master replication group
Another LDAP-based replica
Make sure the Oracle Internet Directory server is started on the Supplier node. To start the directory server, type the following command:
opmnctl startproc ias-component=OID
Identify the consumer node, which must be an new Oracle Internet Directory install as a master. To install a new Oracle Internet Directory as a Master, follow the directions in "If you are installing Oracle Internet Directory as a Master" . Make sure the Oracle Internet Directory server is started on the new consumer node. To start the directory server, type the following command:
opmnctl startproc ias-component=OID
Before configuring the consumer as an LDAP-based replica with customized settings, you must first migrate its metadata to the supplier node, as follows:
Make sure the Oracle Internet Directory server is up and running on both the supplier node and the new node created in Task 2, so that the backup process (remtool –backupmetadata) can succeed.
From the consumer node, run the following command:
remtool –backupmetadata \
–replica "consumer_host:consumer_port/consumer_repl_dn_pwd" \
–master "supplier_host:supplier_port/supplier_repl_dn_pwd"
Apart from loading the metadata into master replica, this tool creates a file named ocbkup.consumer_replica_id.TO.supplier_replica_id.timestamp.dat containing the metadata as back up. This file is created in the $ORACLE_HOME/ldap/log directory. This file contains the changes made to the master replica in LDIF format, a copy of SSO container entry [orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext] and DAS URL container entry [cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext].
If the metadata backup succeeded, remtool displays the following message in the terminal:
Backup of metadata will be stored in $ORACLE_HOME/ldap/log/ocbkup.consumer_replica_id.TO.supplier_replicaid.timestamp.dat. Metadata copied successfully.
The message will contain the actual path of your ORACLE_HOME and filename.
If the metadata backup is unsuccessful, the $ORACLE_HOME/ldap/log/remtool.log file will contain error messages. If you invoked remtool from a terminal, error messages appear on that terminal.
To ensure data consistency, change the directory server on the supplier node to read-only. To do this:
Create an LDIF file containing the following:
Dn: Changetype: modify Replace: orclservermode Orclservermode: r
On the supplier, run the following command:
ldapmodify –D "cn=orcladmin" –w administrator_password \ –h host_name_of_supplier_node –p port –f name_of_LDIF_file.ldif
To add a replica, enter the following:
remtool -paddnode [-v] [-bind supplier_host_name:port/replication_dn_password]
|
See Also: The "remtool" command-line tool reference in Oracle Identity Management User Reference for more information about the Replication Environment Management Tool |
To do this:
Search for the last applied change number on the supplier node.
ldapsearch -D "cn=orcladmin" -w administrator_password -h supplier_host \ -p port_number -b "" -s base "objectclass=*" lastchangenumber
Modify the corresponding agreement with the retrieved last applied number at the supplier. To do this:
On the supplier, create an LDIF file with the retrieved last applied change number:
dn:orclagreementid=agreement_identifier, orclreplicaid=supplier_replica_identifier,cn=replication configuration changetype: modify replace: orclLastAppliedChangeNumber orclLastAppliedChangeNumber: last_change_number_retrieved_in_step_1.
On the supplier, modify the agreement by using ldapmodify:
ldapmodify -D "cn=orcladmin" -w password -h host_name -p port_number \ -f LDIF_file
If there is a large number of entries in the naming contexts that you want to replicate to the LDAP-based replica, then Oracle Corporation recommends that you back up these naming contexts at the supplier node and then load them to the LDAP-based replica.
To back up the naming contexts:
Identify the replication agreement DN created in "Task 4: Add an LDAP-Based Replica by Using the Replication Environment Management Tool".
ldapsearch -h supplier_host -p port \ -b "orclreplicaid=supplier_replicaID,cn=replication configuration" \ -s sub "(orclreplicadn= orclreplicaid=consumer_replica_ID, \ cn=replication configuration)" dn
On the supplier, use the following command to get the data from the supplier. Data loaded into the file will be based on the agreement configured:
ldifwrite –c connect_string_of_sponsor_node \ -b "replication_agreement_dn_retrieved_in_step_1" \ –f name_of_output_LDIF file
|
See Also: "Determining What Is to Be Replicated in LDAP-Based Partial Replication" The "ldifwrite" command-line tool reference in Oracle Identity Management User Reference for more instructions on using ldifwrite to back up part of the naming context |
If you performed "Task 3: Change the Directory Server at the Supplier to Read-Only Mode", then change the directory server on the supplier back to read/write mode. To do this:
Create an LDIF file containing the following:
Dn: Changetype: modify Replace: orclservermode Orclservermode: rw
Run the following command:
ldapmodify –D "cn=orcladmin" –w administrator_password \ –h host_name_of_supplier_node –p port –f name_of_LDIF_file
To do this:
If there are multiple files, then combine them into one file—for example, backup_data.ldif.
If naming contexts exist on the LDAP-based consumer replica, then remove them by using bulkdelete. Enter the following:
bulkdelete.sh –connect connect_string_of_replica -base "naming_context"
Perform this step for each naming context that was backed up in "Task 6: Back Up the Naming Contexts to Be Replicated".
On the consumer, load the data to the replica by using bulkload in the append mode. Enter the following:
bulkload.sh –connect connect_string_of_replica –append –check \
–generate –restore backup_data.ldif
bulkload.sh –connect connect_string_of_replica -load
|
See Also:
|
Follow the procedure described in "Task 8: If DAS or SSO Are Installed on the New Node, Restore Their Entries in the New Node's Directory".
You can change the default parameters for replication agreements, for the replica subentry, and for the replication naming context configuration objects.
Start the Oracle directory replication server, following the procedure described in the "oidctl" command-line tool reference in Oracle Identity Management User Reference.
This section explains how to delete an LDAP-based replica. It contains these topics:
Task 1: Stop the Directory Replication Server on the Node to be Deleted
Task 3: Stop the Directory Server on the Node to be Deleted
|
Note: You cannot delete a replica if it is a supplier for another replica. To delete such a replica, you must first delete all its consumers from the replication group. |
Stop the Oracle directory replication server, following the procedure described in the "oidctl" command-line tool reference in Oracle Identity Management User Reference.
Do this by using the Replication Environment Management Tool. Enter:
remtool -pdelnode [-v] [-bind hostname:port_number/replication_dn_password]
In LDAP-based partial replication, you can determine what is or is not replicated by defining 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
|
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. |
To view and modify parameters for replica naming context objects:
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier, Replica Agreement: replication agreement identifier
Select the replica naming context you want to modify. The Replica Naming Context tab page appears in the right pane. The fields in this tab page are described in Table A-20, "Fields in the Replica Naming Context Tab Page".
After you have entered the appropriate information, choose OK.
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier, Replica Agreement: replication agreement identifier.
Select Naming Context:naming context identifier.
From the toolbar, choose Create. The New Replica Agreement Naming Context dialog box appears.
In the fields in the New Replica Agreement Naming Context dialog box, enter the appropriate information. The fields in this dialog box are described inTable A-20, "Fields in the Replica Naming Context Tab Page".
Choose OK.
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier, Replica Agreement: replication agreement identifier.
Using your mouse, right-click Naming Context:naming context identifier.
Select Delete.
Replica naming context object parameters are listed and described under Replication Schema Elements in Oracle Identity Management User Reference.
|
Note: The replication server reads naming context objects from the supplier replica. |
Example 25-4 Adding a Naming Context Object for an LDAP-Based Replica
This example creates a naming context object that does the following:
Replicates the naming context ou=Americas,cn=mycompany
Excludes from replication the naming context cn=customer profile, ou=Americas,cn=mycompany
Excludes from replication the attribute userpassword
The steps are:
Edit the example file mod.ldif as follows:
dn: cn=naming_context_identifier, cn=replication namecontext, orclagreementid=replication_agreement_identifier, orclreplicaid=supplier_replica_identifier,cn=replication configuration orclincludednamingcontexts: ou=Americas,cn=mycompany orclexcludednamingcontexts: cn=customer profile, ou=Americas, cn=mycompany orclexcludedattributes: userpassword objectclass: top objectclass: orclreplnamectxconfig
Use ldapadd to add the partial replication naming context object to the supplier.
ldapadd -D "cn=orcladmin" -w administrator_password -h supplier_host \ -p port_number -f mod.ldif
Example 25-5 Deleting a Naming Context Object
To delete the naming context object created in Example 25-4, type:
ldapdelete -D "cn=orcladmin" -w administrator_password \ -h supplier_host -p supplier_host_port_number \ "cn=naming_context_identifier, cn=replication namecontext, \ orclagreementid=replication_agreement_identifier, \ orclreplicaid=supplier_replica_identifier, \ cn=replication configuration"
Example 25-6 Modifying the orclIncludedNamingContexts Attribute for a Replica Naming Context Object
The directory replication server uses the orclIncludedNamingcontexts attribute value of the replica naming context object to specify the top-level subtree included in partial replication.
In this example, the included naming context is set to c=us, which means that c=us is to be included in partial replication.
Edit the example file mod.ldif as follows:
DN:cn=naming_context_identifier,cn=replication namecontext, orclagreementid=replication_agreement_identifier, orclreplicaid=supplier_replica_identifier,cn=replication configuration Changetype:modify Replace: orclIncludedNamingcontexts orclIncludedNamingcontexts: c=us
Use ldapmodify to update the replication agreement orclupdateschedule attribute.
ldapmodify -D "cn=orcladmin" -w administrator_password -h supplier_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 25-7 Modifying the orclExcludedNamingContexts Attribute for a Replica Naming Context Object
The directory replication server uses the orclExcludedNamingcontexts attribute value of the replica naming context object to specify the top-level subtrees excluded from partial replication.
In this example, the excluded naming contexts are set to ou=Europe,c=us and ou=Americas,c=us, which means that these two naming contexts are to be excluded from partial replication.
Edit the example file mod.ldif as follows:
DN:cn=naming_context_identifier, cn=replication namecontext, orclagreementid=replication_agreement_identifier, orclreplicaid=supplier_replica_identifier,cn=replication configuration Changetype:modify Replace: orclExcludedNamingcontexts orclExcludedNamingcontexts: ou=Europe, c=us orclExcludedNamingcontexts: ou=Americas, c=us
Use ldapmodify to update the replication agreement orclupdateschedule attribute.
ldapmodify -D "cn=orcladmin" -w administrator_password \ -h supplier_host -p port -f mod.ldif
Restart the directory replication server.
|
Note: A subtree specified in theorclexcludednamingcontexts attribute must also be a subtree of the specified includednamingcontext of the same replica naming context object.
|
Example 25-8 Modifying the orclExcludedAttributes Attribute for a Replica Naming Context Object
You can specify that certain changes made to the included naming context be excluded, at attribute level, from partial replication. To determine which attributes are to be excluded, the directory replication server uses the value of the orclExcludedAttributes attribute of the replica naming context object.
In this example, the telephonenumber and title attributes of the naming context specified in the orclincludednamingcontexts attribute are excluded from replication.
Edit the example file mod.ldif as follows:
DN:cn=naming_context_identifier, cn=replication namecontext, orclagreementid=replication_agreement_identifier, orclreplicaid=supplier_replica_identifier,cn=replication configuration Changetype:modify Replace: orclExcludedAttributes orclExcludedAttributes: telephonenumber orclExcludedAttributes: title
Use ldapmodify to update the replication agreement orclupdateschedule attribute.
ldapmodify -D "cn=orcladmin" -w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
Once you have installed and configured replication, you can view or modify the default values for replication-related objects. This section contains these topics:
Viewing and Modifying Directory Replication Server Configuration Parameters
Viewing and Modifying Parameters for Particular Replica Nodes
Changing the Replication Administrator's Password on All Nodes
Modifying the Speed of Directory Replication
|
Note: No change to any configuration parameter or replication agreement takes effect until the replication server is restarted. |
The section "Directory Server Configuration Parameters" under "Replication Schema Elements" in Oracle Identity Management User Reference lists and describes the directory replication server configuration parameters. These 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 that control replication processing. You can modify some of these attributes.
To view configuration parameters of the directory replication server:
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Server Management.
Select Replication Server. The following tab pages appear in the right pane.
Active Replication Servers, which tells you which directory replication servers are now running
Replication Status, which tells you the number of the last change applied from each supplier to each consumer in the DRG
Changelog Subscriber Status, which lists subscribers to the change log, and gives the number of the last change applied from this node
To modify configuration parameters of the directory replication server:
In the navigator pane, expand Oracle Internet Directory Servers, directory server instance, Server Management, Replication Server.
Select the replication configuration set whose parameters you want to modify. The corresponding tab pages appear in the right pane.
In the General tab page, modify the fields as appropriate.
For a description of these fields, see Table A-16, "Fields in the Replication Server Configuration Set: General Tab Page".
For Advanced Replication-based agreements, in the ASR Agreement tab page, modify the fields as appropriate.
For a description of these fields, see Table A-17, "Fields in the ASR Agreement Tab Page".
Restart the directory replication server to effect your changes.
|
Note: Be sure to add all host names for all nodes in the DRG into the Replication Group Nodes field. Do this for all nodes in the DRG. |
To modify replication configuration parameters by using command-line tools, use the syntax documented in the "ldapmodify" command-line tool reference in Oracle Identity Management User Reference.
"Replication Schema Elements" in Oracle Identity Management User Reference describes the replication server configuration parameters. As noted in that table, the modifiable replication configuration parameters are:
orclChangeRetryCount
orclThreadsPerSupplier
Example 25-9 Modifying the Number of Retries Before a Change Is Moved into the Purge Queue
This example uses an input file named mod.ldif to change 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.
Edit the example file mod.ldif as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclChangeRetryCount orclChangeRetryCount: 5
Use ldapmodify to update the replication server configset0 parameter value as follows:
ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 25-10 Modifying the Number of Worker Threads Used in Change Log Processing
This example uses an input file named mod.ldif to change the number of worker threads used in change log processing to 7.
Edit the example file mod.ldif as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclthreadspersupplier orclthreadspersupplier: 7
Use ldapmodify to update the replication server configset0 parameter value as follows:
ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
|
See Also: The "oidctl" command-line tool reference in Oracle Identity Management User Reference for instructions on restarting the directory replication server |
To modify a particular replica node, you modify the replica subentry. "Replication Schema Elements" in Oracle Identity Management User Reference describes the parameters you can modify in the replica subentry.
|
Note: Because the directory replication server reads replication node objects from the consumer, you must apply all changes to the consumer and, optionally, to the supplier. |
To view and modify a particular replica node by using Oracle Directory Manager:
In the navigator pane, expand Oracle Internet Directory Servers, directory server instance, Replication Management.
Select the replica node you want to view or modify. The corresponding tab pages appear in the right pane.
In the General tab page, you can modify the fields as appropriate. Table A-18, "Fields in the Replica Node: General Tab Page" describes the fields in this tab page.
The Replica Agreements tab page enables you to view the details of the replication agreement in which the specified node participates. The columns in this tab page are described in Table A-19, "Columns in the Replica Agreements Tab Page".
After you have viewed and modified the replica node, restart the directory replication server.
To modify replication configuration parameters by using command-line tools, use the syntax documented in the "ldapmodify" command-line tool reference in Oracle Identity Management User Reference.
Example 25-11 Modifying the orclReplicaURI Attribute for a Particular Replica Node
The directory replication server uses the orclReplciaURI attribute value of the replica subentry to locate the directory server for that replica. If the port or host where the directory server is running is changed, then this attribute must be modified accordingly.
Edit the example file mod.ldif as follows:
Dn: orclreplicaid=unique_replica_identifier, cn=replication configuration Changetype:modify Replace:orclReplicaURI OrclReplicaURI: ldap://host_name:port_number/
Use ldapmodify to update the replica subentry orclreplicauri attribute.
ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 25-12 Modifying the orclReplicaSecondaryURI Attribute for a Particular Replica
The directory replication server uses the orclReplicaSecondaryURI attribute value as an alternate location to contact the directory server for a particular replica. A user can add an alternate ldapURI attribute at which the directory server can be contacted for that particular replica. To add additional ldapURI attribute:
Edit the example file mod.ldif as follows:
Dn: orclreplicaid=unique_replica_identifier, cn=replication configuration Changetype:modify add:orclReplicaSecondaryURI OrclReplicaSecondaryURI: ldap://host_name:port_number/
Use ldapmodify to update the replica subentry OrclReplicaSecondaryURI attribute.
ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 25-13 Modifying the orclReplicaState Attribute for a Particular Replica
OrclReplicaState represents the state of a particular replica. To bootstrap (re-initialize) a replica, update this attribute in the following manner:
Edit the example file mod.ldif as follows:
Dn: orclreplicaid=unique_replicaID, cn=replication configuration
Changetype:modify
replace:orclReplicaState
OrclReplicaState: 0
On the host where the consumer replica is running, use ldapmodify to update the replica subentry orclreplicastate attribute.
ldapmodify –D "cn=orcladmin" –w administrator_password -h consumer_host \ -p port -f mod.ldif
Restart the directory replication server.
This section contains instruction for modifying replication agreements that are based on both Advanced Replication and LDAP.
Replication agreement parameters based on Advanced Replication are stored in replication agreement entries, which have the following DN:
orclAgreementID=000001,cn=replication configuration
To view and modify replication agreement parameters by using Oracle Directory Manager:
In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Replication Management. The following tab pages appear in the right pane:
Replication Status, which tells you the number of the last change applied from each supplier to each consumer in the DRG
Replica Status, which tells you the state of the replica—that is, whether it is online, offline, or in the bootstrapping process.
Changelog Subscriber, which lists subscribers to the change log, and gives the number of the last change applied from this node
ASR Agreement, in which you can view and modify the information for an Advanced Replication-based replication agreement. The fields in this tab page are described in Table A-17, "Fields in the ASR Agreement Tab Page".
|
Note: Be sure to add all host names for all nodes in the DRG into the Replication Group Nodes field. Do this for all nodes in the DRG. |
If you are modifying the values, and want to return to the values that appeared when you first opened this pane, then click Revert. If you are satisfied with your changes, then click Apply.
"Replication Schema Elements" in Oracle Identity Management User Reference lists and describes the replication agreement parameters and indicates those that you can modify.
To add more nodes to the values in a replication agreement entry, run ldapmodify at the command line, referencing an LDIF-formatted file.
Example 25-14 Adding Nodes to a Replication Agreement
This example uses an input file named mod.ldif to add two nodes to a replication agreement:
Edit mod.ldif as follows:
dn: orclagreementid=000001,cn=replication configuration changetype: modify add: orcldirreplgroupdsas orcldirreplgroupdsas: hollis orcldirreplgroupdsas: eastsun-11
Use ldapmodify to update the replication server configset0 parameter value as follows:
ldapmodify –D "cn=orcladmin" –w administrator_password -h host \ -p port -f mod.ldif
Restart the directory replication server.
This procedure modifies the entry containing the replication agreement whose DN is orclagreementid=000001,cn=replication configuration. The input file adds the two nodes, hollis and eastsun-11, into the replication group governed by oraclagreementid=000001.
|
Note: You must include the new nodes—for example,hollis and eastsun-11 in the previous sample LDIF file—in the orclDirReplGroupDSAs parameter on each node in the replicated environment before you start the replication process.
"Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)" explains the process of adding a new node to a replication environment. |
Because Oracle Internet Directory 10g Release 2 (10.1.2) supports only one configuration set for the directory replication server, you do not need to specify a configuration set.
Example 25-15 Modifying the orclExcludedNamingContexts Attribute for an Oracle Database Advanced Replication Replica Agreement
In a replication agreement based on Advanced Replication, the directory replication server uses the value of the orclExcludedNamingcontexts attribute of the replica agreement entry to specify the top level subtrees to be excluded from replication.
In this example, two top level naming contexts—c=us and c=uk—are excluded from Advanced Replication.
Edit the example file mod.ldif as follows:
dn: orclAgreementID=000001, cn=replication configuration Changetype:modify Replace: orclExcludedNamingcontexts orclExcludedNamingcontexts: c=us orclExcludedNamingcontexts: c=uk
Use ldapmodify to update the replication agreement orclupdateschedule attribute.
ldapmodify -D "cn=orcladmin" -w administrator_password -h consumer_host \ -p port -f mod.ldif
Restart the directory replication server.
LDAP-based replication agreement parameters are stored in replication agreement entries, which have the following DN:
orclAgreementID=unique_identifier_of_the_replication_agreement, orclReplicaId=unique_identifier_of_the_supplier, cn=replication configuration
|
Note: Ensure that the agreement is identical at both the supplier and the consumer. The replication server reads the last applied change number and the naming context from the agreement at the supplier node. It reads the other agreement attributes from the consumer. |
To view and modify replication agreement parameters by using Oracle Directory Manager:
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier.
Select the replica agreement you want to view or modify. The following tab pages appear in the right pane:
General, in which you can view and modify LDAP based replication agreement information. The fields in this tab page are described in Table A-19, "Columns in the Replica Agreements Tab Page".
Replica Naming Context, in which you can view, add, delete, and modify LDAP naming context objects. The fields in this tab page are described in Table A-20, "Fields in the Replica Naming Context Tab Page".
"Replication Schema Elements" in Oracle Identity Management User Reference describes the replication agreement parameters and indicates those that you can modify.
Example 25-16 Modifying the orclUpdateSchedule Attribute for a Particular Replica Agreement
The directory replication server uses the orclupdateschedule attribute value of the replica agreement entry as time interval in minutes to determine how often the replication server process the new change logs from the supplier.
This example shows that replication server will process new change logs from the supplier for every minute.
Edit the example file mod.ldif as follows:
dn: orclAgreementID=id_number,orclReplicaId=replica_identifier, cn=replication configuration Changetype:modify Replace: orclupdateschedule orclupdateschedule: 1
Use ldapmodify to update the replication agreement orclupdateschedule attribute.
ldapmodify -D "cn=orcladmin" -w administrator_password -h consumer_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 25-17 Modifying the orclLastAppliedChangeNumber Attribute for a Particular Replica Agreement
The directory replication server uses the value orclLastAppliedChangeNumber attribute to determine the number of last applied change log processed by the consumer.
The modification of the orclLastAppliedChangeNumber attribute must be applied against the supplier node since replication server reads orclLastAppliedChangeNumber from the same duplicate agreement at the supplier.
In this example, orclLastAppliedChangeNumber attribute of the duplication agreement at the supplier is set to 700, which indicates all change logs with changelog number prior to 700 has been processed by the replication server.
|
Note: Do not modify theorclLastAppliedChangeNumber attribute except as instructed during the partial replication add node procedure.
|
Edit the example file mod.ldif as follows:
dn: orclAgreementID=unique_identifier_of_the_replication_agreement, orclReplicaId=unique_identifier_of_the_supplier,cn=replication configuration Changetype:modify Replace: orclLastAppliedChangeNumber orclLastAppliedChangeNumber: 700
Use ldapmodify to update the replication agreement orclupdateschedule attribute at the supplier.
ldapmodify -D "cn=orcladmin" -w administrator_password \ -h supplier_host -p port -f mod.ldif
Restart the directory replication server.
You can change the password for the replication administrator database account on all nodes of a DRG by using the -chgpwd argument to the Replication Environment Management Tool, remtool. To use this argument, enter:
remtool -chgpwd
The remtool utility then prompts you for the MDS Global Name—that is, the name of the Master Definition Site—the current password, and the new password. It then asks you to confirm the new password. If you enter an incorrect current password, then you must run the Replication Environment Management Tool again.
You can also use the -pchgpwd argument to remtool to change the password of the replication DN of a replica.
To change the password only in the replication wallet, $ORACLE_HOME/dap/admin, use the -pchgwalpwd argument to remtool. To use this argument, enter:
remtool -pchgwalpwd
|
See Also: The "remtool" command-line tool reference in Oracle Identity Management User Reference for more information about using this tool |
Oracle Directory Manager enables you to view the last 25 changes you performed, listing them by change log number, the type of operation—namely, add, modify, or delete—in which each occurred, and the entry on which each was made. It allows you select a particular change to see more specific details about it.
To manage the change log, in the navigator pane expand in succession Oracle Internet Directory Servers, directory server instance, then select Change Log Management. The right pane lists the last 25 changes, beginning with the most recent. It tells you the change number, the type of operation in which each change occurred, and the entry on which the change was made.
To see the details of a particular change, in the right pane, select the change, then choose View Properties. The Change Log window appears. The fields for the Change Log window are listed and described in Table A-21, "Fields in the Change Log Window".
In the default configuration for replication, the orclupdateschedule attribute is set to a value of 1, representing 1 minute. You can shorten the replication processing time by changing the value of the orclupdateschedule attribute to 0, representing 1 second.
In directory replication based on Advanced Replication, the default configuration achieves a processing time that is approximately 2.5 minutes:
1 minute for the supplier to prepare the change for sending to the consumer
30 seconds for Advanced Replication to push the change to the consumer
1 minute for the consumer to apply the change
In the case of Advanced Replication, changing the default value for the orclupdateschedule attribute to 0 results in a replication time of 32 seconds. To do this:
Edit mod.ldif as follows:
dn: orclagreementid=orclagreementid=000001, cn=replication configuration, cn=replication configuration changetype:modify replace: orclupdateschedule orclupdateschedule: 0
Upload mod.ldif as follows:
ldapmodify -D "cn=orcladmin" -w administrator_password -h host_name -p port \ -v -f mod.ldif
Restart the directory replication server
oidctl connect=connect_string server=oidrepld instance=instance_number restart
In LDAP-based directory replication, the default configuration achieves a processing time that is approximately 1 minute during which the change is retrieved from the supplier and applied to the consumer. Changing the default value for the orclupdateschedule attribute to 0 results in a replication time of 1 second. To do this:
Edit mod.ldif as follows:
dn: orclAgreementID=unique_identifier_of_the_replication_agreement, orclReplicaId=unique_identifier_of_the_supplier, cn=replication configuration changetype:modify replace: orclupdateschedule orclupdateschedule: 0
On the consumer host, upload mod.ldif as follows:
ldapmodify -h consumer_host_name -p consumer_port -D cn=orcladmin \ –w administrator_password -v -f mod.ldif
Restart the directory replication server
oidctl connect=connect_string server=oidrepld instance=instance_number restart
To help you install and configure a multimaster replication group with fan-out, this section offers an example with four systems as described in Table 25-2.
Table 25-2 Nodes in Example of Partial Replication Deployment
| Node | Host Name | Port |
|---|---|---|
|
Node1 |
mycompany1.com |
3000 |
|
Node2 |
mycompany2.com |
4000 |
|
Node3 |
mycompany3.com |
5000 |
|
Node4 |
mycompany4.com |
6000 |
In this example, the user has set up the following requirements:
Requirement 1: Node1 and Node2 must be synchronized so that changes made on either node are replicated to the other— but the naming context cn=private users, cn=mycompany is to be excluded from this replication.
Requirement 2: The naming context ou=Americas,cn=mycompany on node3 is to be partially synchronized from Node2 so that only changes made under ou=Americas, cn=mycompany on Node2 are replicated to Node3. The following are to be excluded from this replication:
Changes made under cn=customer profile, ou=Americas, cn=mycompany
Changes in the attribute userpassword.
Requirement 3: Node4 is to be configured as a full replica of node 2, that is, changes to all naming contexts in Node2 will be replicated (one-way) to Node4.
Figure 25-1 Example of Fan-Out Replication
To meet the first requirement in this example, we set up a multimaster replication group for Node1 and Node2. To meet the second, we set up a partial replica for Node2 and Node3, and for the third, full LDAP replication from Node2 to Node4.
This section contains these topics:
Task 1: Set up the Multimaster Replication Group for Node1 and Node2
Task 4: Test the Directory Replication Between Node1 and Node2.
Task 5: Install and Configure Node3 as a Partial Replica of Node2
Task 7: Start the Replication Servers on All Nodes in the DRG
Task 8: Install and Configure Node4 as a Full Replica of Node2
Task 1: Set up the Multimaster Replication Group for Node1 and Node2
To set up the multimaster replication group for Node1 and Node2, follow Tasks 1 through 5 in "Installing and Configuring a Multimaster Replication Group".
Task 2: Configure the Replication Agreement
In the replication agreement between Node1 and Node2, specify the value for the orclExcludedNamingcontexts attribute as cn=private users,cn=mycompany. To do this:
Edit the example file mod.ldif as follows:
dn: orclAgreementID=000001,cn=replication configuration Changetype:modify Replace: orclExcludedNamingcontexts orclExcludedNamingcontexts: cn=private users,cn=mycompany
Use ldapmodify to update the replication agreement orclExcludedNamingcontexts attribute at both Node1 and Node2. To do this, enter:
ldapmodify -D "cn=orcladmin" -w administrator_password -h mycompany1.com \
-p 3000 -f mod.ldif
ldapmodify -D "cn=orcladmin" -w administrator_password -h mycompany2.com \
-p 4000 -f mod.ldif
Task 3: Start the Replication Servers on Node1 and Node2
To do this, follow the instructions in "Task 6: Start the Replication Servers on All Nodes in the DRG".
Task 4: Test the Directory Replication Between Node1 and Node2.
To do this, follow the instructions in "Task 7: Test Directory Replication".
Task 5: Install and Configure Node3 as a Partial Replica of Node2
If you want to use the bootstrap capability of partial replication, then follow Tasks 1 through 5 in "Configuring an LDAP-Based Replica by Using Automatic Bootstrapping".
If you want to configure the replica by using the ldifwrite tool, then follow Tasks 1 through 9 in "Configuring an LDAP-Based Replica by Using the ldifwrite Tool".
Identify Node2 as the supplier and Node3 as the consumer.
Task 6: Customize the Partial Replication Agreement
To do this:
To achieve Requirement 2 in this example, the default replication between Node2 and Node3 must be configured first:
In partial replication, the cn=oraclecontext naming context is replicated by default. You can choose not to replicate it by deleting it at both the supplier (Node2, mycompany2.com) and the consumer (Node3, mycompany3.com).
ldapdelete -D "cn=orcladmin" -w administrator_password -h mycompany2.com \ -p 4000 "cn=includednamingcontext000001, \ cn=replication namecontext,orclagreementid=000002, \ orclreplicaid==node2_replica_id, \ cn=replication configuration" ldapdelete -D "cn=orcladmin" -w administrator_password -h mycompany3.com \ -p 5000 "cn=includednamingcontext000001, \ cn=replication namecontext,orclagreementid=000002, \ orclreplicaid==node2_replica_id, \ cn=replication configuration"
To replicate the naming context ou=Americas,cn=mycompany, and to exclude from replication the naming context cn=customer profile, ou=Americas, cn=mycompany and the attribute userpassword, create a naming context object as follows:
Edit the example file mod.ldif as follows:
dn: cn=includednamingcontext000002,cn=replication namecontext,
orclagreementid=000002,orclreplicaid=node2_replica_id,
cn=replication configuration
orclincludednamingcontexts: ou=Americas,cn=mycompany
orclexcludednamingcontexts: cn=customer profile, ou=Americas, cn=mycompany
orclexcludedattributes: userpassword
objectclass: top
objectclass: orclreplnamectxconfig
Use ldapadd to add the partial replication naming context object at both Node2 and Node3.
ldapadd -D "cn=orcladmin" -w administrator_password -h mycompany2.com \ -p 4000 -f mod.ldif ldapadd -D "cn=orcladmin" -w administrator_password -h mycompany3.com \ -p 5000 -f mod.ldif
If you decide to use the automatic bootstrap capability of partial replication, then edit the example file mod.ldif and use ldapmodify to modify the partial replica orclreplicastate attribute at both Node2 and Node3, as described in "Task 5: On the Consumer, Configure the Consumer Replica for Automatic Bootstrapping" .
Task 7: Start the Replication Servers on All Nodes in the DRG
To do this, follow the instructions in "Task 11: Start the Directory Replication Server on the Consumer Replica".
Task 8: Install and Configure Node4 as a Full Replica of Node2
Since full replica replication is the default configuration when the new node is installed as an LDAP replica, use the instructions in "Installing and Configuring an LDAP Replica with Default Settings". When the installer prompts for the supplier information, provide the supplier hostname, mycompany2.com, the supplier port, 4000, and the super user password.
|
Note: While installing node 4 as described in "If you are installing Oracle Internet Directory as a Replica", you will be asked to provide the supplier's hostname, port, and administrator_user_password. For example:Hostname: mycompany2.com
Porg:4000
Administrator_user_password: admin_user_password
|
Task 9: Test the Replication from Node2 to Node4
Test this replication using the instructions in the section entitled "Task 7: Test Directory Replication".
