Comme vous l'avez dit, MySQlProxy peut être une solution, mais je ne l'ai personnellement jamais testé en production.
J'utilise 2 connexions Db dans mon code pour séparer les requêtes d'écriture et de lecture. 80% des tâches habituelles sont effectuées avec la connexion en lecture. Vous pouvez utiliser le Zend_Application_Resource_Multidb pour gérer cela (pour moi, j'ai fait cette partie bien avant et je stocke simplement une deuxième connexion Db dans le registre).
- Tout d'abord, limitez vos droits d'utilisateur uniquement sur les opérations de lecture et créez un autre dbuser avec une autorisation d'écriture.
- suivez ensuite chaque demande d'écriture dans votre code ("mettre à jour", "insérer", "supprimer" est un bon début) et essayez d'effectuer tous ces appels avec un assistant dédié.
- exécutez votre application et regardez-la planter, puis corrigez les problèmes :-)
C'est plus facile quand on pense à ce problème au début. Par exemple :
- J'ai généralement une usine Zend_Db_Table, prenant un paramètre 'read' ou 'write', et me donnant un Singleton de la bonne Zend_Db_Table (un double singleton, je peux avoir une instance de lecture et une instance d'écriture). Ensuite, j'ai seulement besoin de m'assurer que j'utilise la bonne Zend_Db_Table initialisée lorsque j'utilise des requêtes/opérations d'accès en écriture. Notez que l'utilisation de la mémoire est bien meilleure lorsque vous utilisez Zend_Db_Table comme singletons.
- J'essaie d'obtenir toutes les opérations d'écriture dans un TransactionHandler. Là, je peux vérifier que je n'utilise que des objets liés avec la bonne connexion. Les transactions sont ensuite gérées sur les contrôleurs, je n'essaie jamais de gérer les transactions dans les couches de base de données, toutes les réflexions de démarrage/commit/rollback sont effectuées sur les contrôleurs (ou une autre couche conceptuelle, mais pas la couche DAO).
Ce dernier point, les transactions, est important. Si vous souhaitez gérer la transaction, il est important de faire les requêtes READ À L'INTÉRIEUR de la transaction , avec la connexion compatible WRITE . Comme toutes les lectures effectuées avant la transaction doivent être considérées comme obsolètes, et si votre backend de base de données fait des verrous implicites, vous devrez faire la demande de lecture pour obtenir les verrous. Si votre backend de base de données n'effectue pas de lectures implicites, vous devrez également effectuer les verrous de ligne dans la transaction. Et cela signifie que vous ne devez pas compter sur le mot-clé SELECT pour pousser cette requête sur la connexion en lecture seule.
Si vous avez une bonne utilisation de la couche db dans votre application, le changement n'est pas vraiment difficile à faire. Si vous avez créé des choses chaotiques avec votre couche de base de données/DAO, alors... cela peut être plus difficile.
