[Date Prev][Date Next]
Re: syncrepl simplification
OK, these changes are complete and working in HEAD:
syncrepl consumer only uses be_rootdn
only one consumer per database allowed (as it turns out, config.c
already returned an error if you tried to specify more, so apparently no
one was ever using multiple contexts anyway.)
consumer context is stored in suffix contextCSN attribute, same as
the provider - no more syncrepl subentries.
slapadd options -p, -r, and -i removed.
-w option causes the suffix contextCSN to be updated with the
old value, if any
greatest entryCSN seen in the current Add session
slapcat options -k and -m removed.
provider uses a single sessionlog for the entire context, it is
used automatically for all sync operations. No more sid in sync cookie.
The slapadd -w option is really just a convenience now. Since the
syncprov overlay will scan the database on startup, it will work fine if
you load a provider without it. (But using -w in this case will of
course allow syncprov to startup quicker.) Also since the -w option
compares the old max with the current max, you can run incremental
slapadd's and still get the right result. (It's important not to just
override the old contextCSN with the greatest entryCSN in the current
database; if the last operation on a database was a delete then the
contextCSN will be greater than all the entryCSNs in the database and
just using the greatest entryCSN would therefore cause a rollback.)
So now any provider database can be used as a consumer and vice versa,
without any tweaking in between.
There was a bug where deletes from a sessionlog didn't propagate in a
cascaded setup, but that all works now. We may need to extend the
syncrepl test scripts to test with and without a sessionlog, although it
looks like test019 does some of this already.
Howard Chu wrote:
Kurt D. Zeilenga wrote:
At 09:19 PM 1/12/2005, Howard Chu wrote:That actually makes sense, although the current code doesn't allow for
this. It would require the sessionlog config directive to take a
search specifier (baseDN of a subtree at least) to differentiate logs.
Again this is problematic when you're dealing with ModDN requests; if
an entry moves across a sessionlog boundary then one or both logs
Kurt D. Zeilenga wrote:
The rationale, I believe, for multiple consumer contexts
within a database context was that administrators could state
different consumer policies for different areas of the DIT.
I'll have to think about that some more.
I've been, too. In particular, I think the above rationale more
applies to provider contexts, where one might want to have different
server handling of different requests. For instance, one might
want to have one area covered by a session log and one area not.
At the moment all updates in a context are recorded in all the active
sessionlogs, so the only difference between the multiple logs is their
size. This also seems unnecessary, it would be best to have a single
log of the largest practical size. I have a feeling this sessionlog
stuff was not thoroughly thought out; the fact that there is no config
keyword for the sid on the consumer implies to me that it was never
even tested before.
Given all of this, I think it would be best to have only one
sessionlog per provider, and we can forget about the sid parameter
On the consumer side, we just just require additional
database contexts where the admin desires different consumer
To me, it still sounds like a recipe for disaster. If the separate
consumer contexts are talking to different providers, then you have
the cascade problem I mentioned before. If the contexts are all
pulling from the same provider, then I guess it works. I still don't
see any rationale for the updatedn on the consumer; surely any data
that the provider returns must satisfy the consumer criteria and
therefore must be reflected into the consumer DB.
I concur with regards to the updatedn. Also, we need to revisit
consumer ACLs. Seems odd to me that syncrepl consumer needs
permission to write into its own database.
Yes. OK, I'm going to delete the updatedn stuff then.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support