--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).

--Quanah

--

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

...

...

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