Skip to content
RaphaelAudet edited this page Oct 22, 2012 · 12 revisions

Ideas

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
processes

Scenarios

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

Challenges

  • 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.

Scenarios

  • 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 { … })

Implementation

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

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.

Scenarios

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

Challenges

  • The connection proxy should be able to recover from a master unavailable and switch it’s configuration so the slave is now the master.