„PostgreSQL“ kopija dar neveikia: vientisumo patikros nepakanka

|Autorius: QUASA redakcija|4 min. skaitymo
„PostgreSQL“ kopija dar neveikia: vientisumo patikros nepakanka

„PostgreSQL“ atsarginę kopiją laikykite patikrinta tik tada, kai ji atkuriama izoliuotoje aplinkoje, o atkurtuose duomenyse veikia programai svarbios užklausos. Bazinės kopijos failus ir manifestą tikrinančio įrankio „pg_verifybackup“ dokumentacija aiškiai nurodo, kad sėkminga vientisumo patikra neapima visų patikrų, kurias atliks paleistas serveris.

Jei kopija yra „pg_dump“ archyvas, atkurkite jį į tuščią bandomąją bazę: „pg_restore“ dokumentacijoje aprašyta parinktis „--exit-on-error“ sustabdo atkūrimą įvykus SQL komandos klaidai. Fizinei bazinei kopijai reikia atskiro serverio paleidimo bandymo. Abiem atvejais po atkūrimo patikrinkite svarbiausias lenteles, programos teises ir duomenų šviežumą.

Nustatykite kopijos tipą

Patikros kelias priklauso nuo to, kaip kopija sukurta. „pg_basebackup“ aprašas nurodo, kad įrankis kopijuoja visą duomenų bazių klasterį ir įprastai sukuria „backup_manifest“. Tokiai kopijai skirta „pg_verifybackup“ patikra; „pg_restore“ priima ne paprasto teksto formato „pg_dump“ archyvus. Šie įrankiai nėra vienas po kito vykdomi veiksmai tam pačiam failui.

Prieš automatizuodami bandymą užrašykite kopijos tipą, vietą, sukūrimo laiką ir serverio versiją. Paprasto SQL teksto išrašas vykdomas SQL klientu, todėl jam reikia atskiros bandymo šakos ir nustatymo, kuris sustabdytų vykdymą įvykus klaidai. Jei laikote ir fizines, ir logines kopijas, kiekvienai taikykite jos formatą atitinkančią atkūrimo procedūrą.

Manifestu patikrinkite bazinės kopijos failus

„PostgreSQL“ bazinės kopijos manifeste numatyto failo trūkumas aptinkamas prieš atkūrimą.

Bazinei kopijai su manifestu paleiskite „pg_verifybackup --exit-on-error /kelias/iki/kopijos“. Įrankis patikrina, ar manifestas perskaitomas, ar yra numatyti failai ir ar sutampa manifeste pateiktos jų kontrolinės sumos. Jei kuriant manifestą failų kontrolinės sumos buvo išjungtos, ši patikros dalis negali patvirtinti failų turinio. Paprasto formato kopijoje įrankis taip pat skaito atkūrimui reikalingus WAL įrašus.

„PostgreSQL“ 18 „pg_verifybackup“ gali tikrinti ir tar formato bazinę kopiją, bet jos WAL analizė taikoma tik paprastam formatui. Tar kopijai naudokite „--no-parse-wal“ ir žurnale pažymėkite, kad WAL šiuo žingsniu nepatikrinti. Jei WAL laikomi atskirai, paprasto formato kopijai galima nurodyti jų katalogą; WAL analizei naudokite tikrinamos kopijos versiją atitinkantį įrankį.

Scenarijuje vertinkite komandos baigimo kodą, o ne vien tai, ar atsirado žurnalo failas. Aptikta klaida turi nutraukti sėkmės kelią ir išsaugoti diagnostiką. Taip pat užrašykite, ar buvo praleistos kontrolinės sumos arba WAL analizė: vienodas pranešimas „patikrinta“ tokiems skirtingiems rezultatams būtų klaidinantis.

Atkurkite kopiją izoliuotoje aplinkoje

„pg_dump“ archyvas atkuriamas į atskirą bandomąją „PostgreSQL“ duomenų bazę.

„pg_dump“ archyvui paruoškite atskirą bandomąjį „PostgreSQL“ egzempliorių ir tuščią bazę. Sąlyginė komandų seka: „createdb -T template0 bandymas“, tada „pg_restore --exit-on-error -d bandymas kopija.dump“. Pavadinimus pakeiskite savais, o ryšio parametrus nukreipkite į bandomąjį egzempliorių. „template0“ padeda išvengti papildomų objektų, kurie gali būti vietoje pakeistoje numatytojoje bazės šablono kopijoje.

