TOC

Datenbankmigrationen mit Flyway

Datenbankmigrationen mit Flyway

1. Einführung

Dieser Artikel beschreibt die Schlüsselkonzepte vonFlyway und wie wir dieses Framework verwenden können, um das Datenbankschema unserer Anwendung zuverlässig und einfach kontinuierlich umzugestalten. Am Ende präsentieren wir ein Beispiel für die Verwaltung einer In-Memory-H2-Datenbank mit einem Maven Flyway-Plugin.

Flyway aktualisiert eine Datenbank mithilfe von Migrationen von einer Version zur nächsten. Wir können Migrationen entweder in SQL mit datenbankspezifischer Syntax oder in Java für erweiterte Datenbanktransformationen schreiben.

Migrationen können versioniert oder wiederholbar sein. Ersteres hat eine eindeutige Version und wird genau einmal angewendet. Letzteres hat keine Version. Stattdessen werden sie bei jeder Änderung der Prüfsumme (erneut) angewendet.

Innerhalb eines einzelnen Migrationslaufs werden wiederholbare Migrationen immer zuletzt angewendet, nachdem ausstehende versionierte Migrationen ausgeführt wurden. Wiederholbare Migrationen werden in der Reihenfolge ihrer Beschreibung angewendet. Bei einer einzelnen Migration werden alle Anweisungen in einer einzelnen Datenbanktransaktion ausgeführt.

In diesem Artikel konzentrieren wir uns hauptsächlich darauf, wie wir das Maven-Plugin verwenden können, um Datenbankmigrationen durchzuführen.

2. Flyway Maven Plugin

Um ein Flyway Maven-Plugin zu installieren, fügen Sie Ihrenpom.xml: die folgende Plugin-Definition hinzu 


    org.flywaydb
    flyway-maven-plugin
    4.0.3

Sie können die neueste Version des Plugins überprüfen, die aufMaven repository verfügbar ist.

Dieses Maven-Plugin kann auf vier verschiedene Arten konfiguriert werden. Eine Liste aller konfigurierbaren Eigenschaften finden Sie unterdocumentation.

2.1. Plugin-Konfiguration

Wir können das Plugin direkt mithilfe des<configuration>-Tags in der Plugin-Definition vonpom.xml: konfigurieren 


    org.flywaydb
    flyway-maven-plugin
    4.0.3
    
        databaseUser
        databasePassword
        
            schemaName
        
        ...

2.2. Maven Eigenschaften

Wir können das Plugin auch konfigurieren, indem wir konfigurierbare Eigenschaften als Mavenproperties inpom.xml: angeben 


    ...
    
        databaseUser
        databasePassword
        schemaName
        ...
    
    ...

2.3. Externe Konfigurationsdatei

Wir können die Plugin-Konfiguration auch in einer separaten.properties-Datei bereitstellen: 

flyway.user=databaseUser
flyway.password=databasePassword
flyway.schemas=schemaName
...

Der Standardname der Konfigurationsdatei lautetflyway.properties und sollte sich im selben Verzeichnis wie die Dateipom.xmlbefinden. Die Codierung wird durchflyway.encoding angegeben (Standard istUTF-8).

Wenn Sie einen anderen Namen (z. B.customConfig.properties) als Konfigurationsdatei verwenden, sollte dieser beim Aufrufen des Befehls Maven explizit angegeben werden: 

$ mvn -Dflyway.configFile=customConfig.properties

2.4. Systemeigenschaften

Schließlich können alle Konfigurationseigenschaften auch als Systemeigenschaften angegeben werden, wenn Maven in der Befehlszeile aufgerufen wird: 

$ mvn -Dflyway.user=databaseUser -Dflyway.password=databasePassword
  -Dflyway.schemas=schemaName

Das Folgende hat Vorrang, wenn eine Konfiguration auf mehrere Arten angegeben wird:

  1. Systemeigenschaften

  2. Externe Konfigurationsdatei

  3. Maven Eigenschaften

  4. Plugin-Konfiguration

3. Beispiel für eine Migration

In diesem Abschnitt werden die erforderlichen Schritte zum Migrieren eines Datenbankschemas in eine speicherinterne H2-Datenbank mithilfe des Maven-Plugins beschrieben. Wir verwenden eine externe Datei, um Flyway zu konfigurieren.

3.1. POM aktualisieren

Fügen Sie inpom.xml: eine entsprechende Datenbanktreiberabhängigkeit für die H2-Datenbank hinzu 


    com.h2database
    h2
    1.4.196

Sie können die neueste Version des Treibers überprüfen, die aufMaven repository verfügbar ist. Fügen Sie das Flyway-Plugin zupom.xml hinzu, wie in Abschnitt 2 oben erläutert.

3.2. Konfigurieren Sie Flyway mithilfe einer externen Datei

Erstellen Sie eine DateimyFlywayConfig.properties in$PROJECT_ROOT mit folgendem Inhalt: 

flyway.user=databaseUser
flyway.password=databasePassword
flyway.schemas=app-db
flyway.url=jdbc:h2:mem:DATABASE
flyway.locations=filesystem:db/migration

Die obige Konfiguration gibt an, dass sich unsere Migrationsskripte im Verzeichnisdb/migrationbefinden. Es stellt überdatabaseUser unddatabasePassword eine Verbindung zu einer speicherinternen H2-Instanz her.

Das Anwendungsdatenbankschema lautetapp-db. Bitte ersetzen Sieflyway.user, flyway.password, flyway.url durch Ihren Datenbankbenutzernamen, das Datenbankkennwort und den Datenbankhost / -port entsprechend.

