Antw: Re: Q: duplicate contextCSN; remove it?

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> Quanah Gibson-Mount <quanah@zimbra.com> schrieb am 29.08.2013 um 18:25 in
Nachricht <56CBB4B791932FE0371D9316@[192.168.1.22]>:
> --On Thursday, August 29, 2013 9:48 AM +0200 Ulrich Windl 
> <Ulrich.Windl@rz.uni-regensburg.de> wrote:
> 
>> Hi!
>>
>> When I examine my slapcat of the config database (multi-master
>> replication), I see a duplicate contextCSN; one of them seems obsolete:
>> contextCSN: 20130722065709.189194Z#000000#000#000000
>> contextCSN: 20130729112421.079210Z#000000#001#000000
>>
>> Can I remove one of those, and if so, how? I tried once, but the CSN
>> re-appered, maybe from an other master...
>>
>> Or are those expected to be there?
> 
> The #000# CSN if from when the database was single master.  It will never 
> update once you've moved to MMR, but there are likely still entries that 
> existed prior to MMR with entryCSNs with #000#.  You can simply ignore that 
> CSN now that you are in MMR mode.  The script I wrote to compare CSNs 
> across MMR nodes does exactly that (ignore's the #000# CSN).

Hi!

(I'm not planning to do this, but) Are you saying if I'd dump the database, replace all "#000#" in CSNs with "#001#" (for example) in non contextCSN attributes, and also delete the #000# contextCSN, that entry will not re-appear? I read from your message that the #000# contextCSN is not replicated from remote, but computed locally from matching entryCSNs, right?

If the server clocks were tightly in sync, the owner of the CSN shouldn't be much of an issue, right (assuming no massive parallel updates happened)?

Regards,
Ulrich

> 
> --Quanah
> 
> 
> --
> 
> Quanah Gibson-Mount
> Lead Engineer
> Zimbra, Inc
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration