Minu esimene kogemus Postgresi andmebaasi taastamisega pärast tõrget (invalid page in block 4123007 of relation base/16490)

Tahaksin jagada teiega oma esimest edukaid kogemusi Postgresi andmebaasi täieliku töövõime taastamisel. Olen tutvunud Postgresi andmebaasihalduriga pool aastat tagasi; enne seda ei olnud mul andmebaaside haldamise kogemust üldse.

Töötan pool-DevOps insenerina suures IT-ettevõttes. Meie ettevõte tegeleb tarkvaraarendusega suure koormusega teenustele, mina olen vastutav töövõime, hoolduse ja juurutamise eest. Minu ülesandeks oli tavaline ülesanne: uuendada rakendust ühel serveril. Rakendus on kirjutatud Django's ja uuendamise käigus toimuvad migratsioonid (andmebaasi struktuuri muutmine), ning enne seda protsessi teeme, igaks juhuks, täisdumpi andmebaasist standardse pg_dump programmiga.

Dumpi tegemise käigus tekkis ettenägematu viga (Postgresi versioon – 9.5):

pg_dump: Tabeli "ws_log_smevlog" sisu väljavõttmine ebaõnnestus: PQgetResult() ebaõnnestus. 
pg_dump: Serveri veateade: VIGA: kehtetu leht plokis 4123007 suhtes andmebaasis /16490/21396989
pg_dump: Käsk oli: COPY public.ws_log_smevlog [...]
pg_dunp: [paralleelne arhitüür] töötaja protsess lõpetas ootamatult.

Viga "kehtetu leht plokis" näitab failisüsteemi tasandi probleeme, mis ei ole sugugi hea. Erinevates foorumites soovitati teha FULL VACUUM valikuga zero_damaged_pages selle probleemi lahendamiseks. Mis siis, proovime…

Taastumise ettevalmistamine

TÄHELEPANU! Veenduge, et teete enne andmebaasi taastamise katset kindlasti varukoopia Postgresest. Kui teil on virtuaalne masin, peatage andmebaas ja tehke snapshot. Kui snapshot'i tegemine pole võimalik, peatage andmebaas ja kopeerige Postgrese katalooge (sealhulgas wal-failid) usaldusväärsesse kohta. Meie töös on kõige olulisem mitte halvemaks teha. Loe see.

Kuna overall andmebaas töötas, piirdusin tavapärase andmebaasi dumpimisega, kuid jätsin välja tabeli, kus olid rikutud andmed (valik -T, --exclude-table=TABLE pg_dump-i jaoks).

Server oli füüsiline, snapshot'i tegemine polnud võimalik. Varukoopia on tehtud, liikuge edasi.

Failisüsteemi kontrollimine

Enne andmebaasi taastamise katset on oluline veenduda, et meie failisüsteem on kõik korras. Ja juhul, kui esineb vigu, tuleb need parandada, kuna vastasel juhul saab teha ainult hullemaks.

Minu puhul oli andmebaasiga failisüsteem manustatud "/srv" ja tüüp oli ext4.

Peatame andmebaasi: systemctl stop postgresql@9.5-main.service ja kontrollime, et failisüsteemi ei kasutata ning seda saab külmutada käsu abil lsof:
lsof +D /srv

Pidin peatama ka Redis andmebaasi, kuna see kasutab samuti "/srv". Edasi külmutasin /srv (umount).

Failisüsteemi kontroll tehti tööriistaga e2fsck keermega -f (Sundkontroll, isegi kui failisüsteem on puhtaks märgitud):

Edasi kasutades tööriista dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep checked) saame veenduda, et kontroll on tõepoolest teostatud:

e2fsck ütleb, et probleeme ext4 failisüsteemi tasemel ei leitud, mis tähendab, et saame jätkata andmebaasi taastamise katseid, viidates täpsemalt vacuum full (loomulikult on vajalik failisüsteemi tagasi mountida ja andmebaasi käivitada).

Kui sul on füüsiline server, siis kontrolli kindlasti ketaste seisundit (kasutades smartctl -a /dev/XXX) või RAID-kontrollerit, et veenduda, et probleem ei ole riistvaraline. Minu puhul oli RAID "raud", seetõttu palusin kohalikul adminil kontrollida RAIDi seisundit (server oli minust mitusada kilomeetrit eemal). Ta ütles, et vigu pole, seega saame kindlasti taastamisega alustada.

Katse 1: zero_damaged_pages

Ühendame andmebaasiga psql kaudu kasutajaga, kellel on superkasutaja õigused. Meil on tõesti vaja superkasutajat, kuna valikut zero_damaged_pages suudab muuta ainult tema. Minu juhul on see postgres:

psql -h 127.0.0.1 -U postgres -s [database_name]

Valik zero_damaged_pages on vajalik lugemisvigade ignoreerimiseks (PostgresPro veebilehelt):

Kui on tuvastatud kahjustatud lehe pealkiri, teatab Postgres Pro tavaliselt veast ja katkestab antud tehingu. Kui parameeter zero_damaged_pages on lubatud, siis kuvab süsteem selle asemel hoiatused, nullib mälus kahjustatud lehe ja jätkab töötlemist. See käitumine hävitab andmed, nimelt kõik read kahjustatud lehes.

Lülitame valiku sisse ja proovime teha tabeli täielikku vacuumit:

VACUUM FULL VERBOSE

Kahjuks ebaõnnestus.

Seisime silmitsi sarnase veaga:

INFO: vacuuming "“public.ws_log_smevlog”
WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page
ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_toast – mehhanism "piklike andmete" salvestamiseks Poetgress, kui need ei mahutu ühte lehte (vaikimisi 8 kb).

Katse 2: reindex

Google'i esimene soovitus ei aidanud. Pärast mõne minuti otsimist leidsin teise soovituse – teha reindex defektse tabeli. Seda nõuannet olen kohanud paljudes kohtades, kuid see ei andnud usaldusväärsust. Teeme reindex:

reindex table ws_log_smevlog

reindex lõppes probleemideta.

Kuid see ei aidanud, VACUUM FULL krahhis lõppes analoogse veaga. Kuna olin harjunud ebaõnnestumistega, hakkasin internetis edasisi nõuandeid otsima ja sattusin üsna huvitavale artiklit.

Katse 3: SELECT, LIMIT, OFFSET

Ülaltoodud artiklis soovitati vaadata tabelit rida-realt ja eemaldada probleemsed andmed. Alustuseks pidi kõiki ridu vaatama:

