(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
> .
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?
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
> 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
> .
To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/qAIa7MdxcvQJ.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
