Before we jump into setup, first a bit about our pre-Rails3 environment:

• Mac OS X 10.5.8
• ruby 1.8.6 (2009-06-08 patchlevel 369) [universal-darwin9.0] (stock)
• RubyGems 1.3.7
• Various older versions of Rails (2.3.8, 2.3.5, 2.3.4, 2.3.2, 2.2.2, 2.1.1, 2.1.0, 2.0.2, 1.2.6, 1.2.3)

We will be installing the latest release of Rails which, as of this writing, is Rails 3 beta4.
We will also complete setup using the latest version of Ruby 1.9.
The minimal version of Ruby 1.9 required for this Rails release is 1.9.2.
To complete setup with Ruby 1.8.7, consult the Rails 3 release notes for the minimal version requirements.

The basic installation steps are as follows:

1. Install RVM (Ruby Version Manger)
2. Install Ruby 1.9.2
3. Install Rails3 beta4
4. Profit!

To install, issue the following commands in a terminal window:

1. bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
   • This is the preferred RVM installation method as described in the RVM installation instructions.
2. rvm install 1.9.2-head
3. rvm 1.9.2-head
4. gem install rails --pre

Installation of the rails gem should also install it’s respective dependencies:

    [05:16:50][tquackenbush@TQuackenbush ~]$ gem list

    *** LOCAL GEMS ***
never
    abstract (1.0.0)
    actionmailer (3.0.0.beta4)
    actionpack (3.0.0.beta4)
    activemodel (3.0.0.beta4)
    activerecord (3.0.0.beta4)
    activeresource (3.0.0.beta4)
    activesupport (3.0.0.beta4)
    arel (0.4.0)
    builder (2.1.2)
    bundler (0.9.26)
    erubis (2.6.5)
    i18n (0.4.1)
    mail (2.2.5)
    mime-types (1.16)
    polyglot (0.3.1)
    rack (1.1.0)
    rack-mount (0.6.4)
    rack-test (0.5.4)
    rails (3.0.0.beta4)
    railties (3.0.0.beta4)
    rake (0.8.7)
    rdoc (2.5.8)
    thor (0.13.6)
    treetop (1.4.8)
    tzinfo (0.3.22)

To test out your new installation, try creating a new bare bones Rails 3 application like so:

1. rails new test_app
2. cd test_app
3. bundle install
   • Bundler is the new default dependency manager in Rails 3, and will install any missing gems required by the project.
   • In my case, this was ’sqlite3-ruby (1.3.0)’
4. rails server

As in Rails 2, this should launch a WEBrick server instance listening on localhost port 3000 with output similar to:

    => Booting WEBrick
    => Rails 3.0.0.beta4 application starting in development on http://0.0.0.0:3000
    => Call with -d to detach
    => Ctrl-C to shutdown server
    [2010-06-23 16:54:06] INFO  WEBrick 1.3.1
    [2010-06-23 16:54:06] INFO  ruby 1.9.2 (2010-06-22) [i386-darwin9.8.0]
    [2010-06-23 16:54:06] INFO  WEBrick::HTTPServer#start: pid=6529 port=3000

And that’s it! You’re all ready to go with Rails 3!

Update: June 25th, 2010 (David Czarnecki)

I ran into an issue on one system where rvm and Ruby 1.9.2 were correctly installed on the system, but Rails 3 would not install. The installation would go as follows.

machine-name:~ dczarnecki$ gem install rails --pre
WARNING:  RubyGems 1.2+ index not found for:

RubyGems will revert to legacy indexes degrading performance.

I blew away the ~/.gemrc file and Rails 3 installed successfully. YMMV.

Update: June 29th, 2010 (Joshua Childs)
Ran into two issues with with dependencies while getting setup on my Ubuntu workstation.

First was while problem I ran into was while following the installation steps.

# Command:
josh@jagar-tharn:~$ rvm install 1.9.2-head

# Response:
fail: bison is not available in your path. Please ensure it exists before compiling from head.

# Solution:
sudo apt-get install bison

And the second problem I ran into was while using bundle to setup my dependencies. My workstation did not have sqlite3 installed.

# Command:
josh@jagar-tharn:~/projects/test_app$ bundle install

# Response:
...
Using rails (3.0.0.beta4) from bundler gems
Installing sqlite3-ruby (1.3.0) from rubygems repository at http://rubygems.org/ with native extensions /home/josh/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/rubygems/ext/builder.rb:46: warning: Insecure world writable dir /usr/local/libevent/ in PATH, mode 040777
/home/josh/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/rubygems/installer.rb:483:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/home/josh/.rvm/rubies/ruby-1.9.2-head/bin/ruby extconf.rb
checking for sqlite3.h... no
sqlite3.h is missing. Try 'port install sqlite3 +universal' or 'yum install sqlite3-devel'
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/home/josh/.rvm/rubies/ruby-1.9.2-head/bin/ruby
	--with-sqlite3-dir
	--without-sqlite3-dir
	--with-sqlite3-include
	--without-sqlite3-include=${sqlite3-dir}/include
	--with-sqlite3-lib
	--without-sqlite3-lib=${sqlite3-dir}/lib
...

# Solution:
josh@jagar-tharn:~/projects/test_app$ sudo apt-get install sqlite3
josh@jagar-tharn:~/projects/test_app$ sudo apt-get install libsqlite3-dev

