[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
--20cf303ea4b89c8b7504e7abe440
Content-Type: text/plain; charset=ISO-8859-1
Hi, this *could* be also the root cause of a problem I found some times ago
joking with a particular OL cluster scenario in which I failed to obtain
all entries correctly populated. Please tell me if this could be related.
Long story short:
4-way multimaster cluster --> cluster A
3-way multimaster cluster --> cluster B
one of the members of cluster A has also configured, as provider, one of
the member of cluster B.
By modifying data on any of the members of cluster A I should be able to
see the modification also on any member of cluster B. Correct?
Well, this was failing sometimes on 1 or 2 members.
I had load balancer health-checks continuously polling all of members from
both A and B:
- bind
- search
- unbind
All the members of the cluster were using the contrib/slapo-lastbind
overlay. So the internal authTimestamp attribute populated by an internal
operation.
Could it be that the contextCSN of one node of the cluster were newer than
the one of the providers?
I'm not too expert, just trying to be of help by sharing experiences.
Thanks for reading
Marco
--20cf303ea4b89c8b7504e7abe440
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi, this *could* be also the root cause of a problem I fou=
nd some times ago joking with a particular OL cluster scenario in which I f=
ailed to obtain all entries correctly populated. Please tell me if this cou=
ld be related.<div>
<br></div><div>Long story short:</div><div>4-way multimaster cluster -->=
cluster A</div><div>3-way multimaster cluster --> cluster B</div><div><=
br></div><div>one of the members of cluster A has=A0also=A0configured, as p=
rovider, one of the member of cluster B.</div>
<div><br></div><div>By modifying data on any of the members of cluster A I =
should be able to see the modification also on any member of cluster B. Cor=
rect?</div><div>Well, this was failing sometimes on 1 or 2 members.<br>
</div><div><br></div><div>I had load balancer health-checks continuously po=
lling all of members from both A and B:</div><div>- bind</div><div>- search=
</div><div>- unbind</div><div><br></div><div>All the members of the cluster=
were using the contrib/slapo-lastbind overlay. So the internal authTimesta=
mp attribute populated by an internal operation.</div>
<div>Could it be that the contextCSN of one node of the cluster were newer =
than the one of the providers?</div><div><br></div><div>I'm not too exp=
ert, just trying to be of help by sharing experiences.</div><div>Thanks for=
reading</div>
<div>Marco</div></div>
--20cf303ea4b89c8b7504e7abe440--