Postgresql 10 db helyreállítás

Adatbázis: SQL, XML DB

Helló!

 

Azt szeretném megkérdezni, hogy van-e lehetőségem helyreállítani:

 

waiting for server to start....2023-01-24 11:58:24.591 CET [85430] LOG:  listening on IPv6 address "::1", port 5433
2023-01-24 11:58:24.591 CET [85430] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2023-01-24 11:58:24.599 CET [85430] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5433"
2023-01-24 11:58:24.651 CET [85431] LOG:  database system was interrupted while in recovery at 2023-01-24 11:45:14 CET
2023-01-24 11:58:24.651 CET [85431] HINT:  This probably means that some data is corrupted and you will have to use the last backup for recovery.
................2023-01-24 11:58:41.117 CET [85431] LOG:  database system was not properly shut down; automatic recovery in progress
2023-01-24 11:58:41.134 CET [85431] LOG:  redo starts at 10EA/AED7CA08
2023-01-24 11:58:41.139 CET [85431] WARNING:  will not overwrite a used ItemId
2023-01-24 11:58:41.139 CET [85431] CONTEXT:  WAL redo at 10EA/AEF14050 for Heap/HOT_UPDATE: off 27 xmax 1192455519 ; new off 5 xmax 0
2023-01-24 11:58:41.139 CET [85431] PANIC:  failed to add tuple
2023-01-24 11:58:41.139 CET [85431] CONTEXT:  WAL redo at 10EA/AEF14050 for Heap/HOT_UPDATE: off 27 xmax 1192455519 ; new off 5 xmax 0
2023-01-24 11:58:41.300 CET [85430] LOG:  startup process (PID 85431) was terminated by signal 6: Félbeszakítva
2023-01-24 11:58:41.300 CET [85430] LOG:  aborting startup due to startup process failure
2023-01-24 11:58:41.302 CET [85430] LOG:  database system is shut down
 stopped waiting

 

Köszönöm!

( mauzi v | 2023. 01. 24., k – 13:19 )

you will have to use the last backup for recovery

Mi a kérdés? Nincs mentés?

( zeller | 2023. 01. 24., k – 13:28 )

Azért az összeborulás után meg kéne nézni, hogy miért hasalt el, nem csak úgy simán ráindítani, hogy hátha összevakarja magát...

( rattila | 2023. 01. 24., k – 13:31 )

A gépet nem én kapcsoltam be.

De persze én is próbáltam ráindítani.

Üdv:
Ruzsi

( Dhat | 2023. 01. 24., k – 20:40 )

Valaki nem állított át jogosultságot véletlenül a fájlokon?

( yoursoft | 2023. 01. 24., k – 20:50 )

Elég nagy méretű.

Elsőnek megpróbálnám lemásolni a data könyvtárat egy másik 10-es postgresql alá, akár localban is. Az élest nem piszkálnám, nehogy elrontsak valamit.

Igen egy újabb postgresql is segíthet, de ott csak a 10-esből. Ha nagyobb verzióra szeretne váltani, akkor ott migrálni kellene az adatstruktúrát.

Ha a lemásoltan sem indul el, akkor megpróbálnám a WAL logot valahogy rendbe tenni vagy üríteni a másolaton és úgy elindítani. Ez nem lesz egyszerű.

Így ha jól sejtem elveszíted az utolsó folyamatban lévő módosítás(oka)t, de még mindig jobb mint az elmúlt éveket.

Ha ez bejön, utána piszkálnám az élest. De legyen mentésed a data könyvtárról ha valami esetleg félrecsúszik így kezdheted tiszta lappal!

A pg_wal könyvtár alatt 5 db. 16M-ás fájl van.

Próbáltam törölni őket, de nem lett jobb, illetve kb. darabonkánt visszarakni, de úgy sem. Ezek akkoriak, amikor a ménykű beütött karácsony reggelén.

