Hi,
It seems weird results are popping up faster than I can assemble test-setups to reproduce.
I ran a test in mirrormode were I: 1) Took an slapcat generated LDIF from a 2.3.x setup 2) Removed all entryCSN and contextCSN lines. 3) Ran "slapadd -S 1 -q -w -l ~/load_noCSN.ldif" on server-1 4) Did a "slapcat > toserver2.ldif" on server-1 5) Started server-1 and let applications create and modify objects. 6) Moved toserver2.ldif to server-2. 7) Ran slapadd -q -l toserver2.ldif on server-2 8) Started server-2
Now - I would expect the objects created on step 5 to appear after a while on server-2. They are not. The reason seems to be that the contextCSN has not been updated properly on server-1.
The contextCSN in the "toserver2.ldif" file from step 4 is: 20091118173357.690685Z#000000#001#000000
The contextCSN on both servers are now: 20091119140605.714382Z#000000#001#000000
The entry on server-1 having that entryCSN is a modified object, however, the change has not been replicated to server-2.
Likewise, the entryCSN for one created object in step 5 is: 20091119094729.719193Z#000000#001#000000 It is not present on server-2, but it appears TWICE in a the result from an ldapsearch (scope sub) on its parent object on server-1.
?!?! .. I'm lost. From all I know this should not happen on a healthy setup - unless there's something badly wrong with the procedure I've described above.
It's slapd 2.4.19 with BDB4.8
/Peter
Peter Mogensen wrote:
Hi,
It seems weird results are popping up faster than I can assemble test-setups to reproduce.
?!?! .. I'm lost. From all I know this should not happen on a healthy setup - unless there's something badly wrong with the procedure I've described above.
It's slapd 2.4.19 with BDB4.8
Please test CVS RE24. 2.4.20 is being prepped for release and probably all of these issues have already been addressed.
Howard Chu wrote:
It's slapd 2.4.19 with BDB4.8
Please test CVS RE24. 2.4.20 is being prepped for release and probably all of these issues have already been addressed.
At least the issue about the entry appearing twice in LDIF from ldapsearch is still present in a test with RE24 from today.
If I search the parent with scope "sub" I get the entry twice. If I search with the entry as base, it's only there once.
Results about the weirdness about contextCSN is still pending (the LDIF is still loading on server-2).
/Peter
Peter Mogensen wrote:
Howard Chu wrote:
It's slapd 2.4.19 with BDB4.8
Please test CVS RE24. 2.4.20 is being prepped for release and probably all of these issues have already been addressed.
At least the issue about the entry appearing twice in LDIF from ldapsearch is still present in a test with RE24 from today.
If I search the parent with scope "sub" I get the entry twice. If I search with the entry as base, it's only there once.
Results about the weirdness about contextCSN is still pending (the LDIF is still loading on server-2).
There's no difference between 2.4.19 and CVS RE24. I still don't get the entries replicated even if contextCSN is updated and there's still an entry with ldapsearch outputs twice.
/Peter
openldap-technical@openldap.org
-
Howard Chu -
Peter Mogensen