pg_dump та ПОМИЛКА: відсутній номер 0 для значення тосту


10

Я використовую PostgreSQL 8.4.15. Під час запуску pg_dumpрезервного копіювання бази даних я отримав таку помилку:

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 ...)

Шукаючи це повідомлення про помилку, я знайшов пару посилань ( тут і тут ), які пропонували повторно встановити таблицю. (У цих дискусіях було посилання на запит pg_classтаблиці, щоб знайти потрібне pg_toast_XXXXXXзначення, але здавалося, що це було тому, що воно не відображалось у їхніх повідомленнях про помилки. Я пропустив цю частину, тому що у повідомленні про помилку було вказане значення Я думаю, це може бути зручністю через пізнішу версію PostgreSQL.)

Я пробіг наступне:

REINDEX table pg_toast.pg_toast_987654321;
VACUUM ANALYZE my_table;

Тепер я можу користуватися pg_dumpбез помилок.

Що pg_toastі що насправді робили ці команди? Це лише про просте прибирання чи вони могли позбутися деяких рядків у цій таблиці? Що могло спричинити проблему в першу чергу?

У цій таблиці є близько 300000 рядків, але я б очікував, що з попередньої успішної резервної копії буде лише близько 250 нових рядків (ця таблиця використовується лише для INSERT / SELECT, без оновлення).


Я знайшов цю ідею . Чи можете ви перевірити, чи збігається ваша справа?
dezso

Це також може допомогти stackoverflow.com/questions/47533639 / ...
papanito

Відповіді:


6

Зважаючи на те, що ви робили реіндекс, можливо, це сталося, це було використано індексне сканування, щоб спробувати знайти обсмажені значення в таблиці і не змогли їх знайти. Це звучить як зіпсований індекс. Вакуумний аналіз змінює таблицю, але реіндекс не робить, і зміни дуже незначні.

Спосіб подумати про це полягає в тому, що атрибути TOASTed насправді розбиваються на шматки розміром близько 4 к і зберігаються в рядках. Вони переглядаються та сортуються / з’єднуються з головним рядком під час запиту. Здається, що тут використаний індекс був зіпсований, і тому перевстановлення вирішило проблему.

Я виявив, що пошкоджені індекси зазвичай є ознакою того, що з сервером щось непогано. Добре перевірити та переконатись у тому, що пам'ять, процесор та жорсткі диски радіють усім і не повідомляють про проблеми. Я виявив, що сервери перегріву є особливо схильними до пошкодження індексів, і якщо індекси можуть стати корумпованими, потрібно переживати і про те, що дані також пошкоджуються.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.