Az utolsó gyűjtött adatok nem igazán fontosak.

A adatbázisban lévő konfigurációkat 3-4 hónapja nem módosítottam. Ezek lennének a fontosak.

 

Mit kellene tudnom ezekről a WAL fájlokról? Van egy 7:43-as idejű és 4 db. 7:46-os.

Üdv:
Ruzsi

"2023-01-24 11:58:24.651 CET [85431] LOG:  database system was interrupted while in recovery at 2023-01-24 11:45:14 CET"

Nekem ebből úgy tűnik, hogy 11:45 előtt megpróbált elindulni szegény pg, aztán ki lett rúgva alóla a szék, miközben folyt a recovery, és ez már a következő próbálkozás - amibe viszont az előző, megszakított recovery miatt beledöglött. Szóval már piszkálták korábban a decemberben elhasalt DB-t, csak nem várták meg a recovery végét.
Nekem az a tapasztalatom, hogy bár vannak mimóza jellegű dolgai is, de elég jó a hibatűrése a pg-nek, és ha backup-ból történő visszatöltést javasol, akkor az nem véletlen...

Jó lenne látni a korábbi logokat, meg azt is tudni, hogy a recovery miért szakadt meg? Azért-e, mert már akkor olyan sérült adatbázist látott, amivel nem tudott mit kezdeni, vagy azért, mert elfogyott valami erőforrás (memória (OOM), diszk), vagy csak valakinek elfogyott a türelme (mondjuk az induló postgesql service túl sokáig várakoztatta) és felrúgta az egészet, mint a bolondgombát...

 

Kb. annyit sikerült kinyomoznom, hogy dec. 25.-én 7:45-8:xy között megdöglött a gép.

Hogy ez a Postgres miatt, vagy más miatt, azt nem tudom, bár meg tudom nézni.
Aztán egyszer csak valamikot január elején kiderült, hogy hiányzik a gép és vissza lett kapcsolva.
Gép elindult, de a Zabbix nem és ugye kapásból jött az üzenet, hogy a DB nem elérhető.

Szerintem az első induláskor nem várta ki a systemd az időt és ő lőtte ki. Talán.
Nyomozok.
 

A kb. 4 hónappal ezelőtti Zabbix konfigek kellenének. A begyűjtött adatok, trendek felejhetőek és természetesen
ez a nagy adatmennyiség.

Merre keressem a log-okat?

Az indulási időzítést próbáltam megnövelni egy -t 3600-zal és kézi indítással, de kb az ide küldött log-ot kaptam.

Üdv:
Ruzsi

Nem komplex, inkább favágó munka. A PG külön fájlban tárolja a tábláit, mindenestül, ki lehet tolni onnan valamilyen formátumba, aztán visszahúzni.

De B tervként egyébként érdemes lenne létrehozni egy üres Zabbix adatbázist felülcsapni az üres táblákat azokkal, amelyek kellenek.

https://iotguru.cloud

Hát, hogy belevau...

a Zabbix erősen épít a template-ekre. Meg az autodiscovery is jól szokott működni. Felteszem nem hostonként van az az ezres check. Így viszonylag hamar rá lehet dobni az összes gépre az alap ellenőrzéseket, és a template módosítása az összes érintett hostra érvényes.

A switch/snmp kicsit más dolog, azt annyira nem vágom, de alapvetően az is működött.

Persze nem lesz pont olyan, mint előtte. De lesz valami. És közben lehet ügyeskedni a DB helyreállításával.

( rattila | 2023. 01. 25., sze – 12:48 )

Talán a log legérdekesebb része:

