Warum Sie Datenbank-Migrationen immer zuerst trocken testen sollten, bevor Sie echte Daten berühren

Sie haben ein Migrationsskript geschrieben. Es sieht korrekt aus. Die Logik stimmt. Sie führen es auf der Staging-Umgebung aus, und alles läuft durch. Aber wenn Sie es in der Produktion ausführen, geht etwas schief. Vielleicht schlägt eine Spalten-Constraint fehl. Vielleicht taucht eine Fremdschlüsselverletzung auf. Vielleicht dauert die Migration 45 Minuten statt der erwarteten 5, sperrt eine kritische Tabelle und verursacht eine Kaskade von Timeouts in Ihrer Anwendung.

Dieses Szenario ist häufig. Und es ist vermeidbar. Die Technik ist einfach: Führen Sie einen Dry-Run Ihrer Migration durch, bevor Sie sie jemals echte Daten berühren lassen.

Was ein Dry-Run tatsächlich bewirkt

Ein Dry-Run ist genau das, wonach es klingt. Sie führen Ihr Migrationsskript aus, aber Sie committen die Änderungen nie. Es werden keine Tabellen verändert. Keine Zeilen verschoben. Keine Spalten gelöscht. Sie prüfen lediglich, ob das Skript fehlerfrei läuft, und falls es Probleme gibt, erfahren Sie davon, bevor Daten betroffen sind.

Der gängigste Weg, dies zu tun, ist, Ihre Migration in eine Datenbanktransaktion zu packen und sie mit ROLLBACK statt COMMIT zu beenden. Wenn Sie ein Skript haben, das eine neue Spalte hinzufügt und sie aus einer anderen Tabelle befüllt, packen Sie das Ganze in BEGIN TRANSACTION ... ROLLBACK. Wenn während der Ausführung ein Fehler auftritt, bricht die Transaktion automatisch ab, und die Datenbank kehrt in ihren ursprünglichen Zustand zurück. Wenn kein Fehler auftritt, führen Sie den Rollback trotzdem manuell durch. Sie wollen die Änderung nicht anwenden. Sie suchen nach der Bestätigung, dass das Skript gültig ist.

Hier ist ein konkretes Beispiel, wie das in SQL aussieht:

BEGIN TRANSACTION;

-- Beispiel-Migration: neue Spalte hinzufügen und befüllen
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP;

UPDATE users
SET last_login_at = NOW()
WHERE last_login_at IS NULL;

-- Überprüfen, ob die Daten korrekt aussehen, bevor der Rollback erfolgt
SELECT id, email, last_login_at FROM users LIMIT 10;

-- Transaktion rückgängig machen, Datenbank bleibt unverändert
ROLLBACK;

Was ein Dry-Run Ihnen über Syntaxfehler hinaus verrät

Die Überprüfung auf Syntaxfehler oder Constraint-Verletzungen ist der offensichtliche Vorteil. Aber ein Dry-Run liefert Ihnen viel mehr nützliche Informationen.

Sie können sehen, wie lange die Migration dauern wird. Sie können sehen, wie viele Zeilen betroffen sein werden. Sie können sehen, ob die Migration Tabellen sperrt und wie lange. Dies sind kritische Informationen, insbesondere wenn Ihre Migration auf eine Produktionsdatenbank abzielt, die Tausende von Anfragen pro Sekunde verarbeitet. Wenn Ihr Dry-Run zeigt, dass die Migration 30 Minuten dauern wird und während dieser Zeit die Haupttabelle gesperrt ist, wissen Sie, dass Sie eine andere Strategie benötigen. Vielleicht führen Sie die Migration außerhalb der Hauptgeschäftszeiten durch. Vielleicht verwenden Sie eine Online-Migrationstechnik, die lange Sperren vermeidet. Vielleicht teilen Sie die Migration in kleinere Batches auf.

Ohne einen Dry-Run raten Sie nur. Mit einem Dry-Run haben Sie Daten, um eine fundierte Entscheidung zu treffen.

Wo Sie Ihren Dry-Run durchführen sollten

