Как я могу предотвратить обновление материализованных представлений во время pg_restore?

Я создал дамп базы данных с помощью pg_dump в "произвольном" формате (-Fc). Этот формат позволяет вызывать pg_restore с опцией "jobs" (-j8). Параметры заданий запускают 8 процессов и восстанавливают подавляющее большинство связей в моей базе данных в течение 10 минут.

Осталось 4 процесса. Один из них - это обновление материализованного представления, а остальные 3 - это индексы, которые будут применяться к трем таблицам, которые материализованное представление использует в качестве источников данных. Индексы «ждут» согласно pg_stat_activity, предположительно потому, что REFRESH материализованного представления все еще обращается к исходным таблицам.

Когда индексы на месте, обновление представления занимает всего пару минут. Поскольку в течение REFRESH индексы отсутствуют, я отключил процесс REFRESH в 17 часов, что привело к сбою pg_restore.

Как я могу

  1. Установите порядок элементов, чтобы индексы создавались первыми
  2. Отключите обновление материализованного представления и сделайте это вручную позже
  3. Измените файл дампа в настраиваемом формате, чтобы сказать "БЕЗ ДАННЫХ".
  4. Перехватить оператор REFRESH MATERIALIZED VIEW и выбросить его в корзину

Или любое другое решение, которое выполняет свою работу?


person Kirk Roybal    schedule 25.06.2014    source источник
comment
Сообщите об этой проблеме в списке рассылки pgsql-hackers как можно скорее. Ссылка на этот вопрос, но также опишите проблему. Если это удобно, можно было бы разместить здесь ссылку на ваше сообщение через archives.postgresql.org.   -  person Craig Ringer    schedule 26.06.2014
comment
Хорошо, сделал это. Спасибо за совет.   -  person Kirk Roybal    schedule 26.06.2014


Ответы (3)


Дэвид Дж. Джонстон опубликовал для меня ответ в списке рассылки pgsql-hackers.

"Есть / можете ли вы попробовать параметры '-l (el) & -L' для pg_restore?

http://www.postgresql.org/docs/9.3/static/app-pgrestore.html < / а>

(пример использования внизу страницы)

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

Следует научить pg_dump / pg_restore справляться с этим лучше, что является основной причиной, по которой Крейг попросил вас опубликовать здесь как можно скорее, но для того, чтобы заставить его работать, потребуется ручное вмешательство. Теоретически возможности "листинга" должны позволить вам делать то, что вам нужно ".

Я думаю, что это (pg_restore -l | pg_restore -L) доставит меня туда, где мне нужно идти, вставив между ними небольшой сценарий оболочки, который подталкивает материализованные представления в конец списка, но тогда мне также придется управлять мои собственные зависимости для элементов, которые я повторно сортирую (MatViews of MatViews). Это довольно серьезно ограничивает для меня полезность материализованных представлений. Для версии 9.3.x мне, вероятно, потребуются зависимости MatView глубиной не более 1.

Изменить: чтобы прекратить материализацию данных при восстановлении, я начал делать это:

pg_dump mydatabase -Fd backup_dir
pg_restore -l  -Fd backup_dir | sed '/MATERIALIZED VIEW DATA/d' > ordered.lst
pg_restore -L ordered.lst -Fd backup_dir mydatabase

Это удаляет операторы REFRESH MATERIALIZED VIEW из восстановления. Спасибо Дэвиду Дж. Джонстону за советы.

person Kirk Roybal    schedule 26.06.2014

В качестве дополнения к принятому ответу, когда все индексы завершены и / или вы запустили ANALYZE, вы можете обновить материализованные представления в правильном (зависимом) порядке, используя:

pg_restore -l -Fd backup_dir | grep 'MATERIALIZED VIEW DATA' > refresh.lst
pg_restore -L refresh.lst -Fd backup_dir mydatabase
person Jiri Baum    schedule 20.08.2014

Одно решение, вы можете попробовать.

Возможно, вы можете создать MatView в отдельной схеме, посвященной им. Для обратной совместимости можно использовать синонимы.

pg_restore может использоваться только схемой.

person Aret    schedule 26.06.2014
comment
Это может быть более полезным, если исключить схему для представлений mat из основного pg_dump и выгрузить их на отдельном шаге. Однако этот двухэтапный процесс потребует модификации сценариев резервного копирования, предназначенных для обслуживания нескольких баз данных. - person Kirk Roybal; 27.06.2014
comment
Правда, надеюсь исправят pg_restore. :) - person Aret; 28.06.2014