Поврежденные индексы Postgres pg_upgrade (Великобритания), отсутствующие значения, хотя отсутствуют записи при выборе на основе индекса

#postgresql #upgrade #postgresql-9.6 #postgresql-12

#postgresql #Обновление #postgresql-9.6 #postgresql-12

Вопрос:

После 9.6-> 12.3 pg_upgrade мы отметили, что некоторые серьезные выборки дают недостающие результаты! ПЕРЕИНДЕКСАЦИЯ или удаление / создание исправили проблему.

Маркерные точки обновления

Остановка 9.6
rsync 9.6 файлы данных и bin с Centos7 по Centos8 (предварительно установлено 12)
pg_upgrade
./analyze_new_cluster.sh
./delete_old_cluster.sh

Для каждой базы данных мы обнаружили 1-3 УНИКАЛЬНЫХ поврежденных индекса. Пропущено около 20 значений для каждого индекса.

Мы нашли очень полезный инструмент amcheck! https://www.postgresql.org/docs/10/amcheck.html

 SELECT bt_index_check(c.oid), c.relname, c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree' AND n.nspname = 'pg_catalog'
-- Don't check temp tables, which may be from another session:
AND c.relpersistence != 't'
-- Function may throw an error when this is omitted:
AND i.indisready AND i.indisvalid
ORDER BY c.relpages DESC LIMIT 10;

ОЧЕНЬ ВАЖНО: закомментируйте (И n.nspname = ‘pg_catalog’ ОГРАНИЧЕНИЕ 10) ограничения путем проверки, чтобы запустить функцию bt_index_check и для вашего индекса!

И да, функция выдает исключение при обнаружении поврежденного индекса.

Почему индекс идет не так? Как мы можем быть уверены, что наша новая база данных согласована и обновление прошло успешно?

1. К какому типу данных относятся индексированные столбцы? Если это так, text или varchar это может быть вызвано изменением glibc между CentOS 7 и 8.

2. Varchar(255)! Большое спасибо! Тогда не Великобритания, а только индексы varchar!

Ответ №1:

Почему индекс идет не так?

Наиболее вероятным объяснением является разница в версиях glibc между CentOS 7 и CentOS 8.

Этот пост в блоге дает еще некоторое представление об этом.

В общем случае при изменении версий glibc (например, из-за системных исправлений или обновления ОС) вам следует переиндексировать все индексы, которые включают text , varchar или char столбцы.

Это не то, на что Postgres может влиять напрямую, хотя возможность использовать параметры сортировки ICU является частичным решением этой проблемы. Но если версия операционной системы ICU обновляется (например, снова неявно из-за системных исправлений), у вас возникнет та же проблема (но, похоже, библиотеки ICU обновляются реже, чем библиотеки glibc)

Я думаю, что ведется некоторая работа, чтобы, по крайней мере, предупредить пользователя. Но, насколько мне известно, ничего подобного не было зафиксировано в текущей версии 12 или предстоящей версии 13.