PostgreSQL 14 uz 18: kas salūzt un kā atjaunināt droši

PostgreSQL 14 atbalsts beidzas 2026. gada 12. novembrī, un lielākajai daļai komandu mērķis ir PostgreSQL 18. pg_upgrade var pāriet no 14 uz 18 vienā solī, tāpēc nav iemesla apstāties pie 15, 16 vai 17. Taču viens solis no 14 uz 18 nozīmē, ka vienlaikus saņemat četru galveno versiju nesaderības. Tālāk ir tās, kas tiešām aptur atjaunināšanu vai salauž lietas pēc tās, ar kļūdām, ko redzēsiet, un kas mainās, ja datubāze ir simtiem gigabaitu vai vairāki terabaiti.

Kāpēc tagad un kāpēc 18

Saskaņā ar PostgreSQL versiju politiku 14. versijas pēdējais laidiens ir 2026. gada 12. novembrī. Pēc tam vairs nav ne drošības, ne kļūdu labojumu. PostgreSQL 19 gaidāms nedēļu vēlāk, taču lielākā daļa produkcijas sistēmu izvēlēsies versiju, kurai jau ir mazie atjauninājumi. Mūsu pārskats par PostgreSQL 14 atbalsta beigām apraksta izvēli starp 18 un 19. Šis raksts ir par tehnisko pusi, pārejot no 14 uz 18.

pg_upgrade dokumentācija atbalsta atjaunināšanu no 9.2 un jaunākām versijām, tāpēc 14 uz 18 ir viens atbalstīts solis. Darbojas arī loģiskā replikācija un dump/restore. Ja metode vēl nav izvēlēta, skatiet mūsu pg_upgrade un loģiskās replikācijas salīdzinājumu. Lielākā daļa tālākā attiecas uz jebkuru metodi, jo tas ir par jauno serveri, nevis par to, kā tajā nonāk dati.

Kas aptur pg_upgrade: datu kontrolsummas

Ar šo vispirms saskarsies lielākā daļa 14 uz 18 atjauninājumu. Kopš PostgreSQL 18 initdb pēc noklusējuma ieslēdz datu kontrolsummas. Daudzi 14. versijas klasteri izveidoti bez tām, un pg_upgrade prasa, lai abi klasteri sakristu. pg_upgrade --check apstājas uzreiz:

$ pg_upgrade --check -b /usr/lib/postgresql/14/bin -B /usr/lib/postgresql/18/bin \
    -d /var/lib/postgresql/14/main -D /var/lib/postgresql/18/main
...
old cluster does not use data checksums but the new one does
Failure, exiting

Risinājums ir izveidot jauno klasteri ar jauno opciju --no-data-checksums. Debian vai Ubuntu sistēmās pg_createcluster nodod initdb opcijas pēc --. Vispirms pārbaudiet veco klasteri:

# vai vecajā klasterī ir kontrolsummas? (0 = nav)
pg_controldata /var/lib/postgresql/14/main | grep checksum

# ja nav, izveidojiet jauno klasteri tādu pašu
initdb -D /var/lib/postgresql/18/main --no-data-checksums ...

Kontrolsummas ir vērtīgas, jo atklāj glabātuves bojājumus. Ieslēdziet tās kā atsevišķu, plānotu soli pēc atjaunināšanas, nevis tās laikā. Lielai datubāzei šim solim vajag savu dīkstāvi, skatiet sadaļu par lielām datubāzēm tālāk.

Kas neļauj serverim startēt: dzēsti iestatījumi

Ja pārnesat veco postgresql.conf vai to ģenerē konfigurācijas pārvaldība, iestatījums, kura vairs nav, neļauj serverim startēt. Pietiek ar vienu rindu, kas palikusi no tipiskas 14. versijas rezerves servera konfigurācijas:

LOG:  unrecognized configuration parameter "promote_trigger_file" in file ".../postgresql.conf" line 890
FATAL:  configuration file ".../postgresql.conf" contains errors

