How Replication Works

A.3 How Replication Works

This appendix describes how replication works, including the features and architecture of LDAP-based replication, LDAP replica states, and the replication process.

This appendix includes the following sections:

Note:

All references to Oracle Single Sign-On in this appendix refer to Oracle Single Sign-On 10g (10.1.4.3.0) or later.

A.3.1 Architecture of LDAP-Based Replication

Beginning with Oracle Internet Directory 11g Release 1 (11.1.1.7.0), the data flow in LDAP replication consists of the apply phase with the apply queue. The transport phase with the transport queue is no longer used. This section gives a more detailed look at LDAP replication.

Figure A-2 and its accompanying text explain the fan-out replication process.

Figure A-2 LDAP Replication Process

An LDAP change request is made on the Oracle Internet Directory server of Replica A.
The change is accepted and committed to Oracle Internet Directory database storage.
A new change log is generated for the operation and stored in the ods_chg_log table, where:
- server = Replica A
- orclreplicationid/chg_rid = 0 (The value 0 is for user operations.)
- Modifiersname = user DN of the Modifier (by default)
The Replication Server at Replica B fetches the change logs from the ods_chg_log table at Replica A, performs some partial replication filtering in memory, and then puts the change logs directly into the apply queue. The orclupdateschedule configuration attribute determines the replication frequency.
The Replication Server at Replica B requests that the Oracle Internet Directory server at Replica B commit the changes to storage.
The Oracle Internet Directory server at Replica B commits the changes to the Oracle Internet Directory database storage, copies the changes into the asr_chg_log table, and updates the retry count to -2, all in a single LDAP call.

If a failure occurs on the commit, the Oracle Internet Directory server reports the error to the Replication Server, copies the changes to the asr_chg_log table, and decrements the retry count by 1. The Oracle Internet Directory server can then re-apply the commit.

Regardless of success or failure, all change logs are be copied to the asr_chg_log table at Replica B.
If Replica B is the source for any other replicas, a change log is regenerated in ods_chg_log table at Replica B, which follows the following changelog regeneration rules:
- server = server of local replica, Replica B
- orclreplicationid/chg_rid = N
- Modifiersname = Replbind_DN_of_A
orclreplicatid/chg_rid is set to the orclreplicationid value of the processing agreement.

A.3.2 LDAP Replica States

Understand about the replica states for LDAP-based replication.

When LDAP based replication is configured, and the replication server is started, the server reads the replica state orclreplicastate from the local replica, "orclreplicaid=local_Replica_ID, cn=replication configuration". The replication server behaves differently, based upon the local replica state, as shown in Table A-2. The replication server reads the local replica state from the local (consumer) node.

Note:

On Windows systems, ensure that the replication server is not running before you enable bootstrapping by changing the value of orclReplicaState to 0.

Table A-2 LDAP Replica States

Value	Meaning	Server Behavior
0	Bootstrap	Starts replication bootstrap processing to synchronize the consumer directory from the supplier, based on the replication naming context configuration. Updates the replica state to correspond with bootstrap progress. Sets the replica state to 3 (Bootstrap in progress) immediately when it starts to bootstrap. Sets the replica state to 4 (Bootstrap in progress, `cn=oraclecontext` bootstrap has completed) after it completes bootstrapping of `"cn=oraclecontext"` successfully Sets the replica state to 5 (Bootstrap Error occurred) after bootstrap is completed but failure(s) detected during the bootstrap. Then it waits until the replica state is re-set. Note: Human intervention is required; See Troubleshooting Oracle Internet Directory Replication for details. Sets the replica state to 1 (On-line) after bootstrap has completed successfully. Then replication automatically starts to perform normal replication processing.
1	On line	Starts normal replication processing to replicate changes from the supplier to the consumer.
2	Off line	Logs an error message in oidrepld.log similar to this: 2004/09/24:17:41:44 * Replica(dlsun1418_replica2) is in OFFLINE mode, Please update the replica state and restart OIDREPLD... The administrator must set the replica state properly and restart the replication server.
3	Bootstrap in progress	Sets the replica state back to 0 (Bootstrap), then starts to bootstrap again as if the replica state were 0.
4	Bootstrap in progress, `cn=oraclecontext` bootstrap has completed.	Sets the replica state back to 0 (Bootstrap), then starts to bootstrap again as if the replica state were 0.
5	Bootstrap completed; failure detected for one or more naming contexts.	Logs an error message in oidrepld.log similar to this: 2004/09/24:17:13:30 * Replication BOOTSTRAP_ERROR mode detected for replica(dlsun1418_replica2) Then it waits until the replica state is reset properly.
6	Database copy-Based addnode;	This mode indicates that the replica is a database copy-based addnode.
7	Sync schema	Sync schema, but not data, from supplier to consumer.
8	Boot strap without schema sync	If schema sync was previously performed, but bootstrapping failed at a subsequent step, bootstrapping is started again without performing another schema sync.

