Zoals je al zei, kan MySQlProxy een oplossing zijn, maar ik heb het persoonlijk nooit in productie uitgeprobeerd.
Ik gebruik 2 Db-verbindingen in mijn code om schrijf- en leesverzoeken uit te splitsen. 80% van de gebruikelijke taken worden gedaan met de leesverbinding. Je zou de Zend_Application_Resource_Multidb om dat af te handelen (ik heb dit deel al lang eerder gedaan en ik sla gewoon een tweede Db-verbinding op in het register).
- Beperk eerst uw gebruikersrechten alleen bij de leesbewerking en maak een andere dbgebruiker met schrijfautorisatie.
- volg dan elk schrijfverzoek in je code ("update", "insert","delete" is een goed begin) en probeer al deze oproepen te doen met een toegewijde helper.
- voer je app uit en zie hem crashen, en los vervolgens de problemen op :-)
Het is gemakkelijker als je in het begin aan dit probleem denkt. Bijvoorbeeld:
- Ik heb meestal een Zend_Db_Table-fabriek, die een 'lees'- of 'schrijf'-parameter neemt en me een Singleton van de juiste Zend_Db_Table geeft (een dubbele singleton, ik kan een lees- en een schrijf-instantie hebben). Dan hoef ik er alleen voor te zorgen dat ik de juiste geïnitialiseerde Zend_Db_Table gebruik wanneer ik schrijftoegangsquery's/-bewerkingen gebruik. Merk op dat het geheugengebruik veel beter is als je Zend_Db_Table als singletons gebruikt.
- Ik probeer alle schrijfbewerkingen in een TransactionHandler te krijgen. Ik kan daar controleren of ik alleen objecten gebruik die zijn gekoppeld aan de juiste verbinding. Transacties worden vervolgens beheerd op controllers, ik probeer nooit transacties in databaselagen te beheren, alle start/commit/rollback-denken wordt gedaan op de controllers (of een andere conceptuele laag, maar niet de DAO-laag).
Dit laatste punt, transacties, is belangrijk. Als u de transactie wilt beheren, is het belangrijk om de LEES-verzoeken BINNEN de transactie te doen , met de WRITE-enabled verbinding . Aangezien alle leesbewerkingen vóór de transactie als verouderd moeten worden beschouwd, en als uw database-backend impliciete vergrendelingen uitvoert, moet u het leesverzoek indienen om de vergrendelingen te krijgen. Als uw database-backend geen impliciete leesbewerkingen uitvoert, moet u ook de rijvergrendelingen in de transactie uitvoeren. En dat betekent dat u niet op het SELECT-sleutelwoord moet vertrouwen om dat verzoek op de alleen-lezen verbinding te pushen.
Als je een mooi db-laaggebruik in je applicatie hebt, is de verandering niet echt moeilijk te maken. Als je chaotische dingen hebt gemaakt met je database/DAO-laag, dan... kan het moeilijker zijn.