Re: Re: (ITS#8223) Replication error when slave is down and insert on master are made

[Frank.Offermanns@caseris.de]

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