couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Alonso <>
Subject Re: Error getting security objects when configuring new replica
Date Wed, 14 Jun 2017 16:57:55 GMT
Ok, so I've made some progress on this and I'd like to share it here.

So the error says "*Error getting security objects for
<<"affected_database_here">> : {error,no_majority}*" and that is actually
not related to configuring a new replica node as I was saying before but to
nodes in maintenance mode when read/write operations happen.

In summary, having less than half of the replica nodes available for the
database you're working on raises this error. The database is available
though (maximum availability by design I guess :))

My question then is, what does this error exactly mean? What are the so
called security objects? Is it something one has to carefully consider

Thank you.

On Tue, Jun 13, 2017 at 7:34 PM Carlos Alonso <>

> Hi guys!
> I continue trying to understand how CouchDB clusters work and trying to
> build a compelling administration tool that covers basic operations such as
> adding a node to the cluster, moving a shard from one node to another and
> so on. It is WIP but already open sourced here:
> Testing the scale out procedure (add node, make it replicate some shards,
> remove the shard from the previous location) I've seen the following error
> :
> [error] 2017-06-13T15:58:22.299140Z couchdb@couch-2.couchdb2-replica-admin
> <0.2214.3> -------- Error getting security objects for <<"testdb3">>:
> {error,no_majority}
> Not only mentioning my testdb3 but also with internal ones such as
> _global_changes. I mean, I was scaling out testdb3, but errors appeared
> referring to testdb3 and also _global_changes, but I wasn't scaling out
> _global_changes.
> The error appears when I configure a new node as being replica for an
> existing shard (by adding it to the by_nodes and by_ranges sections of
> document at _dbs/testdb3)
> The error appears every few seconds on the new replica logs once for each
> of the other replicas (3 for testdb3 and 2 for _global_changes at that
> time) and it also appears on the other nodes' logs but just once every few
> seconds.
> The error stops appearing once I remove the maintenance_mode flag on the
> new replica (because before configuring it as replica I enable that flag so
> the node doesn't participate in reads. Kudos Adam Kocoloski for your advice
> here) once pending_changes messages stop appearing on the new replica.
> I think the error is making the catch_up process not to work properly as
> my consistency checks fail when this error appears during the procedure
> (doesn't happen 100% of the times).
> I've seen it both happening when the new replica node was completely empty
> but also when it had the data preloaded (via rsync or because it had
> previously been a replica).
> I hope so many text helps you out :)
> Thanks!
> --
> [image: Cabify - Your private Driver] <>
> *Carlos Alonso*
> Data Engineer
> Madrid, Spain
> Prueba gratis con este código
> #CARLOSA6319 <>
> [image: Facebook] <>[image: Twitter]
> <>[image: Instagram] <>[image:
> Linkedin] <>
[image: Cabify - Your private Driver] <>

*Carlos Alonso*
Data Engineer
Madrid, Spain

Prueba gratis con este código
#CARLOSA6319 <>
[image: Facebook] <>[image: Twitter]
<>[image: Instagram] <>[image:
Linkedin] <>

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 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message