Note: this component is designated "advanced", which means that objects of this type are not expected to be created or altered in most environments. If you believe that such a change is necessary, you may want to contact support in order to understand the potential impact of that change.
A Replication Domain comprises of several Directory Server instances sharing the same synchronized set of data.
The following components have a direct composition relation to Replication Domains:
The properties supported by this managed object are as follows:
| Basic Properties: | Advanced Properties: |
|---|---|
| server-id | window-size |
| base-dn | heartbeat-interval |
| sync-hist-purge-delay | |
| restricted | |
| on-replay-failure-wait-for-dependent-ops-timeout | |
| dependent-ops-replay-failure-wait-time | |
| missing-changes-policy |
| Description | Specifies a unique identifier for the Directory Server within the Replication Domain. Each Directory Server within the same Replication Domain must have a different server ID. A Directory Server which is a member of multiple Replication Domains may use the same server ID for each of its Replication Domain configurations. |
| Default Value | None |
| Allowed Values | An integer value. Lower limit is 1. Upper limit is 65535 . |
| Multi-Valued | No |
| Required | Yes |
| Admin Action Required | None. Modification requires no further action |
| Description | Specifies the base DN of the replicated data. |
| Default Value | None |
| Allowed Values | A valid DN. |
| Multi-Valued | No |
| Required | Yes |
| Admin Action Required | None. Modification requires no further action |
window-size (Advanced Property)
| Description | Specifies the maximum number of replication updates the Directory Server can have outstanding from the Replication Server. To gauge if the current window size setting is sufficient, check the current-rcv-window monitor attribute under load. If it hovers around zero, consider increasing the window size. Likewise, if the current-send-window monitor attribute hovers around zero under load, consider increasing the window size of the associated Replication Server. |
| Default Value | 5000 |
| Allowed Values | An integer value. Lower limit is 10. Upper limit is 100000 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
heartbeat-interval (Advanced Property)
| Description | Specifies the heartbeat interval that the Directory Server will use when communicating with Replication Servers. The Directory Server expects a regular heartbeat coming from the Replication Server within the specified interval. If a heartbeat is not received within the interval, the Directory Server closes its connection and connects to another Replication Server. |
| Default Value | 30000ms |
| Allowed Values | A duration. Lower limit is 10000 milliseconds. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
sync-hist-purge-delay (Advanced Property)
| Description | The time in seconds after which historical information used in replication conflict resolution is purged. The information is removed from entries when they are modified after the purge delay has elapsed. |
| Default Value | 86400s |
| Allowed Values | A duration. Lower limit is 0 seconds. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
restricted (Advanced Property)
| Description | When set to true, changes are only replicated with server instances that belong to the same replication set. By default, replication changes are propagated in the entire topology. In some cases, however, it is desirable to limit the scope of replication. The entry balancing feature, for example, allows the same base DN to be partitioned into multiple data sets. Changes within a data set may be replicated, while the same is not desired between data sets. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
on-replay-failure-wait-for-dependent-ops-timeout (Advanced Property)
| Description | Defines the maximum time to retry a failed operation. An operation will be retried only if it appears that the failure might be dependent on an earlier operation from a different server that hasn't replicated yet. The frequency of the retry is determined by the dependent-ops-replay-failure-wait-time property. Sometimes replicated changes from servers in different remote locations can arrive out-of-order, which leads to replication failures. For instance, a modify of an entry could arrive before the add of the entry. Setting this property gives dependent operations a chance to arrive and be replayed, giving the failed operation a chance to succeed. This property specifies the maximum duration for which the changes may be tried again. For example, if set to 5 seconds, operations from replication that fail to replay can be retried as long as the timestamp of the operation is within 5 seconds of the current system time. This will only delay the processing of a failed dependent operation and any changes that directly depend on it. Operations to unrelated entries will continue to be replicated. Entries matching the filter "(objectClass=ds-replica-monitor-entry)" under cn=monitor have some monitoring attributes that track this behavior, e.g., requeue-retry-op-success-count and requeue-retry-op-failed-count. A value of zero indicates that this setting is disabled, and operations will never be retried for potential dependency failures. |
| Default Value | 0ms |
| Allowed Values | A duration. Lower limit is 0 milliseconds. Upper limit is 60000 milliseconds. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
dependent-ops-replay-failure-wait-time (Advanced Property)
| Description | Defines how long to wait before retrying certain operations, specifically operations that might have failed because they depend on an operation from a different server that has not yet replicated to this instance. If an operation in replication fails to replay due to a dependency on another recent change, then it is useful to wait in order to give the other change some time to finish replicating. This property is used to determine how long to wait before attempting to apply the failed change again. This property is only applicable if the on-replay-failure-wait-for-dependent-ops-timeout property is set to a non-zero value. |
| Default Value | 10ms |
| Allowed Values | A duration. Lower limit is 1 milliseconds. Upper limit is 5000 milliseconds. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
missing-changes-policy (Advanced Property)
| Description | Determines how the server responds when replication detects that some changes might have been missed. Each missing changes policy is a set of missing changes actions to take for a set of missing changes types. The value configured here only applies to this particular replication domain. Each missing changes policy is a set of missing changes actions to take as a function of a set of missing changes types. This makes it possible to select the preferred data integrity to availability tradeoff. Each value offers greater availability than the previous one at the cost of data integrity. Each missing changes event will result in a 'replication-missing-changes-action' alarm with an associated message that will describe the action taken as a function of the missing changes configuration. Alternatively 'missing-changes-policy' may be configured on the replication server if per replication domain configuration is not needed. |
| Default Value | use-server-default |
| Allowed Values | maximum-integrity - Enter the missing changes lockdown state in response to missing changes as much as possible. This strongly favors data integrity over availability. favor-integrity - This is the same as the 'maximum-integrity' policy except there is increased availability with regard to 'indirect' missing changes (the replica is hosted by a server not involved in the connection). Enter the missing changes lockdown state in those case where it makes sense to do so. favor-availability - This is the same as the 'favor-integrity' policy except there is increased availability with regard to 'previous' missing changes (also known as 'null CN' missing changes). With this policy the missing changes state will not persist across restarts of the server. This is the recommended balance between data integrity and availability for most installations. maximum-availability - Never enter the missing changes lockdown state in response to missing changes. This strongly favors availability over data integrity. Note that this value allows changes to be applied from remote servers even though some of those changes are missing, which will cause the replication servers to enter a persistently inconsistent state. To restore the missing changes initialize from a known good server with 'dsreplication initialize'. Alternatively the missing changes can be determined by comparing to a known good server with 'ldap-diff' and then apply the missing changes using the replication repair control. use-server-default - Use the value from the 'missing-changes-policy' property on the replication server. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
To list the configured Replication Domains:
dsconfig list-replication-domains
[--property {propertyName}] ...
To view the configuration for an existing Replication Domain:
dsconfig get-replication-domain-prop
--domain-name {name}
--provider-name {name}
[--tab-delimited]
[--script-friendly]
[--property {propertyName}] ...
To update the configuration for an existing Replication Domain:
dsconfig set-replication-domain-prop
--domain-name {name}
--provider-name {name}
(--set|--add|--remove) {propertyName}:{propertyValue}
[(--set|--add|--remove) {propertyName}:{propertyValue}] ...