Como dijiste, MySQlProxy puede ser una solución, pero personalmente nunca lo probé en producción.
Uso conexiones de 2 Db en mi código para dividir las solicitudes de escritura y lectura. El 80% de las tareas habituales se realizan con la conexión de lectura. Puede usar Zend_Application_Resource_Multidb para manejar eso (para mí, he hecho esta parte mucho antes y simplemente almaceno una segunda conexión Db en el registro).
- Primero limite sus derechos de usuario solo en la operación de lectura y cree otro dbuser con autorización de escritura.
- luego realice un seguimiento de cada solicitud de escritura en su código ("actualizar", "insertar","eliminar" es un buen comienzo) e intente realizar todas estas llamadas con un ayudante dedicado.
- ejecuta tu aplicación y observa cómo falla, luego soluciona los problemas :-)
Es más fácil cuando piensas en este problema al principio. Por ejemplo:
- Por lo general, tengo una fábrica de Zend_Db_Table, que toma un parámetro de "lectura" o "escritura" y me da un Singleton de la Zend_Db_Table correcta (un singleton dual, puedo tener una instancia de lectura y una instancia de escritura). Entonces solo necesito asegurarme de que uso la Zend_Db_Table correctamente inicializada cuando uso consultas/operaciones de acceso de escritura. Tenga en cuenta que el uso de la memoria es mucho mejor cuando se usa Zend_Db_Table como singletons.
- Trato de obtener todas las operaciones de escritura en un TransactionHandler. Allí puedo verificar que uso solo objetos vinculados con la conexión correcta. Luego, las transacciones se administran en los controladores, nunca intento administrar las transacciones en las capas de la base de datos, todo el pensamiento de inicio/confirmación/reversión se realiza en los controladores (u otra capa conceptual, pero no en la capa DAO).
Este último punto, las transacciones, es importante. Si desea administrar la transacción, es importante realizar las solicitudes de LECTURA DENTRO de la transacción , con la conexión habilitada para ESCRIBIR . Como todas las lecturas realizadas antes de la transacción deben considerarse obsoletas, y si el backend de su base de datos está realizando bloqueos implícitos, deberá realizar la solicitud de lectura para obtener los bloqueos. Si el backend de su base de datos no está realizando lecturas implícitas, también deberá realizar los bloqueos de fila en la transacción. Y eso significa que no debe confiar en la palabra clave SELECT para impulsar esa solicitud en la conexión de solo lectura.
Si tiene un buen uso de la capa de base de datos en su aplicación, el cambio no es realmente difícil de hacer. Si hiciste cosas caóticas con tu base de datos/capa DAO, entonces... puede ser más difícil.
