Pull to refresh
0
0

Пользователь

Send message

Вкину пару кейсов.

На больших объемах еще помогает ускориться в копировании - перед созданием подписки на больших таблицах удалить индексы(если они не уникальные и не являются частью констрейнтов), а после того, как статус таблицы сменится на 'd' - индекс можно будет в конкурентном режиме построить как и был.

Еще кейс с расширением postgis и вариантом publication for all tables - можно споткнуться о таблицу этого расширения с одной строкой и уник. индексом.

Часть 2 видимо еще последует, что день грядущий нам готовит ))

Если заранее на стенде разработки держать версию PostgreSQL более свежую — большая часть граблей в хранимках, изменений в стандартных функциях, расширениях вполне может быть выловлена. Ровно как и раскатка структуры бд на новой версии выявит проблемы, на которых pg_basebackup гарантированно споткнется.
На «кошках» можно попробовать кластер также через pg_upgrade провести(ИМХО, с ключом -k самый быстрый способ обновиться).
Про обновление через логич. репликацию — годный вариант обойти проблему пересборки индексов, но есть проблема переноса blob(бывает и такое в бд держат).
Более информативно было вроде как тут.
Также сталкивался с подобной проблемой. При типе хранилища lvm, если диск VM большой в объеме и свободного места в хранилище мало, то удалить снепшот была задача нетривиальная.
Продолжительное время использую скрипт Andy Burton.
http://www.andy-burton.co.uk/blog/.

Information

Rating
6,598-th
Location
Курган, Курганская обл., Россия
Date of birth
Registered
Activity