Flyway – Einfache Datenbankmigration mit SQL und Java

Datenbankmigration?

Datenbankmigration ist keine besonders beliebte Aufgabe, denn ein Problem tritt immer wieder auf: Man hat eine neue Version einer Anwendung erstellt, auf den Server aufgespielt und die vorher aufgeschriebenen Änderungen am Datenbank-Schema durchgeführt. Trotzdem will die Anwendung nicht starten und füllt das Log mit SQL-Fehler. Hat man eine Änderung vergessen? War etwas nicht dokumentiert? Wurde etwas in der falschen Reihenfolge ausgeführt oder vielleicht neue Datensätze doppelt eingefügt? Und wie kommt man wieder auf einen funktionierenden Stand, egal ob alt oder neu, bevor die ersten wütenden Anrufe kommen?

Die Ursache dieses Problems ist eigentlich simpel: Die Datenbank hat keine Version. Deswegen ist häufig auch nicht klar auf welchem Stand sie aktuell ist und was geändert werden muss um sie auf den neuesten Stand zu bringen. Eine beliebte Lösung sind SQL-Skripte, entweder ein großes oder viele kleine, von denen man sich die benötigten aussucht und manuell ausführt. Wirklich zuverlässig ist das aber nicht, denn gerne wird eine Änderung übersehen, ein Skript vergessen oder doppelt ausgeführt. Und elegant oder einfach ist dieser Ansatz sowieso nicht. Bei nicht fachgerechter Ausführung, ist der Ansatz mit SQL-Skripten fehleranfällig.

Dabei gibt es bei Programmcode schon lange eine Lösung, die auch hier helfen würde: Versionierung. Ein Update von Version 1.0 auf 3.0? Kein Problem, man lässt einfach die Skripte für 1.5, 2.0 und 3.0 durchlaufen. Exakt diesen Ansatz bietet Flyway. Es kennt die momentane Version der Datenbank, die aktuellste verfügbare Version und die benötigten Änderungs-Skripte, die dann automatisch ausgeführt werden. Da es sehr leichtgewichtig ist und nur auf SQL und Java basiert, sind Einarbeitung und Integration in wenigen Stunden erledigt. Danach läuft die Datenbankmigration automatisch oder auf Knopfdruck ab und das mühsame Zusammensuchen von SQL-Skripten entfällt.

Flyway

Zum Download gibt es Flyway unter anderem als Kommandozeilen-Anwendung und als JAR das sich in eigene Anwendungen oder Build-Skripte einbinden lässt. Es kommt ohne externe Abhängigkeiten aus und braucht nur den passenden JDBC-Treiber, der aber meistens ja sowieso im Classpath verfügbar ist.

An Datenbanken wird alles wichtige unterstützt, von kommerziellen Schwergewichten wie Oracle, SQL Server oder DB2 über Open-Source-Alternative wie MySQL oder PostgreSQL bis hin zu kleineren Lösungen wie H2 oder Derby.

Eine Datenbankmigration lässt sich entweder über die Kommandozeile manuell anstoßen oder kann automatisch im Rahmen eines Build-Skripts oder beim Anwendungsstart ablaufen. Dank einer einfachen API sind hier beliebige eigene Lösungen machbar.

Funktionsweise

Die wichtigste Frage ist aber natürlich, wie Flyway funktioniert. Der gewählte Ansatz ist erstaunlich einfach und grenzt Flyway deutlich von schwergewichtigeren Datenbankmigrations-Tools wie Liquibase ab.

Alle benötigten Skripte, egal ob SQL oder Java, werden in einem Ordner gespeichert, der im Classpath verfügbar sein muss. Flyway durchsucht dann automatisch diesen Order sowie dessen Unterordner und merkt sich die gefundenen Skripte. Damit Flyway erkennen kann zu welcher Version ein Skript gehört, muss ein einfaches Namensschema eingehalten werden:

Flyway Namensschema

