best way to upgrade

[Steven Grimm]

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.

-Steve