Re: ContextCSN values in 3-multimaster setup

[Quanah Gibson-Mount <quanah@symas.com>]

--On Thursday, January 19, 2017 3:36 PM +0100 Marc Franquesa 
<mark@l3jane.net> wrote:

> > I can assume some downtime and be in safe place. My idea was to proceed
> as follows:
>
> - Take slapcat Backup of all DITs (including cn=config)
> - Remove any contextCSN attribute from the resulting LDIFs
> - Stop all 3 servers
> - Remove entirely the DBs on the servers
> - Do a slapadd of the previous LDIFs
> - Start servers again (so re-replicating again with new contextCSN, now
> corret).
>
> Should that work ? even for cn=config DB ?

That will not work.  As I explained previously, the contextCSN values are 
generated from the entryCSN values in your database.  Removing the 
contextCSN values will have no effect if there still exist entries in your 
database with an entryCSN of serverID's you have since gotten rid of. 
There is also no point in dumping cn=config and doing any work on it, as it 
clearly has the correct values (as per your later data).

> Also to further confuse a bit more the scenario, today I realized that
> a new contextCSN appeared:
>
> dn: dc=l3jane,dc=net
> contextCSN: 20170111084028.692133Z#000000#001#000000
> contextCSN: 20170118224410.110554Z#000000#003#000000
> contextCSN: 20161228225757.121969Z#000000#004#000000
> contextCSN: 20160201102250.543748Z#000000#005#000000
> contextCSN: 20150917152138.054326Z#000000#006#000000

That would mean a modification came in from a serverID where previously 
there had been no modifications from that serverID.

> Also the explanation that conextCSN attribute is =
> contextCSN#rid#sid#000000 seem not correct as I have rids 001, 002 and
> 003, and serverIds 1,2,3 so none of this matches with my results.

I'm not clear what you mean.  Your results clearly show that in the course 
of time you have had servers with serverIDs of 1, 3, 4, 5, and 6 that have 
received modifications.  A contextCSN for a given SID will *only* show up 
if a modification was ever performed on the server with that given SID 
(thus causing an entryCSN value to be generated for that SID).
> But I get this contextCSN values:
>
> dn: cn=config
> contextCSN: 20170111084531.247823Z#000000#001#000000
> contextCSN: 20161230165409.486624Z#000000#003#000000
>
> Si I'm missing one contextCSN? (there are 3 providers) ?

No.  See above.

> # ldapsearch -LLL -x  -s base  contextCSN
> dn: dc=l3jane,dc=net
> contextCSN: 20170111084028.692133Z#000000#001#000000
> contextCSN: 20170118224410.110554Z#000000#003#000000
> contextCSN: 20161228225757.121969Z#000000#004#000000
> contextCSN: 20160201102250.543748Z#000000#005#000000
> contextCSN: 20150917152138.054326Z#000000#006#000000

See above.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>