[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--001a113f999e8de01b052fe42f4a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Quanah,
I do see in the consumer log that it is retrieving and applying the
updates. So the do_syncrep2 log entries also show the missing ,csn=3D...
condition.
Therefore, yes, there is no delay in data the actual replication being
performed - there is a delay (as evidenced by the check of the CSN in the
DSA of the provider and consumer report) in the CSN attribute for the DSA
being updated. Clearly, syncrepl sees the CSN's coming across so it should
be able to handle the lack of the CSN being in the response from the
provider and get the DSA's CSN updated. I'll see if I can figure out a
patch that will work.
(sending from my personal address because I'm tired of gauss marking
everything I send as probably spam - I'm not really that suspicious a
character)
- Frank
On Thu, Apr 7, 2016 at 8:20 AM, Frank Swasey <Frank.Swasey@uvm.edu> wrote:
> On 4/7/16, 12:04 AM, "openldap-bugs on behalf of quanah@zimbra.com" <
> openldap-bugs-bounces@openldap.org on behalf of quanah@zimbra.com> wrote:
>
> >--On Thursday, April 07, 2016 4:22 AM +0000 quanah@zimbra.com wrote:
> >
> >> So the change is still correctly replicated to the replicating MMR nod=
e.
> >
> >I see the same behavior with the example configuration that was provided
> as
> >well. While the CSN bit may not be logged, the change is replicated as =
it
> >should be.
>
> <snip>
> >
> >So while the lack of the ,csn bit is annoying... I see no actual data
> loss,
> >etc.
>
>
> Quanah,
>
> I=E2=80=99ll go peer deeper into the logs on the consumer side.
>
> If I find the same here, that indicates the provider is saying =E2=80=
=9Cthere
> are changes=E2=80=9D but not sending the CSN and syncrepl is retrieving a=
nd
> applying the changes, but not updating the CSN in the DSA of the consumer=
.
> Which suggests that syncrepl needs a patch or that I should not be trusti=
ng
> the CSN value in the consumer=E2=80=99s DSA in the check_syncrepl script =
(although,
> I can=E2=80=99t think of another quick way to assess whether the provider=
and
> consumer are in sync - off the top of my head). Eventually, syncprov doe=
s
> send the CSN and the consumer=E2=80=99s CSN gets updated, so things repor=
t as
> having caught up.
>
> - Frank
>
>
--=20
I am not young enough to know everything. - Oscar Wilde (1854-1900)
--001a113f999e8de01b052fe42f4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Quanah,<div><br></div><div>=C2=A0 I do see in the consumer=
log that it is retrieving and applying the updates.=C2=A0 So the do_syncre=
p2 log entries also show the missing ,csn=3D... condition. =C2=A0</div><div=
><br></div><div>=C2=A0 Therefore, yes, there is no delay in data the actual=
replication being performed - there is a delay (as evidenced by the check =
of the CSN in the DSA of the provider and consumer report) in the CSN attri=
bute for the DSA being updated.=C2=A0 Clearly, syncrepl sees the CSN's =
coming across so it should be able to handle the lack of the CSN being in t=
he response from the provider and get the DSA's CSN updated.=C2=A0 I=
9;ll see if I can figure out a patch that will work.</div><div><br></div><d=
iv>(sending from my personal address because I'm tired of gauss marking=
everything I send as probably spam - I'm not really that suspicious a =
character)</div><div><br></div><div>- Frank</div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Thu, Apr 7, 2016 at 8:20 AM, Frank=
Swasey <span dir=3D"ltr"><<a href=3D"mailto:Frank.Swasey@uvm.edu"; targe=
t=3D"_blank">Frank.Swasey@uvm.edu</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">On 4/7/16, 12:04 AM, "openldap-bugs on behalf of <a hre=
f=3D"mailto:quanah@zimbra.com";>quanah@zimbra.com</a>" <<a href=3D"m=
ailto:openldap-bugs-bounces@openldap.org">openldap-bugs-bounces@openldap.or=
g</a> on behalf of <a href=3D"mailto:quanah@zimbra.com";>quanah@zimbra.com</=
a>> wrote:<br>
<br>
>--On Thursday, April 07, 2016 4:22 AM +0000 <a href=3D"mailto:quanah@zi=
mbra.com">quanah@zimbra.com</a> wrote:<br>
><br>
>> So the change is still correctly replicated to the replicating MMR=
node.<br>
><br>
>I see the same behavior with the example configuration that was provide=
d as<br>
>well.=C2=A0 While the CSN bit may not be logged, the change is replicat=
ed as it<br>
>should be.<br>
<br>
<snip><br>
><br>
>So while the lack of the ,csn bit is annoying... I see no actual data l=
oss,<br>
>etc.<br>
<br>
<br>
Quanah,<br>
<br>
=C2=A0 I=E2=80=99ll go peer deeper into the logs on the consumer side.<br>
<br>
=C2=A0 If I find the same here, that indicates the provider is saying =E2=
=80=9Cthere are changes=E2=80=9D but not sending the CSN and syncrepl is re=
trieving and applying the changes, but not updating the CSN in the DSA of t=
he consumer.=C2=A0 Which suggests that syncrepl needs a patch or that I sho=
uld not be trusting the CSN value in the consumer=E2=80=99s DSA in the chec=
k_syncrepl script (although, I can=E2=80=99t think of another quick way to =
assess whether the provider and consumer are in sync - off the top of my he=
ad).=C2=A0 Eventually, syncprov does send the CSN and the consumer=E2=80=99=
s CSN gets updated, so things report as having caught up.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Frank<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature">I am not young enough to know everything. =
- Oscar Wilde (1854-1900)</div>
</div>
--001a113f999e8de01b052fe42f4a--