Description of problem:

may not be really a new idea, but in case: rfe to "automatically" enable or disable a consumer replication agreement using the topology plug-in from IPA
in the case of high LDAP traffic and let's say a topology with 4xMMR and some numbers of consumers in replication to several masters, there is the "know" issue of high replication latency with the single replication thread.
Once the nsds5ReplicaBusyWaitTime and session time are tuned, the next workaround is to try to reduce the number of replication agreements.

this is happening when there are errors from the replication plug-in like

Unable to acquire replica: the replica is currently being updated by another supplier. Will try later
and
Replication session backing off for 3 seconds

the challenge is, it is not acceptable in some environment to have only one consumer updated by just one master, at least 2 masters must be in replication to a consumer for reliability reason, at the heavy disadvantage of performance (replication latency due to "high" LDAP traffic)

in that situation we have to deal with major blocker for sites that need to grow.

with the nsds5ReplicaEnabled feature, and using the topology plug-in (or any other solid way) to detect a master is going down, the consumer replication agreements should be enabled and disabled on the fly so end users or apps depending on 1 consumer only till get the updated recent data.

this would allow to contribute to less LDAP traffic and significantly reduce replication latency without changing the current implementation (more plug-ins?)

this could also be applied to the masters to reduce the full 4xMMR mesh, or allow to optimize LDAP replication traffic when there are more than 4 masters.
Ideas can go on.

may be there are some plans for IPA with 4.3.2+ for dynamic topologies.

if this makes sense, there should be a patent if applicable.


Version-Release number of selected component (if applicable):
rhds10

How reproducible:
not trivial

Steps to Reproduce:
1. have 4xMMR plus at least 4 consumers, and some data
2. generate "some" MOD, preferably with "large" attribute values in the MB range, quantity depends on environment. size of systems (ram, disk i/o)
3.

Actual results:


Expected results:


Additional info: