Open juanbrein opened 3 months ago
Thank you for your report @juanbrein
{'EXIT',nodistribution}}
indicates an issue with erlang distribution (that's the erlang VM inter-node clustering system).
Unfortunately I don't use couchdb with docker much so don't have an exact reason for the failure. It may be a networking issue or a permissions issue.
Also try to take a look at https://hub.docker.com/_/couchdb it's one of experiments of creating a cluster with compose and running some basic load testing https://gist.github.com/nickva/cf9cac975ceb062b61872f7857a0e104. Maybe that will give you some hints.
Thanks for the hint! I tried using NODENAME, but the problem is that it sets the -name flag to couchdb@127.0.0.1 if NODENAME is 127.0.0.1 ... and that name is different from the one assigned on kubernetes -name couchdb
....
Another way would be to change the node name in the shard files... but that is not documented either...
I have to say that even though the restore process from / to same configurations work... if you are in scenarios like myself... which I believe is not so radical... it doesn't work, the errors are not very useful and is not documented...
Description
When I run the official docker image using these environment variables it cores dump:
export COUCHDB_ERLANG_COOKIE=XXX export COUCHDB_PASSWORD=XXX export COUCHDB_SECRET=XXX export COUCHDB_USER=admin export ERL_FLAGS=" -name couchdb "
Steps to Reproduce
Expected Behaviour
Should be able to run couchdb
Your Environment
Additional Context
The reason I need this is because I run couchdb in Kubernetes using the official helm chart. I also have a plain docker compose configuration in my local machine. When I copy the data from one environment to another I get the infamous error message "This database failed to load."
I read on different forums that the cluster name has to be the same in order for that work.
I can't find any documentation related unfortunately.