Postgres instance v recovery, přitom otevřená korektně

[jhonzatko]

Ahoj všem!

Narazil jsem na takový problém, se kterým si zatím nevím rady a napadlo mě zkusit se zeptat zde, zda už jste třeba někdo neřešil ...
Mám korektně nastartovanou instanci Postgresu ve verzi 13.
Vše se tváří ok, dokud nespustím jeden relativně náročný dotaz. Po nějaké době vykonávání dotazu začnou do logu padat hlášky, že instance je v recovery režimu. Kontrola přes pg_controldata ale vrací, že instance je In production.
Tak jsem z toho nějaký zmatený a nedaří se mi zatím přijít na to, co je příčinou.
Napadlo mě třeba poškození nějakých bloků, ale říkám si, že to by se asi v logu projevilo jinak.
Nepotkal jste se s tím už někdo někdy?
Díky za každý případný nápad!

[Reklama]

[Pavel Stěhule]

Ahoj všem!

Narazil jsem na takový problém, se kterým si zatím nevím rady a napadlo mě zkusit se zeptat zde, zda už jste třeba někdo neřešil ...
Mám korektně nastartovanou instanci Postgresu ve verzi 13.
Vše se tváří ok, dokud nespustím jeden relativně náročný dotaz. Po nějaké době vykonávání dotazu začnou do logu padat hlášky, že instance je v recovery režimu. Kontrola přes pg_controldata ale vrací, že instance je In production.
Tak jsem z toho nějaký zmatený a nedaří se mi zatím přijít na to, co je příčinou.
Napadlo mě třeba poškození nějakých bloků, ale říkám si, že to by se asi v logu projevilo jinak.
Nepotkal jste se s tím už někdo někdy?
Díky za každý případný nápad!

Nemuze treba zauradovat OOM killer - postgres pujde do restartu, po urcitou dobu bude v recovery a kdyz se tam podivate, tak uz je nahore. Je neco zajimaveho v logu pg?

[jhonzatko]

Diky za tip! Nakonec to vypada, ze to bude opravdu nejspis neco na urovni OS. Po odeslani prispevku jsem zjistil, ze problem se zacal vyskytovat az po preclusterovani na druhy node a po kontrole jsem narazil na to, ze nektere soft limit parametry se na nodech lisi.
V logu (pro me prekvapive) nic dalsiho neni. Pouze chybovy kod 57P03, ale zadna do kontextu uvadejici zprava predtim. Nicmene predpokladam, ze to klidne muze byt zpusobeno custom konfiguraci logovani.
Planoval jsem nastavit uroven na debug, abych zjistil vice, ale nejprve otestuji narovnani parametru OS.

[jhonzatko]

Tak nakonec to bude asi slozitejsi. Narovnani parametru problem nevyresilo. Zjistil jsem ale, ze jsem problem schopen jednoznacne reprodukovat. Staci jeden konkretni jednoduchy select a skoncim v logu s nasledujicim:

00000 LOG:  server process (PID 24537) was terminated by signal 11: Segmentation fault
00000 DETAIL:  Failed process was running: select * from XXX  where id ='YYY';
00000 LOG:  terminating any other active server processes
57P02 WARNING:  terminating connection because of crash of another server process
57P02 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 memory.
57P02 HINT:  In a moment you should be able to reconnect to the database and repeat your command.

Dohledal jsem zatim, ze k tomu byl nejaky bug, ale v mnou pouzivane verzi db (13.10) by jiz mel byt vyresen.
Snazim se patrat dal a zjistit, co konkretne by tenhle problem mohlo zpusobovat.

[Martin Mlynář]

Vzdy, kdyz narazim na takovouhle ducharinu, saham po memtestu. Fakt, zkus ten stroj chvili potrapit a overit, ze RAM je ok.

[Reklama]

[jhonzatko]

Diky, zkousel jsem taky, nicmene bez efektu.
Nakonec, pro me naprosto nepochopitelne, se problem prestal objevovat po provedeni vacuum full.
Problem se tim sice "vyresil", bohuzel se mi nepovedlo jednoznacne urcit, co bylo pricinou

[Pavel Stěhule]

Diky, zkousel jsem taky, nicmene bez efektu.
Nakonec, pro me naprosto nepochopitelne, se problem prestal objevovat po provedeni vacuum full.
Problem se tim sice "vyresil", bohuzel se mi nepovedlo jednoznacne urcit, co bylo pricinou

Pokud pomůže VACUUM FULL, tak s vyšší pravděpodobností byl poškozený index, s nižší datový soubor. Důvody pro poškození mohou být různé - od chyby Postgresu až po hw problémy. Dnes už se hodně doporučuje zapnout checksumy na úrovni datových stránek. To by mělo detekovat některé hw problémy.

[jhonzatko]

Diky, dava to smysl. Jen to hledani je trosku metoda pokus/omyl
Zapnuti pg_checksums uz je v procesu, v neprodukci uz mame nasazeno, pro produkci hledame vhodne okno.
Ono to pri vetsim objemu dat docela trva

[Pavel Stěhule]

Diky, dava to smysl. Jen to hledani je trosku metoda pokus/omyl
Zapnuti pg_checksums uz je v procesu, v neprodukci uz mame nasazeno, pro produkci hledame vhodne okno.
Ono to pri vetsim objemu dat docela trva

Jakýkoliv coruupt se dost špatně investiguje. V některých případech databáze zahlásí chybu formátu, dost často ale spadne na segfault, jindy to vrátí špatný výsledek a rozklíčovat proč a co se stalo, je alchymie. V Postgresu jsou dneska nástroje pro kontrolu konzistence jak tabulek tak některých typů indexů.