Version updating in a production environment

46 views
Skip to first unread message

Papa Mike

unread,
Mar 29, 2012, 2:14:33 PM3/29/12
to redi...@googlegroups.com
So, assuming you're running Redis with one master and one or more slaves, when a new version of Redis comes out, how are folks out there updating to the new version?  I gather that many just do a "SHUTDOWN SAVE" on the master, replace the Redis binary and start it back up.  That's probably a pretty quick operation, I grant you, but there's no doubt that, in a 24x7 environment, you would be incurring some downtime while you did it.  Is there a better/recommended way?  Is there any way to do it without downtime pending the Redis cluster stuff making some headway?

Tim Lossen

unread,
Mar 29, 2012, 3:23:08 PM3/29/12
to redi...@googlegroups.com
in a cloud environment, you can setup a replication chain

(old master) -> (old slave) -> (new master) -> (new slave)

and then at some point switch from the old master to the new master,
cut the connection between new master and old slave, and shut down
the two old instances. this approach involves (almost) zero downtime.

tim

> --
> You received this message because you are subscribed to the Google
> Groups "Redis DB" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/__J2SVuO2bkJ
> .
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en
> .

--
http://tim.lossen.de

Arnaud GRANAL

unread,
Mar 29, 2012, 3:23:28 PM3/29/12
to redi...@googlegroups.com
On Thu, Mar 29, 2012 at 9:14 PM, Papa Mike <iampa...@gmail.com> wrote:
So, assuming you're running Redis with one master and one or more slaves, when a new version of Redis comes out, how are folks out there updating to the new version?  I gather that many just do a "SHUTDOWN SAVE" on the master, replace the Redis binary and start it back up.  That's probably a pretty quick operation, I grant you, but there's no doubt that, in a 24x7 environment, you would be incurring some downtime while you did it.  Is there a better/recommended way?  Is there any way to do it without downtime pending the Redis cluster stuff making some headway?



Use a dedicated IP address per Redis instance:

IP dedicated to Redis: 192.168.0.100 (where client connects)

Server A: 192.168.0.10
Server B: 192.168.0.11

Let's say Redis is running on server A and you want to upgrade it.

Server B: Start Redis with SLAVEOF 192.168.0.10
Server B: Wait for the sync, bind 192.168.0.100 on server B
Server A: Upgrade Redis.
SLAVEOF 192.168.0.11 and bind back 192.168.0.100.

It may be interesting to include this in the FAQ because some other people may actually need it.

What do you think about this ?

A.

Papa Mike

unread,
Mar 29, 2012, 3:53:56 PM3/29/12
to redi...@googlegroups.com
Thanks for the info - I have a couple follow-up questions, if you're game...

I was under the impression that when a Redis instance is slaved, it's read-only... when you change the binding of the IP address that the clients connect to, won't you be connecting to a read-only instance?  The changing of the IP address binding could be effectively instantaneous, but wouldn't you have to then execute a slaveof no one on the 2nd server to make it a "master" that can handle writes?  I know we're talking about, potentially, a very narrow outage here but even very narrow outages matter in some circumstances.

Also, this scenario requires slaving two different versions of Redis together - is the slaving of mismatched Redis versions "guaranteed" to be supported?




On Thursday, March 29, 2012 1:23:28 PM UTC-6, Arnaud Granal wrote:

Tim Lossen

unread,
Mar 29, 2012, 3:58:13 PM3/29/12
to redi...@googlegroups.com
no, slaves are not read-only -- writing to slaves is just normally
discouraged,
so as not to produce inconsistencies.

as to connecting different redis versions, this should work in most
cases.

> --
> You received this message because you are subscribed to the Google
> Groups "Redis DB" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/Hkisy7QKitUJ

Papa Mike

unread,
Mar 29, 2012, 4:16:50 PM3/29/12
to redi...@googlegroups.com
Sounds like a livable plan, then... many thanks!

> To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com

> .
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en
> .

Sebastian Stadil

unread,
Mar 29, 2012, 5:36:57 PM3/29/12
to redi...@googlegroups.com
Captured this information at http://www.quora.com/Redis/How-can-you-perform-no-downtime-updates-on-Redis for the community and credited the authors.

To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/qAIa7MdxcvQJ.

To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.



--


Follow us: Twitter - Facebook - Blog

Reply all
Reply to author
Forward
0 new messages