Hi Adam,
I hope I can ask some more stupid questions :)
How can the cluster continue to function, when the shards are only on
one node and that node happens to be the one down?
I thought that specifying n=3 would tell CouchDB to automatically make
it so that I have three copies of the data.
Hi Ulrich,
Assuming usersdb-XYZ already existed, yes you should have needed a revision ID
to issue a successful PUT request there.
The statement in the docs is a statement about the availability of the system
for reads and writes. The cluster will continue to function in that degraded
state wi
Hi Adam,
this is interesting, I was able to send PUT requests to
http://localhost:5986/_dbs/userdb-XYZ without giving a revision. Is this
intended or should I try to reproduce the issue and file a bug report?
If I understand you correctly, then with default settings (replica level
of 3 and 8
Hi Ulrich, sharding is indeed per-database. This allows for an important degree
of flexibility but it does introduce maintenance overhead when you have a lot
of databases. The system databases you mentioned do have their own sharding
documents which can be modified if you want to redistribute th
Hello,
I haven't quite understood the 2.1.1 documentation for sharding in one
aspect: it is described how to get the sharding document for one
database, how to edit it by e. g. adding a node to it and how to upload
it again. I've tried that and it works fine.
However, if I have the couch_per
