Replies: 1 comment
-
Please read this page: https://redis.io/docs/management/admin/, especially the last item. Unfortunately you do need to shutdown Sidekiq to point it to a new Redis primary. You can work around this if you use something like HAProxy to add a layer of indirection. I do wish Sidekiq could migrate between Redis servers without disruption but Redis upgrades happen so infrequently that it's never been seen as high priority. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey all,
quick question regarding a redis version update while using sidekiq.
We are currently in the process of updating a legacy rails app.
One of the next steps will increase the sidekiq version to 6.0.2 (from 5.2.9). This will require to update the running redis server from 3.2 to (at least) 4. Over the next weeks/months we will likely be doing these updates several times until we are fully uptodate regarding rails/sidekiq/redis versions.
But I am wondering what the best approach is to update redis in order not to lose any jobs. Should we shutdown sidekiq before the redis update (and start again after the update)? Or would the redis client / sidekiq be smart and robust enough to handle retries and downtimes?
I did a test with a staging system and a direct update of redis (without sidekiq shutdown) seemed fine. Though staging might not have the same usage pattern as production. I am leaning towards the safe approach and do a sidekiq shutdown. But due to our infrastructure setup, this will create extra overhead and complications.
Note that we have aof enabled for redis.
Beta Was this translation helpful? Give feedback.
All reactions