Migrations-Review

Das Problem

Migrationen sind die risikoreichsten Aenderungen in jedem System. Eine Schemamigration, die eine NOT-NULL-Spalte ohne Default hinzufuegt, sperrt die Tabelle und scheitert an bestehenden Zeilen. Eine Spaltenumbenennung bricht jede Abfrage, die den alten Namen referenziert — einschliesslich derer auf Servern, die noch nicht aktualisiert sind. Und wenn etwas schiefgeht, bedeutet “einfach zurueckrollen” oft Datenverlust.

Der Prompt

Pruefe die folgende Migration auf Sicherheit und Zero-Downtime-Deployment. Handle als Datenbank-Reliability-Engineer.

DATENBANK: [PostgreSQL / MySQL / MongoDB]
TABELLENGROESSE: [z.B. 50M Zeilen in users, 200M Zeilen in events]
DEPLOYMENT: [z.B. Rolling Deployment, Blue/Green, Single Server]
ORM: [z.B. Prisma, Knex, Django, Alembic, rohes SQL]

MIGRATIONSCODE:
[Migrationsdatei(en) einfuegen]

ANWENDUNGSCODE-AENDERUNGEN:
[Code, der sich zusammen mit der Migration aendert]

Bewerte in diesen Dimensionen:

1. **Rueckwaertskompatibilitaet**
   - Kann der alte Anwendungscode mit dem neuen Schema arbeiten?
   - Kann der neue Anwendungscode mit dem alten Schema arbeiten?
   - Werden Spalten-/Tabellenumbenennungen als Hinzufuegen → Migrieren → Loeschen durchgefuehrt?

2. **Lock-Analyse**
   - Wird eine Operation einen exklusiven Tabellen-Lock erwerben?
   - Wie lange wird die Migration bei 50M+ Zeilen dauern?
   - Sind grosse Datenaktualisierungen in Batches aufgeteilt?

3. **Rollback-Sicherheit**
   - Gibt es eine down() / Rollback-Migration?
   - Ist der Rollback sicher (verliert er Daten)?
   - Sind destruktive Operationen (DROP COLUMN) in eine Bereinigungsmigration verschoben?

4. **Datenintegritaet**
   - Werden Defaultwerte fuer neue NOT-NULL-Spalten bereitgestellt?
   - Sind Datentransformationen idempotent (sicher mehrfach ausfuehrbar)?
   - Werden Foreign-Key-Constraints nach dem Backfill hinzugefuegt?

5. **Performance-Auswirkung**
   - Wird die Migration Connection-Pool-Erschoepfung verursachen?
   - Werden Index-Erstellungen mit CONCURRENTLY (PostgreSQL) durchgefuehrt?

Fuer jedes Problem liefere:
- **Schritt**: Welcher Teil der Migration
- **Risiko**: Was in Produktion schiefgeht
- **Schweregrad**: Downtime / Datenverlust / Performance / Sicherheit
- **Fix**: Sichere Migrationsstrategie mit Code

Beispielausgabe

## Migrations-Review: 3 kritische Probleme

### Downtime-Risiko: ALTER TABLE mit NOT NULL auf 50M Zeilen
Code: `ALTER TABLE users ADD COLUMN phone VARCHAR(20) NOT NULL`
Risiko: Schreibt gesamte Tabelle um. Exklusiver Lock fuer 5-15 Minuten.
Fix (3-Phasen sichere Migration):
  -- Phase 1: Nullable Spalte hinzufuegen (sofort, kein Lock)
  ALTER TABLE users ADD COLUMN phone VARCHAR(20);
  -- Phase 2: In Batches auffuellen (kein Lock)
  UPDATE users SET phone = 'unbekannt' WHERE phone IS NULL AND id BETWEEN $1 AND $2;
  -- Phase 3: NOT NULL setzen
  ALTER TABLE users ALTER COLUMN phone SET NOT NULL;

### Datenverlust: Spaltenumbenennung ohne Uebergangsphase
Code: `ALTER TABLE orders RENAME COLUMN total TO total_cents`
Risiko: Alte Server referenzieren noch `total`. Alle Abfragen schlagen fehl.
Fix: Expand/Contract-Pattern verwenden.

Wann verwenden

Bei jeder Migration vor dem Staging-Einsatz ausfuehren, besonders bei Tabellen mit mehr als 1M Zeilen. Kritisch fuer Teams mit Rolling Deployments, bei denen alter und neuer Code koexistieren muessen.

Profi-Tipps

• Immer Tabellengroessen angeben — eine Migration, die bei 1.000 Zeilen sicher ist, kann bei 10.000.000 katastrophal sein.
• Auf produktionsnaher Kopie testen — “Generiere einen Testplan, der diese Migration auf einer Datenbank mit realistischem Datenvolumen validiert.”
• Destruktive Aenderungen phasenweise — nie Umbenennen, Loeschen und Hinzufuegen in derselben Migration.
• Runbook anfordern — “Generiere ein Schritt-fuer-Schritt-Runbook fuer die Produktionsausfuehrung dieser Migration, inklusive Rollback-Trigger.”