Another case of the AP nature of the system. The create database operation succeeds if at least one node performs the action (which is to create a document in the non-clustered _dbs database).
The 500 is because the operation timed out waiting for a majority of nodes to report success, I am guessing. Once the other two nodes come back up, the _dbs database update will be replicated to them. B. > On 19 Jun 2017, at 13:17, Carlos Alonso <carlos.alo...@cabify.com> wrote: > > Hi guys, > > I've just seen the following scenario and I'd like to have your input on it. > > Running a CouchDB 2.0.0 cluster of 4 nodes, 2 of them being down, if I try > to create a new database I get an error 500 from the server but > unexpectedly, the database is created!! Also, depending on the configured > replicas, the nodes down may even get a replica. Should I file a GH issue > for further investigation on this? > > Regards > -- > [image: Cabify - Your private Driver] <http://www.cabify.com/> > > *Carlos Alonso* > Data Engineer > Madrid, Spain > > carlos.alo...@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.
