Skip to content


Subversion checkout URL

You can clone with
Download ZIP


RaphaelAudet edited this page · 12 revisions
Clone this wiki locally


I’ll collect ideas for the future development of multi_db on this page. Feel free to comment!

Readonly mode

This would throw special exceptions (MultiDb::ReadOnlyMode) if any
write operations are attempted. The controller could intercept these
exceptions with rescue_from MultiDb::ReadOnlyMode, … to display
a maintenance page.

It may be possible to toggle this mode by sending SIGUSRx to the application


  • The master must be brought down for maintenance
  • Running complex migrations that require a write lock for some reason


  • The application has to be designed around this (e.g. not updating a users ‘last_login’ on login, not writing tracking information to the db etc.)

“Master only” mode

This would force all communication to the master.

It may be possible to toggle this mode by sending SIGUSRx, too.


  • Monitoring detects that the db has stopped replicating (happens for example on replication conflicts in a master/master setup using MySQL)
  • Bringing down the slave(s) for maintenance

Use “Master only” mode when “transaction”

ActiveRecord::Base implement a “transaction” function, this disable the “autocommit = true” option in your DB.
This introduce a problem with multi_db because your rails app can’t read the uncommitted rows unless you use the “master only” mode (aka. ActiveRecord::Base.connection_proxy.with_master { … })


This is what I have done for my own project :
I override the ActiveRecord::Transaction::ClassMethods model

module ActiveRecord
module Transactions
module ClassMethods def multi_db_transaction options = {}, *args, &block if options.delete(:master_only) ActiveRecord::Base.connection_proxy.with_master do transaction *args.insert(0, options), &block end else transaction *args.insert(0, options), &block end end end end


So now you can call
ActiveRecord::Base.multi_db_transaction(:master_only => true) do …

Master-Master replication

In a configuration with two master nodes (and to slaves, each one being the master and slave of the other one, such as described here). The gems could fallback to the other master for read/write.


  • To achieve high availability if one mysql server is down.


  • The connection proxy should be able to recover from a master unavailable and switch it’s configuration so the slave is now the master.
Something went wrong with that request. Please try again.