Breng elke lezer en schrijver in kaart
Werk op een geïsoleerd schema met representatieve gesanitiseerde gegevens. Je hebt de huidige en volgende applicatieversies nodig, kennis van je migratieframework, een gereviewde back-upstrategie en zicht op langlopende transacties. Neem workers, geplande jobs, rapporten en oudere applicatie-instanties mee. Een API kan snel worden bijgewerkt terwijl een langlopende worker nog steeds naar de oude kolom schrijft.
Onze illustratieve rapportageservice slaat een exportlabel op in label en wil display_name. Dit is een ontwerpvoorbeeld, geen universeel uitvoerbare SQL. Bevestig je exacte PostgreSQL-versie en framework voordat je migratiesyntaxis of lockinstellingen kiest.
Breid uit zonder de oude representatie te laten vervallen
Introduceer eerst het nieuwe nullable veld. Rol een compatibiliteitsrelease uit die beide waarden in één transactie schrijft en leest met de vereiste fallback zolang gegevens onvolledig zijn. Definieer wat er gebeurt wanneer een klant een record bewerkt tijdens de backfill. Een retry mag geen tweede logische export creëren.
PostgreSQL ALTER TABLE bewerkingen verkrijgen locks, waarbij het niveau afhangt van het subcommando. Een kleine wijziging kan achter een langlopende transactie wachten en vervolgens ander werk belemmeren. Review de specifieke bewerking en observeer wachttijden tijdens de repetitie; additief betekent niet lock-vrij.
Technische referentie: PostgreSQL ALTER TABLE · PostgreSQL expliciete locking.
Maak de compatibiliteitsgrens zichtbaar
| Schema en schrijvers | Lezersgedrag | Herstelbeslissing |
|---|---|---|
| Alleen label bestaat | Oude code ondersteund | Voeg eerst nieuw veld toe |
| Beide velden; schrijvers van alleen oud blijven | Lees label als gezaghebbend | Schakel lezers nog niet over |
| Alle schrijvers dual-write; geverifieerde backfill | Een nieuw veld kan gezaghebbend worden | Alleen terugrollen naar compatibele dual-writing code |
| Oud veld verwijderd | Geen code mag naar label verwijzen | Oud artifact is incompatibel |
Een fallback voor ontbrekende waarden kan een niet-null maar verouderde nieuwe waarde niet detecteren. Schakel oude-only writers uit en verifieer de consistentie voordat u van reader wisselt. Terugrollen naar oude-only code na reader-cutover kan divergentie opnieuw creëren. Houd de compatibiliteitsrelease in plaats daarvan aan als het beoordeelde herstelartefact.
Backfill in begrensde, herstartbare stappen
Vind rijen die gekopieerd moeten worden zonder een nieuwere klantbewerking te overschrijven. Gebruik een stabiele ordening, een concurrency-safe updatevoorwaarde en batches die op de workload zijn afgestemd. Leg de voortgang vast zodat een fout kan hervatten op een bekend punt. Monitor schrijfvolume, lock waits, request latency en replicatie waar aanwezig.
Geen batchgrootte is veilig voor elke applicatie. Vergelijk in een repetitie een kleine batch met normaal verkeer en kies daarna een pauze- of stopregel. Als een batch mislukt, inspecteer wat is gecommit voordat u opnieuw probeert. Een onbeperkte retry-loop kan een herstelbare mismatch omzetten in aanhoudende databasedruk.
Controleer semantiek, niet alleen gevulde rijen
Verifieer ontbrekende waarden, representatieve labels, nieuwe records en updates van bestaande exports. Het tellen van niet-null rijen kan er correct uitzien terwijl waarden uit de verkeerde bron zijn gekopieerd. Test het compatibiliteitsartefact tegen gedeeltelijk gevulde data en oefen met een worker die vóór de deployment is gestart.
Leg schemaversie, migratierevisie, voltooiingscriteria en incompatibele combinaties vast. Inspecteer fallbackgebruik en consistentie voordat u een van beide verwijdert. Als controles mislukken, stop de backfill of promotie, bewaar bewijs en kies een compatibel artefact of een beoordeelde voorwaartse reparatie. Beweer niet dat een applicatierollback gecommitte data reconstrueert.
Laat het oude veld vervallen in een andere gereviewde release
Verwijder oude reads en writes nadat de backfill en observatieperiode aan uw criteria voldoen. Controleer ook infrequente jobs naast interactieve routes. Het laten vallen van het oude veld hoort in een latere wijziging met een eigen herstelbeslissing, zodat een releaseprobleem u niet dwingt codereparatie te combineren met datareconstructie.
Als er slechte data verschijnt na retirement, stop verdere schade en gebruik het herstelplan of een goedgekeurde reparatie. Pas geen destructieve down migration toe alleen omdat tooling een rollback-knop toont. Voeg de matrix toe aan de releaseregistratie en oefen dataherstel voordat u productie wijzigt. Het nuttige resultaat is een expliciete compatibiliteitsgrens, niet een zero-downtime garantie.
Officiële referenties
Documentatie is beoordeeld voor dit artikel. Voorbeelden zijn plannings-oefeningen, geen commando's die op een PrivacyNodes-server zijn getest. Controleer de documentatie voor uw geïnstalleerde versie.