If you intend on using sessions, you need to configure PHP to use a shared database resource to manage the sessions. Otherwise you will find that someone who has a session on server 1 gets switched to server 2 which doesn't recognise his PHP Session ID and causes the user session to be reset, losing context etc.
The separation of reads and writes is good practice, but it needs some application specific fine-tuning. For instance, if you do go to master-slave you need to calibrate the optimum refresh rate. Too infrequent means that the slave data is out of date for too long, too frequent might cause a bit of a system load. What I have seen done in practice is three database resources, write (to master), read (from slave) and urgent read (from master). This allows the inline transaction processing reads to keep in synch by using the master database - after all if someone clicks on "review cart" after they add a product to the cart, you want to be sure that they're seeing the up-to-date cart. Regular reads, for reporting etc, can work off the slave database where a delay of a few minutes in the reported data is acceptable. For selected super users, you might allow them to chose which database they want to run their reports from.
Also, if you do go to the master/slave database setup, you need to build in some recovery logic into your applications. For instance if something bad happens and your application can't connect to the master database, would you like it to attempt a connection to the slave? I'd suggest you look at a config "failover switch" for this, where if the application fails to contact the master, it can set a failover switch so that all applidation servers know to use the slave database until the flag is reset. This reset can be done manually when the problem is solved. This kind of thing is crucial in a clustered master/slave setup, otherwise you end up with a "split brain" - different application servers updating different databases.
