Dotaz: Postgres 9 - Dotaz na postgres profiky - autovacuum konflikt

[DBmania]

Resim problem ohledne konfliktu autovakua, ktery zamkne pristup k tabulce(to prevent wraparound) a aplikace nad postgresem ostrouha. Jak resite problem, aby autovacuum neblokoval pristup? Jedna se o několika TB db. Podle dokumentace si postgres ridi autovacuum proces sam a rucni spusteni se nedoporucuje...pouze v nouzovych pripadech a pri zastaveni komunikace postgresu s aplikaci. Co s tim?

Odpovědi

[X]

Urcite? Vacuum neblokuje pristup viz dokumentace:

Plain VACUUM (without FULL) simply reclaims space and makes it available for re-use. This form of the command can operate in parallel with normal reading and writing of the table, as an exclusive lock is not obtained.

Dale z diskuze zde:

If the vacuum finds a lot of empty pages at the end of the table, it will try to truncate them and takes a strong lock to do so. It is supposed to check every 20ms to see if anyone else is blocked on that lock, at which point it stops doing the truncation and releases the lock. So it should never get "caught" holding the lock in order to be cancelled.

Dale je tam zminovana oprava ve verzi 9.6.16. Mimochodem postgress 9 ma release date 2010. To je deset let stara databaze??

[DBmania]

Urcite. Prechod na novejsi verzi je planovan, ale ne zitra ani za tyden.

[J]

To bude nejaky dobry oddil kdyz pouziva 13let starou DB… az se mi chce rict jmeno jedne ceske banky…

[okbobcz]

Nevím, kde jste četl, že se ruční přístup nedoporučuje? VACUUM se ručně pouští běžně (i se zapnutým autovacuuem). Autovacuum volá VACUUM FREEZE, které řeší wraparound v neblokujícím režimu, nicméně pokud se z nějakého důvodu nedokončí tak jej finálně pustí v blokujícím režimu (možná jste jej canclovali ručně, možná to něco ve vašem stacku to canclovalo. A pokud by ani toto nedoběhlo, tak se vám pak zastaví Postgres.

Jinak běžně můžete předejít automatickému spuštění VACUUM FREEZE tím, že ručně (typicky když máte slabší provoz) spustíte VACUUM FREEZE. Je tam docela hezká vychytávka. Data, která jsou už zafreezovaná se znovu nefreezují - při dalším spuštění se freezují jen datové stránky změněné po posledním volání příkazu VACUUM FREEZE. Je průser, když se to spustí jednou za uherský rok - pak to běží dlouho (v podstatě to přepisuje celou databázi). Je lepší to ručně spustít jednou za pár měsíců.

Teď jste ve stavu, kdy bych to nechal doběhnout - případně můžete vypnout autovacuum, a pořešit to ručně. Ale asi sami dobře víte, kolik toho o Postgresu víte, a jaká je šance, že něco zmrvíte, tak být váma, bych nechal autovacuum doběhnout. Do toho stavu, kde jste, jste se při trochu rozumné údržbě neměli nikdy dostat.

[DBmania]

Ano, došlo to do stavu, kdy se autovacuum spustil v blokujicim rezimu. DB dostava konstatne zabrat a v kombinaci s velkym mnozstvim dat to autovacuum sem tam neda. Dela to jen u jedne velke DB s xTB dat, u mensich DB to neni problem. A mate pravdu, tady v tom konkretnim pripade se bude muset zavest vynuceny VACUUM FREEZE ve vhodnych oknech, nejspise o vikendech.

Dekuji za reakce.

[okbobcz]

Pripadne, abyste zmensili rizika, tak autovacuum muzete vypnout per tabulka (pripadne konfigurovat per tabulka), pripadne u velke zateze a vetsich tabulek se doporucuje trochu potunit autovacuum: a) aby se poustel casteji (stahnout prahy na polovic pripadne prejit na absolutni cisla - 20% z stovek milionu radku uz je prilis), b) aby bezel rychleji (stahnout delay, nebo zvysit cost limit).

[DBmania]

Poladit autovacuum je urcite vhodne ke zvazeni, nicmene aktualne to chci spise tlacit do nizkozatezovych casovych oken, tady to znm. vikendy, kdy jsou io operace na minimu a system skoro nic nedela. Kdyz tu ta moznost je, tak rutinni autovacuum 1-2x do mesice by mel zajistit, ze si da autovacuum pohov v dobe nejvetsi zateze systemu, ale to se musi vyzkouset.

[okbobcz]

pokud mate takovy typ zateze, tak urcite o kazdy vikend vacuum freeze analyze, a autovacuum si nechte zapnute pro sychr

[okbobcz]

Jinak autovacuum neni vas nepritel - po vacuuu mate rychlejsi pristup k tabulkam, k indexum - uvolnuje se vam prostor uvnitr tabulek.

[Andrej]

Co s tím:

1. Zkusil bych, jestli jakýsi 13+ let starý problém existuje i dnes, na PostgreSQL 15.3 a novějším.
2. Pokud ano, nahlásil bych bug a/nebo bych se zeptal na PostgreSQL mailing listech.

