PostgreSQL: objem a obsah WAL logů zpětně

[jhonzatko]

Ahoj,
rad bych se tu na zkusenejsi a znalejsi obratil s prosbou o radu.
Resim situaci, kdy se mi zblaznila nejaka Postgre instance a za vikend vygenerovala nestandardne velke mnozstvi wal logu, coz nekolikrat vedlo k ucpani archivniho file systemu, jelikoz se fs zaplnil drive nez doslo ke spusteni naplanovane zalohy archivnich logu.
Dle uzivatelu nemela nad db probihat zadna nestandardni aktivita a ja se ted zpetne snazim zjistit, co se tam vlastne stalo.

Na Oracle mam k dispozici view, pres ktera jsem schopny zjistit objem vygenerovanych logu zpetne a nejak to porovnat s beznym vikendem, pripadne v EE mam k dispozici ASH pro analyzu probehle aktivity. Na Postgre se mi zatim nic podobneho najit nepodarilo. Existuje zde ve standardu neco, cim bych se toho dopatral?
Pripadne existuje nejaka moznost vycist to z tech archivovanych wal logu?
Auditovani tam bohuzel nemam zapnuto, takze ze standardniho logu to nevyctu.
Diky moc za pripadne napady ci nasmerovani!

[Reklama]

[Pavel Stěhule]

V Postgresu samotném nikde nevidíte historická data. Pro provoz se doporučuje používat aplikace jako je Munin, Zabix, pgwatch2, ... které si metriky z Postgresu sbírají a drží historii. Postgres sám to nedělá. Pokud jste žádný takový tool neměli, tak nic nenajdete.

[czechsys]

pgbadger by vam to z logu vytahl, ale pokud WALy nelogujete, tak...

[NaRootuJeNeskutecneDebilniRegistracniFormular]

Pripadne existuje nejaka moznost vycist to z tech archivovanych wal logu?

pg_xlogdump/pg_waldump?

[jhonzatko]

V Postgresu samotném nikde nevidíte historická data. Pro provoz se doporučuje používat aplikace jako je Munin, Zabix, pgwatch2, ... které si metriky z Postgresu sbírají a drží historii. Postgres sám to nedělá. Pokud jste žádný takový tool neměli, tak nic nenajdete.

Diky moc za potvrzeni, alespon vim, ze se s tim nema smysl dal trapit A nadhodim ke zvazeni, zda neco zminovaneho do budoucna nenasadit.

pg_xlogdump/pg_waldump?

Diky za napad. Tohle jsem zkousel jako prvni, ale vytahnul jsem z toho jen info, ktere mi bohuzel prilis nepomohlo. Potreboval bych vedet, ktera aplikace do toho "busila", resp. ktery uzivatel atd. Ale to jsem z toho nevycetl.

pgbadger by vam to z logu vytahl, ale pokud WALy nelogujete, tak...

WAL logy archivujeme, takze k dispozici je mam. Zkusim se na tuhle variantu podivat, diky!

[Reklama]

[czechsys]

pgbadger by vam to z logu vytahl, ale pokud WALy nelogujete, tak...

WAL logy archivujeme, takze k dispozici je mam. Zkusim se na tuhle variantu podivat, diky!

Pozor na rozdil mezi archivaci WAL a logovani do postgresql.log.

Jinak, jeste mate jednu moznost, kdyz mate ty WALy. Spuste si obnovu na server stranou a nastavte si log jak potrebujete a muzete sledovat...

[jhonzatko]

Diky, koukal jsem ted na ten pgbadger a uz jsem taky zjistil, ze to parsuje klasicky log a netyka se to WAL logu.
Moje chyba, spatne jsem to pochopil.
Jinak napad s nastavenim logu a naslednou obnovou je fajn, ale nejspis to v tomto konkretnim pripade nebude mozne.

[Pavel Stěhule]

Diky, koukal jsem ted na ten pgbadger a uz jsem taky zjistil, ze to parsuje klasicky log a netyka se to WAL logu.
Moje chyba, spatne jsem to pochopil.
Jinak napad s nastavenim logu a naslednou obnovou je fajn, ale nejspis to v tomto konkretnim pripade nebude mozne.

Tak jestli máte archivované wal logy, tak možná tam budete mít atime v souboru - je otázkou ale jak daleko do historie máte archiv wal - dost často se drží 2 týdny, max měsíc - i když záleží na provozu. Případně transakční log má v sobě nějaké timestampy, minimálně kvůli implementaci recovery_target_time, takže z toho by se dal odvodit čas vytvoření transakčního logu. Na to abyste se podíval, co je v transakčním logu slouží https://www.postgresql.org/docs/current/pgwaldump.html