Jeden Leser und Schreiber erfassen
Arbeiten Sie an einem isolierten Schema mit repräsentativen, bereinigten Daten. Sie benötigen die aktuelle und die nächste Anwendungsversion, Kenntnis Ihres Migrationsframeworks, eine geprüfte Backup-Strategie und Einblick in lang laufende Transaktionen. Beziehen Sie Worker, geplante Jobs, Berichte und ältere Anwendungsinstanzen ein. Eine API kann schnell aktualisiert werden, während ein lang laufender Worker noch in die alte Spalte schreibt.
Unser beispielhafter Reporting-Dienst speichert ein Export-Label in label und möchte display_name. Dies ist ein Designbeispiel, kein universell ausführbares SQL. Bestätigen Sie Ihre genaue PostgreSQL-Version und Ihr Framework, bevor Sie Migrationssyntax oder Lock-Einstellungen wählen.
Erweitern, ohne die alte Darstellung aufzugeben
Führen Sie zuerst das neue nullable Feld ein. Stellen Sie ein Kompatibilitäts-Release bereit, das beide Werte in einer Transaktion schreibt und mit dem erforderlichen Fallback liest, solange die Daten unvollständig sind. Definieren Sie, was passiert, wenn ein Kunde einen Datensatz während des Backfills bearbeitet. Ein Wiederholungsversuch darf keinen zweiten logischen Export erzeugen.
PostgreSQL ALTER TABLE -Operationen erwerben Locks, wobei die Ebene vom Unterbefehl abhängt. Eine kleine Änderung kann hinter einer langen Transaktion warten und dann andere Arbeit behindern. Prüfen Sie den konkreten Vorgang und beobachten Sie Wartezeiten während der Probe; additiv bedeutet nicht lock-frei.
Technische Referenz: PostgreSQL ALTER TABLE · PostgreSQL explizites Locking.
Die Kompatibilitätsgrenze sichtbar machen
| Schema und Schreiber | Leserverhalten | Wiederherstellungsentscheidung |
|---|---|---|
| Nur Label existiert | Alter Code unterstützt | Zuerst neues Feld hinzufügen |
| Beide Felder; Nur-alt-Schreiber bleiben | Label als maßgeblich lesen | Leser noch nicht umstellen |
| Alle Schreiber dual-write; Backfill verifiziert | Neues Feld kann maßgeblich werden | Rollback nur auf kompatiblen Dual-Writing-Code |
| Altes Feld entfernt | Kein Code darf das Label referenzieren | Altes Artefakt ist inkompatibel |
Ein Fallback für fehlende Werte kann einen Nicht-Null-, aber veralteten neuen Wert nicht erkennen. Bevor Sie die Reader umstellen, ziehen Sie reine Alt-Writer zurück und überprüfen Sie die Konsistenz. Ein Rollback auf reinen Alt-Code nach dem Reader-Cutover könnte die Divergenz wiederherstellen. Behalten Sie stattdessen das Kompatibilitäts-Release als geprüftes Wiederherstellungsartefakt bei.
In begrenzten, wiederaufsetzbaren Arbeitsschritten nachfüllen
Finden Sie Zeilen, die kopiert werden müssen, ohne eine neuere Kundenbearbeitung zu überschreiben. Verwenden Sie eine stabile Reihenfolge, eine nebenläufigkeitssichere Update-Bedingung und für die Arbeitslast gewählte Batches. Persistieren Sie den Fortschritt, damit ein Fehler an einer bekannten Grenze fortgesetzt werden kann. Überwachen Sie Schreibvolumen, Lock-Wartezeiten, Anforderungslatenz und Replikation, wo vorhanden.
Keine Batch-Größe ist für jede Anwendung sicher. Vergleichen Sie in der Probe einen kleinen Batch mit normalem Verkehr und wählen Sie dann eine Pause- oder Stoppregel. Wenn ein Batch fehlschlägt, prüfen Sie, was committet wurde, bevor Sie es erneut versuchen. Eine unbegrenzte Wiederholungsschleife kann eine behebbare Abweichung in anhaltenden Datenbankdruck verwandeln.
Semantik prüfen, nicht nur befüllte Zeilen
Verifizieren Sie fehlende Werte, repräsentative Labels, neue Datensätze und Aktualisierungen vorhandener Exporte. Das Zählen von Nicht-Null-Zeilen kann korrekt erscheinen, während Werte aus der falschen Quelle kopiert wurden. Testen Sie das Kompatibilitätsartefakt mit teilweise befüllten Daten und führen Sie einen vor dem Deployment gestarteten Worker aus.
Erfassen Sie Schema-Version, Migrationsrevision, Abschlusskriterien und inkompatible Kombinationen. Prüfen Sie Fallback-Nutzung und Konsistenz, bevor Sie eines davon entfernen. Wenn Prüfungen fehlschlagen, stoppen Sie das Backfill oder die Promotion, bewahren Sie Beweise auf und wählen Sie ein kompatibles Artefakt oder eine geprüfte Vorwärtsreparatur. Behaupten Sie nicht, dass ein Anwendungs-Rollback committete Daten rekonstruiert.
Das alte Feld in einem weiteren geprüften Release entfernen
Entfernen Sie alte Lese- und Schreibzugriffe, nachdem das Backfill und der Beobachtungszeitraum Ihre Kriterien erfüllen. Prüfen Sie auch seltene Jobs sowie interaktive Routen. Das Löschen des alten Feldes gehört in eine spätere Änderung mit eigener Wiederherstellungsentscheidung, damit ein Release-Problem Sie nicht zwingt, Code-Reparatur mit Datenrekonstruktion zu kombinieren.
Wenn nach der Stilllegung fehlerhafte Daten auftauchen, stoppen Sie weiteren Schaden und verwenden Sie den Wiederherstellungsplan oder eine genehmigte Reparatur. Wenden Sie keine destruktive Down-Migration nur deshalb an, weil das Tooling eine Rollback-Schaltfläche bietet. Hängen Sie die Matrix an die Release-Eintrag und proben Sie Datenwiederherstellung vor der Änderung der Produktion. Das nützliche Ergebnis ist eine explizite Kompatibilitätsgrenze, keine Zero-Downtime-Garantie.
Offizielle Referenzen
Die Dokumentation wurde für diesen Artikel überprüft. Beispiele sind Planungsübungen, keine auf einem PrivacyNodes-Server getesteten Befehle. Prüfen Sie die Dokumentation für Ihre installierte Version.