Checkliste Datenbankmigration
Checkliste Datenbankmigration für sichere Schemaänderungen: Sperren prüfen, Backup, Expand-and-Contract, Backfills in Batches und Prüfung nach jeder Migration.
- Typischer Rhythmus pro Schemamigration
- Die Checkliste 5 Abschnitte, 20 Punkte
- Variablen
{{database}}{{migration}} - Aus der CI starten
Diese Checkliste ist für jede Schemaänderung an einer Produktionsdatenbank gedacht: neue Tabellen oder Spalten, geänderte Datentypen, neue Indizes, umbenannte oder gelöschte Spalten und Daten-Backfills. Mit den optionalen Punkten passt sie auch für ein Upgrade der Datenbank-Engine. Sie geht von einer relationalen Datenbank wie PostgreSQL oder MySQL und einem Migrationswerkzeug wie Flyway, Liquibase, Alembic, Rails- oder Prisma-Migrationen aus, die Schritte sind aber werkzeugneutral.
Wer verantwortlich ist
Wer die Migration geschrieben hat, ist für den Durchlauf verantwortlich. Eine zweite Person mit Datenbankkenntnis prüft die Migration, bevor sie in Produktion läuft. Bei großen Tabellen bleibt die ausführende Person dabei, bis die Prüfschritte erledigt sind.
Typische Fehler
- Unerwartete Sperren. Manche Änderungen schreiben die Tabelle neu oder setzen eine exklusive Sperre, und alle Abfragen stauen sich dahinter. Das Sperrverhalten jedes Statements für die eigene Datenbankversion prüfen und ein Lock-Timeout setzen, damit eine blockierte Migration schnell abbricht, statt die Anwendung lahmzulegen.
- Umbenennen und Löschen in einem Schritt. Alter Code, der während des Deployments noch läuft, bricht. Expand and Contract nutzen: neue Spalte anlegen, Code deployen, der beide schreibt, Daten nachziehen, Lesezugriffe umstellen und die alte Spalte erst in einem späteren Release löschen.
- Backfills in einer Transaktion. Millionen Zeilen auf einmal zu ändern, verursacht lange Sperren und Replikationsverzug. In kleinen Batches nachziehen.
- Test auf einer leeren Datenbank. Eine Migration, die lokal eine Sekunde dauert, braucht auf Produktionsdaten womöglich eine Stunde. Auf einer aktuellen, anonymisierten Kopie testen.
Runbook kann den Durchlauf anlegen, sobald ein Pull Request eine Migration hinzufügt. So sind Review und Backup dokumentiert, bevor die Migration die Produktion erreicht.
Die Checkliste: Datenbankmigration {{database}}: {{migration}}
Review
-
Migration
{{migration}}von einer zweiten Person mit Kenntnis von{{database}}geprüft -
Jedes Statement auf Tabellen-Rewrites und exklusive Sperren auf großen Tabellen geprüft
Online-Optionen nutzen, wo die Datenbank sie bietet, etwa CREATE INDEX CONCURRENTLY in PostgreSQL oder Online-DDL-Werkzeuge für MySQL.
-
Änderung ist abwärtskompatibel mit der aktuell laufenden Anwendungsversion
Alter Code muss mit dem neuen Schema funktionieren, bis das Deployment abgeschlossen ist.
-
Destruktive Schritte (Drop, Rename, Typänderung) in ein späteres Release verschoben
-
Down-Migration oder schriftlicher manueller Rückweg vorhanden, oder begründet, warum keiner möglich ist
Testen
-
Migration läuft fehlerfrei auf einer aktuellen, anonymisierten Kopie der Produktionsdaten
-
Laufzeit auf dieser Kopie gemessen und im Durchlauf notiert
-
Anwendungstests laufen gegen das migrierte Schema grün
-
Upgrade der Datenbank-Engine auf geänderte Standardwerte und veraltete Funktionen getestet optional
Produktion vorbereiten
-
Frisches Backup oder Snapshot von
{{database}}erstellt und Zeitstempel notiert -
Lock-Timeout und Statement-Timeout für die Migrations-Session gesetzt
-
Migration außerhalb der Lastspitzen geplant, wenn sie große Tabellen betrifft
-
Ausreichend Speicherplatz für Index-Builds oder Tabellenkopien vorhanden
Ausführen
-
Migration
{{migration}}in Produktion ausgeführt und Ausgabe geprüft -
Replikationsverzug auf den Replikaten während und nach der Migration im akzeptablen Rahmen optional
-
Daten-Backfill läuft in Batches, Fortschritt wird verfolgt optional
Prüfen
-
Schema in Produktion entspricht dem erwarteten Stand, etwa Spalten, Indizes und Constraints
-
Fehlerrate der Anwendung und Slow Query Log zeigen keine neuen Probleme
-
Zeilenzahlen oder Prüfsummen der geänderten Tabellen entsprechen den Erwartungen
-
Folge-Ticket für den Contract-Schritt angelegt, der alte Spalten oder alten Code entfernt optional
Checkliste als Markdown
Diese Checkliste aus der Pipeline starten
Wenn ein Pull Request eine Migrationsdatei hinzufügt, POST /api/v1/runs mit der Vorlage "Datenbankmigration {{database}}: {{migration}}" und dem Dateinamen als migration aufrufen.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Datenbankmigration {{database}}: {{migration}}", "variables": {"database": "…", "migration": "…"}}'Häufige Fragen
Wie führt man eine Datenbankmigration ohne Downtime durch?
Jede Migration abwärtskompatibel zum laufenden Code halten und Statements vermeiden, die große Tabellen sperren. Für Umbenennungen und Löschungen das Expand-and-Contract-Muster nutzen, Indizes online aufbauen und Daten in Batches nachziehen. Dann lassen sich Code und Schema getrennt deployen und jeweils zurückrollen.
Braucht jede Migration eine Down-Migration?
Eine Down-Migration ist nützlich, aber nicht immer möglich, zum Beispiel nachdem Daten gelöscht wurden. Entscheidend ist, vor der Migration zu wissen, wie man sich erholt. Das kann ein Down-Skript sein, eine Wiederherstellung aus dem gerade erstellten Backup oder ein bereits geschriebener Forward-Fix.
Was ist der Unterschied zwischen Schemamigration und Datenbank-Upgrade?
Eine Schemamigration ändert die Struktur der eigenen Tabellen. Ein Datenbank-Upgrade ändert die Version der Engine, etwa eine neue Hauptversion von PostgreSQL oder MySQL. Upgrades bringen geänderte Standardwerte, veraltete Funktionen und neue Versionen von Erweiterungen mit sich. Deshalb zuerst auf einer Kopie testen und den Wechsel wie einen kleinen Go-Live planen.
Aktualisiert