On Thursday, February 19, 2015 at 3:12:54 PM UTC-8, Bethany Skurrie wrote: > > I have an application that currently runs its migrations on startup. We > are investigating whether or not we could run this with multiple AWS > instances sharing the same database. Our concern is that both instances > will try to run the migrations at the same time, as there does not appear > to be any locking to prevent this. Has anyone faced/solved this issue > before? I believe it would be reasonably straightforward to add a locking > mechanism using normal database table locking, but I'm sure someone else > must have tired this before, and I would like to hear from them! >
My personal preference is to not migrate on startup, but migrate manually via a rake task. For any applications with stringent uptime requirements, you basically must write your migrations in such a way that your old application code will work continue to work post migration. Apps without stringent uptime requirements can always just stop the app, run the migration, and then start it back up, so migrating on startup works for those, at least in the single process case. I'm open to supporting locking on migrations, at least as an optional feature. For integer migrations, a FOR UPDATE lock on the schema_info entry may be sufficient. However, for timestamp migrations it would be more complex. If anyone wants to take a stab at implementing this, please let me know. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
