On Fri, 8 Jul 2022 at 22:04, Robert Newson wrote:
> Hi,
>
> The config file isn't monitored, so just changing the file won't help,
> you'd need to restart couchdb.
I did not change the config file, used the config API instead and checked
that the files were changed afyerwards.
Did you have an
Hi,
The config file isn't monitored, so just changing the file won't help, you'd
need to restart couchdb.
Did you have anything bypassed in the first place, though?
Could you explain the replication problems you encountered?
I can say for sure that it is generally unsafe to modify shard files
On Fri, 8 Jul 2022 at 17:17, Robert Newson wrote:
>
> Hi,
>
> There's a bug in 3.1.0 that affects you. Namely that the default 5 second
> gen_server timeout is used for some requests if ioq bypass is enabled. Please
> check if your config has a [ioq.bypass] section and try again without
> bypas
Hi,
There's a bug in 3.1.0 that affects you. Namely that the default 5 second
gen_server timeout is used for some requests if ioq bypass is enabled. Please
check if your config has a [ioq.bypass] section and try again without bypasses
for a time.
If you could explain your migration process in
unsubscribe
> On Jul 7, 2022, at 3:29 AM, Luca Morandini wrote:
>
> Dear All,
>
> I moved some CouchDB 3.1.0 databases to a new 4-node cluster via
> copying the shard files.
>
> The operation worked for 5 out of 6 databases; the biggest database
> (about 200GB, 12 shards, 2 replicas) did not
Dear All,
I moved some CouchDB 3.1.0 databases to a new 4-node cluster via
copying the shard files.
The operation worked for 5 out of 6 databases; the biggest database
(about 200GB, 12 shards, 2 replicas) did not come online on the new
cluster.
I suspect high disk latency, but... could someone s
