Question

I have a PHP application that has grown in size. The database used to be on a single master but we intend to change that with a fairly standard master/slave replication for performance and HA.

Since this app is read-heavy I would like to have the reads delegated to the slave replicas and writes going to the master.

The app is based on Zend Framework 1.1.10 and uses Zend_Db.

What would be my best strategy for getting this app to split reads and writes to the DB without refactoring the code too much? (I realize there would probably be some refactoring involved here).

P.S:

I have looked at MySQL Proxy and it seems it can transparently split reads and writes by sitting in between the DB server and the app, but I’m not sure about the performance issues using this in a production environment. Does anyone have experience with this?

Answer 1

As you said MySQlProxy can be a solution, but I personnaly never tested it out in production.

I use 2 Db connections in my code to split-out write and read requests. 80% of the usual tasks are done with the read connection. You could use the Zend_Application_Resource_Multidb to handle that (For me I’ve done this part long before and I simply store a second Db connection in the registry).

• First limit your user rights only on
  read operation and create another db
  user with write authorization.
• then track every write request in
  your code (“update”, “insert”,
  “delete” is a good start) and try to
  make all these calls with a dedicated
  helper.
• run your app and watch it crash, then fix problems 🙂

It’s easier when you think this problem in the beginning. For example:

• I usually have a Zend_Db_Table factory, taking a ‘read’ or ‘write’ parameter, and giving me a Singleton of the right Zend_Db_Table (a dual singleton, it I can have a read instance and a write instance). Then I only need to ensure I use the right initialized Zend_Db_Table when I use write access queries/operations. Notice that memory usage is far better when using Zend_Db_Table as singletons.
• I try to get all write operations in a TransactionHandler. I there I can check I use only objects linked with the right connection. Transactions are then managed on controllers, I never try to manage transaction in Database layers, all start/commit/rollback thinking is done on the controllers (or another conceptual layer, but not the DAO layer).

This last point, transactions, is important. If you want to manage transaction it’s important to make the READ requests INSIDE the transaction, with the WRITE-enabled connection. As all reads done before the transaction should be considered as outdated, and if your database backend is doing implicits locks you’ll have to make the read request to get the locks. If your database backend is not doing implicit reads then you’ll have to perform the row locks in the transaction as well. And that mean you should’nt rely on the SELECT keyword to push that request on the read-only connection.

If you have a nice db layer usage in your application the change is not really hard to make. If you made chaotic things with your database/DAO layer then… it may be harder.