Additive Datenbankänderungen: So fügen Sie hinzu, ohne die Produktion zu gefährden

Sie betreiben eine produktive Anwendung mit tausenden aktiven Nutzern. Ihr Team soll ein Telefonnummernfeld zum Benutzerprofil hinzufügen. Die Änderung wirkt klein, aber allein der Gedanke an ein ALTER TABLE auf der Produktionsdatenbank macht jeden nervös. Was, wenn die Migration die Tabelle sperrt? Was, wenn der alte Anwendungscode abstürzt, weil er die neue Spalte nicht erwartet?

Diese Situation kennt fast jedes Entwicklungsteam, das seine eigene Datenbank betreibt. Die gute Nachricht: Eine Kategorie von Schemaänderungen ist bemerkenswert sicher – selbst unter Produktionslast. Wer diese Kategorie versteht, ändert damit seine Planung von Deployments, die Koordination im Team und das Risiko bei der Weiterentwicklung der Datenbank.

Was eine Änderung additiv macht

Eine additive Änderung ist jede Modifikation, die dem Datenbankschema nur etwas Neues hinzufügt, ohne Vorhandenes zu verändern oder zu entfernen. Die Liste ist einfach:

• Hinzufügen einer neuen Spalte zu einer bestehenden Tabelle
• Erstellen einer neuen Tabelle
• Hinzufügen eines neuen Index
• Hinzufügen einer Einschränkung (Constraint), die keine vorhandenen Daten einschränkt

Das entscheidende Merkmal: Sie erweitern das Schema. Sie benennen keine Spalten um, ändern keine Datentypen, führen keine Tabellen zusammen und löschen nichts. Die alten Teile des Schemas bleiben exakt, wie sie waren.

Warum additive Änderungen sicher sind

Die Sicherheit beruht auf einer einfachen Tatsache: Der alte Anwendungscode hängt nicht von dem neuen Element ab, das Sie gerade hinzugefügt haben. Wenn Sie eine phone-Spalte zur users-Tabelle hinzufügen, liest und schreibt der bestehende Code weiterhin name, email und password genau wie zuvor. Er weiß nichts von der neuen Spalte. Er versucht nicht, sie zu lesen, und er versucht nicht, in sie zu schreiben. Nichts geht kaputt.

Das gilt für andere Arten von Änderungen nicht. Wenn Sie eine Spalte von phone in phone_number umbenennen, versucht der alte Code phone zu lesen und scheitert, weil diese Spalte nicht mehr existiert. Wenn Sie den Spaltentyp von VARCHAR auf INT ändern, könnte der alte Code einen String-Wert schreiben, den die Datenbank nicht mehr akzeptiert. Wenn Sie zwei Tabellen zusammenführen, brechen die alten Abfragen, die auf die ursprüngliche Tabellenstruktur verweisen.

Additive Änderungen vermeiden all diese Probleme, weil sie nichts anfassen, worauf der alte Code angewiesen ist.

Die eine entscheidende Regel

Es gibt eine Bedingung, die additive Änderungen sicher macht: Die neue Spalte muss nullbar sein oder einen Standardwert haben.

Wenn Sie eine Spalte mit NOT NULL und ohne Standardwert hinzufügen, verletzt jede vorhandene Zeile in der Tabelle sofort die Einschränkung. Die Datenbank wird die Migration ablehnen. Im schlimmsten Fall läuft die Migration teilweise durch, gelingt für einige Zeilen und schlägt dann fehl – zurück bleiben inkonsistente Daten, die nur schwer zu bereinigen sind.

Das Standardmuster sieht so aus:

ALTER TABLE users ADD COLUMN phone VARCHAR(20) NULL;

Wenn die Spalte später erforderlich sein soll, fügen Sie zuerst einen Standardwert hinzu:

ALTER TABLE users ADD COLUMN phone VARCHAR(20) NOT NULL DEFAULT '';

Mit einem Standardwert erhält jede vorhandene Zeile einen leeren String. Der alte Anwendungscode kann diese Spalte weiterhin fehlerfrei lesen. Später, nachdem alle Anwendungsinstanzen aktualisiert wurden, um die neue Spalte korrekt zu verarbeiten, können Sie den Standardwert entfernen oder in einer separaten Migration eine NOT NULL-Einschränkung hinzufügen.

Additive Änderungen während der Produktionszeit durchführen

Einer der größten praktischen Vorteile additiver Änderungen ist, dass Sie sie ausführen können, während die Produktion stark ausgelastet ist. In den meisten modernen Datenbanken ist ALTER TABLE ADD COLUMN mit einer nullbaren Spalte ein leichter Vorgang, der die Tabelle nicht für längere Zeit sperrt.