for ((i=0; i/dev/null || echo $i; done

Minu puhul sisaldas tabel 1 628 991 ridu! Headuses oleks olnud vajalik hoolitseda andmete partitsioneerimise eest, kuid see on eraldi arutelu teema. Oli laupäev, käivitasin selle käsu tmuxis ja läksin magama:

for ((i=0; i/dev/null || echo $i; done

Hommikuks otsustasin kontrollida, kuidas asjad edenevad. Minu üllatuseks avastasin, et 20 tunni jooksul oli skaneeritud vaid 2% andmetest! Ma ei tahtnud oodata 50 päeva. Järjekordne täielik ebaõnnestumine.

Aga ma ei lasknud alla. Mind hakkas huvitama, miks skaneerimine kestis nii kaua. Dokumentatsioonist (taas postgrespro) sain teada:

OFFSET näitab, et tuleb vahele jätta määratud arv ridu, enne kui hakatakse ridu väljundisse andma.
Kui on määratud nii OFFSET kui ka LIMIT, siis süsteem kõigepealt jätab vahele OFFSET read ja seejärel hakkab loendama ridu LIMIT piirmäära jaoks.

LIMITi rakendamisel on oluline kasutada ka ORDER BY klauslit, et tulemuste read väljastataks kindlas järjekorras. Vastasel juhul tagastatakse ettearvamatud alamkogud ridu.

Ilmselgelt oli ülaltoodud käsk vale: kõigepealt ei olnud order by, tulemus võis olla vale. Teiseks pidi Postgres esmalt skaneerima ja vahele jätma OFFSET-read, ning koos kasvu CHECKSUM_AGG väheneks tootlikkus veelgi.

Katse 4: võtta dump tekstivormingus

Seejärel tuli mulle pähe, näiliselt geniaalne idee: võtta dump tekstivormingus ja analüüsida viimast salvestatud rida.

Aga kõigepealt tutvume tabeli struktuuriga ws_log_smevlog:

Meie puhul on meil veerg „id“, mis sisaldas ridu unikaalset identifikaatorit (loenduri). Plaan oli järgmine:

1. Alustame dumpi tegemist tekstivormingus (sql-käskudena)
2. Teatud hetkel katkeb andme salvestamine vea tõttu, kuid tekstifail oleks ikkagi kettale salvestatud.
3. Vaadates tekstifaili lõppu, leiame viimase rida id, mis salvestati edukalt.

Alustasin andmete salvestamist tekstivormingus:

pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

Andmete salvestamine katkeb, nagu oodata oli, sama vea tõttu:

pg_dump: Serveri veateates: ERROR: invalid page in block 4123007 of relation base/16490/21396989

Seejärel vaatasin tail ma dumpi lõppu (tail -5 ./my_dump.dump) ja avastasin, et dump katkeb real, mille id on 186 525. "Tähendab, probleem on real, mille id on 186 526, see on vigane, see tuleb kustutada!" - mõtlesin ma. Kuid kui tegin päringu andmebaasi:
«select * from ws_log_smevlog where id=186529» selgus, et selle reaga on kõik korras... Rida, mille indeksid on 186 530 – 186 540 töötasid samuti probleemideta. Järjekordne "geniaalne idee" ebaõnnestus. Hiljem sain aru, miks see juhtus: andmete kustutamisel või muutmisel tabelist ei kustutata neid füüsiliselt, vaid need märgitakse „surnud tupplehtedeks", seejärel tuleb autovacuum ja märgib need read kustutatutena ja lubab neid kasutada uuesti. Üheks selgituseks, kui andmed tabelis muutuvad ja autovacuum on sisse lülitatud, siis need ei säili järjestikku.

Katse 5: SELECT, FROM, WHERE id=

Ebaõnnestumised muudavad meid tugevamaks. Ei tasu kunagi alla anda, tuleb minna lõpuni ja uskuda endasse ja oma võimalustesse. Seetõttu otsustasin proovida veel ühte varianti: vaadata lihtsalt kõik kirjed andmebaasis ükshaaval. Teades oma tabeli struktuuri (vt ülal), on meil id, mis on ainulaadne (peamine võti). Tabelis on 1 628 991 rida ja id need on järjestatud, mis tähendab, et saame neid lihtsalt ükshaaval läbi vaadata:

for ((i=1; i/dev/null || echo $i; done

Kui keegi ei mõista, töötab käsk järgmiselt: vaatab tabelit realt real ja saadab stdout-i /dev/null, kuid kui SELECT-käsk ebaõnnestub, kuvatakse veateksti (stderr saadetakse konsooli) ja väljastatakse üksus, mis sisaldab viga (tänu ||, mis tähendab, et SELECT-l tekkisid probleemid (käskluse väljumiskood ei ole 0)).

Mul oli vedanud, mul oli välja töötatud indekseid alusel id:

See tähendab, et õige id-ga rea leidmine ei tohiks võtta palju aega. Teoorias peaks see toimima. Noh, käivitan käsu. tmux ja lähen magama.

Hommikuks avastasin, et olin vaadanud umbes 90 000 kirjet, mis moodustab veidi üle 5%. Suurepärane tulemus, kui võrrelda eelneva meetodiga (2%)! Kuid 20 päeva ootamine ei olnud just see, mida ma tahtsin...

Katse 6: SELECT, FROM, WHERE id >= ja id <

Kliendi andmebaasiks oli saadaval suurepärane server: kaheprotsessoriline Intel Xeon E5-2697 v2, meie käsutuses oli lausa 48 lõime! Serveri koormus oli keskmine, saime probleemideta võtta umbes 20 lõime. Ka RAM-i oli piisavalt: koguni 384 gigabaiti!

Seetõttu tuli käsk anda paralleelselt:

for ((i=1; i/dev/null || echo $i; done

Siin oleks võinud kirjutada kauni ja elegantse skripti, kuid ma valisin kiireima paralleelimise viisi: jagasin vahemiku 0-1628991 käsitsi intervallideks 100 000 kirjet ja käivitasin eraldi 16 käsu järgmist tüüpi:

for ((i=N; i/dev/null || echo $i; done

Aga see ei ole kõik. Tegelikult võtab andmebaasi ühendamine ka mingil ajal ja süsteemi ressursse. Ühendamine 1 628 991 puhul ei olnud just väga mõistlik, nõustuge. Seetõttu tõmbleme ühe ühenduse all 1000 rida ühe asemel. Ehk käsk muutus selliseks:

for ((i=N; i=$i and id/dev/null || echo $i; done

Avame 16 akent tmux sessioonis ja käivitame käsud:

1) for ((i=0; i=$i and id/dev/null || echo $i; done
2) for ((i=100000; i=$i and id/dev/null || echo $i; done
…
15) for ((i=1400000; i=$i and id/dev/null || echo $i; done
16) for ((i=1500000; i=$i and id/dev/null || echo $i; done

Päeva pärast sain esimesed tulemused! Nimelt (väärtused XXX ja ZZZ ei salvestunud):

ERROR: puudu olev lõhik nummer 0 toast väärtusele 37837571 pg_toast_106070
829000
ERROR: puudu olev lõhik nummer 0 toast väärtusele XXX pg_toast_106070
829000
ERROR: puudu olev lõhik nummer 0 toast väärtusele ZZZ pg_toast_106070
146000

See tähendab, et meil on kolm rida, mis sisaldavad viga. Esimese ja teise probleemse kirje id asusid vahemikus 829 000 ja 830 000, kolmanda id vahel oli vahemikus 146 000 ja 147 000. Edasi pidime lihtsalt leidma probleemsete kirjete täpsed id väärtused. Selleks vaatame meie probleemsete kirjetega vahemikku samm-sammult ja tuvastame id:

for ((i=829000; i/dev/null || echo $i; done
829417
ERROR: unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070
829449
for ((i=146000; i/dev/null || echo $i; done
829417
ERROR: unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070
146911

Õnnelik lõpplahendus

Me leidsime probleemsed read. Siseneme andmebaasi läbi psql ja proovime need eemaldada:

my_database=# delete from ws_log_smevlog where id=829417;
DELETE 1
my_database=# delete from ws_log_smevlog where id=829449;
DELETE 1
my_database=# delete from ws_log_smevlog where id=146911;
DELETE 1

Minu üllatuseks kustutati kirjed probleemideta ka ilma valikuta zero_damaged_pages.

Seejärel ühendasin andmebaasiga, tegin VACUUM FULL (arvan, et see polnud vajalik), ja lõpuks sain edukalt varukoopia läbi pg_dump. Dump tehti ilma igasuguste vigadeta! Probleem sai lahendatud nii primitiivsel viisil. Õnne polnud piire, pärast nii paljusid ebaõnnestumisi leidsin lõpuks lahenduse!

Tänud ja järeldused

Selline oli minu esimene kogemus Postgresi andmebaasi taastamisel. Selle kogemuse mäletan pikalt.

Ja lõpetuseks, tahaksin tänada ettevõtet PostgresPro vene keelde tõlgitud dokumentatsiooni eest ja täiesti tasuta online-kursused, mis aitasid mul probleemi analüüsimisel väga palju.

Allikas: habr.com