pg_dump i ERROR: brak fragmentu 0 dla wartości toast


10

Używam PostgreSQL 8.4.15. Podczas uruchamiania pg_dumptworzenia kopii zapasowej bazy danych wystąpił następujący błąd:

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  missing chunk number 0 for toast value 123456789 in pg_toast_987654321
pg_dump: The command was: COPY public.my_table (id, .... all the columns ...)

Podczas wyszukiwania tego komunikatu o błędzie znalazłem kilka odniesień ( tu i tutaj ), które sugerowały ponowne indeksowanie tabeli. (W tych dyskusjach było odniesienie do zapytania pg_classtabeli w celu znalezienia właściwej pg_toast_XXXXXXwartości, ale wydawało się, że było tak, ponieważ nie było to wyświetlane w ich komunikatach o błędach. Pominąłem tę część, ponieważ miałem wartość wyświetlaną w komunikacie o błędzie Myślę, że może to być wygoda ze względu na późniejszą wersję PostgreSQL.)

Uruchomiłem następujące:

REINDEX table pg_toast.pg_toast_987654321;
VACUUM ANALYZE my_table;

Teraz mogę używać pg_dumpbez błędów.

Co pg_toasti co faktycznie zrobiły te polecenia? Czy są to tylko proste porządki, czy może pozbyli się niektórych wierszy w tej tabeli? Co mogło być przyczyną problemu?

W tej tabeli znajduje się około 300 000 wierszy, ale spodziewam się, że będzie tylko około 250 nowych wierszy od poprzedniej udanej kopii zapasowej (ta tabela jest używana tylko dla INSERT / SELECT, bez aktualizacji).


Znalazłem ten pomysł . Czy możesz sprawdzić, czy Twoja sprawa jest taka sama?
dezso

Odpowiedzi:


6

Biorąc pod uwagę, że to, co zrobiłeś, było ponownym indeksowaniem, to prawdopodobnie zdarzyło się, że użył skanu indeksu, aby spróbować zlokalizować tostowane wartości w tabeli i nie mógł ich znaleźć. Brzmi to jak uszkodzony indeks. Analiza próżniowa zmienia tabelę, ale reindex nie zmienia, a zmiany są bardzo niewielkie.

Sposobem na przemyślenie tego jest to, że atrybuty TOASTed są faktycznie dzielone na kawałki o wielkości około 4k i są przechowywane w rzędach. Są one wyszukiwane i sortowane / ponownie łączone z głównym wierszem w czasie zapytania. Wygląda na to, że użyty tutaj indeks został uszkodzony, więc reindex rozwiązał problem.

Odkryłem, że uszkodzone indeksy są zwykle oznaką, że coś jest nie tak z serwerem. Dobrze jest sprawdzić i upewnić się, że pamięć, procesory i dyski twarde są zadowolone i nie zgłaszają problemów. Przekonałem się, że przegrzanie serwerów jest szczególnie podatne na uszkodzenie indeksów, a jeśli indeksy mogą ulec uszkodzeniu, należy się martwić, że dane również zostaną uszkodzone.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.