views:

165

answers:

3

Hi everybody,

I was thinking about using memcached to store sessions instead of mySQL, which seemed like a good idea, at first.

When it comes to the failover part of utilizing memcached servers, It's a bit worrying that my sessions will stop working if the memcached would go offline. It will certainly affect my users.

There's a few techniques that we already utilize to reduce failover, including having a pool of servers available to compensate in the event of downtime, utilizing sharding/consistent hashing across the server pool and so on. We would also do some sort of graceful degradation that tells the users that something have gone wrong and they are welcome to login again, in the event of them being kicked out due to memcached server failover.

So how does people generally deal with these issues when storing sessions on memcached servers?

+5  A: 

First, if you put something in memcache only, you should be OK losing it. For everything else, there's persistent storage.

Second, memcached simply doesn't fail very often. There aren't any moving parts like disk platters. The only times I've ever lost sessions were due to reboots for kernel upgrades. But losing those sessions weren't a big deal, because of the first point.

So to answer your question directly, if a datum is OK to lose, storing it in a memcache session only is OK. If it's not OK to lose, store it in persistent storage, and maybe cache it in memcache for speed.

John Douthat
+2  A: 

Anyone considering this should read Dormando's session post. It's got all the details you could want.

Dustin
Hi! Great link!
Industrial
+2  A: 

You could create a fail safe method by using both the db and memcached. Check to see if your memcached object is in memory else store session in the db then create the memcache instance. Just make sure when log out / sign out, it flushes/removes the memcached...

So check memcached first, if fails, check db... :)

Jesse
Smart! A little more code, but better performance. Me like!
Industrial