2022-12-25 04:53:05.612 CET [208569] zabbix@zabbix FATAL:  the database system is in recovery mode
2022-12-25 04:53:05.718 CET [208542] LOG:  invalid record length at 10EA/9340AA8: wanted 24, got 0
2022-12-25 04:53:05.718 CET [208542] LOG:  redo done at 10EA/9340A58
2022-12-25 04:53:05.718 CET [208542] LOG:  last completed transaction was at log time 2022-12-25 04:53:02.294891+01
2022-12-25 04:53:06.632 CET [208572] zabbix@zabbix FATAL:  the database system is in recovery mode
2022-12-25 04:53:06.632 CET [208573] zabbix@zabbix FATAL:  the database system is in recovery mode
2022-12-25 04:53:06.638 CET [208574] zabbix@zabbix FATAL:  the database system is in recovery mode
2022-12-25 04:53:06.639 CET [208575] zabbix@zabbix FATAL:  the database system is in recovery mode
2022-12-25 04:53:08.371 CET [1407] LOG:  database system is ready to accept connections
2022-12-25 04:53:14.741 CET [208598] zabbix@zabbix ERROR:  out of shared memory
2022-12-25 04:53:14.741 CET [208598] zabbix@zabbix HINT:  You might need to increase max_locks_per_transaction.
2022-12-25 04:53:14.741 CET [208598] zabbix@zabbix STATEMENT:  select clock,ns,value from history_str where itemid=24790 and clock<=1671940389 and clock>1671936789 order by clock desc limit 2
2022-12-25 05:05:56.493 CET [208595] zabbix@zabbix ERROR:  index key does not match expected index column
2022-12-25 05:05:56.493 CET [208595] zabbix@zabbix STATEMENT:  delete from history where itemid=47247 and clock<1671334529
2022-12-25 07:37:29.874 CET [1407] LOG:  server process (PID 223159) was terminated by signal 9: Kilőve
2022-12-25 07:37:29.874 CET [1407] DETAIL:  Failed process was running: delete from history where itemid=26046 and clock<1671345070
2022-12-25 07:37:29.874 CET [1407] LOG:  terminating any other active server processes
2022-12-25 07:37:29.875 CET [213846] zabbix@zabbix WARNING:  terminating connection because of crash of another server process
2022-12-25 07:37:29.875 CET [213846] zabbix@zabbix DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared me
2022-12-25 07:37:29.875 CET [213846] zabbix@zabbix HINT:  In a moment you should be able to reconnect to the database and repeat your command.

...

A syslog már sajnos kishiftelődött. :-(

 

Úgy látom, kifogyott a shared memory-ból.

Üdv:
Ruzsi

Mondjuk recovery idejére nem ártott volna leállítani az _összes_ olyan szolgáltatást, ami akár csak egy percig is hozzá akar nyúlni a PG szerverhez.. bármilyen szinten. Ha jól látom itt a zabbixos állandó próbálkozás futott "out of shared memory" -ra .. Aztán lehet beindult az OOM killer és kilőtte recovery közben a PG-t.. de az OOM csak tipp.. Az viszont tényleg nagyon NEM JÓ hogy recovery módban cseszegeti az adatbázist a Zabbix.. 

022-12-25 04:53:08.371 CET [1407] LOG:  database system is ready to accept connections

^^ mondjuk ez is egy érdekes cucc, mert előtte nem látnám hogy befejezte volna a recovery-t ennek ellenére a PG server mégis úgy döntött, hogy oké, most már jöhetnek a "kliensek".

Tehát már karácsony táján összeborult/újraindult recovery módban - ha ez ugyanaz a gép, akkor jó esélyed van arra, hogy az általam hiányolt 2023-01-24 11:45:14 CET-et közvetlenül megelőző logok lennének az érdekesek, azok amik azt az időszakot fedik le, amikor a recovery megszakításra került.

Azon azért elgondolkodnék, hogy van ugyan zabbix, de azt, hogy alatta esik-kel a db, semmi és senki nem veszi észre, semmilyen riasztás nincs rá...

( yoursoft | 2023. 01. 25., sze – 12:50 )

Több kérdés is felmerült, így inkább külön szálat indítok:
Standard telepítésnél:
1. A logokat a /var/log/postgresql alatt kellene ubuntu alatt keresned

2. A maga a db (data) a /var/lib/postgresql/10 alatt van

3. A config fájlokat a /etc/postgresql* alatt találod

4. Sibike kolléga által ajánlott pg_resetwal lehet a megoldásod a wal log-ra, ne törölgesd kézzel.

Közben azért kutakodom én is és megtaláltam mindent a fent említett helyeken. Köszönöm, hogy leírtad ezeket, jó, ha pontosan tudom, mit merre találok.

A pg_resetwal-lal megvárom a + HDD-t és akkor állok neki.
A log-ban látott WAL koordinátákra szükségem lesz majd?

Üdv:
Ruzsi

Még nem kellett ilyet kiadnom. De ha van mentésed a komplett main könyvtárról. Akkor többször is próbálkozhatsz.

Még érdemes leállítani majd a Zabbix-et vagy letiltani a hozzáférését pl. tűzfallal a postgresql-hez, hogy közbe nem próbálkozzon a postgresql-el, mert csak bekavar. Addig kell csak leállítani, amíg a DB normálisan el nem indul egyszer.

( rattila | 2023. 02. 10., p – 08:00 )

No, tegnap előtt sikerült betenni a gépbe egy 1T-s HDD-t és lemásolni a pgsql DATA könyvtárat.

 

Ma ezzel kezdtem:
 

postgres@tarthost:/usr/lib/postgresql/10/bin$ ./pg_resetwal -n /var/lib/postgresql/10/main
Current pg_control values:

pg_control version number:            1002
Catalog version number:               201707211
Database system identifier:           6890877792838121257
Latest checkpoint's TimeLineID:       1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          2:1192455519
Latest checkpoint's NextOID:          137822
Latest checkpoint's NextMultiXactId:  10609
Latest checkpoint's NextMultiOffset:  21217
Latest checkpoint's oldestXID:        992398938
Latest checkpoint's oldestXID's DB:   16385
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 16385
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Size of a large-object chunk:         2048
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
Data page checksum version:           0

Values to be changed:

First log segment after reset:        00000001000010EA000000B0

 

Van itt valami paraméterezendő a számomra?

Üdv:
Ruzsi

( rattila | 2023. 02. 10., p – 10:16 )

Úgy néz ki, sikerült elindulnia a DB-nek!
Köszönöm asegítséget!!!

2023-02-10 10:13:14.996 CET [25013] zabbix@zabbix ERROR:  out of shared memory
2023-02-10 10:13:14.996 CET [25013] zabbix@zabbix HINT:  You might need to increase max_locks_per_transaction.
2023-02-10 10:13:14.996 CET [25013] zabbix@zabbix STATEMENT:  select clock,ns,value from history where itemid=28069 and clock>1676020091
2023-02-10 10:13:15.328 CET [25011] zabbix@zabbix ERROR:  out of shared memory

 

Hol kellene állítani ezen a shared memory-n? Zabbix és/vagy Postgresql?

Üdv:
Ruzsi

( rattila | 2023. 02. 10., p – 18:03 )

Semmi extra!

Már 7.-e óta, azaz amikor a kollégám betette a mentési 1T-s HDD-t, fut a Postgresql!

Erősen meglepődtem! Szóval igazán nem tudom.

Én a pg_resetwal programmal próbálkoztam, ami szépen le is futott, leállított Zabbix szerver, de ezek szerint futó PGSQL mellett és azóta megy.

Jött, ment és eltelt 1,5 hónap ... Ilyen ez az 'ámítástechnika. Paranormális.

 

Most szeretném kitisztítani a felesleges gyűjtött adatokat és menteni a Zabbix DB-t.
De ehhez fel kellene eleveníteni a 2017, 2019-es emlékeim...
Ja, azóta találtam vagy 3 mentést is ...

Üdv:
Ruzsi