pg_dump ali pg_basebackup: ena tabela ali celoten grozd odloči izbiro

Če morate obnoviti posamezno tabelo ali zbirko preseliti v novejšo glavno različico PostgreSQL, izberite logični izvoz pg_dump. Če morate po izgubi strežnika obnoviti celoten podatkovni grozd, uporabite fizično osnovno kopijo pg_basebackup. Prvi izvozi posamezno zbirko in omogoča izbiro objektov, drugi pa pri vsaki izdelavi kopije obravnava celoten grozd, ne posamezne zbirke ali tabele.

Odločilno vprašanje je, kaj mora po okvari spet delovati. Če zadostuje stanje ob zadnji uporabni kopiji, izberite pot glede na obseg obnove. Če potrebujete stanje v določenem trenutku med kopijami, načrt vključuje še arhiviranje dnevnika WAL; sama izbira enega od ukazov te zahteve ne izpolni.

Izbira po vrsti izgube

Najprej opredelite predmet obnove. Spodnji scenariji predpostavljajo, da je uporabna kopija nastala pred izgubo podatkov in da je na voljo okolje, v katerem jo je mogoče obnoviti.

• Izbrisana je ena tabela, preostala zbirka pa deluje: arhivski izvoz pg_dump omogoča izbiro vsebine za obnovo.
• Zbirko selite v novejšo glavno različico: logični izvoz omogoča, da ciljna namestitev znova ustvari njene objekte in naloži podatke.
• Izgubljen je podatkovni imenik ali strežnik: fizična osnovna kopija pg_basebackup je osnova za obnovo grozda.
• Vrniti se morate na trenutek tik pred napačno spremembo: poleg fizične osnovne kopije potrebujete neprekinjen arhiv WAL.

Če imate samo fizično kopijo, lahko posamezno tabelo pridobite tako, da celoten grozd najprej obnovite v ločenem primerku in tabelo od tam prenesete logično. Tak obvoz zahteva prostor, čas in delujoč ločen primerek. Potreba po pogosti obnovi posameznih objektov je zato dober razlog za arhivske logične izvoze, tudi če za odpoved strežnika hranite fizične kopije.

Ko manjka ena tabela

Za izbiro objektov pri obnovi je primeren arhiv pg_dump v formatu custom ali directory. Pri navadnem izvozu SQL dobite zaporedje ukazov, arhiv pa lahko pregledate in njegovo vsebino obnovite selektivno. Izvoz je konsistenten tudi med uporabo zbirke in običajnim bralcem ter piscem ne zapre dostopa.

Možnost izbire tabele v pg_restore obnovi definicijo oziroma podatke imenovane tabele, vendar sama ne vključi vseh odvisnih objektov, kot so indeksi. Pred obnovo zato preglejte vsebino arhiva in ugotovite, kateri povezani objekti morajo biti prisotni ali posebej izbrani. Tudi izvoz, ki je bil že ob nastanku omejen na eno tabelo, samodejno ne zajame vseh drugih tabel, od katerih je odvisna.

Pri izbrisani tabeli v sicer delujoči zbirki je varneje najprej obnoviti vsebino v ločeno zbirko. Tam lahko primerjate strukturo, zapise in odvisnosti, preden podatke prenesete v delujoče okolje. Če se je tabela po nastanku izvoza spreminjala, boste iz njega dobili le stanje ob izvozu; poznejših sprememb v njem ni.

Ko se spremeni glavna različica

Za selitev v novejšo glavno različico je uporabna logična predstavitev podatkov in definicij, ki jo ustvari pg_dump. Fizična kopija pa ohrani datoteke izvornega grozda; neposredno nalaganje teh datotek v drugo glavno različico ni postopek selitve. Pri več zbirkah morate logične izvoze načrtovati za vsako posebej.

Selitev zahteva tudi obravnavo objektov, ki jih izvoz ene zbirke ne pokrije. Mednje spadajo globalni objekti grozda, na primer vloge in definicije tabelnih prostorov. V ciljnem okolju preverite še razširitve, lastništvo in pravice, saj prenosljiv arhiv sam po sebi ne zagotovi, da bo aplikacija po obnovi uporabljala vse zahtevane objekte.