Neben einigen festen Elementen (Präfix, Trennzeichen und Suffix) enthält ein Skript-Name zwei wichtige Informationen: Version und Beschreibung. Letztere ist in erster Linie für andere Entwickler interessant und beschreibt was im Skript passiert. Wichtig für Flyway ist hingegen die Versions-Information. Anhand dieser Nummer werden die für ein Update notwendigen Skripte erkannt, die Skripte sortiert und am Ende die Versionsnummer in den Metadaten der Datenbank gespeichert. Flyway unterstützt dabei eine beeindruckende Menge an Schreibweisen und hat auch mit Konstruktionen wie 2.4.12.1b keine Probleme.

Die aktuelle Versionsnummer eines Datenbankschemas wird zusammen mit weiteren Metainformationen im Schema selbst gespeichert. Dazu legt Flyway sich eine eigene Tabelle SCHEMA_VERSION an.

SQL- und Java-Skripte

Die SQL-Skripte dürfen fast beliebigen SQL-Code enthalten. Die einzelnen Statements können dabei über eine oder mehrere Zeilen gehen, Hauptsache sie enden mit einem Semikolon. Eine Ausnahme sind Stored Procedures, diese müssen je nach Datenbank mit den üblichen Schlüsselwörtern beginnen und enden. Auch ein (–) oder mehrzeilige (/* … */) Kommentare sind kein Problem.

Zusätzlich können die SQL-Skripte Platzhaltern verwenden. Diese werden dann während der Datenbankmigration mit Werten aus einer Properties-Datei befüllt. Dadurch kann etwa das Test- andere Werte als das Produktivsystem verwenden.

Die Java-„Skripte“ sind nicht wirklich Skripte sondern ganz normale Klassen, die das Interface JdbcMigration implementieren. Dieses gibt eine einzige Methode vor, die eine JDBC-Connection als Parameter erhält und dann beliebige Aktionen ausführen darf. Dadurch sind auch Migrationsaktionen möglich, die mit SQL alleine nicht machbar wären. Beispielsweise Daten vom Dateisystem in BLOBs kopieren.

Nachteile und Einschränkungen

Vor allem im Vergleich mit ähnlichen Tools wie Liquibase fallen einige Nachteile von Flyway auf. Der größte ist sicher die fehlende Downgrade-Unterstützung. Einige andere Tools können nicht nur auf neuere Versionen aktualisieren sondern auch auf ältere Versionen zurückgehen, in dem sie Änderungen rückgängig machen. Liquibase verzichtet auf dieses Feature, da es in der Praxis ohnehin meistens nicht zuverlässig funktioniert. Destruktive Änderungen bei denen die gelöschten Daten unbekannt sind, etwa ein Tabelleninhalt, lassen sich eben nicht rückgängig machen. Eine gute Backupstrategie ist hier wichtiger als wackelige Migrations-Features.

Ein weiterer wichtiger Unterschied ist der Verzicht auf eine Abstraktionsschicht über SQL. Dadurch können Datenbankmigrationen mit Flyway nur durchgeführt werden, wenn die Skripte Standard-SQL enthalten. Sobald datenbankspezifische Erweiterungen verwendet werden, geht dies auf anderen Datenbanken natürlich schief. Eine abstraktere Sprache könnte natürlich in SQL umgesetzt werden das die jeweilige Zieldatenbank versteht. Liquibase verwendet hier etwa eine eigene DDL-Sprache. Andererseits hat der Verzicht auf dieses Feature auch einen entscheidenden Vorteil: es muss keine neue Sprache gelernt werden.

Fazit

Flyway ist ein einfaches, schlankes Tool das seine Aufgabe einwandfrei erledigt. Da es auf SQL, Java setzt ein schnell verständliches Konzept setzt, ist die Einarbeitung in wenigen Stunden erledigt. Allerdings hat die schlanke Strategie auch Nachteile: andere Tools bieten mehr fortgeschrittene Funktionen, sind dafür allerdings auch wesentlich komplizierter. In den meisten Fällen dürfte Flyway als simple und intelligente Lösung völlig ausreichen. Und besser als das sonst übliche Chaos mit manuellen Änderungsskripten ist es in jedem Fall.

Interesse?

Haben Sie Probleme mit ihrem aktuellen Datenbankmigrations-Prozess oder steht eine größere Migration bevor? Wir bieten Ihnen umfassende und professionelle Beratung!

Getagged mit: , , , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

* Copy This Password *

* Type Or Paste Password Here *