Peter Mogensen wrote:
What I do is:
- Took an slapcat generated LDIF from a 2.3.x setup
- Removed all entryCSN and contextCSN lines.
- Ran "slapadd -S 1 -q -w -l ~/load_noCSN.ldif" on server-1
- Did a "slapcat > toserver2.ldif" on server-1
- Started server-1 and let applications create and modify objects.
- Moved toserver2.ldif to server-2.
- Ran slapadd -q -l toserver2.ldif on server-2
- Started server-2
Now - I would expect the objects created on step 5 to appear after a while on server-2. They are not.
I have discovered, that after load on server-1, the first thing I usually to is to modify the userPassword attribute of the database root object. userPassword is not used by syncrepl, only by an client application. syncrepl uses cn=config which is rootdn in both cn=config and the database.
This of course changes the entryCSN of the root object: Before the modification: entryCSN: 20091202100930.380800Z#000000#001#000000 contextCSN: 20091202100930.696427Z#000000#001#000000
After the modification: contextCSN: 20091202100930.696427Z#000000#001#000000 userPassword:: BASE64 entryCSN: 20091202101058.188515Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20091202101058Z
What surprises me is that contextCSN does not change. Shouldn't contextCSn change when entryCSN of the root object changes?
/Peter