Проблемы с запуском AUTO_VACUUM (для предотвращения обертывания) на очень большой таблице

Question

У меня возникла проблема и вам нужен совет. Я, как правило, разработчик, однако с недавними кадровыми изменениями в моей компании я теперь единственный ИТ-специалист, поэтому мне приходится входить во многие неизвестные области и действительно нуждаться в некоторой помощи.

Мы работаем с postgres 8.3. База данных пытается запустить AUTO_VACUUM в большой таблице объектов (pg_catalog.pg_large_object), чтобы предотвратить обкатку идентификатора транзакции. Думаю, я понимаю основы того, что это значит. Проблема в том, что эта таблица 750G с 452 миллионами строк. AUTO_VACUUM много записывает на диск и съедает дисковое пространство (вчера он потреблял последние 250 ГБ 1 Тбайт). После аварийного отключения, мы резервное копирование и работа с 1100 ГБ пространства, и 100 ГБ бесплатно. Однако после того, как postgres вернулся и запущен, он снова начал процесс AUTO_VACUUM. Если я убью транзакцию (которая, я уверен, не рекомендуется), она просто перезагружается.

Так вот мои вопросы:

1) Для этой таблицы, сколько места будет ему необходимо завершить процесс AUTO_VACUUM? Как это определить?

2) Есть ли лучший способ настроить сервер для обработки этой ситуации, чтобы он не требовал смехотворного объема дискового пространства, когда это необходимо для этого?

3) Если нет до 2, как вы можете решить эту проблему?

Я не являюсь администратором базы данных и не имею возможности администрирования сервера Linux, а просто разработчику попросят носить много шляп. Я пытаюсь получить консультанта DBA, чтобы помочь решить проблему, но компания отталкивается. Они, похоже, не понимают серьезности проблемы, несмотря на все мои усилия.

Предложения? Комментарии? Любые советы или рекомендации, которые вы можете предоставить, будут очень признательны. Если вам нужна дополнительная информация, дайте мне знать.

Answer 1

Если вы не решите эту проблему достаточно быстро, ваша база данных войдет в аварийное завершение, чтобы предотвратить повреждение данных, и откажется начать резервное копирование до тех пор, пока не завершится txid wraparound vaccuum. Проверьте журналы, чтобы увидеть, насколько близко к этой точке вы, вы будете видеть сообщения, как:

WARNING: database "mydb" must be vacuumed within 177009986 transactions 
HINT: To avoid a database shutdown, execute a database-wide VACUUM in "mydb". 

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

Причина, по которой она потребляет тонны дискового пространства, вероятно, заключается в том, что вы находитесь на старой версии, которая не имеет автоматических настроек freespacemap, и вы, вероятно, превысили и/или max_fsm_relations. Проверьте журнал, вы можете видеть сообщения об этом.

К сожалению, вы не можете просто поднять эти параметры после факта. Эта старая установка PostgreSQL потеряла знания о том, какое пространство в таблице является бесплатным. Для правильной очистки и восстановления потребуется таблица CLUSTER, для которой требуется как минимум столько свободного места, как размер таблицы + индекса, а требует исключительной блокировки на столе на время прогона.

Большинство из менее навязчивых вариантов смягчения, таких как pg_reorg, теперь больше не открыты для вас, когда вы приближаетесь к принудительной защите от txid. Ваш лучший выбор - это, скорее всего, дать autovacuum пространство, в котором он нуждается, чтобы завершить работу - или справиться с простоями и CLUSTER, а затем VACUUM FREEZE таблицу, чтобы ускорить процесс и завершить его.

После того, как вы оправились, я рекомендовал бы значительно увеличить max_fsm_pages и убедиться, что max_fsm_relations достаточно большой. Много рекомендаций по настройке для этих старых версий есть, поиск.

Планируйте обновление до 9.2, которое автоматически управляет картой freespace (как и любая версия 8.4+) и имеет всевозможные усовершенствования автоволн, чтобы помочь вам в первую очередь избавиться от этих рассолов.

Если эта ситуация в отчаянии, подумайте о связи с professional PostgreSQL support provider. (Правильное раскрытие: я работаю для 2ndQuadrant, одного из перечисленных поставщиков).

Answer 2

Поддержка в реальном времени на #postgresql (IRC) FreeNode поразительна. Есть часто осведомленные люди, которые бодрствуют и могут поговорить о DBA/деталях разработки. Я не могу рекомендовать его достаточно.