| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
Replication is the mechanism that maintains exact duplicates of specified naming contexts on multiple nodes. This chapter tells you how to install and configure replication in Oracle Internet Directory.
At 10g (10.1.4.0.1), there are four types of installation for replication. They are:
Installing Oracle Internet Directory as a master
Installing Oracle Internet Directory as an Advanced Replication-based replica
Installing Oracle Internet Directory as a one-way LDAP-based replica
Installing Oracle Internet Directory as a two-way LDAP-based replica
The procedures for installing the three types of replica are very similar, so they are grouped into one topic. The few differences are pointed out in the procedures.
This chapter contains these topics:
Preliminary Information for Installing and Configuring a Replication Group
Installing and Configuring One-Way or Two-Way LDAP-Based Replication
Example: Installing and Configuring a Multimaster Replication Group with Fan-Out
For either multimaster replication or two-way fan-out replication, if any node in the replication group is running 10g (10.1.4.0.1), then all nodes must be running 10g (10.1.4.0.1).
In a one-way fan-out deployment, the supplier of a 10g (10.1.4.0.1) consumer can be running 10g Release 3 (10.1.2.0.2). This is true for a supplier of either LDAP-based replication or Advanced Replication-based replication.
This section describes the types of installation you need to perform to configure a replication group. It also introduces the Replication Environment Management Tool, which enables you to perform various configuration tasks.
This section contains the following topics:
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 an Advanced Replication-Based Replica or as a One-Way or Two-Way LDAP-Based Replica", and choose "Advanced Replication" when that choice appears.
LDAP replicas can be either one-way or two-way.
One-way LDAP replicas are read-only. Only changes made to the master are replicated to the replica. There is no replication from the replica to the master.
To create a one-way LDAP replica, follow the directions in the section entitled "If You are Installing Oracle Internet Directory as an Advanced Replication-Based Replica or as a One-Way or Two-Way LDAP-Based Replica", and choose "One-way LDAP replica" when that choice appears.
Two-way LDAP replicas are updatable in both directions. Changes made to either replica are replicated to the other.
To create a two-way LDAP replica, follow the directions in the section entitled "If You are Installing Oracle Internet Directory as an Advanced Replication-Based Replica or as a One-Way or Two-Way LDAP-Based Replica", and choose "Two-way LDAP replica" when that choice appears.
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. You can do this for both one-way and two-way replicas.
|
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 a one-way (read-only) LDAP replica, select One-Way LDAP Replica.
For a two-way (read-write) LDAP replica, select Two-Way LDAP Replica
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: Theremtool command-line tool reference in Oracle Identity Management User Reference for more information about the Replication Environment Management Tool |
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)
|
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 (10.1.4.0.1), 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.
When you add a node to a DRG, it must be running the same version of Oracle Internet Directory as the other nodes in the DRG. If you want to add a new 10g (10.1.4.0.1) node to a DRG containing nodes at an earlier release, first upgrade all existing nodes to 10g (10.1.4.0.1).
This section discusses the general tasks you perform when installing and configuring a multimaster replication group. It contains these topics:
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:
|
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 an Advanced Replication-Based Replica or as a One-Way or Two-Way LDAP-Based 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 \ –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.
|
Note: If Oracle Delegated Administration Services is not configured, you might see an error message similar to this when you runremtool with the -backupmetadata option:
Failed to add "orclApplicationCommonName=ias.acme.com, cn=IAS Instances, cn=IAS, cn=Products, cn=OracleContext" as "uniquemember" to entry "cn=Associated Mid-tiers, orclapplicationcommonname=DASApp, cn=DAS,cn=products, cn=OracleContext at replica ldap://myhost:389 Please ignore this error message. |
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.)
If the wallets do not exist on a specific site, create them by typing the following command on the remote node:
oidpasswd connect=connect_string create_wallet=true
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/ldap/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 Chapter 30, "Oracle Internet Directory Replication Installation and Configuration". |
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 connect="connect_string" check="TRUE" \ generate="TRUE" file="file_with_absolute_path_name"
|
Note: If data is extracted from Oracle Internet Directory usingldifwrite, then, in addition to other options, use the restore="TRUE" option to restore the operational attributes. |
On the same node, enter:
bulkload connect="connect_string_1" load="TRUE"
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 connect="connect_string_2" load="TRUE"
then enter
bulkload connect="connect_string_3" load="TRUE"
and so on, until you loaded the data onto all the nodes in the DRG.
|
See Also: Thebulkload 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 4, "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: Chapter 6, "Process Control of Oracle Internet Directory Components" for information on Oracle Internet Directory process control. "Conflict Resolution in Oracle Replication" Chapter 7, " 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 30.3.2.3.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 an Advanced Replication-Based Replica or as a One-Way or Two-Way LDAP-Based 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 connect="connect_string" \ basedn="orclAgreementID=000001,cn=replication configuration" \ file="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: Theremtool 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 connect="db_connect_string_of_new_node" check="TRUE" generate="TRUE" \ load="TRUE" restore ="TRUE" \ file="absolute_path_to_the_ldif_file_generated_by_ldifwrite"
|
Note: If you load data from an earlier version of Oracle Internet Directory, such as 10g Release 2 (10.1.2.0.2) onto a node running 10g (10.1.4.0.1), you must update the password policy entries as described in "Password Policy and Fan-out Replication". |
To start the directory server, type the following command on the new node:
opmnctl startproc ias-component=OID
|
Note: If you need to change configuration or agreement parameters, see Chapter 31, "Oracle Internet Directory Replication Monitoring and Management". |
To start the directory replication server, type the following command on the new node:
oidctl connect=db_connect_string_of_new_node server=oidrepld \ instance=1 flags="-p port" start
|
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: Theopmn 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: Theremtool 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. |
To start the directory replication server, type the following command on each of the remaining nodes of the DRG:
oidctl connect=connect_string server=oidrepld instance=1 \ flags='-h host -p port' start
This section contains these topics:
Installing and Configuring a One-Way or Two-Way LDAP Replica with Default Settings
Installing and Configuring an LDAP-Based Replica with Customized Settings
"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:
In LDAP-based replication, only the naming contexts listed in the namingcontexts attribute of the root DSE can be replicated to the consumer.
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 (10.1.4.0.1) LDAP replica to an Oracle Internet Directory 10g master that is running an earlier version, such as 10g Release 2 (9.0.4) or 10g Release 2 (10.1.2). You can also upgrade an LDAP replica of a 10g (9.0.4) or (10.1.2 master to 10g (10.1.4.0.1). Be aware, however, that earlier releases do not support all the features of 10g (10.1.4.0.1).
|
Note: Make sure the schemas are synchronized. Otherwise, the replication server might not be able to apply changes to the consumer replica. |
Two-way LDAP-based replication is not backward compatible. It is only supported between replicas that are both running 10g (10.1.4.0.1).
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, use the bulkload utility to load data to all replicas in a group.
Use bulkload with the check="TRUE", generate="TRUE", and restore="TRUE" arguments, and then with the load="TRUE" argument. Preserve the operational attributes by using the same intermediate files (generated by using the generate="TRUE" argument) for all replicas. As of 10g (10.1.4.0.1), you can load multiple replicas in the same invocation of the bulkload command by using connect="connect_string" with the appropriate connect string for each replica.
Backup using this method can take a long time for a directory with one million entries.
|
See Also:
|
This section discusses using default namingcontext configuration settings as a 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 an Advanced Replication-Based Replica or as a One-Way or Two-Way LDAP-Based Replica" .
For a one-way (read-only) LDAP replica, select One-Way LDAP Replica.
For a two-way (read-write) LDAP replica, select Two-Way 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.
After Task 2 has completed, the replication server on the new replica is automatically started. If this is a one-way replica, you do not need to do anything else. If this is a two-way replica, however, you must ensure that the replication server is started at both the sponsor and the new replica.
To start or restart the Oracle Internet Directory replication server at the sponsor replica, type:
oidctl server=oidrepld connect=connect_string_of_sponsor replica \ instance=instance_number_of_consumer_replica \ flags= "-p port_of_oid_server_running_at_sponsor_replica \ -h hostname_of_sponsor_replica" start
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 30-1 compares these two methods.
Table 30-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: Ensure the Directory Replication Servers are Started
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.
|
Note: If Oracle Delegated Administration Services is not configured, you might see an error message similar to this when you runremtool with the -backupmetadata option:
Failed to add "orclApplicationCommonName=ias.acme.com, cn=IAS Instances, cn=IAS, cn=Products, cn=OracleContext" as "uniquemember" to entry "cn=Associated Mid-tiers, orclapplicationcommonname=DASApp, cn=DAS,cn=products, cn=OracleContext at replica ldap://myhost:389 Please ignore this error message. |
|
See Also: Theremtool command-line tool reference in Oracle Identity Management User Reference for more information about remtool 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 on the consumer replica:
remtool -paddnode [-v] [-bind supplier_host_name:port/replication_dn_password]
The remtool utility will prompt for agreement type. Select One-Way or Two-Way LDAP, depending on which type of replica you are adding.
|
See Also: Theremtool 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: Chapter 31, "Oracle Internet Directory Replication Monitoring and Management" 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.
The exact procedure for starting the replication servers depends on whether this is a one-way or a two-way replica.
For one-way LDAP replication, you must start the replication server at the consumer. Type:
oidctl server=oidrepld connect=connect_string_of_consumer_replica \ instance=instance_number_of_consumer_replica \ flags= "-p port_of_oid_server_running_at_consumer \ -h hostname_of_sponsor_replica -m false" start
Using the -m false option is recommended when starting the Oracle Internet Directory replication server at the consumer for one-way LDAP replication. It disables conflict resolution for better performance.
For two-way LDAP replication, you must start the Oracle Internet Directory replication servers at both the sponsor replica and the new replica, as follows:
Start or restart the replication server at the sponsor replica. Type:
oidctl server=oidrepld connect=connect_string_of_sponsor_replica \ instance=instance_number_of_sponsor_replica \ flags= "-p port_of_oid_server_running_at_sponsor_replica -h hostname_of_consumer_replica" start
Start the replication server at the new replica. Type:
oidctl server=oidrepld connect=connect_string_of_consumer_replica \ instance=instance_number_of_consumer_replica \ flags= "-p port_of_oid_server_running_at_new_replica \ -h hostname_of_consumer_replica"
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 6: Change the Directory Server at the Supplier to Read/Write Mode
Task 10: Ensure the Directory Replication Servers are Started
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 on the consumer replica:
remtool -paddnode [-v] [-bind supplier_host_name:port/replication_dn_password]
The remtool utility will prompt for agreement type. Select One-Way or Two-Way LDAP, depending on which type of replica you are adding.
|
See Also: Theremtool command-line tool reference in Oracle Identity Management User Reference for more information about the Replication Environment Management Tool |
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 connect="connect_string_of_sponsor_node" \ basedn="replication_agreement_dn_retrieved_in_step_1" \ file="name_of_output_LDIF_file"
|
See Also: "Determining What Is to Be Replicated in LDAP-Based Partial Replication" The |
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 connect="connect_string_of_replica" basedn="naming_context"
Perform this step for each naming context that was backed up in "Task 5: 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 connect="connect_string_of_replica" append="TRUE" check="TRUE" \ generate="TRUE" restore="TRUE" file="backup_data.ldif" bulkload connect="connect_string_of_replica" load="TRUE"
|
Note: If you load data from an earlier version of Oracle Internet Directory, such as 10g Release 2 (10.1.2.0.2) onto a node running 10g (10.1.4.0.1), you must update the password policy entries as described in "Password Policy and Fan-out Replication". |
|
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.
The exact procedure for starting the replication servers depends on whether this is a one-way or a two-way replica.
For one-way LDAP replication, you must start the replication server at the consumer. Type:
oidctl server=oidrepld connect=connect_string_of_consumer_replica \ instance=instance_number_of _consumer_replica \ flags= "-p port_of_oid_server_running_at_consumer_replica \ -h hostname_of_consumer_replica -m false" start
Using the -m false option is recommended when starting the Oracle Internet Directory replication server at the consumer for one-way LDAP replication. It disables conflict resolution for better performance.
For two-way LDAP replication, you must start the Oracle Internet Directory replication servers at both the sponsor replica and the new replica, as follows:
Start or restart the replication server at the sponsor replica. Type:
oidctl server=oidrepld connect=connect_string_of_sponsor_replica \ instance=instance_number_of_sponsor_replica \ flags= "-p port_of_oid_server_running_at_sponsor_replica -h hostname_of_sponsor_replica" start
Start the replication server at the new replica. Type:
oidctl server=oidrepld connect=connect_string_of_consumer_replica \ instance=instance_number_of_consumer_replica \ flags="-p port_of_oid_server_running_at_new_replica \ -h hostname_of_consumer_replica"
In 10g (10.1.4.0.1), Oracle Internet Directory supports more fine-grained password policies than in previous releases. This can cause problems when a master node is an earlier version, such as 10g Release 2 (10.1.2.0.2), and the new fan-out node is 10g (10.1.4.0.1). The password policy entries from the master node might not behave as expected when bootstrapped or migrated to the fan-out node. To correct this problem, as part of the fan-out node setup, after the data from the master is bootstrapped or migrated, you must update the password policy entries by invoking the Java class oracle.ldap.oidinstall.backend.OIDUpgradePasswordPolicies. The command-line syntax is as follows:
java –cp oracle_home/ldap/lib/oidca.jar:oracle_home/ldap/jlib/ldapjclnt10.jar oracle.ldap.oidinstall.backend.OIDUpgradePasswordPolicies host port bindDN bindPassword oracle_home[protocol]
Table 30-2 describes the command-line parameters.
Table 30-2 Command-line Parameters to OIDUpgradePasswordPolicies
| Parameter | Description |
|---|---|
|
|
The host on which the 10g (10.1.4.0.1) directory server is running |
|
|
The port on which the 10g (10.1.4.0.1) directory server is listening. If the protocol is |
|
|
The privileged administrative user, usually |
|
|
The user password associated with the bindDN |
|
|
The Oracle home for this instance of Oracle Internet Directory |
|
|
An optional parameter. It should be |
All actions performed by the tool are logged to ppUpgrade.log in the oracle_home\ldap\log directory.
|
Note: Before running the tool, ensure that the appropriate environment variable is set correctly:
|
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-24, "Fields in the Replica Agreement: 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-24, "Fields in the Replica Agreement: 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 30-1 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 30-2 Deleting a Naming Context Object
To delete the naming context object created in Example 30-1, 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 30-3 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 30-4 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 30-5 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.
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 30-6 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 30-7 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 30-8 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: Thehiqretry.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 Comparison and 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 Oracle Internet Directory Comparison and 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:
|
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 30-3.
Table 30-3 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 |
|
Node5 |
mycompany5.com |
7000 |
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.
Requirement 4: Node5 is to be configured as a two-way (updatable) full replica of Node1.
Figure 30-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 10: Install and Configure Node5 as a Two-Way Replica of Node1
Task 11: Test the Two-Way Replication Between Node1 and Node5
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 10: Ensure the Directory Replication Servers are Started".
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 a One-Way or Two-Way 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 an Advanced Replication-Based Replica or as a One-Way or Two-Way LDAP-Based Replica", you will be asked to provide the supplier's hostname, port, and password of the super usercn=orcladmin. |
Task 9: Test the Replication from Node2 to Node4
Test this replication using the instructions in the section entitled "Task 7: Test Directory Replication".
Task 10: Install and Configure Node5 as a Two-Way Replica of Node1
Because full replica replication is the default configuration when the new node is installed as an LDAP replica, follow the instructions in "Installing and Configuring a One-Way or Two-Way LDAP Replica with Default Settings". When the installer prompts for the supplier information, provide the supplier hostname, mycompany1.com, the supplier port, 3000, and the super user password.
Task 11: Test the Two-Way Replication Between Node1 and Node5
Create an entry at Node1 using either Oracle Directory Manager or the ldapadd command-line tool. Wait for the entry to be replicated at Node5. After the entry is replicated to Node5, apply a change to that entry at Node5 using either the ldapmodify command-line tool or Oracle Directory Manager. The change will be replicated to Node1.
This section contains the following topics:
This section describes limitations and warnings related to the use of replication failover.
As of Oracle Internet Directory 10g (10.1.4.0.1), replication failover requires administrator intervention.
Following failover, you must compare and reconcile the consumer with the new supplier.
The new agreement must be of the same type and direction as the old agreement.
Only two topology types are supported. See "Replication Failover".
When a supplier fails, its directly connected replica can only fail over to another directly connected replica of the failed supplier.
The replication filtering policy for the agreement between the new supplier and old supplier must match that between the old supplier and consumer.
In most cases, you should fail over the replica in a way that preserves the original replica type. In the case shown in Figure 30-2, node 2 is the old supplier for both node 1 and 3, and node 1 is read-only. When node 2 fails, you could, in theory, set up either node 1 or 3 as the new supplier node. Best practice, however, is to fail over node 1 so that node 3 is the supplier. This preserves node 1's original, read-only replica type.
If the new agreement is a two-way agreement, after you compare and reconcile the consumer with its new supplier, you must also compare and reconcile all other replicas that are connected to the new supplier with the new supplier. For example, in Figure 30-3, Node 2 has a two-way agreement with Node 3. Node 3 is connected to another replica, Node 4. When Node 2 fails, you set up a two-way agreement between node 3 and node 1. After comparing and reconciling node 3 with node 1, you must also compare and reconcile Node 4 with node 3 to ensure that the replicas are synchronized.
There are two types of replication failover. They are:
Stateless
Time-based
Use stateless failover when you are unable to plan for the failover in advance. Stateless replication failover makes no assumptions about the state of the replicas. You can fail over to a new supplier at any time. Stateless failover requires more work after failover to synchronize the nodes.
Use time-based failover for planned failover. Time-based failover results in less work after failover. However, it requires some setup ahead of time to ensure that the following assumptions are true at the time of failover:
The nodes are mostly synchronized
The new supplier has preserved its change logs so that complete synchronization can be achieved quickly.
This section explains how to perform a stateless replication failover. It consists of the following tasks:
Task 1: Stop all Directory Replication Server on related Nodes
Task 2: Break Old Replication Agreement and Setup New Agreement
Task 7: Start all Directory Replication Server on related Nodes
Stop the Oracle directory replication servers on the new supplier, old supplier and consumer, by typing:
oidctl connect=db_connect_string server=oidrepld instance=instance_number \ host=hostname stop
|
See Also:
|
Break the old replication agreement between the old supplier and consumer and set up a new agreement between the new supplier and consumer. Do this by using the Replication Environment Management Tool. Type:
remtool -pchgmaster [-v] [-bind consumer_host::port_number/replication_dn_password]
Obtain the last change number from the new supplier.
For a one-way agreement, use the following command:
ldapsearch -h new_supplier_host -p port_number -b "" \ -s base "objectclass=*" lastchangenumber
For a two-way agreement, use the following command:
ldapsearch -h consumer_host -p port_number -b "" \ -s base "objectclass=*" lastchangenumber
Save this number!
Use the Oracle Internet Directory Comparison and Reconciliation Tool to compare and reconcile the new supplier and consumer. For a one-way agreement, type:
oidcmprec operation=reconcile \ source=new_supplier_host:port/new_supplier_replication_dn_passwd \ destination=consumer_host:port/consumer_replication_dn_passwd \ base='""' scope=sub
For a two-way agreement, type:
oidcmprec operation=merge \ source=new_supplier_host:port/new_supplier_replication_dn_passwd \ destination=consumer_host:port/consumer_replication_dn_passwd \ base='""' scope=sub
This example assumes that the entire directory is replicated and, therefore, that base is set to " ". If you are using partial replication, use the base and dns2exclude arguments to the oidcmprec tool to include the desired DIT.
Modify the new agreement with the retrieved last applied number at the new supplier. To do this:
Create an LDIF file with the last change number you retrieved in "Task 3: Save Last Change Number".
For a one-way agreement, it should look similar to this:
dn: agreement_dn changetype: modify replace: orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host: last_change_number_retrieved. - replace: orclLastAppliedChangeNumber;transport$new_supplier_host$consumer_host orclLastAppliedChangeNumber;transport$new_supplier_host$consumer_host: last_change_number_retrieved_from_new_supplier
For a two-way agreement, it should look similar to this:
dn: agreement_dn changetype: modify replace: orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host: last_change_number_retrieved_from_new_supplier - replace: orclLastAppliedChangeNumber;transport$new_supplier$consumer orclLastAppliedChangeNumber;transport$new_supplier$consumer: last_change_number_retrieved_from_new_supplier - replace: orclLastAppliedChangeNumber;apply$consumer_host$new_supplier_host orclLastAppliedChangeNumber;apply$consumer_host$new_supplier_host: last_change_number_retrieved_from_consumer - replace: orclLastAppliedChangeNumber;transport$consumer_host$new_supplier_host orclLastAppliedChangeNumber;transport$consumer_host$new_supplier_host: last_change_number_retrieved_from_consumer
Modify the agreement by using ldapmodify, as follows:
ldapmodify -D "cn=orcladmin" -w password -h host_name -p port_number \ -f LDIF_file
If the old supplier was down when you performed "Task 2: Break Old Replication Agreement and Setup New Agreement", the old agreement on the old supplier was not cleaned up. Clean it up now by using the Replication Environment Management Tool. Type:
remtool -pcleanup -agrmt [-v] [-bind consumer_host::port_number/replication_dn_password]
Start the Oracle directory replication servers on the new supplier, the old supplier and the consumer, by typing:
oidctl connect=db_connect_string server=oidrepld instance=instance_number \ host=hostname flags='-p port_number' start
|
See Also:
|
This section explains how to perform a time-based replication failover. It contains these topics:
Task 1: Configure Change Log Garbage Collection Object on New Supplier
Task 5: Stop all Directory Replication Servers on Related Nodes
Task 6: Break Old Replication Agreement and Set Up New Agreement
Task 9: Start All Directory Replication Servers on Related Nodes
Configure the changelog purging configuration entry on the new supplier so that it preserves change logs for the desired period of time, for example, 24 hours, as follows:
Create an LDIF file similar to this:
dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry changetype:modify replace: orclpurgetargetage orclpurgetargetage: 24
Apply the LDIF file by typing:
ldapmodify -p port -h host -D dn -w password -f LDIF_file
Obtain the last change number from the new supplier, as follows:
ldapsearch -h new_supplier_host -p port_number -D cn=orcladmin -w admin_pwd \ -b "" -s base "objectclass=*" lastchangenumber
Save this number!
Enable change log regeneration at the new supplier, as follows:
Create an LDIF file like this:
dn: changetype: modify replace: orcldiprepository orcldiprepository: TRUE
Apply the LDIF file by typing:
ldapmodify -D "cn=orcladmin" -w password -h host_name -p port_number \ -f LDIF_file
Wait for a period of time no greater than the value of orclpurgetargetage in the changelog purging configuration entry.
Stop the Oracle directory replication servers on the new supplier, old supplier and consumer, by typing:
oidctl connect=db_connect_string server=oidrepld instance=instance_number host=hostname stop
|
See Also:
|
Break the old replication agreement between the old supplier and the consumer, then set up a new agreement between the new supplier and the consumer. Do this by using the Replication Environment Management Tool, as follows:
remtool -pchgmaster [-v] [-bind hostname:port_number/replication_dn_password]
Modify the new agreement at the new supplier so that its last applied change number has the value you retrieved in "Task 2: Save Last Change Number from New Supplier", as follows:
Create an LDIF file with the retrieved last applied change number, similar to this:
dn: agreement_dn changetype: modify replace: orclLastAppliedChangeNumber orclLastAppliedChangeNumber: last_change_number_retrieved
Apply the LDIF file to the agreement by using ldapmodify:
ldapmodify -D "cn=orcladmin" -w password -h host_name -p port_number \ -f LDIF_file
If the old supplier was down when you performed "Task 6: Break Old Replication Agreement and Set Up New Agreement", the old agreement on the old supplier was not cleaned up. Clean it up now by using the Replication Environment Management Tool. Type:
remtool -pcleanup -agrmt [-v] [-bind hostname:port_number/replication_dn_password]
Start the Oracle directory replication servers on the new supplier, the old supplier and the consumer, by typing:
oidctl connect=db_connect_string server=oidrepld instance=instance_number host=hostname start
|
See Also:
|
