Edit the example file mod.ldif as follows:

39-4 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory 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, 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 39–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 1s original, read-only replica type. Figure 39–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 39–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. 2 1 3 Two-way LDAP One-way LDAP 2 1 3 failover Setting Up Replication Failover 39-5 Figure 39–5 Compare and Reconcile All Connected Replicas Determining Which Type of Replication Failover to Use 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. Performing a Stateless Replication Failover This section explains how to perform a stateless replication failover. It consists of the following tasks: ■ Task 1: Stop all Directory Replication Server on related Nodes ■ Task 2: Break Old Replication Agreement and Set up New Agreement ■ Task 3: Save Last Change Number ■ Task 4: Compare and Reconcile New Supplier and Consumer ■ Task 5: Update Last Applied Change Number of New Agreement ■ Task 6: Clean Up Old Agreement on Old Supplier ■ Task 7: Start All Directory Replication Server on related Nodes Task 1: Stop all Directory Replication Server on related Nodes Stop the Oracle directory replication servers on the new supplier, old supplier and consumer, by typing: oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \ flags=-h LdapHost -p LdapPort stop 2 Two-Way LDAP New LDAP Agreement 1 3 4 2 1 3 4 failover 39-6 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory Task 2: Break Old Replication Agreement and Set 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. Task 3: Save 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 Task 4: Compare and Reconcile 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. Task 5: Update Last Applied Change Number of New Agreement Modify the new agreement with the retrieved last applied number at the new supplier. To do this: 1. Create an LDIF file with the last change number you retrieved in Task 3: Save Last Change Number . See Also: The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management See Also: The oidcmprec command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management Setting Up Replication Failover 39-7 For a one-way agreement, it should look similar to this: dn: agreement_dn changetype: modify replace: orclLastAppliedChangeNumber;applynew_supplier_hostconsumer_host orclLastAppliedChangeNumber;applynew_supplier_hostconsumer_host: last_change_number_retrieved. - replace: orclLastAppliedChangeNumber;transportnew_supplier_hostconsumer_host orclLastAppliedChangeNumber;transportnew_supplier_hostconsumer_host: last_change_number_retrieved_from_new_supplier For a two-way agreement, it should look similar to this: dn: agreement_dn changetype: modify replace: orclLastAppliedChangeNumber;applynew_supplier_hostconsumer_host orclLastAppliedChangeNumber;applynew_supplier_hostconsumer_host: last_change_number_retrieved_from_new_supplier - replace: orclLastAppliedChangeNumber;transportnew_supplierconsumer orclLastAppliedChangeNumber;transportnew_supplierconsumer: last_change_number_retrieved_from_new_supplier - replace: orclLastAppliedChangeNumber;applyconsumer_hostnew_supplier_host orclLastAppliedChangeNumber;applyconsumer_hostnew_supplier_host: last_change_number_retrieved_from_consumer - replace: orclLastAppliedChangeNumber;transportconsumer_hostnew_supplier_host orclLastAppliedChangeNumber;transportconsumer_hostnew_supplier_host: last_change_number_retrieved_from_consumer 2. Modify the agreement by using ldapmodify, as follows: ldapmodify -D cn=orcladmin -q -h host_name -p port_number -f LDIF_file Task 6: Clean Up Old Agreement on Old Supplier If the old supplier was down when you performed Task 2: Break Old Replication Agreement and Set up New Agreement , the old agreement on the old supplier was not cleaned up. Clean it up now by using the Replication Environment Management Tool. Type: remtool -pcleanup -agrmt [-v] [-bind consumer_host::port_number] you are prompted for the replication_dn_password. Task 7: Start All Directory Replication Server on related Nodes Start the Oracle directory replication servers on the new supplier, the old supplier and the consumer, by typing: oidctl connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=component_name \ flags=-h LdapHost -p LdapPort start See Also: The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management 39-8 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory Performing a Time-Based Replication Failover This section explains how to perform a time-based replication failover. It contains these topics: ■ Task 1: Configure Change Log Garbage Collection Object on New Supplier ■ Task 2: Save Last Change Number from New Supplier ■ Task 3: Enable Change Log Regeneration on New Supplier ■ Task 4: Wait for the Desired Time Period to Elapse ■ Task 5: Stop all Directory Replication Servers on Related Nodes ■ Task 6: Break Old Replication Agreement and Set Up New Agreement ■ Task 7: Update Last Applied Change Number of New Agreement ■ Task 8: Clean Up Old Agreement on Old Supplier ■ Task 9: Start All Directory Replication Servers on Related Nodes Task 1: Configure 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:

