Proper path to promote a Single Node to Cluster Mode

[skeyby]

Hello everybody,

I have a single instance (that was booted with couchdb@127.0.0.1 in vm.args) that needs to be clustered.

I tried to change vm.args to this machine internal ip in order to make it connect to a secondary (empty) machine but when I restarted CouchDB no DB could be found, so I reverted vm.args to couchdb@127.0.0.1 and everything reappeared.

What's the correct path to switch a single-node to multi-node?

I was thinking about setupping the secondary (now empty) node with a correct couchdb@ address and do a complete replication from one node to another, then erase the used-to-be single-node and make him join the cluster with the secondary node.... but this looks like a lot of work... isn't any simpler path?

Thanks

[janl]

@skeyby the mapping of node name to shards happens in the internal _dbs database (:5986 in 2.x, /_node/_local/* in 3.x). What you could do is rewrite all docs in _dbs to point to your “new” vm.args name. At that point you will get no db shards can be opened, and then you can change the vm.args name and restart CouchDB, after which all shards will be found again. But this is a very error prone procedure (must not change vm.args name before changing the _dbs docs) and we don’t usually recommend outside of a forensic situation.

Your plan to stand up a new node and replicate into it is a lot less problematic.

[kripper]

Hi @janl,

I guess migrating from a single node to a cluster is a common use case. Is there still no tool or feature to rename a node safely?

We have a node with thousand of databases and would like to 1) rename the node to a FQDN, 2) add a second node, 3) end up with a cluster with n=2 where the second node would be a failover-node in case the first-node goes offline. Is this possible? Does it make sense?
AFAIU this 2-node-cluster would provide eventual consistency and there is no action required to failover since this would be similar to a master-master setup, right?

To rename the "couchdb@127.0.0.1" node, do we just need to PUT a change to each /_node/_local/_dbs/<db> doc?
Why is it a "very error prone procedure" or "not recommended"?

[kripper]

I created a script that:

• renames all 'changelog', 'by_range' and 'by_node' references in all databases
• Adds a second node to the cluster
• Adds the second node to all databases

After restarting CouchDB, all databases and docs are replicated on the second node.
I tested shutting down the first node and I can still access all data on the second node.

All databases changed now to n=r=w=2.

I just wonder why is it possible to access the second node when the first node is down and quorum is not met?

[kripper]

There is a bug preventing security objects (database permissions) to be replicated on the second-node: #1611 (comment)

[skeyby]

Thanks @janl ,
my 2 cents is that the manual for single-node setup should be a bit more clear on this topic.

I understand the sake of simplicity and universality of indicating couchdb@127.0.0.1 but just suggesting couchd@localip (or maybe better couchdb@hostname) wouldn't throw the user into a dead end.