<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:56 AM, thierry bordaz
wrote:<br>
</div>
<blockquote cite="mid:525FA63D.9020204@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 10/17/2013 10:49 AM, Ludwig
Krispenz wrote:<br>
</div>
<blockquote cite="mid:525FA4B3.6090209@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<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>
<br>
Yes I agree they are not this is a transient status. Transient
because the RA will continue going through the changelog until it
hits U4. At this point it will write U4 in the "replicated RUV"
and until master_B will apply U4 both server will appear out of
sync.<br>
My understanding is that this "replicated RUV" only says it is in
sync or not, but does not address how far a server is out of sync
from the other (how many updates are missing). When you say it is
more or less a copy, it is exactly what it is. If it is a copy
=> in sync, if it different => out of sync.<br>
</blockquote>
maybe we need to define what "in sync" means. For me in sync means
both servers have the same set of updates applied.<br>
<br>
Forget fractional for a moment, if we have standard replication and
master A is at U4 and master B is at U2, we say they are not in sync
- or not ? You could keep a replicated ruv for thos as well, but
this wouldn't change things.<br>
<blockquote cite="mid:525FA63D.9020204@redhat.com" type="cite"> <br>
<blockquote cite="mid:525FA4B3.6090209@redhat.com" type="cite">
<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>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>