Som du sagde, kan MySQlProxy være en løsning, men jeg har personligt aldrig testet det i produktion.
Jeg bruger 2 Db-forbindelser i min kode til at opdele skrive- og læseanmodninger. 80 % af de sædvanlige opgaver udføres med læseforbindelsen. Du kan bruge Zend_Application_Resource_Multidb at håndtere det (For mig har jeg gjort denne del længe før, og jeg gemmer simpelthen en anden Db-forbindelse i registreringsdatabasen).
- Begræns først kun dine brugerrettigheder ved læsning, og opret en anden dbuser med skrivetilladelse.
- så spor hver skriveanmodning i din kode ("opdater", "indsæt","slet" er en god start), og prøv at foretage alle disse opkald med en dedikeret hjælper.
- kør din app og se den gå ned, og løs derefter problemer :-)
Det er nemmere, når du tænker på dette problem i begyndelsen. For eksempel:
- Jeg har normalt en Zend_Db_Table-fabrik, der tager en 'læse' eller 'skrive'-parameter og giver mig en Singleton af den rigtige Zend_Db_Table (en dobbelt singleton, hvis jeg kan have en læseinstans og en skriveinstans). Så skal jeg kun sikre mig, at jeg bruger den rigtige initialiserede Zend_Db_Table, når jeg bruger skriveadgangsforespørgsler/operationer. Bemærk, at hukommelsesbrug er langt bedre, når du bruger Zend_Db_Table som singletons.
- Jeg forsøger at få alle skriveoperationer i en TransactionHandler. Der kan jeg kontrollere, at jeg kun bruger objekter, der er forbundet med den rigtige forbindelse. Transaktioner administreres derefter på controllere, jeg forsøger aldrig at administrere transaktioner i databaselag, al start/commit/rollback-tænkning udføres på controllerne (eller et andet konceptuelt lag, men ikke DAO-laget).
Dette sidste punkt, transaktioner, er vigtigt. Hvis du vil administrere transaktionen, er det vigtigt at foretage LÆS-anmodningerne INDE i transaktionen , med den WRITE-aktiverede forbindelse . Da alle læsninger udført før transaktionen skal betragtes som forældede, og hvis din database-backend laver implicitte låse, bliver du nødt til at lave læseanmodningen for at få låsene. Hvis din database-backend ikke laver implicitte læsninger, bliver du også nødt til at udføre rækkelåsene i transaktionen. Og det betyder, at du ikke skal stole på SELECT-søgeordet til at skubbe denne anmodning på den skrivebeskyttede forbindelse.
Hvis du har en god brug af db-lag i din applikation, er ændringen ikke rigtig svær at lave. Hvis du lavede kaotiske ting med dit database/DAO-lag, så... kan det være sværere.