1. Create an LDIF file similar to this:

dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry changetype:modify replace: orclpurgetargetage orclpurgetargetage: 24

2. Apply the LDIF file by typing:

ldapmodify -D cn=orcladmin -q -p port -h host -D dn -f LDIF_file Task 2: Save Last Change Number from New Supplier Obtain the last change number from the new supplier, as follows: ldapsearch -h new_supplier_host -p port_number -D cn=orcladmin -q \ -b -s base objectclass= lastchangenumber Save this number Task 3: Enable Change Log Regeneration on New Supplier Enable change log regeneration at the new supplier, as follows: 1. Create an LDIF file like this: dn: changetype: modify replace: orcldiprepository orcldiprepository: TRUE See Also: Chapter 4, Understanding Process Control of Oracle Internet Directory Components See Also: Chapter 35, Managing Garbage Collection Setting Up Replication Failover 39-9 2. Apply the LDIF file by typing: ldapmodify -D cn=orcladmin -q -h host_name -p port_number -f LDIF_file Task 4: Wait for the Desired Time Period to Elapse Wait for a period no greater than the value of orclpurgetargetage in the changelog purging configuration entry. Task 5: Stop all Directory Replication Servers on Related Nodes Stop the Oracle directory replication servers on the new supplier, old supplier and consumer, by typing: oidctl connect=connStr server=oidrepld instance=1 \ componentname=oidComponentName \ flags=-h LdapHost -p LdapPort stop Task 6: Break Old Replication Agreement and Set 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. Task 7: Update Last Applied Change Number of New Agreement Modify the new agreement at the new supplier so that its last applied change number has the value you retrieved in Task 2: Save Last Change Number from New Supplier , as follows: 1. Create an LDIF file with the retrieved last applied change number, similar to this: dn: agreement_dn changetype: modify replace: orclLastAppliedChangeNumber orclLastAppliedChangeNumber: last_change_number_retrieved 2. Apply the LDIF file to the agreement by using ldapmodify: ldapmodify -D cn=orcladmin -q -h host_name -p port_number -f LDIF_file Task 8: Clean Up Old Agreement on Old Supplier If the old supplier was down when you performed Task 6: Break Old Replication Agreement and Set Up New Agreement , the old agreement on the old supplier was not cleaned up. Clean it up now by using the Replication Environment Management Tool. Type: See Also: Chapter 4, Understanding Process Control of Oracle Internet Directory Components See Also: The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management 39-10 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory remtool -pcleanup -agrmt [-v] [-bind hostname:port_number] you are prompted for the replication_dn_password. Task 9: Start All Directory Replication Servers on Related Nodes Start the Oracle directory replication servers on the new supplier, the old supplier and the consumer, by typing: oidctl connect=connStr server=oidrepld instance=1 \ componentname=oidComponentName \ flags=-h LdapHost -p LdapPort start See Also: The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management See Also: ■ Chapter 4, Understanding Process Control of Oracle Internet Directory Components ■ The oidctl command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management. 40 Managing Replication Configuration Attributes 40-1 40 Managing Replication Configuration Attributes This chapter describes configuration attributes that control the Oracle Internet Directory replication server. The attributes reside in specific containers in the DIT. See Chapter 41, Managing and Monitoring Replication for specific replication management tasks. This chapter contains the following sections: ■ Introduction to Replication Configuration Attributes ■ Configuring Replication Configuration Attributes by Using Fusion Middleware Control ■ Managing Replication Configuration Attributes From the Command Line Introduction to Replication Configuration Attributes This introduction contains the following topics: ■ The Replication Configuration Container ■ The Replica Subentry ■ The Replication Agreement Entry ■ The Replication Naming Context Container Entry ■ The Replication Naming Context Object Entry ■ The Replication Configuration Set ■ Examples of Replication Configuration Objects in the Directory The Replication Configuration Container All replication information for a node resides in the container cn=replication configuration located at the root DSE. This entry resides on each node in a DRG. The following is a sample replication configuration container entry: dn: cn=replication configuration orclaci: access to entry by browse orclaci: access to attr= by search,read orclnormdn: cn=replication configuration cn: replication configuration description: Replication agreement Container object objectclass: top objectclass: orclcontainerOC 40-2 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory The Replica Subentry The Replica subentry has the DN orclreplicaid=Replica_ID,cn=replication configuration This subentry is created at installation under the replication configuration container. It contains attributes that identify and define the characteristics of the node it represents. Table 40–1 describes the attributes of the replica subentry. Under Update Mechanism, EM indicates that you can manage this attribute with Oracle Enterprise Manager Fusion Middleware Control. LDAP indicates that you can manage this attribute by using LDAP tools. In Figure 40–3 on page 40-12, a replica subentry is represented by orclReplicaID=UID_of_node_D,cn=replication configuration. The following is a sample replica subentry: dn: orclreplicaid=myhost1_repl1,cn=replication configuration objectclass: top objectclass: orclreplicasubentry orclreplicaid: myhost1_repl1 Table 40–1 Attributes of the Replica Subentry Attribute Description Update Mechanism Default Possible Values orclreplicaid Unique identifier for directory database. Initialized at installation. Matches orclreplicaid at the root DSE. Read-only hostname_ ORACLESID Integer orclreplicauri Address used to open a connection to this replica. EM, LDAP Valid ldapURI format orclreplicaseconda ryuri Addresses used if orclReplicaURI cannot be used. EM, LDAP Valid ldapURI format orclreplicatype Defines the type of replica such as read-only or readwrite. EM, LDAP ReadWrite 0: ReadWrite 1: Read-Only 2: Pilot orclpilotmode Defines whether replica is in pilot testing mode. remtool -pilotreplica 0: False 1: True orclreplicastate Defines state of the replica. EM, LDAP You can set 0, 1, 2, 6, or 8. Server sets other values. See Table D–1 on page D-6. pilotstarttime Time when replica entered pilot testing mode. Read-only Time Note: On Windows systems, ensure that the replication server is not running before you enable bootstrapping by changing the value of orclReplicaState to 0. Managing Replication Configuration Attributes 40-3 orclreplicauri: ldap:myhost1:3060 orclreplicasecondaryuri: ldap:myhost1.mycompany.com:3060 orclreplicastate: 1 The Replication Agreement Entry The DN of the Replication Agreement Entry is: orclagreementid=Agreement_ID,orclreplicaid=Replica_ID,cn=replication configuration This entry contains attributes that define the replication agreement between the two or more nodes and is associated with the orclReplAgreementEntry objectclass. There are two kinds of agreement:

