Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1) |
2. The Directory Server Access Control Model
3. Understanding the Directory Server Schema
4. Directory Server Index Databases
5. Directory Server Replication
Overview of the Directory Server Replication Architecture
Basic Replication Architecture
Directory Server Change Processing
Replication Server Selection Algorithm
Replication Server Load Balancing
Historical Information and Conflict Resolution
What is a Replication Conflict?
Purging Historical Information
Schema Replication Architecture
Safe Read Mode and Replication Groups
Assured Replication Connection Algorithm
Assured Replication and Replication Status
Assured Replication Monitoring
Fractional Data Set Identification
Fractional Replication Filtering
Fractional Replication and Local Operations
How the External Change Log Works
Porting Applications That Rely on Other Change Logs
Differences Between the ECL and the LDAP Change Log Draft
Limitations of the Compability API
Each replicated domain in a replicated topology has a certain replication status, depending on its connections within the topology, and on how up to date it is with regard to the changes that have occurred throughout the topology.
Knowledge of a domain's replication status enables a replicated topology to do the following:
Manage certain aspects of assured replication
Enable certain administrative tasks
Administer and monitor replication effectively
For more information, see Monitoring a Replicated Topology in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
The following sections outline the different statuses that a replicated domain can have.
The following list provides a description of each possible replication status that can be held by a replicated domain.
The local replicated domain is not connected to any replication server. Replication cannot occur until a connection to a replication server is established. This is the only possible status if there is no connection to a replication server.
The local replicated domain is almost in sync with its peers (that is, with the updates received on the replication server). The client LDAP requests have been processed normally.
The local replicated domain is too late regarding updates that have been queued by the replication server. What constitutes too late is defined by the degraded status threshold, that is, the number of changes that the replication server has in its queue for the directory server. With this status, the local directory server might be slow in replaying changes. This can have an impact on assured replication.
An online full update is currently being performed on the local replicated domain (in other words, the domain is receiving entries from a remote directory server). The full update must be completed before the status can be changed and before the replicated domain can participate in replication again.
The local replicated domain does not have the same generation ID as the replication server to which it is connected. Replication cannot run until the local domain is initialized with a data set that has the same generation ID as its replication server. To initialize the local domain, perform an online full update, an LDIF import, or a binary copy of the database, retaining the domain entries.
A directory server that is slow in replaying changes is assigned a DEGRADED_STATUS. The stage at which the server is regarded as “too slow” is defined by the degraded status threshold and is configurable, based on the number of updates queued in the replication server for that directory server.
When the degraded status threshold is reached, the directory server assumes a degraded status and is considered to be unable to send acknowledgments in time. A server with this status can have an impact on assured replication, as replication servers no longer wait for an acknowledgment from this server before returning their own acknowledgments.
Apart from being assigned a degraded status, a directory server can change status if an administrator performs one of the following tasks on the topology:
Full update. When a replicated domain is initialized online from another server in the topology, the directory server status for that domain changes to FULL_UPDATE_STATUS. When the full update has completed, the directory server reinitializes its connection to the topology, and the status is reset to NORMAL_STATUS.
Local import or restore. When a replicated domain is reinitialized by using a local import or restore procedure, the directory server status for that domain changes to NOT_CONNECTED_STATUS.
Resetting the generation ID. If a replicated domain connects to a replication server with a generation ID that is different from its own, the domain is assigned a BAD_GEN_ID status. A domain can also be assigned this status if a reconnection occurs after a full online update, a local import, or a restore with a set of data that has a different generation ID to that of the replication server.
In addition, you might need to reset the generation ID of all the replication servers in the topology by running the reset generation ID task on the directory server. This causes all the replication servers in the topology to have a different ID to the ID of the directory servers to which they are connected. In this case, the directory servers are assigned a BAD_GEN_ID status.