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

Re: syncrepl simplification

Aaron Richton wrote:

I vote in favor of a single context. Among the few odds I don't
understand of syncrepl, there's the usefulness of the "attrsonly"
parameter to searches, the usefulness fo the size/time limits and so.
In my opinion, if the aim is to have a replica of a database, the
updates should be performed with essentially unlimited administrative
privileges. I might be missing something, or others may have a much

attrsonly and certain limits, like time, make very little sense. (I could
make an argument that a time limit might stop a runaway process, but I'd
sooner leave that to the operating system, ulimit or such.)


I've found it important to have data limits, eg certain parts of the tree
and/or attributes, available. In practice, however, I find myself
implementing those on the server side, and giving the slave maintainer
some DN with not-quite-everything visible as the syncrepl bind DN. I'm not
even sure if the client-side functionality (which is there with the attrs=
directive) is strictly necessary.

Well, part of the idea behind syncrepl is to eliminate the need to explicitly configure replication agreements on the provider. While you can certainly control access to data on the provider (using ACLs and whatnot) you wouldn't want to be forced into making a lot of special settings on the provider for the purpose of limiting replication. As such, the client-side attrs= option makes sense.

Going to a single context sounds like a good idea. If I'm not missing
something, I think this might also allow for the rid= parameter to go
away, which is a big win from a usability perspective (no more phantom
cn=syncreplXXX entry, no more thinking up fresh RIDs, etc.)

Yes, that's been very inconvenient and I'd like to make it go away.

re: limits - sizelimits are a particular problem; since entries are not transmitted in entryCSN order, any refresh phase that is interrupted by a sizelimit is essentially wasted. The provider only sends a fresh cookie at the end of the refresh phase because it can't be incremented safely during the refresh. As such, incremental refreshes are impossible. (This problem could be solved if we had server-side sorting; the provider could send entries in entryCSN order then, so it could send a fresh cookie with every entry.)

-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support