> Hello, > > I have additional information. The problem is the entryCSN. > User 1, which got replicated has entryCSN: > 20150827083333.751721Z#000000#001#000000 > user 2, which got NOT replicated has entryCSN: > 20150827083333.119585Z#000000#001#000000, which seems to be in the past > user 3, replicated, 20150827083334.847604Z#000000#001#000000 > user 4, not replicated 20150827083334.228113Z#000000#001#000000, which > seems to be in the past > user 5, replicated 20150827083335.588191Z#000000#001#000000 > user 6, replicated 20150827083335.946835Z#000000#001#000000 > user 7 not replicated 20150827083335.282686Z#000000#001#000000, which > seems to be in the past > > So in previous posts I got the answer, that microseconds exact time > synchronization is only important with master master and concurrent > writes. But now it also seems to be important with delta-synrepl. > > So I suppose this ITS can be closed, since it is not a bug, but worked as > designed? > So how to get a good enough time synchronization with windows (since the > normal time synchronization of windows seems to be not enough)? > Of course, if you close the ITS I can ask this question again in the > technical list. > > Regards, > Frank
ITS#8295 may be the problem here. Fixed in git master. Please test and followup to that ticket, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
