Блог

Я обновился с Postgres 10 до Postgres 14, используя --link опцию pg_upgrade. Общий размер баз данных составляет около 10 ТБ. pg_upgrade прошел успешно и быстро, как и предлагал инструмент —

Optimizer statistics are not transferred by pg_upgrade. Once you start the new server, consider running: /usr/pgsql-14/bin/vacuumdb --all --analyze-in-stages

Я выполнил приведенную выше команду, но процесс застрял. В качестве побочного эффекта этого (или нет, не уверен), когда я создаю публикацию, приглашение никогда не возвращается, и публикация не создается даже через много часов.

postgres=# выбрать * из pg_stat_progress_vacuum;

Это тот же результат, что и вчера. Что я могу сделать, чтобы ускорить это и команду «создать публикацию»? Примечание: Виртуальная машина, на которой работает Postgres, довольно мощная (64 ГБ оперативной памяти, 16 ядер). Спасибо!

изменить 1: вывод pg_stat_activity для того же pid,

vacuumdb --all --analyze-in-stages не побежит VACUUM , но ANALYZE , так что вам придется заглянуть внутрь pg_stat_progress_analyze , чтобы посмотреть, как у него дела.

VACUUM Процесс, который вы видите запущенным, не имеет к этому никакого отношения. Это антиобертывающий вакуум, который в настоящее время спит, но в остальном обрабатывается. Позвольте этому завершиться; этот процесс важен для работоспособности вашей базы данных. если вы хотите, чтобы дальнейшие запуски autovacuum в этой таблице выполнялись быстрее, уменьшите autovacuum_vacuum_cost_delay для этой таблицы.

Простое выполнение обновления не должно было приводить к запуску вакуума защиты от обтекания, так что решение о запуске сразу после обновления может быть совпадением по времени. С другой стороны, возможно, ваша новая версия базы данных имеет другие параметры конфигурации , например, более низкое значение для autovacuum_freeze_max_age , запуск с этой новой настройкой-это то, что вызвало ее запуск прямо сейчас. Вы перенесли все настройки конфигурации, отличные от настроек по умолчанию, с v10 на v14?

Я согласен с Лоренцем, что нужно дать этому закончиться, но это не значит, что вам нужно позволить этому закончиться прямо сейчас. Вы можете завершить очистку бэкэнда, чтобы у вашей публикации «СОЗДАТЬ» была возможность запуска. Автоматическая очистка может быстро перезапуститься, поэтому при отмене вакуума у вас уже должна быть попытка запустить публикацию «СОЗДАТЬ». Таким образом, он сможет получить блокировку до того, как вакуум сможет снова включиться и снова захватить блокировку. Но убедитесь, что у вас не вошло в привычку отменять пылесосы каждый раз, когда они причиняют вам неудобства.

Кроме того, вы должны значительно увеличить maintenance_work_mem. Похоже, что в настоящее время он установлен на 64 МБ, что довольно мало для сервера, который вы описываете. Если вы установите для него значение 1 ГБ, то он сможет очистить всю таблицу всего за один проход по индексам, а не за семь, для которых вы в настоящее время работаете. Я бы изменил эту настройку в файле conf и НАСТРОИЛ сервер, прежде чем вы отмените вакуум, таким образом, у нового вакуума, который запускается, должна быть новая настройка.

Наконец, я не знаю, почему это приводит к удалению индекса. Я думал, что v14 изменил его так, чтобы аварийные пылесосы не утруждали себя этим, а просто замораживали кортежи в куче и оставляли индексы на потом. Я думаю, мне нужно немного больше изучить v14, чтобы понять, что он здесь делает на самом деле.