Rails migrations with no downtime
pedro.herokuapp.com
Rails migrations with no downtime
1–10 of 22 posts
Re: Rails migrations with no downtime
#2What's the Django equivalent of this?
Re: Rails migrations with no downtime
#3This is old news, but we successfully use https://github.com/freels/table_migrator in production not on heroku. It creates a copy of the table, performs the schema changes, copies the data over, then renames the tables for almost (i.e. 1-2 seconds) no downtime.
Re: Rails migrations with no downtime
#4If you're writing your code to work against multiple schemas, how do you test it? Do you run your test suite twice, once with the pre-migration schema, and again with the post-migration schema?
Re: Rails migrations with no downtime
#5I use percona tools pt-online-schema-change http://www.percona.com/doc/percona-toolkit/2.0/pt-online-sch..., wrote a custom gem for it while ago
Re: Rails migrations with no downtime
#6Andy Delcambre wrote a post two months ago about how Engine Yard handles zero-downtime deploys with migrations. Link here: http://www.engineyard.com/blog/2011/zero-downtime-deploys-wi...
Re: Rails migrations with no downtime
#7If you're writing your code to work against multiple schemas, how do you test it? Do you run your test suite twice, once with the pre-migration schema, and again with the post-migration schema?
For sure.
Most of the time migrations are developed in a feature branch, so the owner is responsible for splitting his branch into two or three before sending pull requests (as many as required to address issues with hot compatibility).
This means that we have two or more merges (and deploys) from master, each requiring a full run of the test suite.
Re: Rails migrations with no downtime
#8What's the Django equivalent of this?
You pretty much have to do the same thing - release code using new models before migrating the db. Django tends to spell out all columns in its SQL statements, so when you delete one from the db, but fail to upgrade the code you will run into a db exception.
I'd also recommend using South for migrations http://south.aeracode.org/
Re: Rails migrations with no downtime
#9This is old news, but we successfully use https://github.com/freels/table_migrator in production not on heroku. It creates a copy of the table, performs the schema changes, copies the data over, then renames the tables for almost (i.e. 1-2 seconds) no downtime.
How does this deal with foreign key references? I thought that if you rename a table the FK references from other tables will still point at the renamed table? Discussion here: http://dev.mysql.com/doc/refman/5.0/en/rename-table.html
The Percona pt-online-schema-change tool goes to great lengths to avoid this kind of problem.
Re: Rails migrations with no downtime
#10There is another problem unmentioned in this article with his simple table modification example... When you modify a table the DB needs to write the entire table to disk, locking it all the time. Depending on how much data is in the table and how fast your IO is this can be hours and hours of downtime on the live database, for a migration that only took a few seconds locally on your test database.
Running migrations on live databases with lots of data in them is hard. There are many strategies to work around this problem, but generally running an 'alter table' on your primary db server on a huge table while it is in use should be your very last option.