Es gibt Ausnahmen. Ältere MySQL-Versionen können die Tabelle während eines ALTER TABLE sperren. Auch das Hinzufügen einer Spalte an einer bestimmten Position mit AFTER kann zu mehr Sperren führen als das Hinzufügen am Ende. Aber im Allgemeinen ist das Hinzufügen einer nullbaren Spalte eine der sichersten Operationen, die Sie an einer Live-Datenbank durchführen können.

Das bedeutet: Sie brauchen kein Wartungsfenster. Sie müssen nicht auf verkehrsarme Zeiten warten. Sie können die Migration tagsüber durchführen, prüfen, ob sie funktioniert, und dann zum nächsten Schritt Ihres Deployments übergehen.

Wie dies schrittweise Deployments ermöglicht

Additive Änderungen ermöglichen eine Deployment-Strategie, die mit anderen Arten von Schemaänderungen nur schwer zu erreichen ist: Rolling Updates ohne Koordination.

Stellen Sie sich vor, Sie haben zehn Anwendungsinstanzen hinter einem Load Balancer. Sie möchten eine neue Version ausrollen, die die phone-Spalte liest und schreibt. So läuft der Prozess ab:

1. Führen Sie die Migration aus, um die phone-Spalte hinzuzufügen. Das Schema hat jetzt die neue Spalte, aber alle zehn Instanzen laufen noch mit dem alten Code, der sie ignoriert.
2. Aktualisieren Sie eine Instanz auf den neuen Code. Diese Instanz beginnt, die phone-Spalte zu lesen und zu schreiben. Die anderen neun Instanzen arbeiten normal weiter, weil sie die neue Spalte nie anfassen.
3. Aktualisieren Sie nach und nach die restlichen Instanzen eine nach der anderen. Zu jedem Zeitpunkt dieses Prozesses koexistieren alte und neue Instanzen ohne Konflikte.

Dies ist nur möglich, weil die Schemaänderung additiv ist. Wenn die Änderung das Löschen oder Umbenennen einer Spalte erfordern würde, würden die alten Instanzen in dem Moment brechen, in dem die Migration läuft. Sie wären gezwungen, alle Instanzen auf einmal zu aktualisieren, was das Risiko erhöht und sorgfältige Koordination erfordert.

Wann Sie über additive Änderungen hinausgehen sollten

Additive Änderungen sind sicher, aber nicht immer ausreichend. Irgendwann müssen Sie ungenutzte Spalten entfernen, Datentypen zur Behebung von Performance-Problemen ändern oder Tabellen für neue Funktionen umstrukturieren. Diese Änderungen sind riskanter und erfordern andere Strategien.

Die praktische Reihenfolge ist: Beginnen Sie mit additiven Änderungen, um neue Spalten und Tabellen einzuführen, lassen Sie den Anwendungscode nachziehen, und planen Sie dann die invasiveren Änderungen in separaten Migrationen. Jede Migration sollte genau eine Sache tun und nur eine Sache. Mischen Sie keine additive Änderung mit einer destruktiven Änderung im selben Migrationsskript.

Eine kurze Checkliste für additive Änderungen

Bevor Sie eine additive Änderung in der Produktion durchführen, gehen Sie diese Punkte durch:

• Ist die neue Spalte nullbar oder hat sie einen Standardwert?
• Fügt die Migration nur Dinge hinzu, ohne vorhandenes Schema zu ändern oder zu entfernen?
• Haben Sie die Migration auf einer Kopie der Produktionsdaten getestet?
• Haben Sie einen Rollback-Plan? (Für additive Änderungen ist der Rollback normalerweise einfach ALTER TABLE DROP COLUMN, aber prüfen Sie, ob es funktioniert.)
• Kann der alte Anwendungscode nach der Migration ohne Änderungen weiterlaufen?

Wenn Sie alle Fragen mit Ja beantworten können, sind Sie bereit, die Migration zuversichtlich durchzuführen.

Die konkrete Erkenntnis

Additive Änderungen sind die sicherste Kategorie von Datenbankschema-Modifikationen, weil sie das Schema erweitern, ohne etwas zu beschädigen, wovon der alte Code abhängt. Verwenden Sie nullbare Spalten oder Standardwerte, führen Sie sie während der normalen Geschäftszeiten durch und rollen Sie Ihre Anwendungsinstanzen schrittweise aus. Dieser Ansatz beseitigt die Spannung zwischen der Weiterentwicklung Ihrer Datenbank und der Aufrechterhaltung der Produktionsstabilität. Beginnen Sie jede Schemaänderung mit der Frage: Kann ich das additiv machen? Wenn ja, tun Sie das zuerst. Heben Sie sich die riskanteren Änderungen für später auf, wenn das neue Schema bereits in Gebrauch und der alte Code außer Dienst gestellt ist.