Suche
Datenbankmigration

Flyway 4.1.0 vereinfacht Datenbankmigration weiter

Melanie Feldmann

© Shutterstock / doobiz

Flyway 4.1.0 vereinfacht die Datenbankmigration für PostgreSQL und MYSQL. Bei der einen Datenbank machen nicht-transaktionale Statements kein Problem mehr, bei der anderen tauchen bei Replikaten jetzt keine Warnungen mehr auf. Außerdem aktualisieren sich große Projekte mit mehreren tausend Migrationen nun schneller.

Flyway ist ein Open Source Datenbankmigrations-Tool, mit dem sich Migrationen in SQL oder Java schreiben lassen. Flyway unterstützt rund 20 Datenbanken: darunter Oracle, SQL Server und jetzt neu EnterpriseDB. Außerdem neu in der aktuellen Version sind die Unterstützung von nicht-transaktionalen Statements in PostgreSQL, verbesserte Unterstützung für MySQL-Replikate und Performanceverbesserungen.

Nicht-transaktionale PostgreSQL-Statements unterstützt

Obwohl PostgreSQL DDL-Transaktionen unterstützt, gibt es einige Statements wie CREATE INDEX CONCURRENTLY, ALTER TYPE … ADD VALUE und VACUUM, die nicht innerhalb einer Transaktion laufen können. Flyway 4.1.0 bringt zwei große Verbesserungen, die es ermöglichen diese Statements transparent durchzuführen. Flyway erkennt nun automatisch, ob ein nicht-transaktionales Statement in einer Migration vorkommt.  Wenn dem so ist, läuft die komplette Migration ohne Transaktionen ab und wird in den Logs deutlich gekennzeichnet.  Um zu verhindern, dass sich transaktionale und nicht-transaktionale Statements innerhalb einer Migration vermischen, gibt es den neuen allowMixedMigrations-Parameter. Wenn er deaktiviert ist, wirft Flyway in diesen Fällen einen Fehler aus.

Dies hilft aber nicht bei CREATE INDEX CONCURRENTLY, weil Flyway auch die Migration von Datenbanken verschiedener Applikation-Nodes parallel erlaubt. Damit das Ganze nicht unübersichtlich wird, nutzt Fylway einen separate Verbindung mit SELECT … FOR UPDATE, um die Metadatentabelle zu sperren und so Konsistenz herzustellen. Dafür gibt es nun den Single Connection Mode in Kombination mit PostgreSQL Advisory Locks. Es wird nur noch eine einzige Verbindung genutzt, um die Metadatentabelle zu managen und die Migration durchzuführen.

Lesen Sie auch: Die Highlights der Graphdatenbank Neo4j 3.0

Keine Problemen mehr mit MySQL-Replikaten

Wenn MySQL in einem Cluster läuft, unterstützt es zwei Arten von Typen für Replikate: Statement-basiert und Zeilen-basiert. Seit MySQL 5.6 führten Zeilen-basierte Replikate zu Warnungen, weil Flyway MySQLs USER()-Funktion dazu genutzt hat, den Namen des aktuellen Nutzers in der Metadatentabelle zu speichern. Das konnte zu verschiedenen Ergebnissen in unterschiedlichen Nodes führen. Um das zu verhindern, nutzt Fylway nun installedBy.

Performance verbessert

Für Projekte, die Flyway bereits länger benutzen, sammeln sich über Zeit tausende von Migrationen an. Die Migration auf neuere Versionen wird dann eine zeitraubende Angelegenheit, da Flyway die Metadatentabelle jedes Mal erneut lesen muss. Mit Flyway 4.1.0 kommt einer neuer Caching-Mechanismus für die Metadatentabellen, der für hohe Performance auch bei vielen Migrationen sorgt.

Parallele Migration von leeren Datenbanken läuft fehlerfrei

Flyway funktioniert auch mit mehreren Applikations-Nodes reibungslos, da es mit SELECT … FOR UPDATE Metadatentabellen sperrt, um so für Konsistenz zu sorgen. Das klappt aber nicht für leere Datenbanken, in denen es keine Einträge zum Sperren gibt, oder wo noch keine Metadatentabelle oder ein Schema erstellt wurde. Mit Flyway 4.1.0 ist dies nicht mehr länger ein Problem.

Mehr Infos finden sich in den Release Notes und in einem Blogpost zum Release.

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.