What are some key configuration settings for using an InnoDb table for session storage? I want to start clustering my PHP app servers but don't want to go for a sticky-sessions load balancing setup at this point. However, I want sessions that are persisted to disk and implement proper locking. I have a server already dedicated to the database with comfortable amount of free ram so I'd like to consider using an additional instance of MySQL purely for session storage on the same machine. Currently my sessions folder on the file system is ~131Mb and has ~23k files. I'm planning on using InnoDb with SELECT ... FOR UPDATE to implement the session locking.

Is running two instances of MySQL optimized for different purposes on the same server a bad idea? (If so, why?)

For the sessions-only instance what are some optimization tips? I want it to be persistent, but don't mind losing a little bit of data in the event of a disaster whereas with the main app db I don't want to risk any data loss.

If I can spare say 256Mb of ram for this MySQL instance (main instance has ~6Gb), how should I allocate it?

Disable query cache or no?

What settings can I use to reduce disk writes (since I don't care about durability so much with this instance)? E.g. innodb_locks_unsafe_for_binlog, innodb_flush_method, etc..
You could experiment with innodb_flush_log_at_trx_commit

According to the MySQL Documentation on innodb_flush_log_at_trx_commit


  If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is
  written out to the log file once per second and the flush to disk
  operation is performed on the log file, but nothing is done at a
  transaction commit. When the value is 1 (the default), the log buffer
  is written out to the log file at each transaction commit and the
  flush to disk operation is performed on the log file. When the value
  is 2, the log buffer is written out to the file at each commit, but
  the flush to disk operation is not performed on it. However, the
  flushing on the log file takes place once per second also when the
  value is 2. Note that the once-per-second flushing is not 100%
  guaranteed to happen every second, due to process scheduling issues. 
  
  The default value of 1 is required for full ACID compliance. You can
  achieve better performance by setting the value different from 1, but
  then you can lose up to one second worth of transactions in a crash.
  With a value of 0, any mysqld process crash can erase the last second
  of transactions. With a value of 2, only an operating system crash or
  a power outage can erase the last second of transactions. InnoDB's
  crash recovery works regardless of the value. 
  
  For the greatest possible durability and consistency in a replication
  setup using InnoDB with transactions, use
  innodb_flush_log_at_trx_commit=1 and sync_binlog=1 in your master
  server my.cnf file. 
  
  Caution
  
  Many operating systems and some disk hardware fool the flush-to-disk
  operation. They may tell mysqld that the flush has taken place, even
  though it has not. Then the durability of transactions is not
  guaranteed even with the setting 1, and in the worst case a power
  outage can even corrupt the InnoDB database. Using a battery-backed
  disk cache in the SCSI disk controller or in the disk itself speeds up
  file flushes, and makes the operation safer. You can also try using
  the Unix command hdparm to disable the caching of disk writes in
  hardware caches, or use some other command specific to the hardware
  vendor.


Based on this, values other than 1 put InnoDB at risk of losing 1 second's worth of transactions, or a transaction commit's worth of data.

As far as innodb_flush_method, the default is best. I wrote an earlier post to describe the effects of tweeking it.

As for running multiple instances of MySQL, it's OK as along as you have enough memory for the OS and enough memory of DB Connections for the multiple instances.