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