あなたが言ったように、MySQlProxyは解決策になる可能性がありますが、私は個人的にそれを本番環境でテストしたことはありません。
コードで2つのDb接続を使用して、書き込み要求と読み取り要求を分割します。通常のタスクの80％は、読み取り接続を使用して実行されます。 Zend_Application_Resource_Multidb それを処理するために（私にとってはずっと前にこの部分を実行し、2番目のDb接続をレジストリに保存するだけです）。
- 最初に、読み取り操作でのみユーザー権限を制限し、書き込み権限を持つ別のdbuserを作成します。
- 次に、コード内のすべての書き込みリクエストを追跡し（「更新」、「挿入」、「削除」が適切な開始です）、専用のヘルパーを使用してこれらすべての呼び出しを実行してみてください。
- アプリを実行してクラッシュを確認し、問題を修正します:-)
最初にこの問題を考えると簡単です。例：
- 私は通常Zend_Db_Tableファクトリを持っており、「read」または「write」パラメータを取り、正しいZend_Db_Tableのシングルトンを提供します（デュアルシングルトン、読み取りインスタンスと書き込みインスタンスを持つことができます）。次に、書き込みアクセスクエリ/操作を使用するときに、正しく初期化されたZend_Db_Tableを使用していることを確認するだけで済みます。 Zend_Db_Tableをシングルトンとして使用すると、メモリ使用量がはるかに向上することに注意してください。
- TransactionHandlerですべての書き込み操作を取得しようとしています。そこで、正しい接続でリンクされたオブジェクトのみを使用していることを確認できます。その後、トランザクションはコントローラーで管理されます。データベースレイヤーでトランザクションを管理しようとはしません。すべての開始/コミット/ロールバックの考え方は、コントローラー（または、DAOレイヤーではなく、別の概念レイヤー）で行われます。
この最後のポイントであるトランザクションは重要です。トランザクションを管理する場合は、トランザクション内でREADリクエストを行うことが重要です。 、書き込み対応の接続 。トランザクションの前に行われたすべての読み取りは古くなっていると見なす必要があり、データベースバックエンドが暗黙的なロックを実行している場合は、ロックを取得するために読み取り要求を行う必要があります。データベースバックエンドが暗黙的な読み取りを行っていない場合は、トランザクションでも行ロックを実行する必要があります。 つまり、読み取り専用接続でその要求をプッシュするためにSELECTキーワードに依存するべきではないということです。
アプリケーションでdbレイヤーを適切に使用している場合、変更を加えるのはそれほど難しくありません。データベース/DAOレイヤーで混沌としたものを作成した場合は...難しいかもしれません。