Aufgabe 22 - Migration in zwei Phasen ohne Ausfall

Aufgabe 22 - Migration in zwei Phasen ohne Ausfall

Worum geht es?

Sie benennen eine Spalte in Ihrer laufenden Datenbank um, ohne dass die Anwendung dabei ausfällt und ohne dass ein Rollback unmöglich wird (siehe Kapitel Datenbank produktionsnah). Das sind vier Deployments für eine Umbenennung, und beim ersten Mal wirkt das übertrieben. Es ist das Verfahren, mit dem große Systeme ohne Wartungsfenster auskommen.

Was Sie dafür brauchen

• Kapitel Datenbank produktionsnah, Abschnitt Migrationen.
• Kapitel Auslieferung mit Containern, Abschnitt Rollback.
• Ihr Projekt aus Aufgabe 21 mit gefülltem Seed und der Vorschauumgebung aus Aufgabe 11.

Welche Kompetenzen Sie erwerben und zeigen

• Sie erstellen Migrationen, wenden sie im Deployment an und schneiden sie abwärtskompatibel.
• Sie führen eine Umbenennung als Zwei-Phasen-Änderung ohne Ausfall durch.
• Sie beurteilen, welche Schemaänderung ein Rollback überlebt und welche nicht.

Pädagogische Einordnung

• Reproduktion: eine additive Migration erstellen und anwenden (Teil A).
• Reorganisation und Transfer: den Bruch bei einer Umbenennung nachstellen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: die Umbenennung in vier Schritten durchführen und begründen (Teil C).

Alles in der Vorschau

Diese Übung läuft vollständig in der Vorschauumgebung aus Aufgabe 11. Vor jeder entfernenden Migration erstellen Sie eine Sicherung. Ein DROP COLUMN ist nicht rückgängig zu machen.

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Die einfache Migration

1. Erstellen Sie eine Migration, die eine neue Spalte mit Vorgabewert anlegt. Notieren Sie den Befehl und den Namen der entstandenen Datei.

2. Öffnen Sie die erzeugte Migrationsdatei und lesen Sie das SQL darin. Notieren Sie die Anweisung.

3. Wenden Sie die Migration in der Vorschauumgebung an. Notieren Sie den Befehl, der dort verwendet wird, und erklären Sie in zwei Sätzen, warum es ein anderer ist als der aus Punkt 1.

4. Prüfen Sie in psql mit \d auf Ihrer Tabelle, dass die Spalte da ist.

5. Starten Sie die vorige Anwendungsversion gegen das neue Schema, indem Sie ein Rollback durchführen. Beschreiben Sie in zwei bis drei Sätzen, warum sie weiterläuft.

6. Ordnen Sie fünf Änderungen danach ein, ob sie ein Rollback überleben, und begründen Sie jede in einem halben Satz: neue Tabelle, neue Spalte mit Vorgabewert, neue Spalte mit NOT NULL ohne Vorgabewert, neuer Index, entfernte Spalte.

Teil B - Den Bruch nachstellen

1. Benennen Sie eine Spalte in einem Zug um, also mit einer einzigen Migration, und liefern Sie die passende Anwendungsversion aus.

2. Führen Sie danach ein Rollback auf die vorige Anwendungsversion durch und rufen Sie die Anwendung auf. Notieren Sie die Fehlermeldung und den Statuscode, den ein Benutzer sieht.

3. Beschreiben Sie in vier bis fünf Sätzen, was hier schiefgegangen ist. Beantworten Sie dabei, was das Rollback zurückgeholt hat und was nicht.

4. Beschreiben Sie in zwei bis drei Sätzen den zweiten Moment, in dem dieselbe Migration Schaden anrichtet, nämlich die Sekunden während des Deployments, in denen alte und neue Version gleichzeitig laufen.

5. Stellen Sie den funktionierenden Zustand wieder her.

Teil C - Die Umbenennung in vier Schritten

Führen Sie jetzt dieselbe Umbenennung nach dem Verfahren aus dem Kapitel durch. Nach jedem der vier Schritte prüfen Sie zwei Dinge: Läuft die Anwendung? Und funktioniert ein Rollback auf die vorige Version?

1. Hinzufügen. Eine Migration legt die neue Spalte an, die alte bleibt. Die neue Anwendungsversion schreibt in beide Spalten und liest aus der neuen, falls gefüllt, sonst aus der alten. Liefern Sie aus und führen Sie beide Prüfungen durch.

2. Befüllen. Eine Migration kopiert die vorhandenen Werte in die neue Spalte. Prüfen Sie mit einer Abfrage, dass keine Zeile leer geblieben ist, und notieren Sie die Abfrage. Führen Sie beide Prüfungen durch.

3. Umstellen. Die nächste Version liest und schreibt nur noch die neue Spalte. Liefern Sie aus und führen Sie beide Prüfungen durch.

4. Entfernen. Erstellen Sie zuerst eine Sicherung. Erst dann entfernt eine Migration die alte Spalte. Führen Sie beide Prüfungen ein letztes Mal durch und notieren Sie, ab wann ein Rollback auf Schritt 2 nicht mehr in Frage kommt.

5. Legen Sie eine Tabelle mit vier Zeilen an, eine je Schritt, mit den Spalten Schritt, Migration, Anwendungsversion, Rollback möglich auf. Füllen Sie sie aus.

6. Beurteilen Sie in vier bis fünf Sätzen den Aufwand. Vergleichen Sie vier Deployments mit der Alternative, nämlich einem Wartungsfenster, in dem die Anwendung abgeschaltet wird. Nennen Sie eine Situation aus Ihrem eigenen Projekt, in der Sie den Aufwand treiben würden, und eine, in der Sie ihn sich sparen.

7. Halten Sie zwei Regeln für Ihr Projekt schriftlich fest: was niemals von Hand auf der Produktionsdatenbank geschieht, und was vor jeder entfernenden Migration passiert. Legen Sie beide in docs/entscheidungen.md ab.

Wissenscheck

1. Was ist eine Migration, und warum liegt sie im Repository?
2. Worin unterscheiden sich die Befehle für die Entwicklung und für die Produktion?
3. Warum sind additive Änderungen unproblematisch und entfernende nicht?
4. Welche vier Schritte hat die Zwei-Phasen-Änderung, und was passiert in jedem?
5. Warum laufen während eines Deployments für einige Sekunden zwei Versionen gleichzeitig?
6. Warum ist ein ALTER TABLE von Hand auf dem Server ein Problem, auch wenn es funktioniert?
7. Warum erstellt man vor einer entfernenden Migration eine Sicherung, und was gehört zu einer brauchbaren Sicherung dazu?

Abgabe

Die Migrationsdateien aller vier Schritte liegen im Repository, ebenso die zugehörigen Anwendungsversionen in der Git-Historie. In protokoll.md stehen die Einordnung der fünf Änderungen aus Teil A, die Fehlermeldung aus dem nachgestellten Bruch in Teil B, die Vier-Schritte-Tabelle mit den Rollback-Prüfungen und die Beurteilung des Aufwands. Die beiden Regeln stehen in docs/entscheidungen.md.