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()).
RDBMs:
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).
NoSQL:
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).