Časa obnove ni mogoče zanesljivo sklepati iz imena orodja. Logična obnova ponovno ustvari objekte in naloži podatke, fizična pa vrne datoteke grozda. Na trajanje vplivajo tudi količina podatkov, shramba, omrežje in delo, potrebno po zagonu obnovljenega primerka.

Ko odpove celoten strežnik

pg_basebackup izdela osnovno kopijo delujočega grozda, vključno z njegovim podatkovnim imenikom in tabelnimi prostori. Tudi kadar je kopija inkrementalna in vsebuje le spremenjene bloke glede na prejšnjo kopijo, je njen obseg še vedno celoten grozd; pred uporabo jo je treba združiti s kopijami, od katerih je odvisna. Posameznih zbirk ali tabel med izdelavo kopije ne morete izbrati.

Operativna meja je dostop. Povezava uporablja replikacijski protokol, zato potrebuje vlogo s pravico REPLICATION ali superuporabnika, ustrezno dovoljenje v pg_hba.conf in razpoložljivo povezavo za pošiljanje WAL. Običajen dostop do ene zbirke za ta ukaz ne zadostuje. Obratno lahko z ustreznimi pravicami za zbirko izvedete pg_dump, vendar njen izvoz še ni kopija celotnega grozda.

Za samostojno uporabo mora fizična kopija vsebovati WAL, potreben za konsistenten zagon. pg_basebackup ga lahko zajame med izdelavo kopije, kar še ne pomeni, da so shranjene tudi vse poznejše spremembe. Pri načrtu obnove upoštevajte še ciljne poti za tabelne prostore in datoteke konfiguracije, če jih vaša namestitev hrani zunaj podatkovnega imenika.

Ko je cilj določen trenutek

Za vrnitev na izbrani trenutek združite fizično osnovno kopijo z neprekinjenim arhivom WAL. Med obnovo se zapisi predvajajo od osnovne kopije do izbrane točke. Arhiv mora segati najmanj do začetka izdelave osnovne kopije in ostati neprekinjen do želenega trenutka; vrzel lahko prepreči obnovo do cilja.

To je pomembno, kadar napačno spremembo odkrijete po drugih uspešnih spremembah, ki jih želite obdržati. Samostojen pg_dump vrne stanje ob izvozu, samostojna fizična kopija pa ne omogoča poljubne izbire poznejše obnovitvene točke. WAL, zajet samo za konsistentno odprtje osnovne kopije, ne nadomesti arhiva za obdobje po njej.

Obnova na izbrani trenutek zajame celoten grozd. Če iz tako obnovljenega stanja potrebujete le eno tabelo, grozd zaženite v ločenem primerku in tabelo prenesite od tam. Tako določena obnovitvena točka ne poseže neposredno v druge podatkovne zbirke delujočega sistema.

Vaja pokaže, kaj kopija dejansko vrne

V laboratorijski obnovitveni vaji s PostgreSQL 18 je avtor po simuliranem izbrisu obnovil podatke ene tabele iz arhiva pg_dump, v ločenem preizkusu pa zagnal grozd iz kopije pg_basebackup in preveril zapise. Vaja pokaže razliko v obsegu obnovitve, njen rezultat pa velja za opisano postavitev. Pri izbiri tabele je treba posebej preveriti tudi odvisne objekte, ki jih preprost izbor s pg_restore ne zajame.

Za lasten načrt sta smiselni dve ločeni vaji. V začasni zbirki obnovite izbrano tabelo ter preverite njene zapise, strukturo in potrebne povezane objekte. Nato v ločenem primerku obnovite fizično kopijo, zaženite PostgreSQL in preverite zbirke, ki morajo biti na voljo po odpovedi strežnika.

Če je zahtevana obnova na določeno točko, vajo dopolnite s predvajanjem arhiviranega WAL do vnaprej izbranega trenutka. Zabeležite čas do uporabnega sistema in najnovejši podatek, ki ste ga dejansko lahko obnovili. Tako preverite dve različni zahtevi: kako dolgo traja vrnitev v delo in koliko zadnjih sprememb bi ob izgubi ostalo nedosegljivih.

Preberite tudi:

• Ahrefs ali Semrush: 750 proti 500 ključnim besedam ne odloči vsega
• RAG ali fine-tuning: sveži podatki in vedenje zahtevajo različni poti
• pgvector ali Pinecone: več hitrosti lahko pomeni skoraj petkrat višji strošek