Re: (ITS#6641) Syncrepl failure with 'overlay unique'

[hyc@symas.com]

Howard Chu wrote:
> andrew.findlay@skills-1st.co.uk wrote:
>> Full_Name: Andrew Findlay
>> Version: 2.4.23
>> OS: SLES 10.3 x86_64
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (88.97.25.132)
>>
>>
>> The attribute uniqueness overlay can cause syncrepl to jam up.
>> Consider this case:
>
>> The obvious answer is for syncrepl to bypass all data checks, as the supplier
>> server should have already enforced them. The problem with that is that clients
>> could see data that breaks the rules if they query while syncrepl is running
>> (unless the refresh phase is handled as a single transaction and thus isolated
>> from clients until it is complete).
>
> We've talked about doing this isolation in the first refresh upon slapd
> startup. That might still be a good idea.

But that reminds me of the joys of being a Sun sysadmin back in the 1980s, 
when Sun's boot scripts always started their NFS client before starting their 
NFS server. If two machines cross-mounted each other's filesystems and both 
were booting at the same time they would hang, each waiting for the other's 
NFS server to respond to their mount request.

Mirrormode and multimaster bootstrapping becomes a lot harder if you implement 
this type of isolation during startup refresh.

> Doing it on every refresh seems far more problematic, because without some
> type of multi-version concurrency control, that means making the server
> non-responsive until the refresh completes.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/