Re: contextCSN of subordinate syncrepl DBs

[Howard Chu <hyc@symas.com>]

Rein Tollevik wrote:
> I've been trying to figure out why syncrepl used on a backend that is 
> subordinate to a glue database with the syncprov overlay should save the 
> contextCSN in the suffix of the glue database rather than the suffix of 
> the backend where syncrepl is used.  But all I come up with are reasons 
> why this should not be the case.  So, unless anyone can enlighten me as 
> to what I'm missing, I suggest that this be changed.
> 
> The problem with the current design is that it makes it impossible to 
> reliably replicate more than one subordinate db from the same remote 
> server, as there are now race conditions where one of the subordinate 
> backends could save an updated contextCSN value that is picked up by the 
> other before it has finished its synchronization. An example of a 
> configuration where more than one subordinate db replicated from the 
> same server might be necessary is the central master described in my 
> previous posting in 
> http://www.openldap.org/lists/openldap-devel/200806/msg00041.html
> 
> My idea as to how this race condition could be verified was to add 
> enough entries to one of the backends (while the consumer was stopped) 
> to make it possible to restart the consumer after the first backend had 
> saved the updated contextCSN but before the second has finished its 
> synchronization.  But I was able to produce it by simply add or delete 
> of an entry in one of the backends before starting the consumer.  Far to 
> often was the backend without any changes able to pick up and save the 
> updated contextCSN from the producer before syncrepl on the second 
> backend fetched its initial value.  I.e it started with an updated 
> contextCSN and didn't receive the changes that had taken place on the 
> producer.  If syncrepl stored the values in the suffix of their own 
> database then they wouldn't interfere with each other like this.

OK.

> There is a similar problem in syncprov, as it must use the lowest 
> contextCSN value (with a given sid) saved by the syncrepl backends 
> configured within the subtree where syncprov is used.  But to do that it 
> also needs to distinguish the contextCSN values of each syncrepl 
> backend, which it can't do when they all save them in the glue suffix.
> This also implies that syncprov must ignore contextCSN updates from 
> syncrepl until all syncrepl backends has saved a value, and that 
> syncprov on the provider must send newCookie sync info messages when it 
> updates its contextCSN value when the changed entry isn't being 
> replicated to a consumer.  I.e as outlined in the message referred to above.

Then (at least) at server startup time syncprov must retrieve the contextCSNs
from all of its subordinate DBs. Perhaps a subtree search with filter
"(contextCSN=*)" would suffice; this would of course require setting a
presence index on this attribute to run reasonably. (Or we can add a glue
function to return a list of the subordinate suffixes or DBs...)

By the way, please use "subordinate database" and "superior database" when
discussing these things; "glue database" is too ambiguous.
-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/