Oracle Internet Directory replication server logs the bootstrapping process in the Oracle Internet Directory replication server log, $DOMAIN_HOME/servers/OID/logs/componentName/oidrepld00.log.

If bootstrap completes successfully, the log looks similar to the following example, and the replication server automatically starts to perform normal replication processing.

2004/10/06:17:13:25 * Starting OIDREPLD against isunnad03:5555...
2004/10/06:17:13:26 * Starting scheduler...
2004/10/06:17:13:27 * Start to BootStrap from supplier=isunnad03_purify to consumer=isunnad03_purify3
2004/10/06:17:13:28 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ......
2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched
2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=india ......
2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: c=india, 0 entries matched
2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=uk ......
2004/10/06:17:19:57 * gslrbssSyncDIT:Sync done successfully for namingctx: c=uk, 1087 entries matched
2004/10/06:17:19:57 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ......
2004/10/06:17:19:59 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched
2004/10/06:17:20:01 * gslrbsbBootStrap: BOOTSTRAP DONE SUCCESSFULL

If failures are detected, the log looks similar to the following example:

2004/09/14:12:57:23 * Starting OIDREPLD against dlsun1418:4444...
2004/09/14:12:57:25 * Starting scheduler...
2004/09/14:12:57:26 * Start to BootStrap from supplier=dlsun1418_replica to consumer=dlsun1418_replica2
2004/09/14:12:57:27 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ......
2004/09/14:12:58:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched
2004/09/14:12:58:21 * gslrbssSyncDIT:Replicating namingcontext=cn=quan zhou ......
2004/09/14:12:58:23 * BootStrap failure when adding DN=cn=Quan Zhou,server=dlsun1418_replica2,err=Constraint violation.
2004/09/14:12:58:23 * gslrbssSyncDIT:Sync failed for namingctx: cn=quan zhou, only 1 entries retrieved
2004/09/14:12:58:23 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ......
2004/09/14:12:58:25 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched
2004/09/14:12:58:51 * gslrbsbBootStrap: Failure occurred when bootstrapping 1 out of 3 namingcontext(s) from the supplier

Tip:

You have two options for troubleshooting bootstrap failure.

Option 1: Identify the cause of the bootstrap failure and fix the cause, then restart bootstrapping by setting the consumer replica's orclreplicastate to Bootstrap mode.
Option 2: Identify the naming contexts that failed to be bootstrapped and use oidcmprec to reconcile them. Then resume replication by setting the consumer replica's orclreplicastate to Online mode.

Note:

Oidrepld is now in Bootstrap_error mode, so you do need to reset the consumer replica's replica state (orclreplicastate).

A.3.3 Managing an Entry Using Multimaster Replication Process

This section describes how the multimaster replication process adds, deletes, and modifies entries, and how it modifies DNs and RDNs. It contains these topics:

A.3.3.1 How the Multimaster Replication Process Adds a New Entry to a Consumer

When the directory replication server adds a new entry to a consumer, it follows this change application process:

