Master/Slave Databases with Ruby on Rails
Not terribly long ago, I announced Active Delegate, which was a really lightweight plugin that I developed to allow models to talk to multiple databases for specific methods. The plugin worked great for really simple situations, like individual models.. but when it came time to test with associations it fell apart. I haven’t had a chance to work on any updates and knew that it was going to take more work to get it going.
Earlier this week, we helped one of our bigger clients launch their new web site1. For the deployment, we needed to send all writes to a master database and a reads to slaves (initial deployment is talking to almost 10 slaves spread around the globe!). We needed something to get integrated quickly and decided to ditch Active Delegate for the time being and began looking at the following options.
I spoke with Rick Olson2 and he pointed me to a new plugin that he hasn’t really released yet. So, I’m going to do him a favor and announce it for him. Of course… I got his permission first… ;-)
Announcing Masochism!
Masochism3 is a new plugin for Ruby on Rails that allows you to delegate all writes to a master database and reads to a slave database. The configuration process is just a few lines in your environment file and the plugin takes care of the rest.
Installing Masochism
With piston, you can import Masochism with:
$ cd vendor/plugins
$ piston import http://ar-code.svn.engineyard.com/plugins/masochism/
- To learn more about piston, read Every Second Counts with a Piston in your trunk
You can also install it with the old-fashioned way:
$ ./script/plugin install -x http://ar-code.svn.engineyard.com/plugins/masochism/
Configuring Masochism
The first thing that you’ll need to do is add another database connection in config/database.yml
for master_database
. By default, Masochism expects you to have a production database, which will be the read-only/slave database. The master_database
will be the connection details for your (you guessed it…) master database.
# config/database.yml
production:
database: masochism_slave_database
adapter: postgresql
host: slavedb1.hostname.tld
...
master_database:
database: masochism_master_database
adapter: postgresql
host: masterdb.hostname.tld
...
The idea here is that replication will be handled elsewhere and your application can reap the benefits of talking to the slave database for all of it’s read-only operations and let the master database(s) spend their time writing data.
The next step is to set this up in your environment file. In our scenario, this was config/environments/production.rb
.
# Add this to config/environments/production.rb
config.after_initialize do
ActiveReload::ConnectionProxy.setup!
end
Voila, you should be good to go now. As I mentioned, we’ve only been using this for this past week and we’ve had to address a few problems that the initial version of the plugin didn’t address. One of our developers, Andy Delcambre, just posted an article to show how we had a problem with using ActiveRecord observers and masochism, which we’re sending over a patch for now.
As we continue to monitor how this solution works, we’ll report any findings on our blog. In the meantime, I’d be interested in knowing what you’re using to solve this problem. :-)
1 Contiki, a cool travel company we’re working with
2 Rick just moved to Portland… welcome to stump town!
Multiple Database Connections in Ruby on Rails
We have a client that already has some database replication going on in their deployment and needed to have most of their Ruby on Rails application pull from slave servers, but the few writes would go to the master, which would then end up in their slaves.
So, I was able to quickly extend ActiveRecord with just two methods to achieve this. Anyhow, earlier today, someone in #caboose asked if there was any solutions to this and it prompted me to finally package this up into a quick and dirty Rails plugin.
Introducing… Active Delegate!
To install, do the following:
cd vendor/plugins;
piston import http://svn.planetargon.org/rails/plugins/active_delegate
Next, you’ll need to create another database entry in your database.yml
.
login: &login
adapter: postgresql
host: localhost
port: 5432
development:
database: rubyurl_development
<<: *login
test:
database: rubyurl_test
<<: *login
production:
database: rubyurl_servant
<<: *login
# NOTICE THE NEXT ENTRY/KEY
master_database:
database: rubyurl_master
<<: *login
At this point, your Rails application won’t talk to the master_database
, because nothing is being told to connect to it. So, the current solution with Active Delegate is to create an ActiveRecord model that will act as a connection handler.
# app/models/master_database.rb
class MasterDatabase < ActiveRecord::Base
handles_connection_for :master_database # <-- this matches the key from our database.yml
end
Now, in the model(s) that we’ll want to have talk to this database, we’ll do add the following.
# app/models/animal.rb
class Animal < ActiveRecord::Base
delegates_connection_to :master_database, :on => [:create, :save, :destroy]
end
Now, when your application performs a create
, save
, or destroy
, it’ll talk to the master database and your find
calls will retrieve data from your servant database.
It’s late on a Friday afternoon and I felt compelled to toss this up for everyone. I think that this could be improved quite a bit, but it’s working great for the original problem that needed to be solved.
If you have feedback and/or bugs, please send us tickets.