If you're running continuous replication, then the process isn't going to reach 100% (since that would imply all future changes have been replicated, which is clearly impossible). I suspect it's just a reporting anomaly. I didn't reply earlier because I hadn't had time to verify the code but since you bumped the thread, I thought I'd best say something.
B. On 21 Jun 2012, at 17:50, Andreas Kemkes wrote: > Reply to [email protected] > > > ________________________________ > From: Andreas Kemkes <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Tuesday, June 19, 2012 5:36 PM > Subject: Replication and checkpoints - what to expect? > > Upgrading to 1.2 on the target system allowed me to setup an unfiltered > continuous replication between a couchdb 1.1.1 instance and a couchdb 1.2 and > then use the latter as the source for several filtered continuous > replications to shard a monolithic couchdb database. > > The unfiltered replication was started from the futon replicator api, all the > others from the command line using the ../_replicate call. All replications > are pull. > > The all work nicely, except that the replication between couchdb 1.1.1 and > couchdb 1.2 seems to not write any checkpoints after a while: > > Checkpointed source sequence 911275, current source sequence 918089, progress > 99% > > Is this to be expected? Would an upgrade to couchdb 1.2 on the source system > correct the issue? > > > I also think that the filtered replications, which don't involve couchdb > 1.1.1, only checkpoint to the latest sequence that involves a document that > passes the filter. Even if new documents are added at the source and > replicated to the target, a new checkpoint is not always written. > > Is this a known issue? > > How can I further narrow down the issue? > > Any documentation on the interplay of replication and checkpoints would > helpful as well. Thanks for your help. > > -- Andreas