Der ideale Ort ist eine Staging-Umgebung mit Daten, die der Produktion sehr nahe kommen. Aber nicht jedes Team hat eine Staging-Datenbank mit realistischer Datenmenge. Wenn das bei Ihnen der Fall ist, erstellen Sie einen Snapshot der Produktionsdaten zu einem bestimmten Zeitpunkt und laden Sie ihn in eine separate Datenbank. Dieser Snapshot sollte niemals für echte Transaktionen verwendet werden, aber er ist gut genug, um Ihre Migration zu testen.

Einige Teams gehen noch weiter und automatisieren Dry-Runs. Jedes Mal, wenn sich ein Migrationsskript in einem Pull Request ändert, führt ein CI-Job den Dry-Run automatisch durch. So werden Probleme erkannt, bevor der Code überhaupt gemergt wird. Es ist eine kleine Investition, die später erheblich Debugging-Zeit spart.

Wie man Dry-Run-Ergebnisse liest

Eine saubere Ausgabe ohne Fehler und Warnungen ist beruhigend. Aber hören Sie hier nicht auf. Gehen Sie die Logs sorgfältig durch.

Achten Sie auf Zeilen, die nicht befüllt werden konnten, weil die Daten nicht zum neuen Spaltentyp passten. Achten Sie auf Indexkonflikte. Achten Sie auf Fremdschlüsselverletzungen. Manchmal ist ein Dry-Run technisch erfolgreich, scheitert aber logisch. Zum Beispiel könnten die verschobenen Daten leer sein, weil Ihre WHERE-Klausel falsch war. Das Skript lief einwandfrei. Keine Fehler. Aber das Ergebnis ist nutzlos.

Um dies zu erkennen, führen Sie nach Abschluss des Dry-Runs eine SELECT-Abfrage aus, um den Inhalt der geänderten Tabelle so zu überprüfen, als ob die Migration tatsächlich stattgefunden hätte. Sie können dies innerhalb derselben Transaktion tun, bevor Sie den Rollback durchführen. Öffnen Sie eine separate Sitzung, führen Sie die Migration innerhalb einer Transaktion aus, und fragen Sie vor dem Rollback die geänderten Tabellen ab, um die Korrektheit der Daten zu bestätigen. Dieser zusätzliche Schritt verwandelt einen Dry-Run von einer Syntaxprüfung in eine Logikprüfung.

Was ein Dry-Run nicht garantieren kann

Ein Dry-Run ist keine Garantie dafür, dass die Migration in der Produktion reibungslos läuft. Einige Faktoren können nicht vollständig repliziert werden. Die gleichzeitige Abfragelast wird anders sein. Die Datenmenge kann viel größer sein. Das Timing von Sperren kann sich verschieben. Aber ein Dry-Run reduziert Überraschungen. Wenn Sie die Migration in einer Umgebung getestet haben, die der Produktion nahe kommt, und die Ergebnisse Ihren Erwartungen entsprechen, können Sie die echte Migration mit viel höherer Zuversicht durchführen.

Praktische Checkliste vor der Durchführung einer Migration

Bevor Sie eine Migration durchführen, die Produktionsdaten berührt, gehen Sie diese kurze Liste durch:

• Packen Sie die Migration in eine Transaktion und führen Sie sie mit ROLLBACK aus
• Überprüfen Sie die Ausführungszeit und die Sperrdauer
• Verifizieren Sie, dass die Anzahl der betroffenen Zeilen den Erwartungen entspricht
• Fragen Sie die geänderten Tabellen innerhalb der Transaktion ab, um die Datenkorrektheit zu bestätigen
• Überprüfen Sie die Logs auf Constraint-Verletzungen, Indexkonflikte oder Typkonflikte
• Wenn die Migration zu lange dauert oder zu stark sperrt, planen Sie eine alternative Strategie

Die konkrete Erkenntnis

Ein Dry-Run ist kein zusätzlicher Schritt. Es ist der Schritt, der ein selbstbewusstes Deployment von einem stressigen unterscheidet. Führen Sie Ihre Migration in einer Transaktion aus. Machen Sie einen Rollback. Überprüfen Sie die Ergebnisse. Dann entscheiden Sie, ob Sie bereit sind zu committen. Ihre Produktionsdaten werden es Ihnen danken.