Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
From: Adam Kocoloski <kocolosk@apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: Modifying a cluster
Date: Tue, 1 Nov 2016 10:44:23 -0400
References: <261F4DC48EA7304CA0ADF8F46BD0C6412BF4A5791F@PER-S-MAIL07.immersivetechnologies.com>
To: user@couchdb.apache.org
In-Reply-To: <261F4DC48EA7304CA0ADF8F46BD0C6412BF4A5791F@PER-S-MAIL07.immersivetechnologies.com>
Message-Id: <89DB11EF-68FC-417A-B021-9D30A4B10BFB@apache.org>
archived-at: Tue, 01 Nov 2016 14:44:29 -0000

Hi Simon, that sounds more or less correct. I think you meant the =
=E2=80=9C_dbs/<database_name>=E2=80=9D endpoint instead of =
=E2=80=9C_all_dbs=E2=80=9D.

I=E2=80=99d agree that the process you outlined is a lot of manual =
labor. This is part of the price that we pay for having the flexibility =
to define a different sharding topology for each database in the =
cluster.

I might suggest a somewhat different approach - run a 3 node, n=3D3 =
cluster, then put the nodes into =E2=80=9Cmaintenance mode=E2=80=9D one =
at a time to patch and upgrade them. The maintenance mode flag will =
allow the node to continue to participate in the cluster and receive =
updates, but will prevent it from responding to the client until you =
determine that it=E2=80=99s healthy again. Running n=3D3 ensures that =
you will always have two live nodes durably committing data at any point =
in time. I appreciate that this may be more expensive than the n=3D2 =
model, but it=E2=80=99s far simpler operationally (as you won=E2=80=99t =
have to modify the sharding setup at all) and is a configuration that is =
much more extensively tested.

If you want to use this technique the relevant configuration setting is

[couchdb]
maintenance_mode =3D true

Cheers, Adam

> On Nov 1, 2016, at 3:36 AM, Simon Keary =
<SKeary@immersivetechnologies.com> wrote:
>=20
> Hi All,
>=20
> I have a two node cluster with the following configuration:
>=20
> q=3D8, r=3D1, w=3D2, n=3D2
>=20
> =46rom time to time I want to be able to be able to patch/upgrade the =
servers by adding two new nodes (servers) to the cluster and then =
removing the previous two. In this scenario I think all nodes in the =
cluster at any time (2-4) should have copies of all shards of all =
databases. My understanding is then to add a node I need to:
>=20
> 1. Add the node to the list of cluster nodes via a PUT to /_nodes
> 2. For each database update the /_all_dbs/<database_name> pseudo =
document. For each shard in the document add the new node.
>=20
> There are a few things I'm not clear of:
>=20
> 1. Is this generally right? Assuming it is:
> 2. With a large amount of databases it seems impractical to manually =
add a node since a document for each database will need to be modified =
and the modification isn't trivial. At the moment I have a JS script to =
do this but wanted to check I'm not missing something?
> 3. I don't really understand how the system databases (_users, =
_metadata, _replication, _global_changes) fit into the picture? It looks =
like I need to treat them as normal databases and add all the shards for =
them to the new node? Doing a PUT to (for instance) =
_all_dbs/_global_changes to do this fails with "Only reserved document =
ids may start with underscore" so I'm a little confused...
>=20
> Thanks for any help!
> Simon
>=20
> ________________________________
> Disclaimer:
> This message contains confidential information and is intended only =
for the individual(s) named. If you are not the named addressee you =
should not disseminate, distribute or copy this email. Please =
immediately delete it and all copies of it from your system, destroy any =
hard copies of it, and notify the sender. Email transmission cannot be =
guaranteed to be secure or error-free as information could be =
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or =
contain viruses. To the maximum extent permitted by law, Immersive =
Technologies Pty. Ltd. does not accept liability for any errors or =
omissions in the contents of this message which arise as a result of =
email transmission.