Hi Foucauld, unfortunately it’s not a safe assumption. The replicator will by default parallelize the requests between a given source and target, and in the course of that parallelization it may update documents on a target in a different order than they originally appeared on the source.
The problem you’re describing is one I’ve given some thought to in the context of internal replications in a CouchDB 2.0 cluster, where it’s important to be able to compute what fraction of documents in a database have been durably stored on a minimum number of replicas. One thing we know is important to track is the minimum sequence in a target database that wholly contains a peer sequence in the source database; e.g. what’s the sequence in B at the moment that a given checkpointed_source_seq is recorded for an A -> B replication? My recollection is that the replicator does _not_ track that bit of information today - but it could. Regards, Adam > On Jul 30, 2015, at 4:19 AM, Foucauld Degeorges <[email protected]> wrote: > > Awesome, thanks. > Now, to push it a bit further, let's suppose I have three databases in > replication : A -> B -> C, and I need to know which document created in A > is the last one that got to C, so I can display a "synchronized / not > synchronized" symbol next to the various documents in my view. > > To know which document got to C, here is my idea: using B's _active_tasks I > know which update sequence of B got to C. I query B's _changes feed to know > what document/revision that update sequence concerns. I query that same > document/revision on A using the local_seq option. Now I know which update > sequence of A is the last one that got to C, assuming that* sequences are > kept in the same order* through two replications. > > Is that a safe assumption? Or can anyone think of a simpler way to do this, > without having to HEAD each document individually? > > Foucauld > > > 2015-07-29 17:18 GMT+02:00 Alexander Shorin <[email protected]>: > >> On Wed, Jul 29, 2015 at 6:13 PM, Foucauld Degeorges <[email protected]> >> wrote: >>> Just to clarify, by "completed sequence" you mean >> checkpointed_source_seq, >>> is that right ? >> >> Yes. This is an update sequence of source which is recorded in >> checkpoint what means that all the data up to that value are already >> replicated. >> >> -- >> ,,,^..^,,, >>