3.3. Erste Migration definieren

Flyway befolgt die folgende Namenskonvention für Migrationsskripten:

<Prefix><Version>_ .sql_

Wo:

  • <Prefix> - Das Standardpräfix istV, das in der obigen Konfigurationsdatei mit der Eigenschaftflyway.sqlMigrationPrefix konfiguriert werden kann.

  • <Version> - Versionsnummer der Migration. Haupt- und Nebenversionen können durchunderscore getrennt sein. Die Migrationsversion sollte immer mit 1 beginnen.

  • <Description> - Textbeschreibung der Migration. Die Beschreibung muss durch einen doppelten Unterstrich von den Versionsnummern getrennt werden.

Beispiel:V1_1_0__my_first_migration.sql

Erstellen Sie ein Verzeichnisdb/migration in$PROJECT_ROOT mit einem Migrationsskript namensV1_0__create_employee_schema.sql, das SQL-Anweisungen zum Erstellen von z. ein Mitarbeitertisch: 

CREATE TABLE IF NOT EXISTS `employee` (

    `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `name` varchar(20),
    `email` varchar(50),
    `date_of_birth` timestamp

)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

3.4. Migrationen ausführen

Rufen Sie den folgenden Maven-Befehl von$PROJECT_ROOT auf, um Datenbankmigrationen auszuführen: 

$ mvn clean flyway:migrate -Dflyway.configFile=myFlywayConfig.properties

Dies sollte zu einer ersten erfolgreichen Migration führen. Das Datenbankschema kann nun wie folgt dargestellt werden: 

employee:
+----+------+-------+---------------+
| id | name | email | date_of_birth |
+----+------+-------+---------------+

Wiederholen Sie die Schritte aus den Unterabschnitten 3.3. und 3.4. neue Migrationen nach Belieben definieren und ausführen.

3.5. Definieren und Ausführen der zweiten Migration

Erstellen Sie eine zweite Migrationsdatei mit dem NamenV2_0_create_department_schema.sql, die die folgenden zwei Abfragen enthält: 

CREATE TABLE IF NOT EXISTS `department` (

`id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
`name` varchar(20)

)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

ALTER TABLE `employee` ADD `dept_id` int AFTER `email`;

Führen Sie eine ähnliche Migration durch, wie in Abschnitt 3.4 beschrieben. Das Datenbankschema sieht wie folgt aus, nachdem die zweite Migration erfolgreich ausgeführt wurde. 

employee:
+----+------+-------+---------+---------------+
| id | name | email | dept_id | date_of_birth |
+----+------+-------+---------+---------------+
department:
+----+------+
| id | name |
+----+------+

Wir können nun überprüfen, ob beide Migrationen tatsächlich erfolgreich waren, indem wir den folgenden Maven-Befehl aufrufen: 

$ mvn flyway:info -Dflyway.configFile=myFlywayConfig.properties

4. Wie Flyway funktioniert

Um zu verfolgen, welche Migrationen wann und von wem bereits angewendet wurden, wird Ihrem Schema eine spezielle Buchhaltungstabelle hinzugefügt. Diese Metadatentabelle protokolliert auch Migrationsprüfsummen und ob die Migrationen erfolgreich waren oder nicht.

Das Framework führt die folgenden Schritte aus, um sich entwickelnden Datenbankschemata Rechnung zu tragen:

  1. Es überprüft ein Datenbankschema, um seine Metadatentabelle zu finden (standardmäßigSCHEMA_VERSION). Wenn die Metadatentabelle nicht vorhanden ist, wird eine erstellt

  2. Es durchsucht einen Anwendungsklassenpfad nach verfügbaren Migrationen

  3. Es vergleicht Migrationen mit der Metadatentabelle. Wenn eine Versionsnummer kleiner oder gleich einer als aktuell markierten Version ist, wird sie ignoriert

  4. Verbleibende Migrationen werden als ausstehende Migrationen markiert. Diese werden nach Versionsnummer sortiert und der Reihe nach ausgeführt

  5. Bei jeder Migration wird die Metadatentabelle entsprechend aktualisiert

5. Befehle

Flyway unterstützt die folgenden grundlegenden Befehle zum Verwalten von Datenbankmigrationen.

  • Info: Gibt den aktuellen Status / die aktuelle Version eines Datenbankschemas aus. Es wird gedruckt, welche Migrationen anstehen, welche Migrationen angewendet wurden, wie der Status der angewendeten Migrationen ist und wann sie angewendet wurden.

  • Migrate: Migriert ein Datenbankschema auf die aktuelle Version. Es durchsucht den Klassenpfad nach verfügbaren Migrationen und wendet ausstehende Migrationen an.

  • Baseline: Basiert eine vorhandene Datenbank, ausgenommen alle Migrationen, einschließlichbaselineVersion. Baseline hilft, mit Flyway in einer vorhandenen Datenbank zu beginnen. Neuere Migrationen können dann normal angewendet werden.

  • Validate: Überprüft das aktuelle Datenbankschema anhand verfügbarer Migrationen.

  • Repair: Repariert die Metadatentabelle.

  • Clean: Löscht alle Objekte in einem konfigurierten Schema. Alle Datenbankobjekte werden gelöscht. Natürlich sollten Sie clean niemals für Produktionsdatenbanken verwenden.

6. Fazit

In diesem Artikel haben wir gezeigt, wie Flyway funktioniert und wie wir dieses Framework verwenden können, um unsere Anwendungsdatenbank zuverlässig umzugestalten.

Der diesem Artikel beigefügte Code ist fürGithub verfügbar.

Related