PostgreSQL: FATAL: the database system is in recovery mode

18-Lip-2021

No i co tu poradzić? Połączenia do bazy danych czasami się udają, ale nawet wtedy po krótkiej chwili sesja jest zabijana i można znaleźć komunikaty

Zwykle pierwszym dobrym krokiem, kiedy chce się zobaczyć coś więcej od środka, jest analiza zapisów w logu systemowym. Znajdziesz je w /var/lib/edb/as13/data/logs. Log pełen był zapisów w postaci:

Niby to trochę lepiej, bo widać już zapytanie, przy którym dochodzi do błędu, ale… i tak nic to nie mówi w zakresie kolejnych kroków do wykonania. Rzeczywiście, ten serwer był monitorowany przez PEM, rzeczywiście PEM zgłaszał serwer jako niedostępny, ale… to raczej skutek tego problemu, a nie przyczyna. Jakoś nie chce mi się wierzyć w to, że zapytanie generowane przez agenta PEM powoduje „segmentation fault” na systemie. Użytkownicy wysyłający zwariowane zapytania powinni być skutecznie odfiltrowani przez serwer bazy danych, który jeśli widzi, że koszt zapytania jest nieakceptowalny, raczej zakończy w łagodny sposób taką sesję, niż pozwoli przewrócić się na łopatki.

No ale skoro błąd wygląda na systemowy, wewnątrz procesu postgres, to może coś uda się znaleźć w logu sytemowym w  /var/log/messages? Rzeczywiście:

W wygenerowanym tutaj bełkocie odnajduje się słowo „index_advisor”. To rozszerzenie jest uruchamiane wewnatrz procesu postgresql i szczerze – mało mu ufam. Byłbym więc w stanie wyobrazić sobie sytuację, w której jakiś wewnętrzny bug index_advisora powoduje awarię całego procesu postgres obsługującego sesję. Dlatego postanowiłem to sprawdzić i wyłączyć index_advisora. Robi się to przez modyfikację pliku

Odpowiedni wpis dotyczący index_advisora należy usunąć z parametru

Po restarcie postgresa

… wszystkie problemy zniknęły. Bazy są dostępne, można się do nich podłączyć i nawet PEM zaczął je raportować jako dostępne. Bingo!

 

 

Dodaj komentarz:

Autor: Rafał Kraik