[Xerces]

Dobrá ironie, ale bohužel v komerčním světě se nedělá upgrade sw každých 5 let, nebo častěji. U nás jedeme na verzích databází 9 let starých. Proč by měl někdo platit drahý upgrade, když to funguje? Takže za mě naprosto regulérní dotaz.

[X]

Ty ses asi hodne mimo.

v komerčním světě se nedělá upgrade sw každých 5 let, nebo častěji

Ne, dela se daleko casteji pokud nejsi sebevrah.

Proč by měl někdo platit drahý upgrade, když to funguje?

Nejstarsi vymluva na svete tvl. Vy musite byt taky dobra parta.Vic proc? Aby si nemusel chodit zebrat na abicko s plesnivym backendem..

[Max]

Komerční svět pravidelně patchuje a dělá upgrady. Jakékoli nepatchování a setrvávání na stejných verzích vede neodkladně k obrovským problémům. Bez patchování nejsi schopen plnit bezpečností standardy, bez patchování nesplníš iso27002 apod. Bez patchování jednou krutě dojedeš na nějaký bug, limit, nekompatibilitu apod. , a to zrovna v neplánovaný čas, jak jinak. Opravdu nechápu, jak toto někdo může obhajovat.
Zdar Max

[Xerces]

Jakože patchovaný systém neobsahuje bugy a s opatchovanými systémy neotravují admini na Ábíčku, nebo co? Myslím, že to je taková mantra bezhlavě patchovat a upgradovat. Vždycky je to otázka posouzení nákladů, nějaký ISO27002 zajímá tak maximálně audit.

[Max]

Patchovaný systém neobsahuje security bugy (známé / objevené), kdežto na téměř cokoli starého, neopatchovaného, stáhneš proof of concept, který ti buď zajistí práva, nebo sundá ten systém na dálku.
Výmluva, že patchováním si člověk zatáhne do systému chyby a způsobí problémy, je trochu úsměvná. Jednak u kritických věcí existují long term old stable větve, dále si to člověk před nasazením může vždy otestovat.
Takže ty své představy o bezhlavém patchování, máš akorát ty.
Vždy je to prostě o tom, určit si kritičnost systému / záplaty apod. a podle toho nasadit patchovací plán.
Pokud jde o ISO27002, tak to se docela pleteš. Podobná ISO jsou důkaz, že jsou ve firmě nastaveny správné procesy, že se dodržují atd. Bavíme se o DR plánech, funkčních zálohách, jejich kontrole, testování, šifrování storage, podchycenému patchování apod. Ten důkaz pak lze předkládat vedení, matce apod. Prostě všem, kdo tomu nerozumí, tak tímto mají jistotu, že je vše ok. Zároveň je to prověření, že IT nic nezanedbává.
Zdar Max

[okbobcz]

V komerčním světě se samozřejmě dělá upgrade - mnohdy častěji něž každých 5 let. Některé firmy jsou slušné a některé víc nebo míň banda zoufalců a příštipkářů. U software kvalita není hned vidět. Pokud máte správně nastavené procesy, tak upgrade není drahý. Pokud mám špatně napsanou neudržovanou aplikaci bez testů, kde jakýkoliv zásah představuje velké riziko, tak je upgrade drahý nebo náročný. V komerčním světě jsou firmy, které hrají první ligu, a firmy, které nejsou ani tím okresním přeborem.

[Xerces]

Čím větší firma, tím archaičtější a hůře upgradovatelné apps. 10 let bez upgrade opravdu není problém. Uvědomte si, že IT většinou těm firmám nevydělává na chleba, ale je to podpůrná služba (pokud se tedy nebavíme přímo o IT firmě).

[X]

Čím větší firma, tím archaičtější a hůře upgradovatelné apps.

To je nesmysl. Je to presne naopak. Mas pocit, ze moderni firma jede na nejakem zastaralem software? To asi tezko. Mimochodem kazde vetsi spolecnosti vydelava IT na chleba. To ze na to vedeni s prominutim sere, je problem managemantu.

CO JE S TOU CAPTCHOU!?!?!?!?!

[trekker.dk]

Není nějaké 9.x třeba ještě podporováno v RHELu nebo něčem podobném?

[X]

Neni to jedno? Prijit do firmy kde se 10 let na nic nesahlo "protoze to chodi" to fakt nechces.

[Peter Golis]

Ako že by sa hrabal RedHat v zdrojákoch tak rozdielnych generácií po tom ako PGSQL 9.6 prestal podporovať upstream? Teoreticky je to možné, ale asi by to bolo drahšie ako migrácia na nové železo s vyšším výkonom a aktuálnym HW. Teda aspoň z rotačných HDD na NVMe alebo SATA disky (s pravidelnou zálohou).

Obnoviť si zálohu a vyskúšať cvičný upgrade na aktuálnom železe asi nie je až taký problém. Bonus je že človek zistí chyby ktoré by ho prekvapili, a spozná dĺžku downtime.