couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Strange problem replicating
Date Mon, 03 Jun 2013 14:25:00 GMT
Hi Ezequiel,

Chris was not referring to the _id generation algorithm (I recommend
returning it to its default value of "sequential" but it's up to you).

On startup, CouchDB from 1.3.0 onwards will write a config value
called "uuid" under the [couchdb] section. This value must be unique
for each machine, so Chris's advice is relevant only if you have
copied local.ini files between your machines (or generated them both
from the same source file).

A final note, it's much easier to change config values through http.
This ensures that they're correctly formatted on disk but the settings
also take effect "live", there is no need to restart couchdb just to
change a config value. For example;

curl -XPUT localhost:5984/_config/uuids/algorithm -d '"sequential"'

will reset your host back to the default _id generation algorithm.


B.



On 3 June 2013 15:10, Ezequiel Naftali <enaftali@pisol.net> wrote:
> Hi Chris,
> thanks for your answer. We are really worried about this.
>
> We have changed  UUIDS algorithm first to random in both servers
>
> [uuids]
> algorithm = random
>
> and then we deleted that line and we are still having the same problem in both cases.
Is anything else I should do?
> (I restarted the service after the changes)
>
> Thanks,
>
> Ezequiel Naftali
>
>
>
>
> From: Christopher Bonhage
> Sent: Sunday, June 02, 2013 3:40 PM
> To: Ezequiel Naftali
> Cc: user@couchdb.apache.org
> Subject: Re: Strange problem replicating
>
> Hey Ezequiel,
>
> I have run into this several times when I have accidentally misconfigured my servers
with the same UUIDs (which are used for replication checkpointing):
>
> Make sure that all of your couches have unique config value for [couchdb] uuid or just
delete the existing config value on your servers and restart, which will generate new ones.
>
> This behavior is definitely a 'gotcha'; it's fairly new with the introduction of server
UUIDs and can be triggered unintentionally by simply following the noble goal of using the
same configuration files for all of your servers.
>
> I hope that helps!
>
> Christopher Bonhage
>
> On May 31, 2013, at 1:30 PM, Ezequiel Naftali <enaftali@pisol.net> wrote:
>
>
>   Hi, We are developing a PHP application using couchdb.
>   Inside the application I'm trying to replicate 4 DBs in and out: this is *
>   only* happening with one of those replications: database's name is
>   "people". To avoid any PHP library specific issue, I'm testing from bash
>   running curl:
>
>   *curl -H 'Content-Type: application/json' -X POST LOCAL_PATH/_replicate -d
>   '{"source":"REMOTE_PATH/people","target":"LOCAL_PATH/people",
>   "continuous":false}'*
>
>   With this output:
>
>   *{"error":"checkpoint_commit_failure","reason":"Error updating the source
>   checkpoint document: conflict"}*
>
>   I've checked this
>   post<http://stackoverflow.com/questions/15647998/couchdb-checkpoint-commit-failure>,
>   but it doesn't seem to be that, as we're using full paths for replication
>   (both local and remote).
>
>   This happens most of the times, but not always.. Any idea???
>
>   We have also tried the manual replication using the command line.
>
>
>   Thanks,
>
>   Ezequiel Naftali
>

Mime
View raw message