[389-devel] fractional replication monitoring proposal

[Mark Reynolds]

https://fedorahosted.org/389/ticket/47368

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.

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.  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).

Problems with this approach:

-  All the servers need to have the same replication configuration(the 
same fractional replication policy and attribute stripping) to give 
accurate results.

-  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.

-  Performance hit from updating another ruv(in cn=config)?


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.

This is just my preliminary idea on how to handle this.  Feedback is 
welcome!!

Thanks in advance,
Mark

-- 
Mark Reynolds
389 Development Team
Red Hat, Inc
mreynolds at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-devel/attachments/20131015/e21d0b90/attachment.html>