„--exit-on-error“ leidžia iš karto užfiksuoti pirmą SQL klaidą, tačiau savaime neatšaukia jau įvykdytų komandų. Jei būtina, kad nepavykus bandymui bandomoji bazė liktų be iš dalies atkurtų objektų, „pg_restore“ turi ir „--single-transaction“ parinktį; dideliems archyvams jos tinkamumą reikia įvertinti pagal turimus išteklius. Kitu atveju po nesėkmingo bandymo ištrinkite bandomąją bazę ir kitą kartą pradėkite nuo tuščios.

Fizinei bazinei kopijai „pg_restore“ netinka. Jos turinį paruoškite atskirame duomenų kataloge, pasirūpinkite reikalingais WAL įrašais ir paleiskite atskirą serverį; tar archyvus prieš paleidimą reikia išskleisti, o papildomų lentelių erdvių failus padėti į tinkamas vietas. Jei serveris nepasileidžia, vien ankstesnis manifestą tikrinusios komandos sėkmės kodas kopijos atkuriamumo neįrodo.

Patikrinkite duomenis ir programos prieigą

Atkurtos „PostgreSQL“ lentelės naujausias įrašas vertinamas pagal pasirinktą duomenų šviežumo ribą.

Sėkmingas atkūrimas dar neparodo, ar bazėje yra programai reikalingas turinys. Iš anksto pasirinkite kelias kritines lenteles ir patikrinkite, ar jos egzistuoja, ar jose yra tikėtinų įrašų ir ar susijusių įrašų užklausos grąžina prasmingą rezultatą. Sąlyginėje užsakymų sistemoje tai galėtų būti užsakymo ir jo būsenos ryšys; tikrinamas lenteles reikia parinkti pagal tikrąją savo programos schemą.

Tada prisijunkite programos naudojamu vaidmeniu ir vykdykite reprezentatyvias tik skaitymo užklausas. Administratorius gali matyti atkurtą lentelę net tada, kai programos vaidmeniui trūksta teisių arba jos laukiamas objektas nepasiekiamas. Jei bandote ir programos funkcijas, naudokite izoliuotą jos konfigūraciją, kad bandymas nesikreiptų į gamybines integracijas.

Duomenų šviežumą lyginkite su iš anksto nustatyta priimtino praradimo riba. Pavyzdžiui, galite palyginti naujausio įrašo laiką atkurtose užsakymų lentelėse su paskutiniu įrašu, žinomu prieš kopijos sukūrimą. Po kopijavimo atsiradusių duomenų pačioje kopijoje nebus. Jei pasirinkta lentelė kartais ilgai nesikeičia, jos naujausias įrašas nėra pakankamas matas: kartu naudokite kopijos laiką arba specialų kontrolinį įrašą.

Automatizuokite sprendimą ir išsaugokite rezultatą

Automatinis bandymas turi sustoti vos nepavyksta būtinas etapas: kopijos tipo nustatymas, atitinkama failų patikra, atkūrimas, duomenų bei programos užklausos arba šviežumo palyginimas. Bendrą sėkmę skelbkite tik praėjus visoms jūsų procedūroje privalomoms patikroms. Taip atskirsite tvarkingų failų rinkinį nuo atkurtos bazės, kurią iš tiesų galėtų naudoti programa.

Žurnale išsaugokite kopijos identifikatorių, jos sukūrimo ir bandymo laiką, naudotas versijas, kiekvieno etapo baigimo kodą, tikrintus duomenų požymius ir nesėkmės priežastį. Registruokite ir atkūrimo trukmę: ji parodo, kiek laiko užėmė būtent išbandyta procedūra. Toks įrašas leidžia aiškiai matyti, kuri kopija buvo patikrinta, kiek duomenų pavyko grąžinti ir kuriame etape bandymas sustojo.

Taip pat skaitykite:

Dalintis:

Prenumeruokite mūsų naujienlaiškį

Gaukite naujausias Web3, DI ir kriptovaliutų naujienas tiesiai į savo el. pašto dėžutę.

0