Iestatījumi, kas dzēsti starp 14 un 18 un joprojām sastopami reālās konfigurācijās:

• stats_temp_directory: dzēsts 15. versijā.
• promote_trigger_file: dzēsts 16. versijā. Izmantojiet pg_ctl promote vai pg_promote() un pārbaudiet failover rīkus.
• vacuum_defer_cleanup_age: dzēsts 16. versijā.
• force_parallel_mode: 16. versijā pārdēvēts par debug_parallel_query.
• old_snapshot_threshold, db_user_namespace un trace_recovery_messages: dzēsti 17. versijā.

Drošākais ceļš ir sākt ar 18. versijas noklusējuma postgresql.conf un pārnest tikai tos iestatījumus, kurus varat izskaidrot.

Kas salūzt skriptos: rezerves kopijas un monitorings

Datubāzes serveris parasti ir kārtībā. Problēmas ir skriptos ap to.

• Rezerves kopiju funkcijas. PostgreSQL 15 izņēma ekskluzīvo rezerves kopēšanas režīmu. pg_start_backup() un pg_stop_backup() pārdēvētas par pg_backup_start() un pg_backup_stop(), bet pg_is_in_backup() un pg_backup_start_time() vairs nav. 18. versijā vecs skripts beidzas ar function pg_start_backup(unknown) does not exist. Pašrakstīti rezerves kopiju skripti bieži izsauc šīs funkcijas. Rīki kā pgBackRest vai Barman to risina paši, ja izmantojat versiju, kas atbalsta 18.
• Kontrolpunktu statistika. PostgreSQL 17 pārvietoja kontrolpunktu kolonnas no pg_stat_bgwriter uz jauno skatu pg_stat_checkpointer. Vaicājums pēc checkpoints_timed atgriež column "checkpoints_timed" does not exist; jaunā kolonna ir num_timed. Izņemtas arī buffers_backend un buffers_backend_fsync.
• pg_stat_statements. 17. versijā blk_read_time un blk_write_time kļuva par shared_blk_read_time un shared_blk_write_time.
• WAL un I/O statistika. 18. versijā no pg_stat_wal izņemtas wal_write, wal_sync, wal_write_time un wal_sync_time, bet no pg_stat_io — op_bytes.

Monitoringa pārbaudi, kas krīt ar vaicājuma kļūdu, viegli sajaukt ar "nav datu", tāpēc panelis izskatās mierīgs. Atjauniniet monitoringa aģentu, palaidiet katru pielāgoto vaicājumu uz testa 18. versijas servera un izlabojiet tos pirms produkcijas atjaunināšanas.

Kas salūzt pēc atjaunināšanas: funkcijas indeksos

Šo ir viegli palaist garām, jo atjaunināšana izdodas un vaicājumi turpina strādāt. Kopš 17. versijas uzturēšanas operācijas, piemēram, ANALYZE, VACUUM, REINDEX, CREATE INDEX un REFRESH MATERIALIZED VIEW, izpilda funkcijas ar drošu search_path. Funkcija izteiksmes indeksā vai materializētā skatā, kas atsaucas uz savas shēmas tabulām bez shēmas nosaukuma un paļāvās uz datubāzes search_path, tagad krīt.

Tipisks piemērs: PL/pgSQL funkcija app.to_eur() lasa tabulu rates shēmā app, un to izmanto izteiksmes indekss. Pēc atjaunināšanas SELECT vaicājumi joprojām strādā, bet:

shop=# ANALYZE orders;
ERROR:  relation "rates" does not exist
LINE 1: amount * (SELECT rate FROM rates WHERE code = c)
                                   ^
CONTEXT:  PL/pgSQL function app.to_eur(text,numeric) line 1 at RETURN

REINDEX, CREATE MATERIALIZED VIEW, REFRESH MATERIALIZED VIEW un pēc atjaunināšanas ieteiktā vacuumdb --all --analyze-only krīt tāpat. Lielai tabulai tas laika gaitā kaitē arvien vairāk: statistika noveco, plāni pasliktinās, un indeksu nevar pārbūvēt. Atrodiet šīs funkcijas jau uz 14 pirms atjaunināšanas un izlabojiet laikus. Šis vaicājums darbojas gan uz 14, gan uz 18:

-- funkcijas, ko izmanto indeksi un materializētie skati
-- un kurām nav sava search_path (palaidiet uz 14 pirms atjaunināšanas)
SELECT DISTINCT p.oid::regprocedure AS function, c.relname AS used_by
FROM pg_depend d
JOIN pg_proc p      ON p.oid = d.refobjid AND d.refclassid = 'pg_proc'::regclass
JOIN pg_namespace n ON n.oid = p.pronamespace
JOIN pg_language l  ON l.oid = p.prolang
LEFT JOIN pg_rewrite r ON d.classid = 'pg_rewrite'::regclass AND r.oid = d.objid
JOIN pg_class c     ON c.oid = COALESCE(r.ev_class, d.objid)
WHERE c.relkind IN ('i', 'I', 'm')
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
  AND l.lanname NOT IN ('c', 'internal')
  AND NOT EXISTS (SELECT 1 FROM unnest(p.proconfig) AS cfg
                  WHERE cfg LIKE 'search_path=%');

-- labojums: piešķiriet funkcijai vajadzīgo search_path
ALTER FUNCTION app.to_eur(text, numeric) SET search_path = app;

Ne katra funkcija sarakstā ir problēma. Funkcijas, kas izmanto tikai iebūvētos objektus vai katrai tabulai norāda shēmu, ir kārtībā. Taču ir vērts apskatīt katru, un search_path iestatīšana funkcijai nekaitē arī uz 14. ALTER FUNCTION ... SET search_path maina tikai funkcijas definīciju un nepārraksta datus, tāpēc tas ir tikpat ātrs arī uz vairāku terabaitu tabulas.

Drošības izmaiņas: public shēma un MD5 paroles

Kopš 15. versijas parastie lietotāji vairs nevar veidot objektus jaunas datubāzes public shēmā. pg_upgrade saglabā vecās tiesības, tāpēc atjaunināta datubāze uzvedas kā iepriekš. Tas attiecas arī uz datubāzēm, kas izveidotas pēc atjaunināšanas, jo tās tiek kopētas no atjauninātās template1. Pavisam jaunam 18. versijas klasterim ir jaunais, stingrais noklusējums. Tāpēc viena un tā pati migrācija var strādāt atjauninātajā produkcijas serverī un krist jaunā testa serverī. Mūsu raksts par "permission denied for schema public" skaidro risinājumu un to, kā apzināti pāriet uz jauno noklusējumu.

PostgreSQL 18 atzīst MD5 paroles par novecojušām. Tās joprojām darbojas, taču atbalsts tiks izņemts kādā nākamajā galvenajā versijā, un MD5 paroles iestatīšana tagad rada brīdinājumu. Tā kā 14. versijā noklusējums jau ir scram-sha-256, MD5 jaucējvērtības parasti pieder vecām lomām. Atrodiet tās:

SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';

Atiestatiet to paroles, kamēr password_encryption ir scram-sha-256, pārbaudiet, ka klienti pieslēdzas ar SCRAM, un tad pg_hba.conf nomainiet md5 uz scram-sha-256.

Mazākas izmaiņas, ko vērts pārbaudīt

