42 Setting Up Replication Failover
This chapter includes the following sections:
42.1 Introduction to Replication Failover
Since 10g (10.1.4.0.1), Oracle Internet Directory has supported failover of LDAP replicas from one supplier to another. Administrator intervention is required.
The following sections explain replication failover in detail:
42.1.1 Replication Failover Scenario
This section describes the replication failover scenarios.
Figure 42-1 shows a typical failover scenario.
Figure 42-1 Replication Failover Scenario

This scenario has the following features:
-
Apple, Banana and Candy are multimaster replicas in the same DRG.
-
Damson is a read-only fan-out replica of Banana. That is, it is a partial replica using one-way LDAP replication.
-
Eggplant is an updatable fan-out replica of Banana. That is, it is a partial replica using two-way LDAP replication.
-
If Banana goes down, replication between the multimaster DRG and its fan-out replicas is broken.
An administrator can switch Eggplant and Damson to a new supplier, Candy.
42.1.2 Supported Failover Topology Types
This section describes the supported failover topology types supported by Oracle Internet Directory.
Only two failover topology types are supported:
-
The consumer and new supplier are both connected to the old supplier with LDAP-based replication agreements. This is shown in Figure 42-2. Node 1 and Node 3 both have LDAP replication agreements with Node 2. Node 2 is the original supplier for Node 1. When Node 2 fails, you can fail over Node 1 to a new supplier, Node 3.
Figure 42-2 Consumer and New Supplier Connected to Old Supplier by LDAP
-
The consumer is connected to the old supplier with an LDAP-based agreement and the old supplier is in the same Advanced Replication group as the new supplier. This is shown in Figure 42-3. Node 2 and Node 3 are in the same Advanced Replication DRG. Node 2 is the original supplier for Node 4. When Node 4 fails, you can fail over Node 4 to a new supplier, Node 3.
Figure 42-3 Old and New Suppliers in the Same Directory Replication Group
42.1.3 Limitations and Warnings for Replication Failover
This section describes limitations and warnings related to the use of replication failover.
-
As of Oracle Internet Directory 11g Release 1 (11.1.1.0.0), replication failover requires administrator intervention.
-
Following failover, you must compare and reconcile the consumer with the new supplier.
-
The new agreement must be of the same type and direction as the old agreement.
-
Only two topology types are supported.
-
When a supplier fails, its directly connected replica can only fail over to another directly connected replica of the failed supplier.
-
The replication filtering policy for the agreement between the new supplier and old supplier must match that between the old supplier and consumer.
-
In most cases, you should fail over the replica in a way that preserves the original replica type. In the case shown in Figure 42-4, node 2 is the old supplier for both node 1 and 3, and node 1 is read-only. When node 2 fails, you could, in theory, set up either node 1 or 3 as the new supplier node. Best practice, however, is to fail over node 1 so that node 3 is the supplier. This preserves node 1's original, read-only replica type.
Figure 42-4 Failover Preserving Replica Type
-
If the new agreement is a two-way agreement, after you compare and reconcile the consumer with its new supplier, you must also compare and reconcile all other replicas that are connected to the new supplier with the new supplier. For example, in Figure 42-5, Node 2 has a two-way agreement with Node 3. Node 3 is connected to another replica, Node 4. When Node 2 fails, you set up a two-way agreement between node 3 and node 1. After comparing and reconciling node 3 with node 1, you must also compare and reconcile Node 4 with node 3 to ensure that the replicas are synchronized.
Figure 42-5 Compare and Reconcile All Connected Replicas
42.1.4 Types of Replication Failover
This section describes the two types of replication failover types supported by Oracle Internet Directory.
There are two types of replication failover. They are:
-
Stateless
-
Time-based
Use stateless failover when you are unable to plan for the failover in advance. Stateless replication failover makes no assumptions about the state of the replicas. You can fail over to a new supplier at any time. Stateless failover requires more work after failover to synchronize the nodes.
Use time-based failover for planned failover. Time-based failover results in less work after failover. However, it requires some setup ahead of time to ensure that the following assumptions are true at the time of failover:
-
The nodes are mostly synchronized
-
The new supplier has preserved its change logs so that complete synchronization can be achieved quickly.
42.2 Performing a Stateless Replication Failover
This section explains how to perform a stateless replication failover.
This chapter consists of the following tasks:
42.2.1 Stopping all Directory Replication Server on Related Nodes
Stop the Oracle directory replication servers on the new supplier, old supplier and consumer.
To stop all Directory replication server, execute the following command:
oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" stop
42.2.2 Breaking Old Replication Agreement and Setting up New Agreement
Break the old replication agreement between the old supplier and consumer and set up a new agreement between the new supplier and consumer.
Do this by using the Replication Environment Management Tool. Type:
remtool -pchgmaster [-v] [-bind consumer_host::port_number]
you are prompted for the replication_dn_password
.
See Also:
The remtool
command-line tool reference in Reference for Oracle Identity Management
42.2.3 Saving Last Change Number
Obtain the last change number from the new supplier.
For a one-way agreement, use the following command:
ldapsearch -h new_supplier_host -p port_number -b "" \ -s base "objectclass=*" lastchangenumber
For a two-way agreement, use the following command:
ldapsearch -h consumer_host -p port_number -b "" \ -s base "objectclass=*" lastchangenumber
Save this number!
42.2.4 Comparing and Reconciling New Supplier and Consumer
Use the Oracle Internet Directory Comparison and Reconciliation Tool to compare and reconcile the new supplier and consumer.
For a one-way agreement, type:
oidcmprec operation=reconcile \ source=new_supplier_host:port \ destination=consumer_host:port \ base='""' scope=sub
For a two-way agreement, type:
oidcmprec operation=merge \ source=new_supplier_host:port\ destination=consumer_host:port/ \ base='""' scope=sub
you are prompted for the source and destination replication dn passwords.
This example assumes that the entire directory is replicated and, therefore, that base
is set to " ". If you are using partial replication, use the base
and dns2exclude
arguments to the oidcmprec
tool to include the desired DIT.
See Also:
The oidcmprec
command-line tool reference in Reference for Oracle Identity Management
42.2.5 Updating Last Applied Change Number of New Agreement
Modify the new agreement with the retrieved last applied number at the new supplier.
To do this:
42.2.6 Cleaning Up Old Agreement on Old Supplier
This section describes the procedure to clean up old agreement on old supplier by using the Replication Environment Management Tool.
If the old supplier was down when you performed Breaking Old Replication Agreement and Setting up New Agreement, the old agreement on the old supplier was not cleaned up. Clean it up now by using the Replication Environment Management Tool. Type:
remtool -pcleanup -agrmt [-v] [-bind consumer_host::port_number]
you are prompted for the replication_dn_password
.
See Also:
The remtool
command-line tool reference in Reference for Oracle Identity Management
42.2.7 Starting All Directory Replication Server on Related Nodes
This section describes the procedure to start the Oracle directory replication servers on the new supplier, the old supplier and the consumer.
To do this, type:
oidctl connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=component_name \ flags="-h LdapHost -p LdapPort" start
42.3 Performing a Time-Based Replication Failover
This section explains how to perform a time-based replication failover.
This section contains the following topics:
42.3.1 Configuring Change Log Garbage Collection Object on New Supplier
Configure the changelog purging configuration entry on the new supplier so that it preserves change logs for the desired period.
For example, 24 hours, as follows:
See Also:
42.3.2 Saving Last Change Number from New Supplier
Obtain the last change number from the new supplier.
Type the following command:
ldapsearch -h new_supplier_host -p port_number -D cn=orcladmin -q \ -b "" -s base "objectclass=*" lastchangenumber
Save this number!
42.3.3 Enabling Change Log Regeneration on New Supplier
Enable change log regeneration at the new supplier, as follows:
42.3.4 Waiting for the Desired Time Period to Elapse
Wait for a period no greater than the value of orclpurgetargetage
in the changelog purging configuration entry.
Wait for a period no greater than the value of orclpurgetargetage
in the changelog purging configuration entry.
42.3.5 Stopping all Directory Replication Servers on Related Nodes
Stop the Oracle directory replication servers on the new supplier, old supplier and consumer.
Type the following command:
oidctl connect=connStr server=oidrepld instance=1 \ componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" stop
42.3.6 Breaking Old Replication Agreement and Setting Up New Agreement
Break the old replication agreement between the old supplier and the consumer, then set up a new agreement between the new supplier and the consumer.
Do this by using the Replication Environment Management Tool, as follows:
remtool -pchgmaster [-v] [-bind hostname:port_number]
you are prompted for the replication_dn_password
.
See Also:
The remtool
command-line tool reference in Reference for Oracle Identity Management
42.3.7 Updating Last Applied Change Number of the New Agreement
This section describes the procedure to Modify the new agreement at the new supplier.
Modify the new agreement at the new supplier so that its last applied change number has the value you retrieved in Saving Last Change Number from New Supplier, as follows:
42.3.8 Cleaning Up Old Agreement on Old Supplier
You can clean up old agreement on old supplier node by using the Replication Environment Management Tool.
If the old supplier was down when you performed "Breaking Old Replication Agreement and Setting Up New Agreement", the old agreement on the old supplier was not cleaned up. Clean it up now by using the Replication Environment Management Tool. Type:
remtool -pcleanup -agrmt [-v] [-bind hostname:port_number]
you are prompted for the replication_dn_password
.
See Also:
The remtool
command-line tool reference in Reference for Oracle Identity Management
42.3.9 Starting All Directory Replication Servers on Related Nodes
This section describes the procedure to start the Oracle directory replication servers on the new supplier, the old supplier and the consumer.
Type the following command:
oidctl connect=connStr server=oidrepld instance=1 \ componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" start
See Also:
-
Understanding Process Control of Oracle Internet Directory Components
-
The
oidctl
command-line tool reference in Reference for Oracle Identity Management