Closed zidoo closed 6 years ago
Basically the container is not really built for restarting i think. Are you using the Makefile commands up & down to start/stop your containers? I never have issues when using make up
followed by make down
and then starting it again.
Just basic usage:
~ docker run -e "IP=0.0.0.0" -p 7000-7007:7000-7007 grokzen/redis-cluster:latest
~ redis-cli -c -p 7002
127.0.0.1:7002> cluster nodes
af32a8bb3b8a3faea56a190a36b5741da6913d83 127.0.0.1:7004@17004 slave 1da545b2077bcce2715c062feaae985d4109ac80 0 1533551051164 5 connected
d45473deb3bea71c7563d98329fda678a4bd4da4 127.0.0.1:7003@17003 slave 6c0653a9067a1ad2d8cfaeb17bd95352023ba791 0 1533551050000 3 connected
4ce6e8086ede44720f2dcf92336c5c6e3bf19c06 127.0.0.1:7005@17005 slave fdb81f006560c2dacac18b982d0bb2835db52114 0 1533551050555 2 connected
6c0653a9067a1ad2d8cfaeb17bd95352023ba791 127.0.0.1:7002@17002 myself,master - 0 1533551050000 3 connected 10923-16383
fdb81f006560c2dacac18b982d0bb2835db52114 127.0.0.1:7001@17001 master - 0 1533551050659 2 connected 5461-10922
1da545b2077bcce2715c062feaae985d4109ac80 127.0.0.1:7000@17000 master - 0 1533551050000 1 connected 0-5460
~ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05a684759cfd grokzen/redis-cluster:latest "/docker-entrypoint.…" 31 seconds ago Up 30 seconds 6379/tcp, 0.0.0.0:7000-7007->7000-7007/tcp sad_hamilton
~ docker restart sad_hamilton
sad_hamilton
~ redis-cli -c -p 7002
127.0.0.1:7002> cluster nodes
7efad9c0e9a2b9d5b3fa1ec6d933a325517a6608 :7002@17002 myself,master - 0 0 0 connected 12222 16287
Anyway, I'm just not sure that removing nodes files is necessary each time.
Well i am not really sure how you would decide automatically when to do what then. If there is some condition that we can detect and act upon, then sure, but otherwise i would say that you should use docker-compose solution or add --rm
to your basic container run to delete the container after exit so a new one will be created fresh the next start.
I actually need container to stay exactly same as it was before restart. I'm just not sure why rebuild cluster on each restart - I know that lot of people uses Redis as cache only but Redis is very good as permanent storage in specific cases.
Thanks for advice. Cheers, Z
@zidoo I know and understand that you might need it to perform in that way for your case. But remember that it is stated in the readme the intent and purpose of this repo and this version of a redis container The main usage for this container is to test redis cluster code. For example in https://github.com/Grokzen/redis-py-cluster repo.
. So therefore it is not intended for persistent runs across time. It is more designed for very rapid deployment, but it should/could be trashed at any time and you just have to start or create a new container of it when running your tests or trying out the cluster features. BUT, if you ever would like to submit some modifications that would help you out to make it more persistent safe, please submit a PR for it and i will review and if i like it i will merge it, if it still maintains the core feature of quick and simple start.
Hi, I'm pretty fresh in Docker land, please forgive me if I misunderstood something.
After container restart cluster was unable to start properly. Looks like problem is in docker-entrypoint.sh:16:19 - removing nodes.conf for each instance.
Am I doing something wrong or this is some kind of bug?