best way to upgrade
sgrimm at facebook.com
Wed Apr 11 23:05:23 UTC 2007
Brad Oaks wrote:
> I'm assuming you only have one machine to run memcached on. Instead
> of one large instance of memcached running, try running 4 smaller
> instances, each on a different port. Then when you've got the new
> shiny binary compiled, take down one of the 4 and replace it with a
> daemon running the new binary. wait a while, monitor your database
> load, etc. then move on to pool number 2, and so on.
This is more or less the approach we take when we roll out a new
memcached build internally; you can apply it whether you're running
several instances on one host or one instance on each of a bunch of
hosts. We also tend to do it during our lowest-usage time of day so as
to minimize the database load.
> If someone knows of a potential adverse interaction between different
> versions of memcached running on the same server, speak up.
The protocol has stayed the same (aside from some new stats getting
added) for quite a while. There shouldn't be any issue from an
interoperability point of view. We have never had any issue with things
breaking during our rollouts, including way back when we used to run
multiple instances per host (before the multithreaded version.)
When you're rolling out new code to a server that's still running old
code, the only thing to watch out for is that you don't overwrite the
memcached binary. Rename the existing one and copy the new one into
place, or you'll likely cause the existing instances to crash. That's
true for pretty much any app, nothing specific to memcached.
More information about the memcached