PostgreSQL kopiena katru galveno versiju atbalsta piecus gadus. Pēc tam vairs nav ne kļūdu, ne drošības labojumu — un pārvaldītos pakalpojumos, piemēram, Amazon RDS, palikšana uz versijas pēc standarta atbalsta beigām sāk pievienot rēķinam maksu par paplašināto atbalstu. PostgreSQL 14 šo robežu sasniedz 2026. gada novembrī, tāpēc daudzām komandām tas ir aktuāls plānošanas jautājums tieši tagad.
Labā ziņa ir tā, ka galvenās versijas atjaunināšana ir labi izpētīta. Svarīgākais lēmums ir metode, jo tā nosaka dīkstāvi, atgriešanās iespējas un projekta apjomu.
Kāpēc galvenā versija atšķiras no mazās
Mazā versija — piemēram, no 16.4 uz 16.6 — tikai labo kļūdas. Uzinstalējat jaunos bināros failus un pārstartējat. Galvenā versija var mainīt sistēmas katalogu iekšējo formātu, tāpēc esošo datu direktoriju jaunā versija nevar vienkārši palaist. Dati ir jāpārveido vai jāpārvieto, un tieši šeit abas pieejas atšķiras.
1. iespēja: pg_upgrade
pg_upgrade izveido jaunu, tukšu klasteri ar jauno versiju un pārnes tajā jūsu datus. Tam ir trīs būtiski režīmi:
- Kopēšana — nokopē katru datu failu. Drošākais, bet lēns lielām datubāzēm.
- Saites (
--link) — kopēšanas vietā izmanto cietās saites, tāpēc pat vairāku terabaitu datubāzes tiek atjauninātas minūtēs. Kompromiss: tiklīdz jaunais klasteris ir palaists, veco vairs nevar droši izmantot, tāpēc atgriešanās nozīmē atjaunošanu no rezerves kopijas. - Klonēšana (
--clone) — failu sistēmās, kas to atbalsta, dod saišu režīma ātrumu, atstājot veco klasteri neskartu.
Vienmēr vispirms palaidiet pg_upgrade --check: tas parāda nesaderības, neko nemainot. Visbiežāk pārsteidz divas lietas. Pirmkārt, katram izmantotajam paplašinājumam — PostGIS, TimescaleDB, pg_partman u. c. — jābūt uzinstalētam un pieejamam jaunajai versijai. Otrkārt, pirms PostgreSQL 18 pg_upgrade nepārnes optimizētāja statistiku, tāpēc datubāze strādā ar sliktiem vaicājumu plāniem, līdz palaižat vacuumdb --all --analyze-in-stages. Ieplānojiet šo laiku apkopes logā.
2. iespēja: loģiskā replikācija
Šajā gadījumā blakus vecajam serverim uzbūvējat jaunu ar jauno versiju, replicējat datus ar iebūvēto loģisko replikāciju, ļaujat tai panākt avotu un pārslēdzat lietotni. Pati pārslēgšana aizņem sekundes, un vecais serveris paliek neskarts, līdz izlemjat, ka tas vairs nav vajadzīgs — tas dod reālu atgriešanās ceļu. Tajā pašā projektā varat nomainīt arī aparatūru, operētājsistēmu vai mākoņa pakalpojumu sniedzēju.
Cena ir lielāka sagatavošanās. Tabulām vajag primāro atslēgu (vai replikas identitāti), lai replicētos atjauninājumi un dzēšanas. Shēmas izmaiņas netiek replicētas, tāpēc migrācijas laikā shēma ir jāiesaldē. Arī sekvenču vērtības netiek replicētas, tās jāsinhronizē pārslēgšanas brīdī, un lielajiem objektiem vajag atsevišķu risinājumu. Sīkāk to aprakstām mūsu PostgreSQL migrāciju bez dīkstāves ceļvedī.
Pārvaldītās datubāzes
Amazon RDS un Aurora galvenās versijas atjaunināšana uz vietas izmanto pg_upgrade ar visu no tā izrietošo dīkstāvi. Blue/green izvietošana izmanto loģisko replikāciju, lai uzturētu sinhronu kopiju ar jauno versiju un pārslēgtos, ar tādām pašām prasībām attiecībā uz primārajām atslēgām un shēmas izmaiņām. Jebkurā gadījumā vispirms notestējiet atjaunināšanu uz produkcijas momentuzņēmuma — pakalpojums veic atjaunināšanu, bet netestē jūsu lietotni ar jauno versiju.
Kā izvēlēties
- pg_upgrade ir pareizā noklusējuma izvēle, ja varat ieplānot aptuveni 15–60 minūšu apkopes logu un pieņemat atgriešanos no rezerves kopijas (vai izmantojat klonēšanas režīmu).
- Loģiskā replikācija ir papildu pūļu vērta, ja dīkstāve jāmēra sekundēs, ja datubāze ir liela un noslogota vai ja vienlaikus vēlaties pāriet uz jaunu infrastruktūru.
Mūsu pieredzē pats atjaunināšanas mehānisms problēmas rada reti. Pārsteigumi nāk no apkārtnes: paplašinājums, kuram nav versijas jaunajam PostgreSQL, vaicājums, kura plāns mainījās un kļuva lēnāks, vai lietotnes draiveris, kas ir par vecu jaunajam serverim. Visus trīs testēšanā atrast ir lēti, produkcijā — dārgi.
Kontrolsaraksts neatkarīgi no metodes
- Izlasiet katras izlaistās galvenās versijas laidiena piezīmes, meklējot nesaderības.
- Atjaunojiet nesenu produkcijas rezerves kopiju uz jaunās versijas un palaidiet pret to lietotnes testus.
- Pārbaudiet, vai visi paplašinājumi un lietotnes draiveri atbalsta jauno versiju.
- Salīdziniet dārgāko vaicājumu izpildes plānus un laikus vecajā un jaunajā versijā.
- Tieši pirms atjaunināšanas izveidojiet — un pārbaudiet — jaunu rezerves kopiju.
- Pierakstiet atgriešanās soļus un brīdi, pēc kura atpakaļ vairs neatgriezīsieties.
Galvenās atziņas
- Katru PostgreSQL galveno versiju atbalsta piecus gadus; PostgreSQL 14 atbalsts beidzas 2026. gada novembrī.
pg_upgradesaišu vai klonēšanas režīmā ir ātrs un vienkāršs, bet prasa apkopes logu.- Loģiskā replikācija dod pārslēgšanos sekundēs un reālu atgriešanās ceļu, bet prasa vairāk sagatavošanās.
- Lielākā daļa atjaunināšanas problēmu ir paplašinājumi, mainīti vaicājumu plāni un veci draiveri — testējiet tos vispirms.