Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 003127EEC1257EAE_= Content-Type: text/plain; charset="US-ASCII"
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 --=_alternative 003127EEC1257EAE_= Content-Type: text/html; charset="US-ASCII"
<font size=3>Hello,<br> <br> I have additional information. The problem is the entryCSN.<br> User 1, which got replicated has entryCSN: 20150827083333.751721Z#000000#001#000000<br> user 2, which got NOT replicated has entryCSN: 20150827083333.119585Z#000000#001#000000, which seems to be in the past<br> user 3, replicated, 20150827083334.847604Z#000000#001#000000<br> user 4, not replicated 20150827083334.228113Z#000000#001#000000, which seems to be in the past<br> user 5, replicated 20150827083335.588191Z#000000#001#000000<br> user 6, replicated 20150827083335.946835Z#000000#001#000000<br> user 7 not replicated 20150827083335.282686Z#000000#001#000000, which seems to be in the past<br> <br> 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.<br> <br> So I suppose this ITS can be closed, since it is not a bug, but worked as designed?<br> So how to get a good enough time synchronization with windows (since the normal time synchronization of windows seems to be not enough)?<br> Of course, if you close the ITS I can ask this question again in the technical list. </font> <br> <br><font size=3>Regards,</font> <br><font size=3>Frank</font> --=_alternative 003127EEC1257EAE_=--