OR

hire a consultant at $$$$ / hour

I used the technique to successfully get sessions to transparently failover. i.e. the user was not logged out if I stop a pooled memcached instance on one of the machines.

I didn’t manage to use the technique to share sessions across two servers: http://serverfault.com/questions/164350/can-a-pool-of-memcache-daemons-be-used-to-share-sessions-more-efficiently

For the default php.ini memcache configuration both servers should have an identical php.ini line like this:

session.save_path=”tcp://primary_memcached_instance:11211, Tcp://secondary_memcached_instance:11211″

Because the default hashing method is “standard” not “consistent”. The type of hashing algorithm (chosen for memcached) determines how the keys are distributed across the pool of memcached servers. Consistent hashing would offer full failover. Then you can use the settings you describe in your comment to achieve 50% hit/miss on local reads

See http://www.php.net/manual/en/memcache.ini.php#ini.memcache.hash-strategy

Thanks for a great article. I have a question about using this session clustering technique across two round-robin load-balanced LAMP servers.

From my understanding of this article, it should be possible to share sessions across two webservers by defining the save_path on each server to have a local memcache store AND a remote memcache store:

session.save_path=”tcp://localhost:11211, Tcp://192.168.0.[$othermachine]:11211″

That way, the users session should be accessible from whatever server they get landed on and 50% of the time it will be on the localhost and so avoid network traffic? Am I correct or did I misunderstand something?

I haven’t got it to work in testing but I’m thinking that on CentOS 5.5, the PHP memcache extension in the repos might not support transparent replication. It seems the session is only in the first instance and when the user gets sent to the other server, it just creates a new session in the new servers local instance (therefore the user is logged out). i.e. it doesn’t seem to peak inside each instance in turn to work out whether it can find the session – it just peaks into the first instance and then creates a new session if it finds nothing.

interesting idea to use memcachedb as persistent storage. u should run more than one instance of memcachedb for redundancy sake and bear in mind that memcachedb DOES NOT implement the full memcache protocol so it may not be compatible with php’s memcached extension

memcachedb provides persistent storage. Does anyone know if the garbage collection is handled by the php-memcache front-end? Or do we have to manually delete the expired session ids ourselves from the back-end db?

$_SESSION['cart_data'] = ‘blah’;
$_SESSION['captcha_data'] = ‘blah’;