40 Setting Up Replication
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, see Understanding Oracle Internet Directory Replication for an introduction to basic replication concepts.
See Also:
Oracle Internet Directory High Availability in High Availability Guide for information on setting up replication in high availability configurations.
This section contains the following topics:
-
Testing Replication by Using Oracle Directory Services Manager
-
Setting Up a LDAP-Based Replication by Using the Command Line
-
Scenario: Setting Up a Multimaster Replication Group with Fan-Out
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 Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager in 12c Release 2 (12.2.1.3.0).
40.1 Introduction to Setting Up Replication
This section provides an overview of how to set up replication.
If you are unfamiliar with basic replication concepts, see Understanding Oracle Internet Directory Replication before reading this introduction.
This introduction contains the following topics:
40.1.1 Replication Transport Mechanisms
Oracle Internet Directory supports LDAP-based replication transport mechanisms. It 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.
40.1.2 Replication Setup Methods
This section provides information on replication setup methods.
To setup Oracle Internet Directory replication, use one of these methods:
Note:
You must use Command-line Tools to Setup and Modify Replication (ldifwrite
and bulkload
) for the following scenario:
-
Replication for a directory that has more than 100,000 entries
40.1.2.1 Command-line Tools to Setup and Modify Replication
You can use command-line tools to set up LDAP-based replication.
Command-line setup of LDAP-based replication is described in Setting Up a LDAP-Based Replication by Using the Command Line.
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.
Note:
If you start the replication server by using the command line, then you must stop it by using the command line.
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
-
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
-
Tracking replication progress in a directory replication group.
See Also:
The remtool
command-line tool reference in Reference for Oracle Identity Management for more information about the Replication Environment Management Tool
40.1.2.2 Database Copy Procedure to Replicate from an Existing Host
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 Adding a Directory Node by Using the Database Copy Procedure.
40.1.3 Bootstrap Rules for Replication
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:
Disable referential integrity during the replication bootstrapping process. If referential integrity is enabled, bootstrapping fails.
40.1.4 The Replication Agreement
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 Understanding Replication Agreement Entry.
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 Understanding Replication Agreement Entry.
40.1.5 Other Replication Configuration Attributes
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 Managing Replication Configuration Attributes. Once you have set up replication, you can manage these attributes.
You can modify replication attributes by using LDAP tools. These methods are described in Managing and Monitoring Replication.
40.1.6 Replication Process and Architecture
In this section you can find reference information about replication architecture and the replication process.
See How Replication Works for detailed information about replication architecture and the replication process.
40.1.7 Rules for Configuring LDAP-Based Replication
Learn about the rules that apply to LDAP-based replication.
The rules that apply to LDAP-based replication are:
-
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 12c Release 2.
-
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, 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 12c Release (12.2.1.3.0) 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 a previous 11g release. For example, in Figure 6-5, before adding an Oracle Internet Directory 12c Release (12.2.1.3.0) node as Node E, you must first update Nodes A, B, C and G to 12c Release (12.2.1.3.0).
-
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:
Configuring Oracle Internet Directory in Installing and Configuring Oracle Internet Directory 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.
40.1.8 Replication Procedure for a Mixed Deployment of 10g and 11gR1 Nodes
Consider a deployment with a combination of Oracle Internet Directory 10g nodes and 11gR1 nodes.
For example:
-
Two 10g nodes with a supplier node and consumer node
-
Two new 11gR1 nodes (for example, nodes 1 and 2) with LDAP multimaster replication
Replication must be setup as follows:
- Setup LDAP one-way replication from one of the 10g nodes to 11gR1 node 1.
- Setup replication bootstrap (if less than 100,000 entries) and then start the replication server on the 11gR1 node 1.
- When the bootstrap is complete, setup LDAP multimaster replication between 11gR1 node 1 and node 2.
- Setup the replication bootstrap on 11gR1 node 2 and then start the replication server.
Most important, replication from the 10g node to an 11gR1 node must be setup before replication between the 11gR1 nodes is setup.
40.1.9 Replication Security
You can ensure security in replication by using authentication and SSL encryption mechanisms.
This section contains these topics:
40.1.9.1 Authentication of the Directory Replication Server
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 $DOMAIN_HOME/config/fmwconfig/components/OID/admin/oidpwdr
Oracle_SID
.
See Also:
The remtool
command-line tool reference in 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.
40.1.9.2 Use of SSL Encryption in Oracle Internet Directory Replication
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.
Note:
Starting from 12.2.1.3.0, replication server can communicate over an SSL port that is configured for one-way or two-way authentication. No-auth mode of SSL is disabled out-of-box in Oracle Internet Directory 12.2.1.3.0. To enable no-auth mode of SSL, anonymous cipher should be configured. See Configuring ODSM Connection with SSL Enabled for the LDIF file configuration.
See Also:
A sample replication entry with SSL two-way configuration for supplier node:
dn: orclreplicaid=myhost1_repl1,cn=replication configuration orclreplicauri:ldap://myhost1:3131/ orclreplicauri;wallet:<location of auto-login wallet> orclreplicauri;authmode:64 orclreplicatype: 0 orclreplicasecondaryuri:ldap://myhost1:3131/ objectclass:top objectclass:orclreplicasubentry orclreplicaid:myhost1_repl1
where orclreplicauri;authmode
has the SSL authmode(values are 1/32/64 for no-auth/one-way/two-way authentication)
While bringing up oidrepld
in one-way or two-way authentication mode, we need to pass value for parameters in oidctl
startup command, sslauth
and wurl
. The sslauth
is for SSL authentication mode(supports value 1/2/3 for no-auth/one-way or two-way authentication) and wurl
is the location of wallet to connect to consumer node.
Sample oidctl
command to bring up replication server in two-way authentication connectivity to consumer node is:
oidctl connect=inst2 server=oidrepld inst=1 flags=" -h localhost -p 3132 -sslauth 3 -wurl<location of auto-login wallet> start”
40.1.10 LDAP Replication Filtering for Partial Replication
This section describes rules and best practices to follow when specifying naming contexts in LDAP partial replication. It contains the following topics:
40.1.10.1 Filtering of Naming Contexts in LDAP Replication
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.
40.1.10.2 Attributes that Control Naming Contexts
The attributes that control naming contexts are described in Understanding Replication Naming Context Object Entry.
40.1.10.3 Filtering Rules for Naming Contexts in LDAP Replication
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.0.0)), then you cannot exclude a naming context. Instead, you must explicitly specify the naming contexts to be replicated as included naming contexts.
40.1.10.4 Scenarios of Filtering Naming Context in LDAP Replication
The discussion in this section relies on the sample naming context illustrated in Figure 40-1. A partial list of user attributes is shown under cn=user1
, cn=user2
, and cn=user1000
.
Figure 40-1 A Sample Naming Context
![This illustration is described in the text. This illustration is described in the text.](img/oidag125.gif)
See Also:
Oracle Directory Replication Schema Elements in Reference for Oracle Identity Management for descriptions of the attributes in the replication naming context entry
The following examples show how these rules work:
40.1.10.4.1 Scenario A: Included Naming Context is a Subtree of an Included Naming Context in Another Object
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 40-2.
Figure 40-2 Naming Context Object #1
![The entire DIT is included. The entire DIT is included.](img/oidag129.gif)
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 40-3.
Figure 40-3 Naming Context Object #2
![This illustration is described in the text. This illustration is described in the text.](img/oidag130.gif)
The result of combining naming context objects #1 and #2 is shown in Figure 40-4.
Figure 40-4 Result of Combining Naming Context Objects #1 and #2
![This illustration is described in the text. This illustration is described in the text.](img/oidag134.gif)
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
.
40.1.10.4.2 Scenario B: Included Naming Context is a Subtree of an Excluded Naming Context in Another Object
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 40-5.
Figure 40-5 Naming Context Object #3
![Everything under cn=us is excluded Everything under cn=us is excluded](img/oidag131.gif)
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 40-6.
Figure 40-6 Naming Context Object #4
![This illustration is described in the text. This illustration is described in the text.](img/oidag130.gif)
The result of combining naming context objects #3 and #4 is shown in Figure 40-7.
Figure 40-7 Result of Combining Naming Context Objects #3 and #4
![Result of Combining Naming Context Objects #3 and #4 Result of Combining Naming Context Objects #3 and #4](img/oidag131.gif)
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.
40.1.10.5 Rules for Including or Excluding Naming Contexts and Attributes
Oracle Internet Directory has rules to include and exclude naming contexts and attributes.
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.
40.1.10.6 Optimization of Partial Replication Naming Context for Better Performance
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.
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 40-8. It includes the DIT under cn=mycompany
, but excludes everything under c=europe
. It also excludes the attribute userPassword
.
Figure 40-8 Naming Context Object #5
![This illustration is described in the text. This illustration is described in the text.](img/oidag135.gif)
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 40-9. It includes the DIT under cn=hr, c=us, cn=mycompany
but excludes user1
and the attribute userPassword
.
Figure 40-9 Naming Context Object #6
![This illustration is described in the text. This illustration is described in the text.](img/oidag130.gif)
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 40-10.
Figure 40-10 Naming Context Object #7
![Naming Context Object #7 Naming Context Object #7](img/oidag136.gif)
40.2 Testing Replication by Using Oracle Directory Services Manager
Use Oracle Directory Services Manager to test directory replication by doing the following:
40.3 Setting Up a LDAP-Based Replication by Using the Command Line
You can setup a LDAP-based replication by using the command line.
This section contains these topics:
40.3.1 Copying Your LDAP Data by Using ldifwrite and bulkload
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:
-
Command-Line Tools Overview in Reference for Oracle Identity Management
40.3.2 Setting Up an LDAP-Based Replica with Customized Settings
To establish customized settings, you must first install the new node.
To install the new node, follow the instructions in Installing and Configuring Oracle Internet Directory.
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 Implications of 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 usebulkload
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 40-1 compares these two methods.
The following sections explain these methods further:
40.3.2.1 Data Migration Using ldifwrite/bulkload versus Automatic Bootstrapping
You must use the ldifwrite/bulkload or automatic bootstrapping methods for data migration for different fitting scenarios.
Table 40-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 |
Note:
You must use Command-line Tools to Setup and Modify Replication (ldifwrite
and bulkload
) for the following scenario:
-
Replication for a directory that has more than 100,000 entries
For other scenarios, you can use either migration method.
40.3.2.2 Setting Up an LDAP-Based Replica by Using Automatic Bootstrapping
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.
40.3.2.2.1 Identifying and Starting the Directory Server on the Supplier Node
You can 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:
start(name='instance-name',type='OID')
40.3.2.2.2 Creating the New Consumer Node by Installing Oracle Internet Directory
Install a new Oracle Internet Directory on the replica, as documented in Installing and Configuring Oracle Internet Directory.
40.3.2.2.3 Backing Up Metadata from the New Consumer Node
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, as discussed in Creating the New Consumer Node by Installing Oracle Internet Directory, 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.
See Also:
The
remtool
command-line tool reference in Reference for Oracle Identity Management for more information aboutremtool
options, including-backupmetadata
. -
Apart from loading the metadata into master replica, this command creates a file named
ocbkup.
new_replica_id
.TO.
master_replicaid
.
timestamp
.ldif
containing the metadata as back up. This file is created under the$DOMAIN_HOME
/tools/OID/logs
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 $DOMAIN_HOME/tools/OID/logs/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif. Metadata copied successfully.
The message contains the path of your
DOMAIN_HOME
and filename. -
If the metadata backup is unsuccessful, the $DOMAIN_HOME
/tools/OID/logs/remtool.log
file contains error messages. If you invokedremtool
from a terminal, error messages appear on that terminal.
40.3.2.2.4 Adding a LDAP-Based Replica by Using the Replication Environment Management Tool
To add a LDAP-based 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:
See Also:
-
The
remtool
command-line tool reference in Reference for Oracle Identity Management for more information about the Replication Environment Management Tool
40.3.2.2.5 Configuring the Consumer Replica for Automatic Bootstrapping
To use the automatic bootstrap capability, on the consumer, set the orclReplicaState
attribute of the consumer replica subentry to 0
as follows:
40.3.2.2.6 Changing Default Replication Parameters
You can change the default parameters for replication agreements and for the replica subentry.
40.3.2.2.7 Ensuring the Directory Replication Servers are Started
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_1 component name=oid1 \ flags="-h consumer_host -p consumer_port" start
Note:
If you are deploying a single master with read-only replica consumers, you can reduce performance overhead by turning off conflict resolution. To do so, change the value of
orclconflresolution
to 0 by using the following ldif file withldapmodify
:dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclconflresolution orclconflresolution: 0
-
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
40.3.2.3 Setting Up an LDAP-Based Replica by Using the ldifwrite Tool
This section discuss the general tasks you perform when configuring an LDAP-based replica by using the ldifwrite tool. It contains these topics:
40.3.2.3.1 Starting the Directory Server on Both the Supplier and the Consumer Nodes
To start the directory server on both the supplier and the consumer nodes:
40.3.2.3.2 Backing Up Metadata from the New Consumer Node
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, as discussed in Creating the New Consumer Node by Installing Oracle Internet Directory, 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 $DOMAIN_HOME/tools/OID/logs
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 $DOMAIN_HOME/tools/OID/logs/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif. Metadata copied successfully.
The message contains the path of your
DOMAIN_HOME
.The message contains the actual path of your
DOMAIN_HOME
and filename.If the metadata backup is unsuccessful, the $DOMAIN_HOME
/tools/OID/logs/remtool.log
file contains error messages. If you invokedremtool
from a terminal, error messages appear on that terminal.
40.3.2.3.3 Changing the Directory Server at the Supplier to Read-Only Mode
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 the Server Mode.
40.3.2.3.4 Adding a LDAP-Based Replica by Using the Replication Environment Management Tool
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:
The remtool
command-line tool reference in Reference for Oracle Identity Management for more information about the Replication Environment Management Tool
40.3.2.3.5 Backing Up the Naming Contexts to Be Replicated
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:
40.3.2.3.6 Changing the Directory Server at the Supplier to Read/Write Mode
If you performed "Changing 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 the Server Mode.
40.3.2.3.7 Loading the Data on the New Consumer
To load data on the new consumer:
Perform this step for each naming context that was backed up in "Backing Up the Naming Contexts to Be Replicated".
On the consumer, load the data to the replica by using bulkload in the append mode. Ensure DOMAIN_HOME
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"
See Also:
-
The
bulkload
command-line tool reference in Reference for Oracle Identity Management for instructions on using bulkload in either the default mode or the append mode -
The
bulkdelete
command-line tool reference in Reference for Oracle Identity Management
40.3.2.3.8 Changing Default Replication Parameters
You can change the default parameters for replication agreements, for the replica subentry, and for the replication naming context configuration objects. This task is optional.
40.3.2.3.9 Ensuring the Directory Replication Servers are Started
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
Note:
If you are deploying a single master with read-only replica consumers, you can reduce performance overhead by turning off conflict resolution. To do so, change the value of
orclconflresolution
to 0 by using the following ldif file withldapmodify
:dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclconflresolution orclconflresolution: 0
-
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
-
40.3.3 Deleting an LDAP-Based Replica
This section explains how to delete an LDAP-based replica.
This section contains the following topics:
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.
40.3.3.1 Stopping the Directory Replication Server on the Node to be Deleted
Stop the Oracle directory replication server by typing:
oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" stop
40.3.3.2 Deleting the Replica from the Replication Group
You can delete the replica from the replication group by using the Replication Environment Management Tool. Enter:
remtool -pdelnode [-v] [-bind hostname:port_number]
You are prompted for the password. Enter a value for replication_dn_password
.
See Also:
The remtool
command-line tool reference in Reference for Oracle Identity Management
40.4 Scenario: Setting Up a Multimaster Replication Group with Fan-Out
The following topics describe how to set up a multimaster replication group:
40.4.1 Understanding Multimaster Replication
To help you set up a multimaster replication group with fan-out, this section offers an example with four systems.
See Table 40-2.
Table 40-2 Nodes in Example of Partial Replication Deployment
Node | Host Name | Port |
---|---|---|
Node1 |
mycompany1.com |
3000 |
Node2 |
mycompany2.com |
4000 |
Node3 |
mycompany3.com |
5000 |
Node4 |
mycompany4.com |
6000 |
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 underou=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 40-11 Example of Fan-Out Replication
![Description of Figure 40-11 follows Description of Figure 40-11 follows](img/oidag0128.gif)
Description of "Figure 40-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.
40.4.2 Setting Up the Multimaster Replication Group for Node1 and Node2
This section gives information to set up an LDAP-based 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
40.4.3 Configuring the Replication Agreement
In the replication agreement between Node1 and Node2, specify the value for the orclExcludedNamingcontexts
attribute as cn=private users,cn=mycompany
.
Perform the following steps:
40.4.4 Starting the Replication Servers on Node1 and Node2
To start replication servers on node1 and node2, if you are using LDAP-based replication, follow the instructions on
To start replication servers on node1 and node2, if you are using LDAP-based replication, follow the instructions on
40.4.5 Testing the Directory Replication Between Node1 and Node2
Follow the instructions given in this section.
To do this, follow the instructions in Testing Replication by Using Oracle Directory Services Manager.
40.4.6 Installing and Configuring Node3 as a Partial Replica of Node2
If you want to use the bootstrap capability of partial replication, then follow the instructions given in this section.
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.
40.4.7 Customizing the Partial Replication Agreement
You can customize the partial replication agreement as described in this section.
-
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 contextcn=customer profile, ou=Americas, cn=mycompany
and the attributeuserpassword
, 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 useldapmodify
to modify the partial replicaorclreplicastate
attribute at both Node2 and Node3, as described in "Configuring the Consumer Replica for Automatic Bootstrapping".
40.4.8 Starting the Replication Servers on All Nodes in the DRG
Start the replication server at each node before starting the replication process.
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
40.4.9 Installing and Configuring Node4 as a Full Replica of Node2
Full replica replication is the default configuration when the new node is installed as an LDAP replica.
Since full replica replication is the default configuration when the new node is installed as an LDAP replica, use the instructions in Setting Up a 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.
40.4.10 Testing the Replication from Node2 to Node4
Test this replication using the instructions in the section entitled.
Test this replication using the instructions in the section entitled.
40.4.11 Installing and Configuring Node5 as a Two-Way Replica of Node1
Follow the instructions given in this section.
Follow the instructions in Setting Up a LDAP-Based Replication by Using the Command Line. Provide the supplier hostname, mycompany1.com
, the supplier port, 3000
, and the superuser password.
40.4.12 Testing the Two-Way Replication Between Node1 and Node5
Follow the instructions given in this section.
Create an entry at Node1 by using 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 the ldapmodify
command-line tool. The change is replicated to Node1.