Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory 11g Release 1 (11.1.1) E10029-02 |
|
![]() Previous |
![]() Next |
Replication is the process of copying and maintaining the same naming contexts on multiple directory servers. It can improve performance by providing more servers to handle queries and by bringing the data closer to the client. It improves reliability by eliminating risks associated with a single point of failure.
Before reading this chapter, please see Chapter 6, "Understanding Oracle Internet Directory Replication" for an introduction to basic replication concepts.
This chapter presents some information that is common to both Advance Replication-based replication and LDAP-based replication. The procedural sections of the chapter describe how to set up LDAP-based replication and multimaster replication with fan-out. For information and procedures specific to Oracle Database Advanced Replication-based replication, please see Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."
See Also: Oracle Fusion Middleware High Availability Guide for information on setting up replication in high availability configurations. |
This chapter contains the following topics:
Converting an Advanced Replication-Based Agreement to an LDAP-Based Agreement
Setting Up an LDAP-Based Replication Agreement by Using the Replication Wizard
Testing Replication by Using Oracle Directory Services Manager
Setting Up an LDAP-Based Replication by Using the Command Line
Note: All references to Oracle Single Sign-On or Oracle Delegated Administration Services in this chapter refer to Oracle Single Sign-On 10g (10.1.4.3.0) or later and Oracle Delegated Administration Services 10g (10.1.4.3.0) or later. |
If you are unfamiliar with basic replication concepts, please see Chapter 6, "Understanding Oracle Internet Directory Replication" before reading this introduction.
This introduction contains the following topics:
Oracle Internet Directory supports two replication transport mechanisms.
LDAP-based replication uses the industry-standard Lightweight Directory Access Protocol Version 3. You can set up LDAP-based replication in one-way, two-way, and multimaster configurations. This is the recommended protocol for most environments.
Oracle Database Advanced Replication-based replication uses the replication capability of Oracle Database. Only multimaster configurations are supported. (You can create a single master DRG by switching all nodes in a group but one to read-only mode.)
If you must replicate Oracle Single Sign-On data, you must use Oracle Database Advanced Replication-based replication. For information and procedures specific to Advanced Replication-based replication, please see Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."
You can convert an existing Oracle Database Advanced Replication-based multimaster agreement to an LDAP-based multimaster agreement. by using remtool -asr2ldap
. See "Converting an Advanced Replication-Based Agreement to an LDAP-Based Agreement".
See Also: Theremtool command-line tool reference in Oracle Fusion Middleware User Reference for Oracle Identity Management for more information about the Replication Environment Management Tool |
The following methods are available for setting up Oracle Internet Directory replication.
The recommended method for setting up LDAP-based replication is to use the replication wizard in Oracle Enterprise Manager Fusion Middleware Control. The procedure is described in "Setting Up an LDAP-Based Replication Agreement by Using the Replication Wizard". You can also use the wizard for modifying an existing replication agreement, as described in "Viewing or Modifying a Replication Setup by Using the Replication Wizard" and "Deleting an LDAP-Based Replication Agreement by Using the Replication Wizard".
You must use command line tools to set up Advanced Replication-based replication. You can also use command line tools to set up LDAP-based replication.
Command-line setup of LDAP-based replication is described in "Setting Up an LDAP-Based Replication by Using the Command Line". Command-line setup of Advanced Replication-based replication is described in Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."
When setting up replication from the command line, you use the oidctl
command for stopping and starting the replication server. You use bulk tools for backing up data and loading it to other nodes. You use LDAP tools for a few operations.
Optionally, you can use the bootstrap capability of the replication server for the initial data migration.
You use the Replication Environment Management Tool, remtool
, to perform various replication-related tasks, including:
Setting up a replication group
Converting an existing Oracle Database Advanced Replication-based agreement to an LDAP multimaster agreement.
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
See Also: Theremtool command-line tool reference in Oracle Fusion Middleware User Reference for Oracle Identity Management for more information about the Replication Environment Management Tool |
It is possible to set up replication on a new host by copying the Oracle Database from an existing host. This is a complex procedure that is not recommended for most environments. The procedure is described in Appendix L, "Adding a Directory Node by Using the Database Copy Procedure."
Whether you are using the replication wizard in Fusion Middleware Control or the command line, you can use the bootstrap capability of the replication server for the initial data migration.
You set the bootstrap flag by setting the attribute orclreplicastate
to 0
under the replicadn
.
When a replica is in bootstrap mode, the supplier node must be in on line mode (orclreplicastate=1
). Do not set the supplier and consumer to bootstrap at same time.
Bootstrap cannot be used for initial data migration on a node that has more than one supplier. Therefore, bootstrap is limited to the following types of replica:
A leaf replica, that is, one that has no consumer replicas.
A primary replica in a two-node LDAP-based multi-master replication agreement, provided it has no two-way fanout replicas.
A non-primary replica in an LDAP-based multimaster replication agreement with two or more nodes, provided it has no two-way fanout replicas.
A fanout replica with only one supplier
If you set the bootstrap flag (orclreplicastate=0
under replicadn
) of any other replica, the replication server throws one of these messages:
bootstrapping against non-leaf replica is not allowed bootstrap against master replica is not allowed
Note: Bootstrap is not allowed for Oracle Database Advanced Replication replicas. |
When you set up replication, you create a container called a replication agreement in the DIT on each of the participating hosts. The attributes of the replication agreement entry are described in "The Replication Agreement Entry".
If you use the replication wizard in Oracle Enterprise Manager Fusion Middleware Control, your selections on the Settings page of the wizard specify the replication agreement attributes that control connection and scheduling.
Your choices on that page include:
Whether the replication server should use same connection for performing multiple LDAP operations (Keep Alive) or open a new connection for each LDAP operation (Always Use New Connection).
The frequency at which replication should occur (Replication Frequency).
The interval at which the replication server should repeat the change application process (Human Intervention Queue Schedule). See "How the Multimaster Replication Process Adds a New Entry to a Consumer" for more information about the change application process and the human intervention queue.
The replication agreement also contains the replication contexts. These are discussed in more detail in "LDAP Replication Filtering for Partial Replication". The attributes are described in "The Replication Agreement Entry".
In addition to the replication agreement entry, the DIT includes several other entries that contain attributes that control replication. The entries and their attributes are described in Chapter 39, "Managing Replication Configuration Attributes." Once you have set up replication, you can manage these attributes.
Oracle Enterprise Manager Fusion Middleware Control has a Replication page, separate from the replication wizard, that enables you to configure replication attributes. You can also modify replication attributes by using LDAP tools. These methods are described in Chapter 40, "Managing and Monitoring Replication."
See Chapter D, "How Replication Works" for detailed information about replication architecture and the replication process.
The following rules apply to LDAP-based replication:
If you have multiple Oracle Internet Directory instances that use the same Oracle Database, only one of the instances can be set up for replication.
LDAP Multimaster replication is not backward compatible. It is only supported between replicas that are running 11g Release 1 (11.1.1).
For either multimaster replication or two-way fan-out replication, all nodes must be running the same release of Oracle Internet Directory. Therefore, you must turn off replication while performing rolling upgrades.
You can add a one-way fan-out replica that is running a newer release than its supplier. For example, in Figure 6-5, "Example of Fan-Out Replication", Node F can be running a newer release than the other nodes.
In general, 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.
More specifically, if you add a new Oracle Internet Directory 11g Release 1 (11.1.1.2) node to an existing DRG as a one-way fan-out replica, there is no need to upgrade other nodes of DRG. For all other types of replication, first upgrade the nodes in the DRG before adding the new node. This is true whether the existing nodes are running a 10g release or 11g Release 1 (11.1.1.1). For example, in Figure 6-5, "Example of Fan-Out Replication", before adding an Oracle Internet Directory 11g Release 1 (11.1.1.2) node as Node E, you must first update Nodes A, B, C and G to 11g Release 1 (11.1.1.2).
In LDAP-based replication, only the naming contexts listed in the namingcontexts
attribute of the root DSE can be replicated to the consumer.
See Also: The discussion of namingcontexts in: |
The supplier of an LDAP-based replica can be a master node that is not a member of any replication group, a member of a multimaster replication group, or another LDAP-based replica.
See Also: Oracle Fusion Middleware Installation Guide for Oracle Identity Management for instructions on installing Oracle Internet Directory. |
An LDAP-based replica can be a consumer for another LDAP-based replica. That consumer is then called a fan-out replica.
Note: Make sure the schemas are synchronized. Otherwise, the replication server might not be able to apply changes to the consumer replica. |
The new consumer node must be empty. That is, Oracle Internet Directory must be newly installed.
This section contains these topics:
Authentication is the process by which the Oracle directory replication server establishes the true identity of itself when connecting to the directory server. It occurs when an LDAP session is established by means of an ldapbind operation.
It is important that the directory replication server be properly authenticated before it is allowed access to the directory.
The directory replication server uses a unique identity and a password to authenticate with the directory server. The identity of the directory replication server is of the form cn=replication dn,orclreplicaid=
unique_identifier_of_node
,cn=replication configuration
.
When it starts, the directory replication server reads its identity and password from an Oracle Internet Directory secure wallet, and uses these credentials for authentication. If you want to change the password for the replication bind DN, then you must use the -chgpwd
, -presetpwd
, or -pchgwalpwd
option of the Replication Environment Management Tool. The wallet for replication identity is located at ORACLE_INSTANCE/OID/admin/oidpwdr
Oracle_SID
.
See Also: Theremtool command-line tool reference in Oracle Fusion Middleware User Reference for Oracle Identity Management. |
Note: In earlier releases, the replication server required the directory server to allow anonymous bind. The replication server no longer requires that. |
You can deploy Oracle Internet Directory replication with or without SSL. The replication server automatically detects if it is binding to the SSL port of an Oracle Internet Directory instance. If so, it automatically works on top of the Secure Sockets Layer.
To configure LDAP-based replication to use SSL encryption, specify the port number of the SSL port in the orclReplicaURI
attribute, which contains the supplier contact information.
To configure Oracle Database Advanced Replication to use SSL encryption, use Oracle Database Advanced Security. See the Secure Sockets Layer chapter in the Oracle Database Advanced Security Administrator's Guide.
This section describes rules and best practices to follow when specifying naming contexts in LDAP partial replication. It contains the following topics:
Included and Excluded Naming Contexts in LDAP Replication Filtering
Optimization of Partial Replication Naming Context for Better Performance
In LDAP-based replication, you can include a given naming context for replication and exclude one or more of the subtrees within that naming context from replication. You can also exclude from replication one or more of the attributes in that naming context.
In LDAP-based replication, only naming contexts explicitly specified as included are replicated. In Oracle Database Advanced Replication, however, all naming contexts are included by default.
The attributes that control naming contexts are described in "The Replication Naming Context Object Entry". If you use the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Control to set up replication, you set these attributes on the Scope page.
When two or more naming context objects are configured for replication, the filtering rules are as follows:
The overall included naming context is the union of all included naming contexts defined in each naming context object.
The overall excluded naming contexts is the union of all excluded naming contexts defined in each naming context object.
The attribute exclusions in a naming context object are specific only to that naming context object.
If there is a conflict between an included naming context and an excluded naming context, the excluded naming context overrules the included naming context. For example, if an included naming context in naming context object A is a subtree of an excluded naming context specified in another naming context object, B, the subtrees specified in orclexcludednamingcontexts
of naming context object B are not replicated. That is, replication filtering in naming context object A is ignored.
If you configure partial replication between two different versions of Oracle Internet Directory (for example 10g (10.1.4.0.1) and 11g Release 1 (11.1.1)), then you cannot exclude a naming context. Instead, you must explicitly specify the naming contexts to be replicated as included naming contexts.
The discussion in this section relies on the sample naming context illustrated in Figure 37-1. A partial list of user attributes is shown under cn=user1
, cn=user2
, and cn=user1000
.
See Also: "Replication Schema Elements" in Oracle Fusion Middleware User Reference for Oracle Identity Management for descriptions of the attributes in the replication naming context entry |
The following examples show how these rules work:
Scenario A: The Included Naming Context in One Naming Context Object Is a Subtree of the Included Naming Context in Another Naming Context Object
In this scenario, the included naming context in naming context object #2 is a subtree of the included naming context in object #1.
Naming Context Object #1
dn:cn=namectx001, cn=replication namecontext, orclagreementid=unique_identifier_of_the_replication_agreement, orclreplicaid=unique_identifier_of_the_supplier, cn=replication configuration
orclincludednamingcontexts: cn=mycompany
Naming context object #1 includes the entire DIT under cn=myCompany
, as shown in Figure 37-2.
Naming Context Object #2
dn:cn=namectx002, cn=replication namecontext, orclagreementid=unique_identifier_of_the_replication_agreement, orclreplicaid=unique_identifier_of_the_supplier, cn=replication configuration
orclincludednamingcontexts: cn=hr,c=us,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #2 includes the DIT under cn=hr,c=us,cn=mycompany
, but excludes cn=user1
and the attribute userPassword
, as shown in Figure 37-3.
The result of combining naming context objects #1 and #2 is shown in Figure 37-4.
In this scenario, the naming context that is replicated is the highest one specified in the orclincludednamingcontexts
attribute. Any excluded naming contexts are not replicated. All changes under the subtree cn=mycompany
are replicated, except for cn=user1,cn=hr,c=us,cn=mycompany
and the attribute userPassword
under cn=hr,c=us,cn=mycompany
, which are excluded. The attribute userPassword
under the rest of the DIT, however, is not excluded from replication because exclusion of userPassword was specified only for naming context object #2, which only included the DIT under cn=hr
.
Scenario B: The Included Naming Context in One Naming Context Object Is a Subtree of An Excluded Naming Context in Another Naming Context Object
In this scenario, the excluded naming context in naming context object #4 is a subtree of the excluded naming context defined in naming context object #3.
Naming Context Object #3
dn:cn=namectx001,cn=replication namecontext, orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts: c=us,cn=mycompany
Naming context object #3 excludes everything under c=us,cn=mycompany
, as shown in Figure 37-5.
Naming Context Object #4
dn:cn=namectx002,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier, cn=replication configuration
orclincludednamingcontexts: cn=hr, c=us,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #4 includes the DIT under cn=hr,c=us,cn=mycompany
but excludes user1
, and the userPassword
attribute for all users, as shown in Figure 37-6.
The result of combining naming context objects #3 and #4 is shown in Figure 37-7.
In this scenario, the included naming context specified in naming context object #4 is not replicated. That naming context is a subtree of a specified excluded naming context in naming context object #3. In this case, naming context object #4 is ignored, and no changes under cn=hr,c=us,cn=mycompany
are replicated.
The following naming contexts cannot be replicated:
DSE root-specific entry
orclagreementid=000001,cn=replication configuration
cn=subconfigsubentry
cn=Oracle Internet Directory
cn=subregistrysubentry
The following naming contexts cannot be excluded from replication:
cn=catalogs
cn=subschemasubentry
cn=oracleschemaversion
cn=replication configuration
The following attributes cannot be excluded from replication whether they are mandatory or optional. Even if you specify attributes in this list for exclusion from replication, they are always replicated.
orclguid
creatorsname
createtimestamp
cn
dn
attributetypes
objectclasses
objectclass
orclindexedattribute
orclproductversion
You cannot exclude mandatory attributes from replication. For example, suppose that you have an object class named my_object_class
, which includes the following attributes: mandatory_attribute_1
, optional_attribute_1
, and optional_attribute_2
. In this case, you cannot exclude from replication mandatory_attribute_1
.
If you attempt to exclude from replication an attribute that is a mandatory attribute for an entry, replication server still replicates that attribute.
In partial replication, when a naming context is changed from included to excluded using the moddn operation, the replication server deletes the naming context at the consumer. Similarly, if the naming context is changed from excluded to included by using modn at the supplier, then the replication server synchronizes the entire naming context from supplier to consumer.
You must plan partial replication carefully to avoid degrading the performance of the replication process. For best performance, use as few naming context objects as possible. For example, the combined use of naming context objects #5 and #6 fulfills the same requirement as the use of naming context object #7, but using naming context object #7 provides better performance.
This section contains these examples:
Naming Context Object #5
cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts: c=europe,cn=mycompany orclexcludedattributes: userPassword
Naming context object #5 is shown it Figure 37-8. It includes the DIT under cn=mycompany
, but excludes everything under c=europe
. It also excludes the attribute userPassword
.
Naming Context Object #6
cn=namectx002,cn=replication namecontext,orclagreementid=<id>,orclreplicaid=<supplier>,cn=replication configuration orclincludednamingcontexts: cn=hr, c=us,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #6 is shown in Figure 37-9. It includes the DIT under cn=hr, c=us, cn=mycompany
but excludes user1
and the attribute userPassword
.
If naming context objects #5 and #6 are combined, then all changes under cn=mycompany
are replicated, except for c=europe,c=mycompany
, cn=user1,cn=hr,c=us,cn=mycompany
, and the attribute userPassword
.
You could fulfill the same requirement, however, by using naming context object #7. Using a single naming context object provides better partial replication performance.
Naming Context Object #7
cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts: c=europe,cn=mycompany orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany orclexcludedattributes: userPassword
Naming context object #7 is shown in Figure 37-10.
You can convert an existing Oracle Database Advanced Replication-based agreement between two or more nodes to an LDAP multimaster agreement by using remtool -asr2ldap
. The tool prompts you for information. For example:
remtool -asr2ldap
Enter replication administrator's name : repadmin Enter replication administrator's password : Enter global name of MDS : inst1.regress.rdbms.dev.example.com Directory Replication Group (DRG) details : -------- ------------- ----------------------- ------------- ------------- ---- Instance Host Name Global Name Version Replicaid Site Name Type -------- ------------- ----------------------- ------------- ------------- ---- tst1 stacu14 INST1.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst1 MDS tst12 stacu14 INST2.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst12 RMS -------- ------------- ----------------------- ------------- ------------- ---- Do you want to continue? [y/n] : y ------------------------------------------------------------------------------ Migrating ASR agreement to LDAP MM agreement... Enter "SYSTEM" user password for "INST2.REGRESS.RDBMS.DEV.EXAMPLE.COM" database at "stacu14" host : Enter "SYSTEM" user password for "INST1.REGRESS.RDBMS.DEV.example.com" database at "stacu14" host : ------------------------------------------------------------------------------ ASR setup has been cleaned up.------------------------------------------------------------------------------
You configure a one-way, two-way, or multimaster LDAP replica by using the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Control.
Note: You cannot use the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Control to configure an Oracle Database Advanced Replication-based replication agreement. You must do that from the command line. |
You configure an LDAP replication agreement as follows.
From the Oracle Internet Directory menu on the home page, select Administration, then Replication Management.
You are prompted to log into the replication DN account. Provide the host, port, replication DN, and replication DN password. If anonymous binds are enabled on this OID component, the replication DN, host, and port fields fill in automatically and are greyed out. You only need to enter the password.
Click the Create icon.
On the Type screen, select the replication type: One Way Replication, Two Way Replication, or Multimaster Replication.
Click Next. The Replicas screen displays the replication type you selected.
Provide an agreement name. This must be unique across all the nodes.
For one way or two way replication, enter the host, port, user name (replication DN), and replication password for the consumer node. Fields for the supplier node are populated and greyed out.
For multimaster replication, enter the host, port, user name (replication DN), and replication password for the secondary nodes. Fields for the primary node are populated and greyed out.
Click Next to go the Settings page.
In the LDAP Connection field, select Keep Alive if you want the replication server to use same connection for performing multiple LDAP operations. Select Always Use New Connection if you want the server to open a new connection for each LDAP operation.
Enter the Replication Frequency.
Enter the Human Intervention Queue Schedule. This is the interval, in seconds, at which the directory replication server repeats the change application process.
If you have specified Two Way Replication or Multimaster Replication as the agreement type, the settings page contains a section called Replication Server Start Details. You can select Start Server to start the server instance and you can enable bootstrap by selecting Enable Bootstrap. First select the host, then select Instance Name and Component Name for that host. Then you can select Start Server or Enable Bootstrap or both.
Click Next to go to the Scope page. The default primary naming context is filled in.
To exclude a secondary naming context within the default primary naming context, select the primary naming context and click the Create button. Then proceed to Step 16.
To create another primary naming context, click the Create Primary Naming Context button. This invokes the Primary Naming Context dialog.
To specify a primary naming context, either enter the DN manually in the Primary Naming Context field or click Select and browse to the DN you want to use as your primary naming context. Select the container and click OK.
To exclude a secondary naming context, click the Add icon below the Excluded Secondary Naming Contexts field. This invokes the Select Secondary Naming Context to be Excluded dialog. Select the naming context and click OK. The naming context appears in the Excluded Secondary Naming Contexts field.
To exclude an attribute, click the Add icon below the ExcludedAttributes field. This invokes the Select Excluded Attributes screen. Select the attributes you want to exclude and click OK. The attribute now appears in the Excluded Attributes field.
Click OK. The primary naming context is now listed on the Scope page.
Click Next. The Summary page displays a summary of the replication agreement you are about to create.
Use Oracle Directory Services Manager to test directory replication by doing the following:
Invoke Oracle Directory Services Manager and connect to the Oracle Internet Directory server as described in "Invoking Oracle Directory Services Manager".
From the task selection bar, select Data Browser.
Create a single entry on the MDS node, as described in "Adding a New Entry by Using Oracle Directory Services Manager".
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 are replicated.
This section contains these topics:
You can use ldifwrite
and bulkload
to copy LDAP data from one host to another. Use the ldifwrite
utility to back up LDAP data with operational attributes preserved. After 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. 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.
Using this method can take a long time for a directory with one million entries.
See Also:
|
To establish customized settings, you must first install the new node. To do so, follow the instructions in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
After configuring LDAP-based replication with remtool
, you can customize the namingcontext
defining what is replicated for that LDAP-based node.
See Also: The discussion of naming contexts in "Modifying What Is to Be Replicated in LDAP-Based Partial Replication". |
There are two ways to set up 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 37-1 compares these two methods.
Table 37-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 "Setting Up an LDAP-Based Replica by Using Automatic Bootstrapping" .
If ldifwrite/bulkload is your chosen data migration method, configure your LDAP-based replica using "Setting Up 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
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 directory that is not a member of any replication group
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=oid1
Install a new Oracle Internet Directory on the replica, as documented in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
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" \ –master "master_host:master_port"
where master_host:master_port are the hostname and port number for the desired replica's supplier. you are prompted for replication DN password.
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.example.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:3060 Please ignore this error message. |
See Also: Theremtool command-line tool reference in Oracle Fusion Middleware User Reference for Oracle Identity Management 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
.ldif
containing the metadata as back up. This file is created under the ORACLE_INSTANCE
/diagnostics/logs/OID/tools
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_INSTANCE/diagnostics
/logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
Metadata copied successfully.
The message contains the path of your ORACLE_INSTANCE
and filename.
If the metadata backup is unsuccessful, the ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.log
file contains 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]
you are prompted for the replication_dn_password
.
The remtool
utility prompts for agreement type. Select One-Way, Two-Way, or Multimaster LDAP, depending on which type of replica you are adding.
you are prompted for the replica ID of the supplier. This is the value of the attribute orclreplicaid
in the root DSE entry. To find the value to supply, type:
ldapsearch -D cn=orcladmin -q -p port -b "" -s base "objectclass=*" orclreplicaid
you are prompted for the list of available naming contexts in the supplier replica. If you are planning to set up partial replication between server instances running different versions of Oracle Internet Directory, enter e
.
After remtool
has completed successfully, add a separate naming context for each subtree to be replicated, as follows:
Determine the replica ID of the supplier and consumer replica nodes by executing the following search command on both nodes:
ldapsearch -h host -p port -D cn=orcladmin -q -b "" \ -s base "objectclass=*" orclreplicaid
Determine the replication agreement entry, which is of the form:
"orclagreementid=unique_identifier_of_the_replication_agreeement,orclreplicaid=supplier_replica_id,cn=replication configuration"
To find it, type:
ldapsearch -D cn=orcladmin -q -h supplier_host -p supplier_port \ -b "orclreplicaid=supplier_replica_id,cn=replication configuration" \ -s sub "(&(orclreplicadn=*consumer_replica_id*)(objectclass=orclreplagreemententry))" dn
For each naming context that you plan to include in replication, add an entry like the following on both the consumer and supplier replica nodes. The following LDIF file specifies a naming context (subtree) to be included in replication and a some attributes to exclude from replication.
dn: cn=includednamingcontext000002, cn=replication namecontext,orclagreementid=000003, orclreplicaid=stajv18_oid10143,cn=replication configuration objectclass: top objectclass: orclreplnamectxconfig orclincludednamingcontexts: cn=users,dc=small,dc=com orclexcludedattributes: userpassword orclexcludedattributes: telephonenumber cn: includednamingcontext000002
Add the LDIF file to Oracle Internet Directory on the consumer and supplier replica using the following LDAP add command:
ldapadd -D cn=orcladmin -q -h host -p port -v -f ldif_file
Repeat Step3 for each naming context (subtree) to be configured in partial replication.
See Also:
|
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
replace:orclReplicaState
OrclReplicaState: 0
Note: On Windows systems, ensure that the replication server is not running before you enable bootstrapping by changing the value oforclReplicaState to 0 . |
Use ldapmodify
at the consumer to update the consumer replica's subentry orclreplicastate
attribute.
ldapmodify –D "cn=orcladmin" -q -h consumer_host -p port -f mod.ldif
See Also: Chapter 40, "Managing and Monitoring Replication" for more information about the bootstrap capability of the LDAP-based replication |
You can change the default parameters for replication agreements and for the replica subentry.
The exact procedure for starting the replication servers depends on whether this is a one-way or a two-way replica or multimaster replica.
For one-way LDAP replication, you must start the replication server at the consumer. For example, to start the replication server at oid1, type:
oidctl connect=connStr server=oidrepld instance=1 \ name=asinst_1component name=oid1 \ flags="-h consumer_host -p consumer_port" start
For two-way or multimaster LDAP replication, you must start the Oracle Internet Directory replication server at each node, as follows:
oidctl connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=component_name flags="-h \ LdapHost -p LdapPort" start
When the replication server is started, it starts to bootstrap the data from the supplier to the consumer. After the bootstrap has completed successfully, the replication server automatically change to ONLINE mode (orclreplicastate=1
) to process changes from the supplier to the consumer. You can monitor the value of orclreplicastate
by using the following command line:
ldapsearch -p port-h host -D cn=orcladmin -q \ -b "orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration" \ -s base "objectclass=*" orclreplicastate
The entries for Oracle Delegated Administration Services and Oracle Single Sign-On 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
.ldif
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.
See Also: Oracle Identity Management Guide to Delegated Administration and Oracle Application Server Single Sign-On Administrator's Guide in the 10g (10.1.4.0.1) library. |
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 \ -q -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.
See Also: Oracle Application Server Single Sign-On Administrator's Guide in the 10g (10.1.4.0.1) library. |
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 \ -q -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 \ -q -f mod.ldif
Using a browser, test the Oracle Delegated Administration Services and Oracle 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. in the 10g (10.1.4.0.1) library.
To test Oracle Single Sign-On, try to log in as the super admin user "orcladmin"
on the Oracle 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. in the 10g (10.1.4.0.1) library.
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:
A directory that is not a member of any replication group
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=oid1
Identify the consumer node, which must be a new Oracle Internet Directory install. To install a new Oracle Internet Directory as a Master, follow the directions in Oracle Fusion Middleware Installation Guide for Oracle Identity Management 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=oid1
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" \ –master "supplier_host:supplier_port"
you are prompted for the passwords.
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_INSTANCE/diagnostics/logs/OID/tools
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_INSTANCE/diagnostics
/logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
Metadata copied successfully.
The message contains the path of your ORACLE_INSTANCE
.
The message contains the actual path of your ORACLE_INSTANCE
and filename.
If the metadata backup is unsuccessful, the ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.log
file contains 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 switch the server from read/write to read-only mode, use one of the procedures in "Changing Server Mode".
To add a replica, enter the following on the consumer replica:
remtool -paddnode [-v] [-bind supplier_host_name:port]
you are prompted for the replication_dn_password
. The remtool utility prompts 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 Fusion Middleware User Reference for Oracle Identity Management 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 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, ensure that ORACLE_INSTANCE
is set, the 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: "Modifying 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. Use one of the procedures in "Changing Server Mode".
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. Ensure ORACLE_INSTANCE
is set, then 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. Ensure ORACLE_INSTANCE
is set, then 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 11g Release 1 (11.1.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 Oracle Delegated Administration Services or Oracle Single Sign-On 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 connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" start
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 connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=component_name \ flags="-h LdapHost -p LdapPort" start
Start the replication server at the new replica. Type:
oidctl connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" start
Oracle Internet Directory 11g Release 1 (11.1.1) supports more fine-grained password policies than in releases prior to 10g Release 2 (10.1.2.0.2). 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 11g Release 1 (11.1.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 37-2 describes the command-line parameters.
Table 37-2 Command-line Parameters to OIDUpgradePasswordPolicies
Parameter | Description |
---|---|
|
The host on which the 11g Release 1 (11.1.1) directory server is running |
|
The port on which the 11g Release 1 (11.1.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
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 by typing:
oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" stop
Do this by using the Replication Environment Management Tool. Enter:
remtool -pdelnode [-v] [-bind hostname:port_number]
See Also: Theremtool command-line tool reference in Oracle Fusion Middleware User Reference for Oracle Identity Management |
you are prompted for the replication_dn_password
.
To help you set up a multimaster replication group with fan-out, this section offers an example with four systems as described in Table 37-3.
Table 37-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 are replicated (one-way) to Node4.
Requirement 4: Node5 is to be configured as a two-way (updatable) full replica of Node1.
Figure 37-11 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 an LDAP-based multimaster replication group for Node1 and Node2, follow the instructions in "Setting Up an LDAP-Based Replica with Customized Settings"
If you prefer to use Advanced Replication-based replication for your multimaster replication group, follow Tasks 1 through 5 in "Setting Up an Advanced Replication-Based 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" -q -h mycompany1.com -p 3000 -f mod.ldif ldapmodify -D "cn=orcladmin" -q -h mycompany2.com -p 4000 -f mod.ldif
Task 3: Start the Replication Servers on Node1 and Node2
To do this, if you are using LDAP-based replication, follow the instructions on
If you are using Advanced replication, 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 "Testing Replication by Using Oracle Directory Services Manager".
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 "Setting Up 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 "Setting Up 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" -q -h mycompany2.com \ -p 4000 "cn=includednamingcontext000001, \ cn=replication namecontext,orclagreementid=000002, \ orclreplicaid==node2_replica_id, \ cn=replication configuration" ldapdelete -D "cn=orcladmin" -q -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" -q -h mycompany2.com -p 4000 -f mod.ldif ldapadd -D "cn=orcladmin" -q -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, start the replication server at each node.
Type:
oidctl connect=connStr server=oidrepld instance=1 \ componentname=oidComponentName flags="-h LdapHost -p LdapPort" start
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 "Setting Up an LDAP-Based Replication by Using the Command Line". When the installer prompts for the supplier information, provide the supplier hostname, mycompany2.com,
the supplier port, 4000
, and the superuser password.
Task 9: Test the Replication from Node2 to Node4
Test this replication using the instructions in the section entitled
If you are using Advanced replication, use the instructions in the section "Task 7: Test Directory Replication"
Task 10: Install and Configure Node5 as a Two-Way Replica of Node1
Follow the instructions in "Setting Up an LDAP-Based Replication Agreement by Using the Replication Wizard" or in "Setting Up an LDAP-Based Replication by Using the Command Line". Provide the supplier hostname, mycompany1.com
, the supplier port, 3000
, and the superuser password.
Task 11: Test the Two-Way Replication Between Node1 and Node5
Create an entry at Node1 using either Oracle Enterprise 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 Enterprise Manager. The change is replicated to Node1.