• Paplašinājumi. Katram paplašinājumam jābūt instalētam 18. versijai, pirms palaižat pg_upgrade. adminpack izņemts 17. versijā, plpython2u/plpythonu — 15. versijā.
• Loģiskās replikācijas sloti. pg_upgrade pārnes loģiskos slotus un abonementus tikai tad, ja vecais klasteris ir 17 vai jaunāks. No 14 tie jāizveido no jauna.
• Lomas. 16. versijā CREATEROLE zaudēja lielu daļu varas pār citām lomām, un izmaiņām tagad vajag ADMIN OPTION. Skriptiem, kas bez superlietotāja veido un pārvalda lietotājus, var būt vajadzīgas jaunas tiesības.
• VACUUM un ANALYZE uz mantošanas vecāktabulām. 18. versijā tie apstrādā arī bērnus. Vecajai uzvedībai izmantojiet ONLY.
• COPY un CSV. 18. versijā COPY FROM vairs neuzskata \. par CSV faila beigām. Laidiena piezīmes brīdina, ka vecākiem psql klientiem ar 18. versijas serveriem var būt problēmas ar \copy, tāpēc atjauniniet arī klientus.
• Nežurnalētas sadalītas tabulas 18. versijā vairs nav atļautas.
• Pilnteksta meklēšana un pg_trgm. Ja klasteris izmanto ICU vai iebūvēto kolāciju nodrošinātāju, 18. versijas laidiena piezīmes iesaka pēc pg_upgrade pārindeksēt pilnteksta meklēšanas un pg_trgm indeksus. Lielām tabulām izmantojiet REINDEX CONCURRENTLY, kā aprakstīts mūsu REINDEX CONCURRENTLY ceļvedī.
• Noklusējumi. hash_mem_multiplier kopš 15. versijas ir 2.0. 18. versijā effective_io_concurrency un maintenance_io_concurrency noklusējums ir 16, un jaunā asinhronā I/O pēc noklusējuma izmanto io_method = worker. Ja paļaujaties uz noklusējumiem, salīdziniet veiktspēju ar reālistisku slodzi.

Statistika pēc atjaunināšanas

Labā ziņa, īpaši lielām datubāzēm: kopš 18. versijas pg_upgrade saglabā optimizētāja statistiku, arī ja vecais klasteris ir 14. Agrāk vairāku terabaitu datubāze strādāja ar sliktiem plāniem, līdz beidzās ilgs ANALYZE. Paplašinātā statistika (CREATE STATISTICS) netiek pārnesta, tāpēc vispirms palaidiet ANALYZE tabulām, kas to izmanto. Beigās rīks izdrukā divas komandas. Dokumentācija iesaka tās paātrināt ar --jobs un ar PGOPTIONS='-c vacuum_cost_delay=0', ja izmantojat izmaksu aizturi:

vacuumdb --all --analyze-in-stages --missing-stats-only --jobs=8
vacuumdb --all --analyze-only --jobs=8

Pirmā aizpilda statistiku tikai tur, kur tās trūkst, tāpēc datubāze ir gatava apkalpot slodzi daudz ātrāk nekā ar pilnu ANALYZE agrākos atjauninājumos. Otrā atjauno visu un arī skaitītājus, kas iedarbina autovacuum. ANALYZE nebloķē parasto lasīšanu un rakstīšanu, tāpēc lielā datubāzē otro komandu var palaist, kad lietotne jau atkal strādā.

Lielas datubāzes: kas mainās

Dažu gigabaitu datubāzei jebkura metode iekļaujas īsā logā. Pie simtiem gigabaitu vai vairākiem terabaitiem režīma izvēle un sagatavošanās nosaka, vai dīkstāve būs minūtes vai stundas.

