JUG Hannover: Datenbank Schemaänderungen mit Zero Downtime

Seit Kubernetes ist es einfach geworden, neue Versionen eines Microservices ohne Downtime zu deployen.
Refactorings gehören dabei zum alltäglichen Handwerk eines Entwicklers. Im Datenbankumfeld wird aber bereits die Umbenennung eines Feldes zur Herausforderung.
Wann ist der richtige Zeitpunkt zur Schemaänderung?
Denn entweder kann die alte oder die neue Version des Services nicht mit dem neuen Schema arbeiten.

Also doch wieder im Wartungsfenster den Microservice herunter fahren und die Datenbank migrieren? Oder einen Read-only Modus in den Service einbauen, um so den potentiellen Datenverlust zu vermeiden?

Nicht nötig, denn in diesem Talk werden Rezepte vorgestellt, eine Schemaänderung ohne Downtime oder Datenverlust zu meistern.

Es wird gezeigt, wie Datenbankmigrationen getestet werden können.

Dabei wird der Talk durch Beispiele und Fallstricke aus der Praxis veranschaulicht.

Transcript

1. DATENBANK SCHEMAÄNDERUNGEN MIT ZERO DOWNTIME JAVA FORUM NORD 2019 PREVIEW@JUG HANNOVER
2. MOTIVATION WARUM ZERO DOWNTIME DEPLOYMENTS? ▸ Anforderungen der Kunden gestiegen ▸ Internationales Geschäft braucht 24/7 ▸ Manchmal auch, weil es „modern“ ist
3. MOTIVATION WARUM SCHEMA ÄNDERUNGEN ▸ Code refactoring alltäglich ▸ Änderungen durch wachsende Anforderungen ▸ Unterschiede zwischen Modell und Datenbank klein halte ▸ Insbesondere im Support ein Problem
4. GRUNDSÄTZLICHES ▸ Probleme sind technologieunabhängig ▸ Schemalose Datenbanken ebenfalls betroffen ▸ Datenbank wird genau von einer Applikation genutzt!
5. WIE FUNKTIONIERT ZERO DOWNTIME?
6. WIE FUNKTIONIERT ZERO DOWNTIME? LOADBALANCER 1.0 1.0 1.0
7. WIE FUNKTIONIERT ZERO DOWNTIME? LOADBALANCER 1.0 1.0 1.0 1.1
8. WIE FUNKTIONIERT ZERO DOWNTIME? LOADBALANCER 1.0 1.0 1.1
9. WIE FUNKTIONIERT ZERO DOWNTIME? LOADBALANCER 1.0 1.1 1.0 1.1
10. WIE FUNKTIONIERT ZERO DOWNTIME? LOADBALANCER 1.0 1.1 1.1
11. WIE FUNKTIONIERT ZERO DOWNTIME? LOADBALANCER 1.0 1.1 1.1 1.1
12. WIE FUNKTIONIERT ZERO DOWNTIME? LOADBALANCER 1.1 1.1 1.1
13. WELCHE FEHLER KÖNNEN PASSIEREN? ▸ Fehler in alter Version nach Schemaänderung ▸ Datenverlust durch lost updates ▸ Gefährlich, da oft nicht erkannt
14. WELCHE SCHEMAÄNDERUNGEN GIBT ES? ▸ Spalten hinzufügen ▸ Spalten löschen ▸ Spaltennamen ändern ▸ Constraints ändern ▸ Typen ändern ▸ [Enums ändern]
15. WELCHE ÄNDERUNGEN KÖNNEN WIR OHNE RISIKO DURCHFÜHREN?
16. KEINE!
17. WAS SOLLTE ICH BERÜCKSICHTIGEN? ▸ Falls Zero Downtime nicht wirklich notwendig ist: Wartungsfenster nutzen, um Datenbankänderungen zu machen! ▸ Werkzeug benutzen, um Schemaänderungen automatisiert durchzuführen ▸ Schemaänderungen mit Sourcecode versionieren ▸ Jede Datenbankänderungen auf produktionsnahen Stages und auf Produktion in gleicher Reihenfolge durchführen ▸ Möglichst häufig kleine Änderungen
18. WAS SOLLTE ICH BERÜCKSICHTIGEN? ▸ Jedes Schema muss zur Version vor und nach der Änderung passen! 1.0 1.1 SCHEMA 1.0 SCHEMA 1.1 SCHEMAÄNDERUNG
19. SPALTEN HINZUFÜGEN ▸ Risiken: ▸ Änderungen, die in neuer Version passieren, können durch alte Version verloren gehen ▸ Lösung: ▸ Neue Spalten erst benutzen, wenn die alte Version nicht mehr aktiv ▸ Durch Feature-Flags oder zwei Versionen
20. SPALTEN LÖSCHEN ▸ Risiken: ▸ Alte Version versucht in gelöschte Spalten zu schreiben ▸ Lösung: ▸ Spalten erst löschen, wenn diese nicht mehr genutzt werden
21. SPALTEN UMBENENNEN ▸ Risiken: ▸ Datenverluste durch neue und alte Versionen möglich ▸ Alte Version kann nicht mehr schreiben ▸ Lösung:
23. POINT OF NO RETURN
24. CONSTRAINTS ÄNDERN ▸ Risiken ▸ Alte Version verletzt Constraint ▸ Alte Version erwartet Daten, die diese Bedingung erfüllen ▸ Lösung: ▸ Constraint erst einführen oder löschen, wenn Vorgängerversion diese Änderung erfüllen kann bzw. erwartet
25. TYP ÄNDERN ▸ Risiken ▸ Alte Version erfüllt Typ nicht ▸ Alte Version erwartet Daten von anderem Typ ▸ Lösung: ▸ Typ erst ändern, wenn alte Version diese verarbeiten kann ▸ Bei komplexen Änderungen ähnlich wie bei Umbenennung vorgehen!
26. ENUM ÄNDERN ▸ Risiken ▸ Alte Version kennt Wert eines hinzugefügten Enums nicht ▸ Neue Version kennt Wert eines alten Enums nicht ▸ Lösung: ▸ Enum erst benutzen, wenn alte Version damit umgehen kann ▸ Enum erst löschen, wenn sicher nicht mehr verwendet ▸ Enums fehlertolerant mappen
27. UND WAS IST MIT KOMPLEXEREN ÄNDERUNGEN?
28. KOMPLEXE ÄNDERUNGEN
29. KOMPLEXE ÄNDERUNGEN ÄHNLICHES VORGEHEN WIE NAMEN EINER SPALTE ÄNDERN!
30. KOMPLEXE ÄNDERUNGEN ÄHNLICHES VORGEHEN WIE NAMEN EINER SPALTE ÄNDERN! POINT OF NO RETURN
31. KOMPLEXE ÄNDERUNGEN ▸ Neue Tabelle/Collection erstellen ▸ Mapping zwischen alter und neuer Struktur definieren ▸ Script zur Migration der Daten schreiben ▸ Daten nur migrieren, falls noch nicht im Ziel vorhanden ▸ Script muss nicht schnell laufen
32. TESTEN ▸ Migrationskonzept durch Team infrage stellen lassen ▸ Mapper durch Property Based Testing prüfen ▸ Zufälliges Objekt mappen und wieder zurück ▸ v1 -> v2 -> v1’ ▸ v1 == v1’ ▸ Verifikationsschritt nach Migration (Wir haben Zeit!) ▸ Lasttest, um sicher zu gehen, dass das Zero Downtime Deployment wirklich keinen Datenverlust oder andere Fehler verursacht ▸ Aussagekräftige Alerts definieren (immer eine gute Idee)
33. NOCH FRAGEN?
34. KONTAKT ▸ Twitter: @Paderhesse ▸ Mail: carsten@carstenbirkelbach.de ▸ Folien unter: https://speakerdeck.com/cbirkelbach