The directory replication server looks in the consumer for the DN of the parent of the target entry. Specifically, it does this by looking for a global unique identifier (GUID) assigned to the DN of the parent.
If the parent entry exists, then the directory replication server composes a DN for the new entry and places the new entry under its parent in the consumer. It then places the change entry in the purge queue.

If the change entry is not successfully applied on the first try, then:

The directory replication server places the new change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

If the change entry is not successfully applied on all but the last retry, then:

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

If the change entry is not successfully applied on the last retry, then:

The directory replication server checks to see if the new entry is a duplicate of an existing entry.

If the change entry is a duplicate entry, then:

The directory replication server applies the following conflict resolution rules:

The entry with the older creation time stamp is used.
If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change is applied, and the change entry is placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry, then:

The directory replication server places the change entry in the human intervention queue, and repeats the change application process at the interval you specified in the orclHIQSchedule parameter.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the human intervention queue manipulation tool to resolve the conflict.

A.3.3.2 How the Multimaster Replication Process Deletes an Entry

When the directory replication server deletes an entry from a consumer, it follows this change application process:

The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.
If the matching entry exists in the consumer, then the directory replication server deletes it. It then places the change entry in the purge queue.

If the change entry is not successfully applied on the first try, then:

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

If the change entry is not successfully applied on all but the last retry, then:

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

If the change entry is not successfully applied on the last retry, then:

The directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the human intervention queue manipulation tool to resolve the conflict.

A.3.3.3 How the Multimaster Replication Process Modifies an Entry

When the directory replication server modifies an entry in a consumer, it follows this change application process:

The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.
If the matching entry exists in the consumer, then the directory replication server compares each attribute in the change entry with each attribute in the target entry.
The directory replication server then applies the following conflict resolution rules:
1. The attribute with the most recent modify time is used.
2. The attribute with the most recent version of the attribute is used—for example, version 1, 2, or 3.
3. The modified attribute on the host whose name is closest to the beginning of the alphabet is used.
The directory replication server applies the filtered modification, and places the change entry in the purge queue.

If the change entry is not successfully applied on the first try, then:

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

If the change entry is not successfully applied on all but the last retry, then:

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

If the change entry is not successfully applied by the last retry, then:

The directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. You can use the Oracle Internet Directory Comparison and Reconciliation Tool and the Human Intervention Queue Manipulation Tool to resolve the conflict.

A.3.3.4 How the Multimaster Replication Process Modifies a Relative Distinguished Name

When the directory replication server modifies the RDN of an entry in a consumer, it follows this change application process:

The directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.
If the matching entry exists in the consumer, then the directory replication server modifies the RDN of that entry and places the change entry in the purge queue.

If the change entry is not successfully applied on the first try, then:

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

If the change entry is not successfully applied on all but the last retry, then:

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

If the change entry is not successfully applied on the last retry, then:

The directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.

If the change entry is a duplicate entry, then:

The directory replication server applies the following conflict resolution rules:

The entry with the older creation time stamp is used.
If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry, then:

The directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the Human Intervention Queue Manipulation Tool to resolve the conflict.

A.3.3.5 How the Multimaster Replication Process Modifies a Distinguished Name

When the directory replication server modifies the DN of an entry in a consumer, it follows this change application process:

The directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.

The directory replication server also looks in the consumer for the parent DN with a GUID that matches the GUID of the new parent specified in the change entry.
If both the DN and the parent DN of the target entry exist in the consumer, then the directory replication server modifies the DN of that entry and places the change entry in the purge queue.

If the change entry is not successfully applied on the first try, then:

The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

If the change entry is not successfully applied on all but the last retry, then:

The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

If the change entry is not successfully applied by the last retry, then:

The directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.

If the change entry is a duplicate entry, then:

The directory replication server applies the following conflict resolution rules:

The entry with the older creation time stamp is used.
If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry, then:

The directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the Human Intervention Queue Manipulation Tool to resolve the conflict.