I\'m using flyway 1.5 and mysql Ver 14.14 Distrib 5.1.52, for unknown-linux-gnu (x86_64) using readline 5.1
I wrote the following migration:
We just ran into this issue and managed to find a solution that worked for us. It seems that Flyway uses at least two connections: one to lock the schema_version
table, and one to actually run the alters. This issue occurs when the alters take long enough to cause the connection locking the schema_version
table to timeout. The easiest way to fix this is the bump up the MySQL wait_timeout
to something relatively large. In our case we set it to 480 minutes (or 28800 seconds):
set global wait_timeout=28800;
A bit of analysis:
As the Flyway Command-line Tool creates two new connections when it starts, connection staleness can be ruled out.
Flyway will then first open a connection for the metadata table and lock it.
It will then open a second connection and execute the migration. I am assuming this step takes very long (+- 11mins from the logs).
When the migration completes, the transaction on the second connection commits and the new row is added in the metadata table through the first connection.
This is where it bombs... But with a communication and not with a connection timeout or a lock timeout exception.
Could it be that some piece of network equipment (router/switch/proxy) between the app and the DB is dropping inactive connections?