couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: _all_docs consistency in cluster
Date Tue, 06 Jun 2017 16:58:53 GMT
Hi Carlos, yes …

The _all_docs, _changes, _view and _find endpoints do *not* apply any quorum to their results.
They generate a merged result set from exactly one copy of every shard, and the copy that
is selected is not always stable. So this is the defined (if admittedly unexpected) behavior.

One best practice if you’re adding a new node to a cluster (or rebuilding an unhealthy one)
is to set the maintenance mode flag on the node’s config to true:

[couchdb]
maintenance_mode = true

This will cause the node to not participate in any read operations, but it will still receive
and synchronize data. You can watch for pending_changes messages in the logs and view builds
in active_tasks and lift the flag once those clear out. Cheers,

Adam

> On Jun 6, 2017, at 10:39 AM, Carlos Alonso <carlos.alonso@cabify.com> wrote:
> 
> Hi guys.
> 
> I've been experimenting with operating a CouchDB 2.0 cluster and I've seen
> the following unexpected behaviour.
> 
> Having a db with just one shard and just one repica, and a client that just
> inserts a new document and reads /db/_all_docs on a loop every second (just
> to simulate a controlled load) I expect the number of docs on every read to
> be sequentially incrementing, and it actually is.
> 
> However, at some point I add a new replica for that shard, in a different
> node of the cluster and, while the newly added node is synchronising its
> shard the number of read documents is not incremented anymore!! It is only
> when the new repica is synchronised that the numbers match again.
> 
> It feels like while replicating those requests using the new replica as
> coordinator are resolved locally instead of via quorum as I'd expect.
> 
> Has anyone seen something similar?
> -- 
> [image: Cabify - Your private Driver] <http://www.cabify.com/>
> 
> *Carlos Alonso*
> Data Engineer
> Madrid, Spain
> 
> carlos.alonso@cabify.com
> 
> Prueba gratis con este código
> #CARLOSA6319 <https://cabify.com/i/carlosa6319>
> [image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
> <http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
> Linkedin] <https://www.linkedin.com/in/mrcalonso>
> 
> -- 
> Este mensaje y cualquier archivo adjunto va dirigido exclusivamente a su 
> destinatario, pudiendo contener información confidencial sometida a secreto 
> profesional. No está permitida su reproducción o distribución sin la 
> autorización expresa de Cabify. Si usted no es el destinatario final por 
> favor elimínelo e infórmenos por esta vía. 
> 
> This message and any attached file are intended exclusively for the 
> addressee, and it may be confidential. You are not allowed to copy or 
> disclose it without Cabify's prior written authorization. If you are not 
> the intended recipient please delete it from your system and notify us by 
> e-mail.


Mime
View raw message