Всем доброго времени суток.
Ситуация следующая.
Хочу обновить основную версию БД по средствам репликации. Чтоб с минимальным даунтаймом и все такое.
Не могу понять какими средствами клонировать базу. pg_dumpom ?
basebackup и SELECT pg_start_backup('label'); клонируют по файлово, база на новой версии запускается с ошибкой(файлы от старой версии).

Заранее спасибо.

MelkijstaropramenХочу обновить основную версию БД по средствам репликации
Реплика работает только в рамках одной major версии.

Даунтайм в примерно 10 минут (в первый раз, а так - несколько минут) - pg_upgrade в режиме hardlink
Печаль... Спасибо.
мануалы нахваливают демон слоник, который якобы умеет такое проворачивать.
как в наше время с подобной софтиной? толкового ничего нет ?

Melkijstaropramen,

приложение не умеет штатно пережить 10 минут недоступности мастер базы
Решение годами проверенное.

как это штатно без базы

Melkij,

а если обновить slave сервер, он продолжит работу в стэндбай режиме на новой версии, при условии что master не обновлен?

Maxim Boguk, Melkij, mefman,

Понятно. Спасибо всем за потраченное время.

mefman,
Там не логическую ли реплику использовали? Натыкался на подобного рода статьи ..

daevystaropramen,

да логическую, репликация между мажорными версиями возможна только при использовании логической репликации (см. slony, londiste, bucardo, pg_logical)
но если вы делаете это в первый раз, то геморой с настройкой и переключением + вероятность завалить апгрейд, гораздо больше чем если использовать вариант с pg_upgrade с даунтаймом базы
Да я понял. Пока гуглил наткнулся на пару портянок в 20 экранов с применением логической репликации))
Танцы с бубном не рассматриваю, без даунтайма, получается, не обойтись.

staropramenТанцы с бубном не рассматриваю, без даунтайма, получается, не обойтись.
Имею ввиду, что устраивает вариант с небольшим даунтаймом больше, чем вероятность завалить апгрейд, естественно ..

Maxim Bogukstaropramenпропущено...

Имею ввиду, что устраивает вариант с небольшим даунтаймом больше, чем вероятность завалить апгрейд, естественно ..

pg_upgrade downtime если все нормально подготовить 1-5 минут будет (в зависимости от размера базы).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

База не большая, в пол терабайта. Еще не тестил, но читал, действительно быстро получается.

MelkijСпецифично для приложения. SLA в 5 девяток в принципе не может полагаться на постоянную доступность любой из частей приложения или инфраструктуры. Если бизнесу настолько дорого простой в 10 минут, то выделяется соответствующим этому бюджет на архитектора, обсуждаются граничные части, какой функционал критичен, а без чего можно прожить, какой бюджет потребуется на переделку и сопровождение, пишутся изменение приложения под эту архитектуру, продолжается администрирование и сопровождение полученной системы.

Из дешёвого и универсального как прожить без мастер базы - перейти в read-only и читать с реплики. Какую-то запись можно вести в лог или очередь и потом догнать.
Можно резать проект на части и недоступен он соответственно будет только частями. Т.е. нормально сделанное горизонтальное масштабирование на независимые чанки сюда же.

Каким-то проектам - и я встречал такие - для критичной части сервиса база действительно не нужна. Кеша и лога для записи хватает для корректной работы функционала, который должен быть high availability.
Не посоветуете что-то почитать на эту тему? Спасибо.