Looking to achieve DevOps with Flyway? Watch our latest webinar on the Redgate Hub ▶ Watch now
2017-02-09 by Axel Fontaine
Welcome to 2017! And do we have some great things in store for this year! But first let's see how last year went.
Like every year since Flyway's initial launch in 2010, last year was Flyway's best year ever. We had both the fastest growth and the highest number of downloads since we started. In 2016 Flyway was downloaded 1.6 million times!
Flyway yearly downloads
So let's start the year with a brand new release! Flyway 4.1.0 comes with new features, better performance and higher reliability.
These are the highlights of this release:
Let's dive right in!
Once again Flyway expands its ever growing list of supported relational databases to almost 20 (!) and now comes with support for EnterpriseDB.
While PostgreSQL supports DDL transactions, there are unfortunately a number of statements like
ALTER TYPE ... ADD VALUE and
VACUUM among others that are not able to run within a
In fact in the case of
CREATE INDEX CONCURRENTLY there may not even be any other
active for the operation the be able to complete!
Flyway 4.1.0 comes with two major improvements to support these statements in a fully transparent fashion.
First Flyway now autodetects whether a non-transactional statement is present within a migration. If it is, then the whole migration is run without a transaction (and clearly labelled as such in the logs).
In the spirit of fail-fast and to avoid accidentally mixing transactional and non-transactional statements within
the same migration, we have also introduced a new
allowMixedMigrations parameter. When deactivated
it will cause Flyway to throw an error in those situations.
This however still doesn't work with
CREATE INDEX CONCURRENTLY due to Flyway's support for
migrating databases from multiple applications nodes in parallel. To avoid things getting messy, Flyway uses a
separate connection with a careful
SELECT ... FOR UPDATE for locking the metadata table to ensure consistency.
To address this situation we have now introduced a new
single connection mode in combination with PostgreSQL advisory locks.
Now only a single connection is being used for both
managing the metadata table and applying migrations while preserving the concurrent migration capabilities we already had,
while at the same time enabling support for all non-transactional PostgreSQL statements, including
CREATE INDEX CONCURRENTLY.
From an end-user perspective all of this is fully transparent. Migrating a PostgreSQL database has never been easier!
When running in a cluster MySQL supports two types of replication: statement-based and row-based.
Flyway has always worked great with row-based replication. However starting with MySQL 5.6, MySQL statement-based
replication has started producing warnings due to Flyway's use of MySQL's
USER() function to record
the name of the current user in the metadata table. The reason for those warnings is that this could produce different
results on separate nodes.
To prevent this, Flyway has now introduced a new
installedBy setting allowing you to avoid the use
USER() function by manually overriding the name of the database user being recorded.
For projects that have been using Flyway for a long time and have accumulated thousands of migrations, migrating to new versions would take longer and longer due to Flyway re-reading the metadata table every time. This then meant more and more records had to be returned over time. While never an issue for smaller deployments, this certainly started to become a burden for larger projects.
Starting with Flyway 4.1.0 we have introduced a new careful metadata table caching mechanism that provides identical performance when applying thousands of migrations, all the way from the first to the last.
While Flyway has always worked great with multiple application nodes by using careful
SELECT ... FOR UPDATE
metadata table locking to ensure consistency, this didn't work as well for a completely empty database where there
were no records to lock or where not even the metadata table (or the schema!) had already been created.
Flyway 4.1.0 now comes with a number of internal implementation and retry strategies to ensure this now also works cleanly in all cases.
The improvements outlined above are by far not the only ones part of this release. Here are a few more:
Enjoy Flyway 4.1.0 and grab it while it's hot!
It is the fastest, most complete and most reliable Flyway release so far. All users are encouraged to upgrade.
P.S.: Spread the word, follow @flywaydb on Twitter and subscribe to our monthly newsletter below to be notified about updates.