I was hoping for details about how it was accomplished in such a short time, but the article mentions nothing but "special magic sauce".<p>There are obviously complex ways of accomplishing this, but here's how I've managed to pull off fast server switches in the past using nothing but rsync:<p>1) Lower your DNS TTL.<p>2) Do an initial rsync -a --del of the data, with the master still in production. It's OK if this takes a long time.<p>3) Do more rsyncs of the data, which should be faster each time. Time it so you can find your minimum time. Since the filesystem layout gets cached, this can be very fast (just a few seconds for hundreds of thousands of files).<p>4) Shut down services on the old server, such as cron and apache.<p>5) Run the final rsync with services down on both hosts.<p>6) Switch DNS entries to point to the new server while the final rsync is running.<p>7) Bring services up on new server.<p>8) Raise TTL back to normal values.<p>This even works well for medium sized mysql databases, as long as you're OK with the downtime being I/O bound relative to the size of the database.
Why after months of research, stringent requirements for data centers, and general hand-wringing, would you consciously pull the plug for 9 minutes?<p>Edit: That sounds snarky; didn't mean to be. It just struck me that a lot of energy was put into choosing The Best[1] data center and still there was down time.<p>[1] <a href="http://dcurt.is/the-best" rel="nofollow">http://dcurt.is/the-best</a>