Come hai detto MySQlProxy può essere una soluzione, ma personalmente non l'ho mai testato in produzione.
Uso connessioni da 2 Db nel mio codice per suddividere le richieste di scrittura e lettura. L'80% delle normali attività viene svolto con la connessione di lettura. È possibile utilizzare Zend_Application_Resource_Multidb per gestirlo (per me ho fatto questa parte molto tempo prima e memorizzo semplicemente una seconda connessione Db nel registro).
- Prima limita i tuoi diritti utente solo all'operazione di lettura e crea un altro dbuser con autorizzazione in scrittura.
- quindi tieni traccia di ogni richiesta di scrittura nel tuo codice ("aggiorna", "inserisci", "elimina" è un buon inizio) e prova a fare tutte queste chiamate con un assistente dedicato.
- esegui la tua app e guardala in crash, quindi risolvi i problemi :-)
È più facile quando pensi a questo problema all'inizio. Ad esempio:
- Di solito ho una Zend_Db_Table factory, prendendo un parametro 'read' o 'write', e dandomi un Singleton della Zend_Db_Table giusta (un dual singleton, posso avere un'istanza di lettura e un'istanza di scrittura). Quindi devo solo assicurarmi di utilizzare lo Zend_Db_Table inizializzato corretto quando utilizzo query/operazioni di accesso in scrittura. Si noti che l'utilizzo della memoria è molto migliore quando si utilizza Zend_Db_Table come singleton.
- Cerco di ottenere tutte le operazioni di scrittura in un TransactionHandler. Io lì posso verificare di utilizzare solo oggetti collegati con la giusta connessione. Le transazioni vengono quindi gestite sui controller, non provo mai a gestire le transazioni nei livelli del database, tutto il pensiero di avvio/commit/rollback viene eseguito sui controller (o su un altro livello concettuale, ma non sul livello DAO).
Quest'ultimo punto, le transazioni, è importante. Se vuoi gestire la transazione è importante effettuare le richieste di LETTURA ALL'INTERNO della transazione , con la connessione abilitata per la SCRITTURA . Poiché tutte le letture eseguite prima della transazione dovrebbero essere considerate obsolete e se il backend del database esegue blocchi impliciti dovrai effettuare la richiesta di lettura per ottenere i blocchi. Se il back-end del tuo database non esegue letture implicite, dovrai eseguire anche i blocchi di riga nella transazione. E ciò significa che non dovresti fare affidamento sulla parola chiave SELECT per inviare tale richiesta alla connessione di sola lettura.
Se hai un buon utilizzo del livello db nella tua applicazione, la modifica non è davvero difficile da apportare. Se hai creato cose caotiche con il tuo livello di database/DAO, allora... potrebbe essere più difficile.
