<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/17/2013 10:15 AM, thierry bordaz
wrote:<br>
</div>
<blockquote cite="mid:525F9C8A.4060605@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 10/16/2013 05:41 PM, Ludwig
Krispenz wrote:<br>
</div>
<blockquote cite="mid:525EB3AE.2050609@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 10/16/2013 05:28 PM, Mark
Reynolds wrote:<br>
</div>
<blockquote cite="mid:525EB0B9.8020901@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 10/16/2013 11:05 AM, Ludwig
Krispenz wrote:<br>
</div>
<blockquote cite="mid:525EAB4D.80308@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 10/15/2013 10:41 PM, Mark
Reynolds wrote:<br>
</div>
<blockquote cite="mid:525DA868.6040003@redhat.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div class="moz-text-flowed" style="font-family:
-moz-fixed; font-size: 12px;" lang="x-western"><a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://fedorahosted.org/389/ticket/47368">https://fedorahosted.org/389/ticket/47368</a>
<br>
<br>
So we run into issues when trying to figure out if
replicas are in synch(if those replicas use fractional
replication and "strip mods"). What happens is that an
update is made on master A, but due to fractional
replication there is no update made to any replicas. So
if you look at the ruv in the tombstone entry on each
server, it would appear they are out of synch. So using
the ruv in the db tombstone is no longer accurate when
using fractional replication. <br>
<br>
I'm proposing a new ruv to be stored in the backend
replica entry: e.g.
cn=replica,cn="dc=example,dc=com",cn=mapping
tree,cn=config. I'm calling this the "replicated ruv".
So whenever we actually send an update to a replica,
this ruv will get updated. </div>
</blockquote>
I don't see how this will help, you have an additional info
on waht has been replicated (which is available on the
consumer as well) and you have a max csn, but you don't know
if there are outstanding fractional changes to be sent.<br>
</blockquote>
Well you will know on master A what operations get
replicated(this updates the new ruv before sending any
changes), and you can use this ruv to compare against the
other master B's ruv(in its replication agreement). Maybe I
am missing your point? </blockquote>
MY point is that the question is, what is NOT yet replicated.
Without fractional replication you have states of the ruv on all
servers, and if ruv(A) > ruv(B) you know there are updates
missing on B. With fractional, if (ruv(A) > ruv(B) this might
be ok or not. If you keep an additional ruv on A when sending
updates to be, you can only record what ws sent or attempted to
send, but not what still has to be sent<br>
</blockquote>
<br>
I agree with you Ludwig, but unless I missed something would not
be enough to know that the replica B is late or in sync ?<br>
<br>
For example, we have updates U1 U2 U3 and U4. U3 should be skipped
by fractional replication.<br>
<br>
replica RUV (tombstone) on master_A contains U4 and master_B
replica RUV contains U1.<br>
Let's assume that as initial value of the "replicated ruv" on
master_A we have U1.<br>
Starting a replication session, master_A should send U2 and update
the "replicated ruv" to U2.<br>
If the update is successfully applied on master_B, master_B
replica ruv is U2 and monitoring the two ruv shoud show they are
in sync.<br>
</blockquote>
They are not, since U4 is not yet replicated, in master_A you see
the "normal" ruv as U4 and the "replicated" ruv as U2, but you don't
know how many changes are between U2 and U4 an if any of them should
be replicated, the replicated ruv is more or less a local copy of
the remote ruv<br>
<blockquote cite="mid:525F9C8A.4060605@redhat.com" type="cite"> If
the update is not applierd, master_B replica ruv stays at U1 and
the two ruv will show out of sync.<br>
<br>
In the first case, we have a transient status of 'in sync' because
the replica agreement will evaluate U3 then U4 then send U4 and
store it into the "replicated ruv". At this point master_A and
master_B will appear out of sync until master_B will apply U4.<br>
If U4 was to be skipped by fractional we have master_B ruv and
Master_A replicated ruv both showing U2 and that is correct both
servers are in sync.<br>
<br>
Mark instead of storing the replicated ruv in the replica, would
not be possible to store it into the replica agreement (one
replicated ruv per RA). So that it can solve the problem of
different fractional replication policy ?<br>
<br>
<blockquote cite="mid:525EB3AE.2050609@redhat.com" type="cite">
<blockquote cite="mid:525EB0B9.8020901@redhat.com" type="cite">Do
you mean changes that have not been read from the changelog
yet? My plan was to update the new ruv in perform_operation()
- right after all the "stripping" has been done and there is
something to replicate. We need to have a ruv for replicated
operations.<br>
<br>
I guess there are other scenarios I didn't think of, like if
replication is in a backoff state, and valid changes are
coming in. Maybe, we could do test "stripping" earlier in the
replication process(when writing to the changelog?), and then
update the new ruv there instead of waiting until we try and
send the changes.<br>
<blockquote cite="mid:525EAB4D.80308@redhat.com" type="cite">
<blockquote cite="mid:525DA868.6040003@redhat.com"
type="cite">
<div class="moz-text-flowed" style="font-family:
-moz-fixed; font-size: 12px;" lang="x-western">Since we
can not compare this "replicated ruv" to the replicas
tombstone ruv, we can instead compare the "replicated
ruv" to the ruv in the replica's repl agreement(unless
it is a dedicated consumer - here we might be able to
still look at the db tombstone ruv to determine the
status). <br>
<br>
Problems with this approach: <br>
<br>
- All the servers need to have the same replication
configuration(the same fractional replication policy and
attribute stripping) to give accurate results. <br>
<br>
- If one replica has an agreement that does NOT filter
the updates, but has agreements that do filter updates,
then we can not correctly determine its synchronization
state with the fractional replicas. <br>
<br>
- Performance hit from updating another ruv(in
cn=config)? <br>
<br>
<br>
Fractional replication simply breaks our monitoring
process. I'm not sure, not without updating the repl
protocol, that we can cover all deployment
scenarios(mixed fractional repl agmts, etc). However, I
"think" this approach would work for most
deployments(compared to none at the moment). For IPA,
since they don't use consumers, this approach would work
for them. And finally, all of this would have to be
handled by a updated version of repl-monitor.pl. <br>
<br>
This is just my preliminary idea on how to handle this.
Feedback is welcome!! <br>
<br>
Thanks in advance, <br>
Mark <br>
<div class="moz-txt-sig"> <br>
</div>
</div>
<pre class="moz-signature" cols="72">--
Mark Reynolds
389 Development Team
Red Hat, Inc
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:mreynolds@redhat.com">mreynolds@redhat.com</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
389-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:389-devel@lists.fedoraproject.org">389-devel@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/389-devel">https://admin.fedoraproject.org/mailman/listinfo/389-devel</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
389-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:389-devel@lists.fedoraproject.org">389-devel@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/389-devel">https://admin.fedoraproject.org/mailman/listinfo/389-devel</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Mark Reynolds
389 Development Team
Red Hat, Inc
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:mreynolds@redhat.com">mreynolds@redhat.com</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
389-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:389-devel@lists.fedoraproject.org">389-devel@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/389-devel">https://admin.fedoraproject.org/mailman/listinfo/389-devel</a></pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>