Developer-Centric SQL Migrations

Die hier beschriebene Situation erlebten wir in ähnlicher Form bereits in einigen Migrationsprojekten. Das Quellsystem ist eine Oracle-Datenbank, das Zielsystem eine PostgreSQL-Datenbank. Dabei wurde die Oracle Datenbank bisher im Wesentlichen als Datensenke betrachtet und enthält keine Geschäftslogik.

Die Datenbank wurde mittels ora2pg in ein Schema "Staging" in PostgreSQL migriert. Dieses Schema halten wir dabei in derselben Datenbank wie das spätere Zielschema.

Wir wählen diesen Ansatz, damit wir einfache SQL Abfragen zur Migration nutzen können. Alternativ kann es sinnvoll sein, das Staging-Schema in einer eigenen Datenbank, bzw. Datenbankcluster zu halten, um die Datenbanken zu entkoppeln. Wir nutzen Postgres Foreign Data Wrapper, um genauso einfach auf die Daten zuzugreifen. Dies erscheint sinnvoll, denn bei vielen Cloudanbietern kann der einmal zugewiesene Speicher nicht wieder einfach freigegeben werden. Liegt das Staging-Schema in einem eigenen Datnbankcluster, kann der gesamte Server einfach gelöscht werden.

Wir halten es für sinnvoll möglichst frühzeitig mit der Entwicklung der Migrationsskripte zu beginnen. Häufig stellen wir fest, dass die Altdaten Konstellationen enthalten, die man im zukünftigen Schema nicht mehr zulassen möchte. Dann stellt sich die Frage, wie mit den Altdaten umgegangen werden soll.

Migration und Re-Implementierung der Anwendung finden gleichzeitig statt. Dieser Umstand erweist sich als Glücksfall, denn die Migration sorgt so als Treiber für einen "Datenbank-First"-Ansatz. Für die Re-Implementierung ist hilfreich , dass wir bereits mit den Altdaten arbeiten. Dies liefert eine realistische Datenmenge, denn Abfragen auf leeren Tabellen sind stets schnell. Die Nutzung von Produktionsdaten zu Testzwecken ist dagegen ein anderes Thema.

Immer wenn sich das Zielschema ändert, müssen die Migrationsskripte angepasst werden. Die Migrationsskripte selbst sind von den Liquibase oder Flyway-Skripten getrennt.

Es gibt verschiedene Arten von Migrationen. In der Regel ist es sinnvoll bei IT-Systemen eine inkrementelle Migrationsstrategie zu verfolgen. Das kann bedeuten, dass Teile des IT-Systems jeweils in einem Schritt migriert werden (Big Bang). Eine performante Migration der Daten ist dann wichtig.

Beim Bulk-Load von Daten in eine PostgreSQL-Datenbank oder zwischen Tabellen gibt es einiges zu beachten. Ähnliches gilt auch für andere Datenbanken.

Angelehnt an die Liste von EDB sind folgende Punkte wichtig für unser Szenario (PostgreSQL → PostgreSQL mittels SQL):

Dann werden die Daten mittels SQL Skripten geladen. Und dann werden die Indizes, Constraints, Triggers und Foreign Keys wiederhergestellt. Zum Abschluss sollte ein Analyze ausgeführt werden.

Wird die Anwendung neu entwickelt, so ändert sich das Zielschema. Dabei sind insbesondere die Änderungen an den Zieltabellen interessant.

Es ist wichtig, dass diese Änderungen entweder automatisch erkannt und berücksichtigt werden oder vor Ausführung der Skripte auffallen. Da die Laufzeiten für die Migrationen sehr lang sein können (Stunden bis Tage), müssen einfach Fehler vorab oder früh erkannt werden können. Sonst kann die (unbeobachtete) Probemigration erst nach vielen Stunden fehlschlagen und wird nicht abgeschlossen. Damit sind viele Stunden wertvoller Projektzeit verschwendet.

jOOQ generiert aus einem Datenbankschema ein Klassenmodell. Dieses beinhaltet Informationen über die gängigen Datenbankobjekte wie Tabellen, Spalten, Indizes, Constraints, Triggers und Foreign Keys. Mittels dieses Klassenmodells kann man dann einfach alle Indizes oder Constraints einer Tabelle entfernen oder neu erzeugen. Wenn wir dabei alle Tabellen mittels eines topologischen Sortieralgorithmus sortieren, dann können wir die Tabellen in der richtigen Reihenfolge behandeln. Dies gilt im Kontext dieses Blog-Post zumindest solange, wie der "Tabellengraph" keine Zyklen enthält. Damit vergessen wir keine Objekte zu löschen oder zu erzeugen, die im Rahmen der Weiterentwicklung noch entstehen oder gelöscht werden. Statt die Änderungen direkt anzuwenden, können wir uns das SQL ausgeben lassen und einsammeln. Im Beispiel gibt es aktuell keinen Schalter, die Skripte auch direkt gegen die Datenbank auszuführen. Generell sollten die Aktionen nicht vom Notebook eines Entwicklers ausgeführt werden, sondern von einem dedizierten Migrations-System (virtuelle Maschine). Wenn man die Migration manuell startet, sollte man darauf achten, dass dies unter einem Terminal-Multiplexer wie tmux oder screen geschieht, damit die Ausführung nicht abbricht, wenn der ausführende Benutzer die Verbindung beendet. Die Dauer der Migration hängt stark von der Größe der Datenbank ab. Selbst für einige kleine Datenbanken mit < 250 Mio Einträgen und mehreren Tabellen kann die Migration mehrere Stunden dauern. Bei größeren Migrationen ist sicherlich nochmal eine gesonderte Betrachtung notwendig, um Laufzeiten zu optimieren.

Das Beispielprojekt ist auf GitHub verfügbar. Eine etwas ausführlichere Dokumentation findet sich auf den zugehörigen Github Pages.

Wenn man eine neue Not-Null Spalte hinzufügt, dann wird nicht automatisch erkannt, dass in den Abfragen kein Wert für die Spalte bereitgestellt wird. Wer sich die Datenbankdefinition genau angesehen hat, wird feststellen, dass ein PostgreSQL-spezifisches Exclusion Constraint auf der Checkout Tabelle definiert ist. Dieses wurde vom Meta-Modell nicht erkannt und auch nicht in den Skripten berücksichtigt. Daher ist es immer noch wichtig, sich die generierten Skripte anzuschauen und ggf. zu prüfen und zu ergänzen. Gleiches gilt auch, wenn zyklische Abhängigkeiten zwischen Tabellen bestehen.

Auch wenn Änderungen nicht erkannt werden, ist die Nutzung von jOOQ für die Erstellung von Migrationsskripten sehr hilfreich und kann einige Fehlerquellen adressieren, die bei gleichzeitiger Entwicklungstätigkeit auftreten können, wenn das Zielschema nicht eingefroren ist. Notwendige Ergänzungen können im Code oder in den generierten Skripten vorgenommen werden.