Sometimes, things go horribly, horribly wrong, and there’s nothing you can do to stop the slow-motion train wreck unfolding before your very eyes. (Like that one senior prom where you spilled your dinner all over your date’s dress. On the upside, you didn’t need that $200 anyway.) When things go that awry, there’s no way to fix it. (She never did return your phone calls, did she?) The only thing you can do with a mistake like that is to make sure it never, ever happens again.

For most of the sites we produce, we use MySQL as a backend. While it’s extremely rare for the MySQL server to catastrophically fail, it happens, and the more MySQL servers you have, the more likely it is to happen at least once. To keep this from causing problems for us, we replicate our databases (that is, maintain a live copy of them). This provides us with two benefits:

1. If the MySQL master (primary database) blows up, melts down, or gets eaten by vermin, we can “promote” the slave database (the clone) to fulfill the master’s role while we figure out what happened and how to fix it, keeping the site up and preventing any data from being lost.
2. Since the MySQL slave isn’t used for anything other than covering our backsides, we can take it offline periodically to archive all the data in the database without impacting anything. (This is important when your site has literally four million users pouring statistics into it all day, every day, and doing a live backup will slow things down.) Archives are good in case you want to do statistical analysis on your data or in case you accidentally delete everything in the database after working a twelve hour day trying to figure out how vermin ate your master database. (Both of these have happened before. Sort of.)

So, let me walk you through setting up a database slave from scratch.

I am starting with two identical machines that are running identical instances of MySQL. The first of these, Dragon, is going to be the master. The second of these, Unicorn, is going to be the slave. (So I name my servers after mythical beasts. What’s wrong with that?) I am assuming a reasonable level of knowledge with the UNIX shell. If you lack familiarity, you really should spend some time learning. It will make you a better programmer, system administrator, friend, spouse, and human being.

1. First, you should have the following items set in your MySQL configuration (/etc/mysql/my.cnf). If you don’t, add them: they can go anywhere under the [mysqld] heading.

server-id = 1
log-bin = /var/lib/mysql/binlog/mysql-bin
expire_logs_days = 1
max_binlog_size = 100M
relay_log = /var/lib/mysql/binlog/mysqld-relay-bin
relay_log_index = /var/lib/mysql/binlog/mysqld-relay-bin.index

The server-id should be some unique number, not shared with any other machine on your network. Replication occurs by copying around binary log files; you should set expire_logs_days so that you don’t end up with a huge pileup of data clogging up your disk drives (as they will eventually eat up your hard disk). We set binary logs to expire after 1 day, since our disks have a tendency to fill up on us quickly (for example, one of our Guitar Hero master databases has a 6GB binary log directory, even though it expires data after a single day!) Be advised that if you are worried about your slaves falling more than a day behind, you should keep logs around for a greater duration. (However, from our experience, if your slaves fall more than a day behind, you have bigger problems.) Finally, you can put datadir, relay_log, and relay_log_index wherever you please; above are just where we use. (Make sure, however, that they exist and are writable by the mysql user!)

You should restart the server after changing the settings. On Debian and Ubuntu, you can do this via “/etc/init.d/mysql restart”.

2. Your slave should have the same options defined as above in its MySQL configuration. The server-id option, however, must be different from the master (in our case, setting it to “2″ will do). All the other options can be whatever you please.

Also restart this server when it’s set as you like.

3. You should grant permission for the slave to read data from the master. This can be done from the MySQL console on the master (mysql -h dragon -u root). Assuming the user name “foo” and the password “bar”:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'foo'@'unicorn' IDENTIFIED BY 'bar';

You can, of course, restrict which databases and tables you grant permissions with. We don’t in this particular case.

4. You now need to dump all of the data on the master, copy it over to the slave, and import it there; this is necessary even if your databases are empty, as it will initialize the slave regardless.

On the master (this will require your MySQL root password):

mysqldump -uroot -p --all-databases --single-transaction --master-data=1 | gzip >master.sql.gz

If you don’t have a root password (which is generally a bad idea, but fine if your MySQL server is on a private network), you should omit the `-p` above.

You can copy this file over to the slave server using `scp`:

scp master.sql.gz unicorn:

Finally, import the dump on the slave:

zcat master.sql.gz | mysql -uroot

5. Tell the slave to mirror the master.

mysql> CHANGE MASTER TO MASTER_HOST='dragon', MASTER_USER='foo', MASTER_PASSWORD='bar';

6. Start the slave!

mysql> START SLAVE;

You can now monitor the progress of your slave using `SHOW SLAVE STATUS`. (If you use a `\G` instead of a semicolon to terminate the line, it will print out the data in a much more readable format.)

mysql> SHOW SLAVE STATUS\G

There could be a number of errors, which are beyond the scope of fixing here. (In my case, we ran into issues with binary logs and the binary log index files.) These can generally be troubleshooted (troubleshot?) by reading the output of syslog (`tail -f /var/log/syslog`) and fixing the problem one piece at a time; it helps to have a lot of UNIX experience, though.) If all goes well, though, `SHOW SLAVE STATUS` will have lines something like the following:

       Slave_IO_State: Waiting for master to send event
          Master_Host: dragon
          Master_Port: 3306
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
Seconds_Behind_Master: 12887

This indicates that the slave is running and in the process of catching up to the master, and in time will be synchronized with it.

And, that’s (hopefully!) all there is to it! Now, with your new slave, you can go forth and conquer the world! (Or, less ambitiously, cover your backside when you accidentally delete something.)

Obligatory CTO Note: Make sure you keep, and regularly verify your daily backups too!