Como você disse, o MySQlProxy pode ser uma solução, mas eu nunca testei em produção.

Eu uso conexões de 2 Db no meu código para dividir as solicitações de gravação e leitura. 80% das tarefas usuais são feitas com a conexão de leitura. Você pode usar os Zend_Application_Resource_Multidb para lidar com isso (para mim, eu fiz essa parte muito antes e simplesmente armazeno uma segunda conexão Db no registro).

• Primeiro limite seus direitos de usuário apenas na operação de leitura e crie outro dbuser com autorização de gravação.
• rastreie todas as solicitações de gravação em seu código ("atualizar", "inserir", "excluir" é um bom começo) e tente fazer todas essas chamadas com um auxiliar dedicado.
• execute seu aplicativo e observe-o travar, depois corrija os problemas :-)

É mais fácil quando você pensa esse problema no começo. Por exemplo:

• Eu costumo ter uma fábrica Zend_Db_Table, pegando um parâmetro 'read' ou 'write', e me dando um Singleton do Zend_Db_Table certo (um singleton duplo, posso ter uma instância de leitura e uma instância de escrita). Então eu só preciso garantir que eu use o Zend_Db_Table inicializado corretamente quando eu usar consultas/operações de acesso de gravação. Observe que o uso de memória é muito melhor ao usar Zend_Db_Table como singletons.
• Tento obter todas as operações de gravação em um TransactionHandler. Eu lá posso verificar se uso apenas objetos vinculados com a conexão correta. As transações são então gerenciadas em controladores, eu nunca tento gerenciar transações em camadas de banco de dados, todo o pensamento de início/commit/reversão é feito nos controladores (ou outra camada conceitual, mas não a camada DAO).

Este último ponto, transações, é importante. Se você deseja gerenciar a transação, é importante fazer as solicitações READ DENTRO da transação , com a conexão habilitada para WRITE . Como todas as leituras feitas antes da transação devem ser consideradas desatualizadas, e se o backend do seu banco de dados estiver fazendo bloqueios implícitos, você terá que fazer a solicitação de leitura para obter os bloqueios. Se o back-end do banco de dados não estiver fazendo leituras implícitas, você também terá que realizar os bloqueios de linha na transação. E isso significa que você não deve confiar na palavra-chave SELECT para enviar essa solicitação na conexão somente leitura.

Se você tiver um bom uso da camada db em seu aplicativo, a alteração não é muito difícil de fazer. Se você fez coisas caóticas com sua camada de banco de dados/DAO então... pode ser mais difícil.