<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/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? 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 class="moz-txt-link-abbreviated" href="mailto:389-devel@lists.fedoraproject.org">389-devel@lists.fedoraproject.org</a>
<a 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 class="moz-txt-link-abbreviated" href="mailto:mreynolds@redhat.com">mreynolds@redhat.com</a></pre>
</body>
</html>