Release 3.0.1
Part Number A90151-01
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle Internet Directory Administrator's Guide Release 3.0.1 Part Number A90151-01 |
|
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 describes how to install and initialize directory replication server software on a node.
Each node in a group of directory servers holds an updatable copy, also called an updatable replica, of the same naming context or set of naming contexts. These naming contexts are synchronized with each other by replication processing. This group of nodes is called a directory replication group (DRG).
|
Note: The instructions in this section apply to setting up replication in a group of empty nodes. For instructions on adding a node to an existing DRG, see "Adding a Replication Node". If you are deploying more than one Oracle Internet Directory instance on the same machine, then you cannot uniquely identify each directory server instances by the name of its host. In this case, before installing and configuring replication, follow the instructions in "Identifying a Node as Independent of Its Host". |
To install and configure a replication group, perform these general tasks:
Task 1: Install Oracle Internet Directory on All Nodes in the DRG
Task 2: Decide Which Node Will Serve as the Oracle9i Replication Master Definition Site (MDS)
Task 3: At the MDS, Set Up Oracle9i Replication for a Directory Replication Group
Task 4: Load Data into the Directory
Task 5: Start Oracle Directory Server Instances on All the Nodes
Task 7: Start the Replication Servers on All the Nodes
Note that the typical installation of the Oracle9i Enterprise Edition, which is required for the Oracle Internet Directory, includes Oracle9i Replication. By contrast, a typical installation of Oracle9i Standard Edition does not include Oracle9i Replication.
A master definition site (MDS) is any of the Oracle Internet Directory databases in which the administrator is going to run the configuration scripts. A remote master site is any site other than the Master Definition Site that participates in Oracle9i Replication replication.
You must be able to use Oracle Net Services to connect to the MDS database and all other nodes that constitute the DRG.
The following sections lead you through installing and configuring Oracle9i Replication through Oracle Internet Directory installation scripts. More advanced Oracle9i Replication users may prefer to configure Oracle9i Replication through the Oracle9i Replication Manager Tool.
|
See Also:
Oracle9i Replication and the online help for Oracle9i Replication Manager for information on configuring Oracle9i Replication by using the Oracle9i Replication Manager |
Setting up the Oracle9i Replication environment to establish a directory replication group (DRG) requires you to:
Follow these steps, described more fully below, on all nodes in the directory replication group to prepare the Oracle Net Services environment:
To prepare the Oracle Net Services environment for replication:
sqlnet.ora.
The sqlnet.ora file should contain the following parameters at minimum:
names.directory_path = (TNSNAMES) names.default_domain = domain
On UNIX, this file is in $ORACLE_HOME/network/admin
On Windows NT, this file is in ORACLE_HOME\network\admin
tnsnames.ora.
The tnsnames.ora file must contain connect descriptor information in the following format for all Oracle Internet Directory databases:
net_service_name = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = HOST_NAME_OR_IP_ADDRESS) (PORT = 1521)) (CONNECT_DATA = (service_name = service_name)))
On UNIX, this file is in $ORACLE_HOME/network/admin
On Windows NT, this file is in ORACLE_HOME\network\admin
You may want to create multiple rollback segments. You can increase the size of the table spaces and segments to meet your system requirements.
Execute SQL*Plus by typing the following command:
sqlplus system/system_password@net_service_name
At the SQL*Plus prompt, type:
CREATE TABLESPACE table_space_name datafile file_name_with_full_path SIZE 50M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE max_bulk_update transaction_size ex:500M;
At the SQL*Plus prompt, type the following lines for each rollback segment:
CREATE ROLLBACK SEGMENT rollback_segment_name tablespace table_space_name storage (INITIAL 1M NEXT 1M OPTIMAL 2M MAXEXTENTS UNLIMITED);
Repeat the CREATE ROLLBACK SEGMENT command for each rollback segment entered in the initialization parameter file.
init.ora.
Type the following lines in the initialization parameter file:
rollback_segments = (rollback_segment_name_1, rollback_segment_name_2 ...) JOB_QUEUE_PROCESSES = a_minimum_of_total_number_of_LDAP_nodes_minus_one SHARED_POOL_SIZE = 20000000 OPEN_LINKS = a_minimum_of_total_number_of_LDAP_nodes_minus_one
Ensure that the total System Global Area (SGA) does not exceed 50% of your system's physical memory.
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]
To stop and restart the Oracle Internet Directory database, you can use SQL*Plus.
See Also:
|
To configure Oracle9i Replication for the replication group, complete the following steps from the MDS:
$ORACLE_HOME/ldap/bin
\ldap\bin
ldaprepl.sh -asrsetup
This script executes a number of operations.
As the script runs, it asks for the information in the following table, first for the MDS, then for the master sites.
| Information | Definition |
|---|---|
|
Host name |
Name of the computer |
|
Global name |
Net service name of the MDS database, as listed in the file |
|
System password |
system password |
After you have provided the necessary information for the first master site, the script asks if there is another master site.
Y or N. If you enter N, to indicate that you have identified all sites, then it shows a table of the information you have provided, and asks for confirmation. If it is not correct, then press N. The script will start again at the beginning, asking about the MDS again.
After you have provided all the information, the script asks you to verify the correctness of the information. If the information is correct and you press Y, then the script begins configuring the sites.
This process may take a long time, depending on your system resources and the number of nodes in your DRG. The script keeps you informed of its progress.
|
Troubleshooting Tip: If the process fails, then do the following:
Run this command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the failed status and error messages, then this means that Oracle9i Replication set up failed. In this case, you may:
|
|
See Also:
|
To do this, follow the instructions in "Managing Entries by Using Bulk Tools".
To start Oracle directory server instances on all nodes, run the following command:
oidctl connect=net_service_name server=oidldapd instance=instance_number_of_ ldap_server flags='-p port' start
|
See Also:
Chapter 6, "Managing the Oracle Directory Server" for more information on starting an Oracle directory server instance |
You need to configure parameters for:
|
Important:
When you install and configure replication for the first time, you must inform the directory replication server about the existence of the member nodes in the replication agreement. To do this, modify the |
The directory replication server configuration parameters are stored in the replication server configuration set entry, which has the following DN:
cn=configset0,cn=osdrepld,cn=subconfigsubentry
This entry contains replication attributes that control replication processing. You can modify some of these attributes. Note that the orclDirReplGroupAgreement attribute contains a replication agreement identifier. In this release, only one replication agreement is possible.
The next table lists and describes the directory replication server configuration parameters.
| Parameter name | Description | Default Values | Modifiable? |
|---|---|---|---|
|
modifyTimestamp |
Time of entry creation or modification |
|
No |
|
modifiersName |
Name of person creating or modifying the entry |
|
No |
|
orclChangeRetryCount |
Single-valued attribute. The number of processing retry attempts for a change-entry before being moved to the human intervention queue. The value for this parameter must be equal to or greater than 1 (one). |
10 |
Yes |
|
orclPurgeSchedule |
Single-valued attribute. Specifies purge (garbage collection) interval in minutes. Removes entries that are already applied or have been dropped as candidate changes. This thread is initiated periodically based on the frequency that you set. The value for this parameter must be equal to or greater than 1 (one). |
10 minutes |
Yes |
|
orclThreadsPerSupplier |
Number of worker threads directory replication server provides for each supplier for change log processing. The value for this parameter must be equal to or greater than 1 (one). |
5 |
Yes |
|
orclDirReplGroupAgreement |
Multi-valued attribute. Identifies the symmetrical replication agreements for which this server is responsible. |
orclagreementid=000001, |
No |
|
orclChangeLogLife |
Single-valued attribute. Specifies in hours the time for the life of entries in the change log store. 0 (zero) indicates that this is a change number-based purge. See Also: "Change Log Purging" |
0 |
Yes |
To view and modify replication configuration parameters:
Configuration parameters appear in the General tab page. Use this tab page to view replication configuration parameters, and modify many of them. The following table describes the fields in this tab page.
| Field | Description |
|---|---|
|
Modify Timestamp |
Time of entry creation or modification in UTC (Coordinated Universal Time). You cannot modify this parameter. |
|
Modifier's Name |
Name of person creating or modifying the entry. You cannot modify this parameter. |
|
Change Retry Count |
Type the number of attempts that the conflict resolution process tries to apply each update before giving up and logging the incident. The default is 10. |
|
Purge Schedule |
Type the number of minutes in between garbage collections. The replication garbage collection thread removes entries that are already applied or have been dropped as candidate changes. The default is 10. |
|
Number of Threads Per Supplier |
Type the number of worker threads the directory replication server provides for each supplier for change log processing. The default is 5. |
|
Set |
Type the configuration identifier. |
|
Change Log Life |
Type the number of hours for the life of the change log objects. See Also: "Change Log Purging" |
To modify replication configuration parameters by using command-line tools, use the syntax documented in "ldapmodify Syntax".
This example uses an input file named mod.ldif to change the garbage collection interval from the default of 10 minutes to 30 minutes.
mod.ldif as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentrychangetype: modifyreplace:orclPurgeSchedule orclPurgeSchedule: 30
configset0 parameter value as follows:
ldapmodify -h my_host -p 389 -f mod.ldif
This example uses an input file named mod.ldif to change the change log life parameter to 10 hours:
mod.ldif as follows:
dn: cn=configset0,cn=oidrepld,cn=subconfigsubentry changetype: modify replace: orclChangeLogLife orclChangeLogLife: 10
configset0 parameter value as follows:
ldapmodify -h my_host -p 389 -f mod.ldif
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.
mod.ldif as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentrychangetype: modifyreplace: orclChangeRetryCountorclChangeRetryCount: 5
configset0 parameter value as follows:
ldapmodify -h my_host -p 389 -f mod.ldif
This example uses an input file named mod.ldif to change the number of worker threads used in change log processing to 7:
mod.ldif as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclthreadspersupplier orclthreadspersupplier: 7
configset0 parameter value as follows:
ldapmodify -h my_host -p 389 -f mod.ldif
"Restarting Directory Server Instances" for instructions on restarting the directory replication server
See Also:
In the parameter DirectoryReplicationGroupDSAs, type all of the host names of the DSAs in the DRG. Be sure that this information is identical on all the nodes.
Replication agreement parameters are stored in the replication agreement entries which have the following DN:
orclAgreementID=id number,cn=orclreplagreements
This entry contains attributes that pertain only to the nodes participating in this agreement. You can create multiple replication agreements to manage replication between reciprocating nodes, but you can reference only one of them in your start-server message by using Oracle Directory Manager. For Oracle Internet Directory release 3.0.1, only one replication agreement can be used.
To view and modify replication agreement parameters by using Oracle Directory Manager:
The fields in this tab page are described in the following table. You can view the parameters and modify some of them by double-clicking the attributes.
The following table lists and describes the replication agreement parameters.
To add more nodes to the values in a replication agreement entry, run ldapmodify at the command line, referencing an LDIF-formatted file.
This example uses an input file named mod.ldif to add two nodes to a replication agreement:
mod.ldif as follows:
dn: orclagreementid=000001,cn=orclreplagreementschangetype: modifyadd: orcldirreplgroupdsasorcldirreplgroupdsas: hollisorcldirreplgroupdsas: eastsun-11
configset0 parameter value as follows:
ldapmodify -h host -p port -f mod.ldif
This procedure modifies the entry containing the replication agreement whose DN is orclagreementid=000001,cn=orclreplagreements. The input file adds the two nodes, hollis and eastsun-11, into the replication group governed by oraclagreementid 000001.
|
Note:
You must include the new nodes--for example, hollis and eastsun-11 in the above sample LDIF file--in the "Adding a Replication Node" explains the process of adding a new node to a replication environment. |
Because Oracle Internet Directory release 3.0.1 supports only one configuration set for directory replication server, you do not need to specify a configuration set.
To start replication servers on all nodes, type the following command:
oidctl connect=db_connection_string server=oidrepld instance=1
flags='-h host -p port' start
Note that the instance number does not need to be unique across the entire DRG.
|
See Also:
Chapter 6, "Managing the Oracle Directory Server" for information on starting the replication servers |
You can turn off change logging, which occurs in the Oracle directory server, by using the default value of the -l flag in the OID Control Utility command for Oracle directory server from true to false. This is useful if you suspect that the change log file might not be emptying. However, turning change logging off on a given node means that updates on that node cannot be replicated to other nodes in the DRG.
You can turn off the multimaster flag, which occurs in the directory replication server, by using the default value of the -m flag in the OID Control Utility command for Oracle directory server from true to false. This is useful for reducing performance overhead if you are deploying a single master with read-only replica consumers. The multimaster option controls conflict resolution, which serves no purpose if you are deploying a single master.
This method, described in this section, is the easier of the two. The process can be fully automated, and the generated file can be used for partial replication. Use this procedure unless your directory is very large. Backup using this method can take up to seven hours for a directory with one million entries.
This method, described in Chapter 16, "Adding a Node to a DRG by Using the Database Copy Procedure", cannot be fully automated and cannot be reused for partial replication. However, cold backup takes much less time for a large directory server. For example, if your directory has more than a million entries, then use this method.
|
Note: Before you add a replication node, prepare the Oracle Net Services environment. For instructions, see "Prepare the Oracle Net Services Environment for Replication". |
To add a replication node to a functioning DRG of any significant size, follow these steps, each of which is more fully described later in this chapter.
Task 1: Stop the Directory Replication Server on All Nodes
Task 2: Configure the New Node into the LDAP Replication Group on All the Existing Nodes
Task 3: Identify a Sponsor Node and Switch the Sponsor Node to Read-Only Mode
Task 4: Backup the Sponsor Node by Using ldifwrite
Task 5: Perform Oracle9i Replication Add Node Setup
Task 6: Switch the Sponsor Node to Updatable Mode
Task 7: Start the Directory Replication Server on All Nodes Except the New Node
Task 8: Load Data into the New Node by Using bulkload
Task 9: Start LDAP Server on the New Node
Task 10: Configure the LDAP Replication Agreement on the New Node
Task 11: Start the Directory Replication Server on the New Node
To stop the directory replication server, run the following command on each node in the LDAP replication group:
oidctl connect=db_connect_string server=oidrepld instance=1 stop
The following example creates an LDIF file, add_node.ldif, and configures it into the replication group on all the existing nodes.
dn: orclagreementid=000001,cn=orclreplagreements changetype: modify replace: orcldirreplgroupdsas orcldirreplgroupdsas: host_of_the_new_node orcldirreplgroupdsas: host_of_existing_node_1 orcldirreplgroupdsas: host_of_existing_node_2 . . . orcldirreplgroupdsas: host_name_of_existing_node_n
Run the following command against each node in the LDAP replication group:
ldapmodify -h host_name_of_the_node -p port -f add_node.ldif
A sponsor node is one that will supply the data to the new node. To identify a sponsor node and switch it to read-only mode:
change_mode.ldif, containing the following:
dn: changetype: modify replace: orclservermode orclservermode: r
ldapmodify -D "cn=orcladmin" -w welcome -h host_name_of_sponsor_node
-p port -f change_mode.ldif oidctl connect=net_service_name server=oidldapd restart
This restarts all running Oracle directory servers on the sponsor node in Read-Only mode. It takes approximately fifteen seconds for a directory server to restart.
Because this may take a long time, you may start "Task 5: Perform Oracle9i Replication Add Node Setup" while backup is in process.
Enter the following command:
ldifwrite -c db_connect_string -b "" -f output_ldif_file
You can perform this task at the same time as you are performing "Task 4: Backup the Sponsor Node by Using ldifwrite".
From the sponsor node, run the following script:
ldaprepl.sh -addnode
This script executes a number of operations.
As the script runs, it asks for the information in Table 15-1, first for the sponsor node then for the existing master sites.
| Information | Description |
|---|---|
|
Host Name of sponsor node |
Name of the computer |
|
Global name |
Net service name of the MDS or master site database, as listed in |
|
system password |
system password |
When you have identified all the existing master sites, enter N. The script then asks for information regarding the new node. Once you have provided that information, the script shows you a table of the information you have provided, and asks for confirmation.
If the information is not correct, then press N. The script then starts again at the beginning, asking the same information. If the information is correct and you enter Y, then the script begins configuring the sites.
This process can take a long time, depending on your system resources and the size of your DRG. The script keeps you informed of its progress.
|
Troubleshooting Tip: If the process fails, then do the following:
Run this command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the status [failed] and error messages, then this means that Oracle9i Replication set up failed. In this case, you may:
|
To switch the sponsor node to updatable mode:
change_mode.ldif to the following:
dn: changetype: modify replace: orclservermode orclservermode: rw
ldapmodify -D "cn=orcladmin" -w welcome -h host_name_of_sponsor_node
-p port -f change_mode.ldif oidctl connect=net_service_name server=oidldapd restart
To start the directory replication server, type the following command:
oidctl connect=db_connection_string server=oidrepld instance=1
flags='-h host -p port' start
Verify that no directory or replication processes are running on the new node.
To load data, type the following command:
bulkload.sh -connect db_connect_string_of_new_node -generate -load
-restore absolute_path_to_the_ldif_file_generated_by_ldifwrite
To start the LDAP server, type the following command:
oidctl connect=db_connect_string_of_new_node server=oidldapd
instance=1 flags='-p port' start
Run the following command against the new node to add the LDIF file you created in "Task 2: Configure the New Node into the LDAP Replication Group on All the Existing Nodes":
ldapmodify -h host_name_of_the_new_node -p port -f add_node.ldif
To start the directory replication server, type the following command:
oidctl connect=db_connect_string_of_new_node server=oidrepld instance=1
flags='-h host_name_of_new_node -p port' start
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, then you need to delete that node.
You can delete a replication node from a DRG only if there are more than two nodes in the DRG.
To delete a replication node from a directory with fewer than a million entries, follow these steps, each of which is more fully described in this section.
Task 1: Stop the Directory Replication Server on All Nodes
Task 2: Stop All Processes in the Node to be Deleted
Task 3: Delete the Node from the Master Definition Site
Task 4: Start the Directory Replication Server on All Nodes
Task 5: Delete the Node from the Replication Group
Task 6: Restart the Directory Replication Server on the Remaining Nodes
To stop the directory replication server, run the following command on each node in the DRG:
oidctl connect=net_service_name server=oidrepld instance=1 stop
Stop the OID Control Utility and the OID Monitor.
|
See Also:
|
From the MDS, run the following script:
ldaprepl.sh -delnode
This script executes these operations:
orclDirReplGroupDSAs parameter.
As the script runs, it asks for the information in Table 15-2, first for the Master Definition Site then for the node to be deleted.
| Information | Description |
|---|---|
|
Host Name of MDS or master site |
Name of the computer |
|
Global name |
Net service name of the MDS or master site database, as listed in |
Once you have provided that information, the script shows you a table of the information you have provided, and asks for confirmation. If the information is not correct, then press N. The script then starts again at the beginning, asking the same information. If the information is correct and you enter Y, then the script begins configuring the sites.
This process can take a long time, depending on your system resources and the size of your DRG. The script keeps you informed of its progress.
|
Troubleshooting Tip: If the process fails, then do the following:
Run this command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the status [failed] and error messages, then this means that Oracle9i Replication set up failed. In this case, you may:
|
To start the directory replication server, type the following command:
oidctl connect=net_service_name server=oidrepld instance=1
flags='-h host -p port' start
Before deleting the node from the replication group, be sure that all of its changes have been applied to the other nodes.
The following example creates an LDIF file, delete_node.ldif, and configures it into the replication group on all the existing nodes. Notice that this LDIF file does not include the host name of the node to be deleted.
dn: orclagreementid=000001,cn=orclreplagreements changetype: modify replace: orcldirreplgroupdsas orcldirreplgroupdsas: host_name_of_existing_node1 orcldirreplgroupdsas: host_name_of_existing_node2 . . . orcldirreplgroupdsas: host_name_of_existing_node_n
Run the following command against each node in the LDAP replication group:
ldapmodify -h host_name_of_the_node -p port -f delete_node.ldif
After deleting the node, restart the directory replication server on the remaining nodes for greater efficiency. To do this, type the following command:
oidctl connect=db_connection_string server=oidrepld instance=1
flags='-h host -p port' restart
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 below, 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.
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.
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.
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 the 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. Perform the following general steps to address changes in the human intervention queue:
When the directory replication server encounters inconsistent data, you can use the OID reconciliation tool to synchronize the entries on the consumer with those on the supplier. When you do this, perform the following general steps:
"OID Reconciliation Tool Syntax" for syntax and an explanation of how OID reconciliation tool works.
See Also:
In most deployments, a node in a DRG is uniquely identified by the name of the host where Oracle Internet Directory is installed. However, when there are multiple installations of Oracle Internet Directory on the same host, the host name cannot be a unique node identifier. In this case, you should use the orclReplicaId attribute of the Root DSE.
When you identify a node in a DRG by using orclReplicaId instead of the host name, follow the steps in this section.
orclReplicaId a unique value. For example, if there are three nodes on the same computer, and the corresponding directory servers are running on port1, port2 and port3, then you would perform following modifications:
ldapmodify -v -h host -p port1 << EOF dn: changetype: modify replace: orclreplicaid orclreplicaid : replica001 ldapmodify -v -h host -p port2 << EOF dn: changetype: modify replace: orclreplicaid orclreplicaid : replica002 ldapmodify -v -h host -p port3 << EOF dn: changetype: modify replace: orclreplicaid orclreplicaid : replica003
orclreplicaid on all the nodes, perform replication setup as described in "Installing and Configuring Replication".
orcldirreplgroupdsas attribute the same value you assigned to orclreplicaid. To use the previous example, you would give the orcldirreplgroupdsas attribute the values replica001, replica002, replica003.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|