Cartografiați fiecare cititor și scriitor
Lucrați pe o schemă izolată cu date sanitizate reprezentative. Aveți nevoie de versiunile curentă și următoare ale aplicației, cunoștințe despre framework-ul de migrare, o strategie de backup revizuită și vizibilitate asupra tranzacțiilor lungi. Includeți workeri, joburi programate, rapoarte și instanțe mai vechi ale aplicației. Un API se poate actualiza rapid în timp ce un worker de lungă durată încă scrie în coloana veche.
Serviciul nostru ilustrativ de raportare stochează o etichetă de export în label și dorește display_name. Acesta este un exemplu de proiectare, nu SQL universal executabil. Confirmați versiunea exactă de PostgreSQL și framework-ul înainte de a alege sintaxa de migrare sau setările de blocare.
Extindeți fără a retrage vechea reprezentare
Introduceți mai întâi noul câmp care permite valori nule. Implementați o versiune de compatibilitate care scrie ambele valori într-o singură tranzacție și citește cu fallback-ul necesar cât timp datele sunt incomplete. Definiți ce se întâmplă când un client editează o înregistrare în timpul completării. O reîncercare nu trebuie să creeze un al doilea export logic.
PostgreSQL ALTER TABLE operațiile dobândesc blocări, cu nivelul în funcție de subcomandă. O modificare mică poate aștepta după o tranzacție lungă și apoi bloca alte lucrări. Revizuiți operația specifică și observați așteptările în timpul repetiției; aditiv nu înseamnă fără blocări.
Referință tehnică: PostgreSQL ALTER TABLE · Blocare explicită PostgreSQL.
Faceți vizibilă granița de compatibilitate
| Schemă și scriitori | Comportament cititor | Decizie de recuperare |
|---|---|---|
| Doar eticheta există | Cod vechi acceptat | Adăugați mai întâi câmpul nou |
| Ambele câmpuri; scriitorii doar-vechi rămân | Citiți eticheta ca autoritativă | Nu comutați încă cititorii |
| Toți scriitorii scriu dual; completare verificată | Câmpul nou poate deveni autoritativ | Rollback doar la cod compatibil cu scriere duală |
| Câmpul vechi eliminat | Niciun cod nu poate referi eticheta | Artefactul vechi este incompatibil |
Un fallback pentru valori lipsă nu poate detecta o valoare nouă non-nulă dar învechită. Înainte de a comuta cititorii, retrageți scriitorii doar-vechi și verificați consistența. Revenirea la codul doar-vechi după trecerea cititorilor ar putea recrea divergența. Păstrați versiunea de compatibilitate ca artefact de recuperare revizuit.
Completați în muncă limitată, reluabilă
Găsiți rândurile care trebuie copiate fără a suprascrie o editare mai nouă a clientului. Folosiți o ordonare stabilă, o condiție de actualizare sigură pentru concurență și loturi alese pentru volumul de lucru. Persistați progresul astfel încât o eroare să poată relua de la o limită cunoscută. Monitorizați volumul de scriere, așteptările de blocare, latența cererilor și replicarea, dacă există.
Nicio dimensiune de lot nu este sigură pentru fiecare aplicație. În repetiție, comparați un lot mic cu traficul obișnuit, apoi alegeți o regulă de pauză sau oprire. Dacă un lot eșuează, inspectați ce s-a confirmat înainte de a reîncerca. O buclă de reîncercare nelimitată poate transforma o nepotrivire recuperabilă în presiune susținută pe baza de date.
Verificați semantica, nu doar rândurile populate
Verificați valorile lipsă, etichetele reprezentative, înregistrările noi și actualizările exporturilor existente. Numărarea rândurilor non-nule poate părea corectă în timp ce valorile au fost copiate din sursa greșită. Testați artefactul de compatibilitate cu date parțial populate și exersați un worker pornit înainte de implementare.
Înregistrați versiunea schemei, revizia migrării, criteriile de finalizare și combinațiile incompatibile. Inspectați utilizarea fallback-ului și consistența înainte de a elimina oricare. Dacă verificările eșuează, opriți completarea sau promovarea, păstrați dovezile și alegeți un artefact compatibil sau o reparare înainte revizuită. Nu pretindeți că un rollback al aplicației reconstruiește datele confirmate.
Retrageți câmpul vechi într-o altă versiune revizuită
Eliminați citirile și scrierile vechi după ce completarea și perioada de observare îndeplinesc criteriile dumneavoastră. Verificați joburile infrecvente precum și rutele interactive. Eliminarea câmpului vechi aparține unei modificări ulterioare cu propria decizie de recuperare, astfel încât o problemă de versiune să nu vă oblige să combinați repararea codului cu reconstrucția datelor.
Dacă apar date rele după retragere, opriți daunele ulterioare și folosiți planul de recuperare sau o reparare aprobată. Nu aplicați o migrare descendentă destructivă doar pentru că instrumentele expun un buton de rollback. Atașați matricea la înregistrarea lansării și repetați recuperarea datelor înainte de a modifica producția. Rezultatul util este o graniță de compatibilitate explicită, nu o garanție de timp de nefuncționare zero.
Referințe oficiale
Documentația a fost revizuită pentru acest articol. Exemplele sunt exerciții de planificare, nu comenzi testate pe un server PrivacyNodes. Verificați documentația pentru versiunea instalată.