-
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 |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
@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 Your plan to stand up a new node and replicate into it is a lot less problematic. |
Beta Was this translation helpful? Give feedback.
-
Thanks @janl , 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. |
Beta Was this translation helpful? Give feedback.
@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.