1. Oracle Database Advanced Replication-based replication agreement. The

replication agreement for Advanced Replication nodes resides under the replication configuration set. For example: In Figure 40–2 , an Oracle Database Advanced Replication-based replication agreement entry is represented by orclagreementID=000001,cn=replication configuration.

2. LDAP-based replication agreement. The replication agreement for LDAP nodes

resides under the suppliers replica subentry. For example, in Figure 40–3 , an LDAP-based replication agreement entry is represented by orclagreementID=000003, orclReplicaID=UID_of_node_ D,cn=replication configuration. Replication Agreement Entry Attributes Table 40–2 shows the attributes in the replication agreement. Under Update Mechanism, EM indicates that you can manage this attribute with Oracle Enterprise Manager Fusion Middleware Control. LDAP indicates that you can manage this attribute by using LDAP tools. See Also: Replication Schema Elements in Oracle Fusion Middleware Reference for Oracle Identity Management for descriptions of the attributes of the replica subentry. Table 40–2 Attributes of the Replication Agreement Entry Attribute Description Update Mechanis m Default Possible Values orclagreement id Name of replication agreement entry. Read-only orclreplicadn LDAP-based replication only. DN of the replica to identify a consumer in the replication agreement. Read-only DN orclreplicati onprotocol Replication protocol for change propagation to replica. Values: Read-only ODS_ASR_1.0: Oracle Database Advanced Replication-based ODS_LDAP_1.0: LDAP-based orcldirreplgr oupdsas For Oracle Database Advanced Replication-based groups only. Orclreplicaid values of all the nodes in this replication group. This list must be identical on all nodes in the group. You can modify this attribute. LDAP 40-4 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory orclupdatesch edule Update interval for new changes and those being retried. EM, LDAP 60 seconds Greater than or = 0 orclhiqschedu le Interval at which the directory replication server repeats the change application process. EM, LDAP 600 seconds Greater than or = 60 seconds orclldapconnk eepalive Whether the connections from replication server to the directory server are kept active or established every time the changelog processing is done. EM, LDAP 1 0: false 1: true orcllastappli edchangenumbe r Last change number transported or applied at the consumer replica. For LDAP-based agreements, this attribute contains subtypes. The format is: orcllastappliedchangenumber; status_typesupplier_ replicaIDconsumer_replicaID: Number where status_type is: transport or apply, supplier_ replicaID and consumer_replicaID indicate the direction of LDAP data flow, and Number is the last applied change number. It indicates that changelogs from supplier_replicaID to consumer_replicaID with change number less than Number have been transportedapplied at node consumer_replicaID. For Oracle Database Advanced Replication-based agreements, only the base type is used. Read-only orclexcludedn amingcontexts Subtrees to be excluded from replication. Applicable only to Oracle Database Advanced Replication-based agreements. LDAP replication uses the Replication Naming Context Entry, described, in Table 40–3 . Read-only orclreplicati onid Unique identifier of a one-way, two-way, or peer-to-peer replication group Read-only orclagreement type Replication agreement type. Read-only 0: one-wayread-only fan-out replication agreement 1: two-wayupdatable fan-out replication agreement 2: LDAP-based multimaster replication agreement 3: Oracle Database Advanced Replication-based multimaster replication agreement Table 40–2 Cont. Attributes of the Replication Agreement Entry Attribute Description Update Mechanis m Default Possible Values Managing Replication Configuration Attributes 40-5 Oracle Database Advanced Replication-Based Replication Agreements For Advanced Replication, the replication agreement on each node lists all of the nodes in the group. It is identical on each node except for local options such as partitioned naming contexts on the local directory server. The entry for this kind of replication agreement resides immediately below the cn=replication configuration container entry. For example, the DN of such an agreement can look like this: orclagreementID=000001,cn=replication configuration. LDAP Replication Agreements For LDAP-based replication, there are separate replication agreements for each supplier-consumer relationship. For one-way replication, there is a single, one-way replication agreement. The entry for an LDAP-based replication agreement resides immediately below the replica subentry of the node that serves as the supplier. Thus, the DN of the replication agreement as found on a supplier node is: orclagreementID=unique_identifier_of_the_replication_agreement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration Similarly, the DN of the replication agreement as found on a consumer node is: orclagreementID=unique_identifier_of_the_replication_agreeement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration In a fan-out replication agreement, you can tell which node the agreement entry is associated with by looking at its parent. For example, look at the following replication agreement entry. orclagreementID=000002,orclReplicaID=node_A,cn=replication configuration In this example, you can determine that the replication agreement represented by orclagreementID=000002 is associated with node A. This is because the parent of orclagreementID=000002 is orclReplicaID=node_A. Two-Way LDAP Replication Agreements For two-way replication, there can be either a single, two-way replication agreement or two one-way agreements for each supplier-consumer relationship. The following is a sample two-way replication agreement entry: dn: orclagreementid=000002, orclreplicaid=stadd58_repl, cn=replication configuration Notes: ■ The container entry cn=replication configuration is replicated on all nodes, but may not be identical on all nodes. ■ The orclreplicadn attribute of an LDAP-based replication agreement specifies the associated consumer node. ■ The agreementtype indicates the replication agreement type. See Table 40–2, Attributes of the Replication Agreement Entry for values of orclagreementtype.