I am just wondering how Flyway deals with the fact that several dynos can try to run a database migration several times in a clustered environment such as Heroku thereby causing a conflict?
相关问题
- How to specify memcache server to Rack::Session::M
- Connecting Python to a Heroku PostgreSQL DB?
- rails/heroku migrating from gem to toolbelt
- Using runtime env with React and heroku
- Heroku process.env.port is undefined
相关文章
- Django/Heroku: FATAL: too many connections for rol
- Heroku Web Server Won't Start Locally
- Heroku push issue
- Why does Rake task enhancement differ between my l
- Push rejected, failed to detect set buildpack hero
- Flyway not finding my sql migrations in db/migrati
- Email With Rails 3 and Heroku Net::SMTPSyntaxError
- Heroku db:pull 'db:pull is not a heroku comman
This question explains a bit more how the locking behaviour works. It appears to acquire a lock on the Flyway schema table:
select * from dbschema.schema_version for update
which might cause problems for longer running migrations as theinnodb_lock_wait_timeout
setting might cause a timeout, at least in the case of MySQL.It seems Flyway uses locking in order to deal with this issue.
To quote the documentation: