<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/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 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 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>
</body>
</html>