Write operations in DS (All versions) fail when replication servers are down
The purpose of this article is to provide assistance if DS rejects all write operations when replication servers (RSs) are offline.
Symptoms
In a standalone RS topology (DS <-> RS <-> DS), you notice that write operations (add, modify etc) to the directory servers fail when all RSs are down.
You will see an error similar to the following when this happens:
ADD operation failed Result Code: 53 (Unwilling to Perform) The Replication is configured for suffix dc=example,dc=com but was not able to connect to any Replication ServerRecent Changes
Replication servers (RSs) have been taken offline or shut down for another reason.
Causes
Replication is only possible when at least one RS is up, since DS must be connected to an RS for it to take writes. If replication is configured, the default behavior of the DS is to reject any writes if no RSs are found when an update is received. This prevents divergence between the DSs since it’s impossible to replicate those changes to other servers when the RSs are down or when they come back online.
Solution
This issue can be resolved by ensuring you always have at least one RS online that the DS can connect to.
Note
Setting the replication domain isolation-policy to accept-all-updates when all RSs are offline will cause divergence between the DSs. If you allow all updates, any writes occurring when the RS is down will not be replicated to other DSs, even when the RSs come back online. There is no queuing of changes on a DS waiting for the RS to come online; changes are managed via the RSs' changelogDb.
See Also
How do I troubleshoot replication issues in DS 6.x?
How do I use the Access log to troubleshoot DS (All versions)?
Related Training
N/A
Related Issue Tracker IDs
N/A