[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Getting around the single-threaded syncrepl model?



Bannister, Mark wrote:
> If we're primarily adding or deleting entire objects, however, not modifying single attributes,
> won't delta-syncrepl just fall back to syncrepl anyway?

Can't you change your modification process to modify entries instead of
deleting and re-adding them?

When implementing custom sync jobs I always try to minimize write requests to
the providers to avoid the replication storm needed.  Mainly this is what
python-ldap's sub-module ldap.modlist.modifyModlist() is for.  Of course you
have to read all the old entries but that's way less load.

This also has the advantage that the entryUUID is kept which you can use for
robust syncing to other systems even in the case the DN is changed. You also
will have a better accesslog.

> And this still doesn't change the fact that I'm now going to have to spin
> up 10-20 LDAP replicas on a single machine to get around the
> single-threaded replication engine problem.

This is the concept of "replication hubs". You can do this to spread the
syncrepl load.

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature