Need clarrification on rake db:migrate

23 views
Skip to first unread message

Loganathan Sellapa

unread,
Feb 11, 2015, 12:04:55 PM2/11/15
to bangal...@googlegroups.com
Hi All,

I have an HA setup for my rails application in order make my application available always, the setup is having two application servers and one db server. 
 
The setup is running perfectly so far, but I wanted to know, while running the
"rake db:migrate" in any of the one application server will it lock the complete db?
 
Assume that I am running rake db:migrate in one of the application server say "app1", at this time app1 will be down but the request will be handled by another application server (app2). If the database is locked, then both of my applications are wont work right?
 
regards,
Loganathan
Mob: +91 7760780741 | +91 9944414388
Skype: loganathan.sellappa
ViewMe

Aakash Dharmadhikari

unread,
Feb 13, 2015, 12:26:22 AM2/13/15
to Bangalore Ruby User Group
Hello Loganathan,

reply inline

- Aakash

On Wed, Feb 11, 2015 at 10:34 PM, Loganathan Sellapa <logana...@gmail.com> wrote:
Hi All,

I have an HA setup for my rails application in order make my application available always, the setup is having two application servers and one db server. 
 
The setup is running perfectly so far, but I wanted to know, while running the
"rake db:migrate" in any of the one application server will it lock the complete db?

It depends on the type of migration you are running. If you are doing any table level changes, then that particular table will be blocked. It also depends on the DB you are using. For example, index creation is non-blocking in Postgres unlike in MySQL.
 
 
Assume that I am running rake db:migrate in one of the application server say "app1", at this time app1 will be down but the request will be handled by another application server (app2). If the database is locked, then both of my applications are wont work right?

As I said earlier, one of the tables will get locked and not the whole DB. Also, depending on what kind of changes you are making, you might not want the other app server to serve any requests. This is how we handle deployments whose migrations might break the pre-deployment app version. e.g. removing a column that current app version depends on.

1. Enable maintenance mode
2. Run the migrations
3. Deploy the deployment branch onto all app servers
4. Disable maintenance mode

If we don't have any breaking changes, e.g. we are adding a column, which will be simply ignored by currently deployed app version.

1. Run the migrations
2. Deploy the deployment branch onto all app servers

In the second case, application never goes into maintenance state and user don't even realize that a new deployment has happened.
 
 
regards,
Loganathan
Mob: +91 7760780741 | +91 9944414388
Skype: loganathan.sellappa
ViewMe

--
You received this message because you are subscribed to the Google Groups "BANGALORE RUG-Ruby Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bangalorerug...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Loganathan Sellapa

unread,
Feb 13, 2015, 12:30:23 AM2/13/15
to bangal...@googlegroups.com
HI Aakash,

Thanks, JFYI HA is not for my whole application , I want to provide HA for one of my module in my application, so if the the other tables get affected while rake db:migrate, I want to make sure that my HA should work for that particular module of my application.  Now I am clear since rake db:migrate wont lock the complete db.

regards,
Loganathan
Mob: +91 7760780741 | +91 9944414388
Skype: loganathan.sellappa
ViewMe


Reply all
Reply to author
Forward
0 new messages