Hi,
I'm currently exploring CouchDB replication and trying to figure out the
difference between *max_replication_retry_count* and *retries_per_request*
configuration options in *[replicator]* section of configuration file.
Basically I want to configure continuous replication of local couchdb
In my opinion:
The bug to file on GitHub is the actual 500 error. We should return
something a bit friendlier, either a 202 or possibly a 412 if we really
can't create the database on even a single node.
The behaviour, on the other hand, is working as intended.
-Joan
- Original Message
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
Hi guys.
Moving forward with understanding how CouchDB works when working as a
cluster I've reached the add/remove nodes step and I've seen the following
situations in which I'd like to know what do them mean and if there's
something to take care to avoid errors or unexpected behaviours.
First
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
Thanks a lot again for your input Adam.
Following on your comments I've just opened a GH issue with the details:
https://github.com/apache/couchdb/issues/602
Regards
On Wed, Jun 14, 2017 at 7:57 PM Adam Kocoloski wrote:
> Hi Carlos,
>
> Ah, this is an interesting edge