• Copy režīms (noklusējums) kopē katru datu failu. Tam vajag tikpat daudz brīvas vietas, cik aizņem dati, un laiks aug ar datu apjomu. Lielai datubāzei tas parasti ir nepareizs izvēles variants.
• Link, clone un swap nekopē datu failus, tāpēc laiks gandrīz nav atkarīgs no datu apjoma. Paliek shēmas izgāšana un atjaunošana, tāpēc datubāze ar desmitiem tūkstošu tabulu, partīciju un indeksu prasa vairāk laika nekā liela, bet vienkārša. Dokumentācija norāda, ka --swap var būt ātrākais, ja relāciju ir daudz. Visiem trim vecajam un jaunajam datu direktorijam jābūt vienā failu sistēmā.
• Paralēlisms. --jobs paralēli apstrādā vairākas datubāzes un tabulu telpas. Dokumentācija iesaka sākt ar CPU kodolu skaitu. Ja ir viena datubāze vienā tabulu telpā, tas palīdz daudz mazāk.
• Pārbaudes pirms loga. pg_upgrade --check var palaist, kamēr vecais serveris vēl strādā. Palaidiet to dienas iepriekš ar to pašu režīma opciju, ko izmantosiet (--link, --clone vai --swap), lai izpildītos arī režīmam specifiskās pārbaudes.
• Rezerves serveri. Vairāku terabaitu rezerves servera pārbūve no nulles aizņem stundas, un tikmēr nav failover iespējas. Ar link režīmu dokumentācija apraksta rezerves serveru atjaunināšanu ar rsync --hard-links no primārā servera, kas kopē tikai tos failus, kas netika saistīti.
• Kontrolsummu ieslēgšana vēlāk. pg_checksums --enable darbojas tikai uz korekti apturēta klastera un pārraksta blokus uz vietas. Dokumentācija brīdina, ka lielā klasterī tas var aizņemt ilgu laiku, un ar replikām visi mezgli jāpārslēdz saskaņoti vai rezerves serveri jāpārbūvē. Ja šāda dīkstāve nav pieņemama, alternatīva ir loģiskā replikācija uz jaunu klasteri, kas izveidots ar kontrolsummām.
• Loģiskā replikācija pg_upgrade vietā. Ja neiekļaujas pat minūšu dīkstāve, loģiskā replikācija no tās izvairās, taču lielu tabulu sākotnējā kopēšana var ilgt daudzas stundas vai dienas, un avots visu šo laiku glabā WAL replikācijas slotam. Sekojiet līdzi diskam vecajā serverī.

Vienīgais uzticamais apkopes loga novērtējums ir mēģinājums uz pilna izmēra produkcijas kopijas tāda paša tipa glabātuvē. Nomēriet katru soli: --check, pašu atjaunināšanu, startu, pirmo vacuumdb un rezerves serverus.

Drošs atjaunināšanas plāns

1. Atjauniniet 14 uz jaunāko mazo laidienu un izveidojiet pārbaudītu rezerves kopiju.
2. Palaidiet pārbaudes uz 14: kontrolsummu iestatījums, funkcijas bez search_path, MD5 lomas, paplašinājumi un vai tiem ir 18. versijas būvējumi, loģiskās replikācijas sloti.
3. Sakārtojiet konfigurāciju: sāciet ar 18. versijas noklusējumiem un izņemiet dzēstos iestatījumus.
4. Izlabojiet skriptus un monitoringu: rezerves kopiju funkcijas, pg_stat_bgwriter, pg_stat_statements kolonnas un monitoringa aģenta versiju.
5. Izmēģiniet uz pilna izmēra produkcijas kopijas: izveidojiet 18. versijas klasteri ar atbilstošām kontrolsummām, palaidiet pg_upgrade --check, tad īsto atjaunināšanu tajā režīmā, ko izmantosiet. Nomēriet katru soli, palaidiet lietotnes testus un vacuumdb pēc atjaunināšanas un salīdziniet lēnākos vaicājumus.
6. Atjauniniet produkciju apkopes logā ar pierakstītu atkāpšanās plānu, tad pārbūvējiet rezerves serverus un palaidiet vacuumdb.
7. Pēc tam kā atsevišķus uzdevumus plānojiet kontrolsummu ieslēgšanu un atteikšanos no MD5.

Pārvaldītais PostgreSQL

RDS, Cloud SQL vai Azure atjaunināšanu veic pakalpojuma sniedzējs, taču lielākā daļa iepriekš minēto problēmu ir jūsu shēmā, skriptos un klientos. Tās attiecas arī tur: funkcijas indeksos, pārdēvētas monitoringa kolonnas, rezerves kopiju skripti, MD5 lomas un mainīti noklusējumi. Pārbaudiet atjaunināšanu uz produkcijas momentuzņēmuma, pirms to ieplānojat.