Как стать автором
Обновить

Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации

Время на прочтение9 мин
Количество просмотров18K
Всего голосов 38: ↑38 и ↓0+38
Комментарии30

Комментарии 30

Спасибо, полезно.
Весьма полезно. Спасибо
Хорошая статья, спасибо.
а рассматривались ли другие средства логической репликации и если да, то почему окончательный выбор пал именно на pglogical?
Рассматривались мельком. Прорабатывать вопрос начали с pglogical, и к счастью он нас в итоге полностью устроил. Возможно, для кого-то будет интереснее Slony (он как минимум умеет реплицировать версии старше 9.4) или что-то ещё.

Я мигрировал недавно 2.5ТБ базу с 9.4 на 10, простым pg-upgrade
Заняло 30-60 минут. Никаких часов.
Основная проблема при миграции скорость дисков
Основная проблема, левые расширения, которые нужно удалить заблаговременно
Стоит ли говорить что главная возможная причина медленной миграции-использование raid-контроллера, это наибольшая глупость при ssd дисках. Ну и конечно однопоточность операции восстановления и старта.

По цифрам у вас производительность СХД 1 ГБ/с на запись + 1 ГБ/с на чтение одновременно? Как говорится, остаётся только позавидовать :)
Но в общем и целом, да, совершенно согласен, и написал об этом — если вы можете себе позволить даунтайм на время работы pg_upgrade — незачем городить огород.

Если честно- не мерил)) была задача, был выбор железа с запасом, ценой в 700т.р.))) а уж что она там показывает хз. Брали то на замену)
Сейчас вот на 11 хотим уйти.

Спасибо. А как перешли на новое партиционирование? Или ещё не перешли, а только постгрес апнули?
Пока только-только обновились, статья по горячим следам :)
Тогда жду новой статьи ))
НЛО прилетело и опубликовало эту надпись здесь
Если вы чувствуете в себе желание запускать RDBMS в docker, то в статье systemctl start поменяется на docker run, всё остальное плюс-минус останется тем же. Статья же про миграцию, а не про запуск. Либо я не понял суть комментария :)
НЛО прилетело и опубликовало эту надпись здесь
>И попутно избавив мир от {yum install,curl}

Когда уже докерофилы избавят мир от себя? Одиночный curl для скачивания репы для них уже танцы с бубном.
>Как бы 2019-й на дворе

В 2019 ещё и Монго есть, с которым не надо так красочно приседать при обновлении :)
docker без напильников — это почти фантастика, наш опыт печален с ним, все что изменяется в докере жить не должно, а уж тем более базы данных
НЛО прилетело и опубликовало эту надпись здесь
Что вы хотели этим сказать? Разверните мысль, пожалуйста.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
С тем же успехом можно написать sh скрипт «в несколько строчек».
Зачем СУБД заворачивать в docker?
Да и установка пакетов напрямую из интерета, ну это какой-то баян

А баян то в чём? Как в вашем современном мире ставятся пакеты?
НЛО прилетело и опубликовало эту надпись здесь
Кажется что СУБД это такая более-менее статичная вещь, которую не нужно таскать туда-сюда, обновлять по 2-3 раза в месяц.
Я правильно понимаю, что это не просто теория, а у вас есть реальный опыт эксплутации РСУБД в докере с размером БД примерно как у ТС?
Найдут дыру в СУБД

А в докере дыр не бывает, да? :)

Вообще это всё настолько на поверхности, что даже смешно писать.

Вы правы. Это смешно.
RUN apt-get update && apt-get install -y python-pip postgresql-11-pglogical postgresql-11-pgl-ddl-deploy && pip install pgrepup

А здесь, я полагаю, вы пакеты из шкафа достаете, а не из интернета ставите?
Сударь, не спорьте с современными девопУсами. Они любят бубунту, curl и консоль для них страшное шаманство, iptables -vnL они не смотрят (т.к. после докера там уже ничего непонятно). Журналы не читают (т.к. docker logs это насмешка). Обновлять софт не обновляют.

Зато любят повторять мантру про «чтобы развернуть на любой машине и оно 100% завелось». Хотя до 100% с их куцыми познаниями всё равно как до китая.
Спасибо за статью.
У нас был чем-то похожий кейс, только база у нас в AWS RDS (соответственно ни о какой нормальной мастер-мастер репликации не может быть и речи).
Использовали Bucardo для мастер-мастер «репликации», скажем так, не все так радужно.

Не замеряли лаг при использовании логической репликации? То что база у Вас большая это видно, но вот насколько она нагружена?
Как поведет себя репликация, если я на новый хост переключу приложение налету? То есть например запрос А пошел на старый хост, который еще не успели реплицировать на новый, а запрос Б пошел уже на новый сервер? Или же пока работает pgrepup, новая база в режиме read-only?
НЛО прилетело и опубликовало эту надпись здесь
Да, Bucardo это триггерная репликация.
Конкретно в нашем случае из-за того что база на RDS мы не могли ничего использовать кроме Bucardo.
Проблема вторая — если реально хочется бесшовную миграцию с мультимастерами, приложение должно уметь с этим работать.
Вывод — если у вас есть база в RDS и вы хотите ее обновить на один мажорный релиз, то не стоит париться с попытками репликации, а просто уложить сайт на maintenance на несколько минут.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий