Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd like to set up mysql sessions in my hosting environment that works for all of my clients across the board for my load balanced environment. After some googling, it sounds like most people's solutions involve overriding their session handlers with php code. Since I am not the web admin for all of the sites I host, I'd rather not touch the PHP code itself.

Is there a way through Apache or PHP config to add PHP code that gets processed for all pages? Or is there a preferred mysql session handler that people use? the only one I've found is which seems a little less documented and supported than I'd like for a production environment.


share|improve this question
up vote 3 down vote accepted

It isn't quite clear in your question, but I am going to presume you are asking how to handle PHP sessions in a (load balanced) server cluster.

Traditional PHP sessions are stored in flat files - the location and details of which are configured in php.ini. The problem with this and a server cluster is, of course, that a session file created on one server is not available on any other server.

There are a number of solutions to this problem, each with their own advantages and disadvantages.

Sticky sessions:

Have your load balancer hash the requesting IP and always send the same user to the same server. This may work for dealing with sessions, but it scales poorly, doesn't handle failed nodes well, and doesn't allow for more efficient (i.e. load based) load balancing.

Clustered File Systems:

By using a distributed file system, you can replicate your sessions across multiple nodes, and each node can have access to the sessions equally. A typical two node setup might include DRBD and OCFS2 - but you do encounter some difficulty setting up heartbeat and failover. A more resilient system might use GlusterFS, but adds considerable overhead. Both of these approaches may encounter some problems with file locking, although GlusterFS should work fairly well (it supports flock()).


As you mention, it is possible to store sessions in MySQL (and PgSQL). Databases tend to be already installed, and available to multiple nodes, and support locking for atomic transactions. However, the feature set of a relational database is not really necessary for storing flat files, and may add some amount of unnecessary overhead. (PHP used to bundle the msession extension which, I believe, is no longer maintained).


Recent key-value stores are well suited to storing PHP sessions. Previously, there may have been some difficulty with locking, and authentication but I believe most of these have been addressed. Examples in this category might include MongoDB and CouchDB.

Volatile Storage:

Some memory caches are well established and commonly used in distributed systems (e.g. Memcached, Redis). These key-value stores offer most of what is needed for session management, and memcached in particular is very easy to setup as a session store. However, these tend to have two major drawbacks - a) if the server storing the sessions goes down or needs to be restarted, the session data is lost, since it is stored in memory and b) as session data grows, the memory usage grows, which may result in old objects being removed from the cache.

A proposed solution:

Most of the good solutions will combine a cache with some persistent storage - to avoid excessive database load, but protect against loss of data. Unfortunately, these solutions do often require modifying PHP code to include a custom session_save_handler.

One good solution though, that does not require modifying PHP code is MemBase. It runs on the same protocol as memcached - making it easily configured for use as a session handler, but also provides persistence.

Essentially, the setup entails:

  • Download and install the MemBase application (binaries available in .deb and .rpm)
  • Configure the server (it has a web interface - not ideal, but it does the job)
  • Install the php5-memcached extension (but don't install memcached as it conflicts with MemBase)
  • Change your session.save_handler and session.save_path in php.ini to point to the MemBase server
  • Restart your web server, php-fpm, etc. (a quick search finds this guide, which seems reasonable)

The approach should scale fairly well, you have control over the amount of memory used, the data is persistent, performance is good with minimal overhead, the setup is easy, and it does not require the alteration of any PHP code (just changing some php.ini settings).

share|improve this answer
Thanks for the response. Rereading my original question, I think I left out some key things(question updated). Yeah, I have a load balanced environment (EC2 based), and am trying to get my sessions to store in mySQL. Right now I have sticky sessions in place, but obviously this creates problems whenever a server has to go down for any reason. I'd like to be able to restart/stop/upgrade/crash/etc servers at any time without affecting the sites at all. I'll check out MemBase. It sounds like a good option. – Talik Jan 7 '12 at 20:45
@Talik: I think MemBase is a good solution - it can be built into clusters as well, but setting up automatic failover is a bit more of a challenge (but with a replicated cluster, shouldn't be as big of a concern) - manual failover is very easy to setup on it. I also quite like GlusterFS - especially in an environment where you also need the files to be available to all nodes, using a distributed file system caters to multiple purposes. – cyberx86 Jan 8 '12 at 1:25

For anyone else interested in this, it looks like PHP has a setting that can be set through the ini file called auto_prepend_file. This can be used to create a session handling script that will run for all websites without any modification to the site code itself.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.