Комментарии 33
Лучше расскажите как потом компаниям сползать обратно на ванильный PostgreSQL когда финансирование вашей БД прекратится.
Как минимум вы должны своих клиентов обезопасить предоставив такой инструмент, может тогда кто-то бы и рискнул попробовать ваше решение не под дулом пистолета.
Нет никаких проблем вернуться на ванильную версию PostgreSQL. Более того, у нас в планах заложена реализация поддержки «ванилек».
Как, как... Берешь любую их реплику или мастер, выкидываешь все прослойки типа балансировщика и patroni, снимаешь с неё basebackup, тащишь его на другой сервер, подкладываешь standby.signal и вуаля. Вот тебе двухузловой pg без слотов и остального гемора.
Ну да, при этом один узел только для чтения. Хотя и в статье не увидел мастер-мастер, ну или шардирования.
Конструктор это все на мой субъективный взгляд.
Все эти patroni и HAProxy можно и самому поставить. У них у всех в документации написано, что они из коробки все делает.
Это типа как "москвич"?
Ради интереса - сравнитесь с Postgres Pro.
На сайте цен не находится, минимального количества лицензируемых ядер тоже, но есть ссылка на партнёров-интеграторов.
Продукт для местных филиалов Газпрома или Пенсионного Фонда?
Документ с политикой лицензирования можно скачать у нас на странице продукта https://www.orionsoft.ru/proxima в разделе "материалы". Цены можно запросить, обратившись на сайт info@orionsoft.ru, либо через любого авторизованного партнера Orion soft.
Вы очень лукавите, рассказывая о сложностях настройки кластера.
В предложенном вами решения, все компоненты стандартные, хорошо документтрованы и достаточно просты в настройке и эксплуатации.
Сложность любого кластера не в его настройке, а в его поддержке. Чем ваше решение поможет когда кластер развалиться, окажеться в не согласованном состоянии и будет два мастера каждый со своим набором не отреплицированных транзакций?
Ну это все patroni разрулит. По крайней мере разработчики для этого старались, и уверяют, что переключения могут происходить пока вы спите
Другое дело, зачем больше одного patroni в архитектуре?!
Я не отрицаю, что кластер нельзя настроить самому. С попытки так пятой, предварительно разобравшись со всеми параметрами, можно научиться его ставить условно за 3-4-5 часов (в Proxima DB он устанавливается за 15 минут). Но есть дополнительная проблема в том, что штатные пакеты (PostgreSQL, Patroni) в большинстве российских ОС значительно отстают от актуальных версий, местами критически отстают. Примерная последовательность действий, которые нужно совершить, чтобы все собрать из свежих пакетов в один продукт, как раз и описана в статье. И кластерное ПО Patroni как раз предназначено для того, чтобы кластер не "разваливался". При этом Proxima DB - это коммерческий продукт, и, покупая готовое "коробочное" решение, пользователь получает техническую поддержку от вендора.
А зачем в архитектуре больше одного patroni?
В чем смысл иметь две независимые БД в какой-нибудь "Рога и Копыта"? Или Вы как-то их скрестили?
В смысле "зачем больше одного patroni?" Один инстанс патрони следит за одним инстансом постгреса. Три инстанса постгреса - три инстанса патрони.
Зачем патрони следить за одним инстансом??? Он чо сам не умеет работать что ли :)? Вроде и коннекты принимает и даже sql умеет выполнять. Зачем ему одному patroni?
Patroni организует по крайней мере два инстанса (кластера) в отказоустойчивую единицу. Главная цель вовремя переключится и не устроить split-brain при этом. Это вот прям killer feature.
Вы, по-моему, теорию что такое патрони и зачем оно понаслышке знаете, а вот практики с ним не имели. Ещё раз: один инстанс патрони следит за одним инстансом постгреса. Сколько инстансов постгреса есть - столько инстансов патрони нужно для отслеживания их состояния. Инстансы патрони договариваются между собой о том, чей инстанс постгреса будет мастером, кто репликами и каждый из них соответственно пинает свой подконтрольный инстанс постгреса.
Ну где-то примерно за этим вопрос и задавал :). Ну ок. Тогда добавлю. Вся эта патронация не для того, чтобы договориться кто есть кто. Это вы сами решаете. Это все для того, чтобы со 100% вероятностью заключить, что мастер больше не мастер и пора менять лидера. Собственно замута как раз в этом, и патрони как раз для этого в первую, но не единственную очередь. Как это работает? Там кворум. т.е. несколько патрони голосуют жив мастер или нет. И только так можно определить стоит ли менять мастера именно сейчас.
Да, дела с этим тулом не имел, только читал и слушал. А потом пошел и сам все настроил. Там три параметра, чтобы собрать мастер-реплика.
А что произойдёт, если сервер с этим самым единственным патрони упадёт?
В архитектуре должно быть несколько PG и не сколько патронов. Если кто-то один выйдет из строя, его функции распределяться по работающим в данный момент. А ваша восстановить сломавшееся колено.
Нет никакого единственного патрони. У каждого инстанса постгреса под боком свой инстанс патрони, который за этим инстансом постгреса следит. Инстансы патрони между собой постоянно состоянием обмениваются. Рафт, вроде бы, сейчас уже из патрони выпилили за непопулярностью; обычно все настраивают с синхронизацией состояний инстансовчерез кластер etcd/consul. Если текущий "мастер" перестаёт слать в условный etcd периодический апдейт о том, что он в порядке, то другие инстансы по определенному алгоритму пытаются схватить его тапки. У кого получилось, тот свой подшефный инстанс постгреса повышает до звания мастера; остальные инстансы патрони свои подшефные постгресы перенастраивают чтобы те были репликами с нового мастера. Вот и вся магия, если очень грубо на пальцах обьяснять.
Вообще документация и исходники патрони не безумно объёмные. Три-четыре неспешных часа хватает чтобы подробно понять как у него внутре неонка работает.
Как не отроешь новый отечественный аналог, так везде просят бабки.
Зачем компании переезжать с бесплатного на платный аналог того же самого?
Если бы вы работали в компании КИИ, то этот вопрос бы не вставал. Однако зачем платить ноунейм чувакам при живом PostgresPRO или на крайняк поделках Аренадаты - вопрос. Может эти дешевле?
Всегда есть вариант использовать ванильный PostgreSQL бесплатно. Но бесплатных, да и коммерческих аналогов с подобной автоматизацией развертывания кластеров нет.
Сравнение Proxima DB с ванильной версией PostgreSQL представлено по ссылке.
Ну не скажите. Подобная автоматизация развёртывания есть у Виталия Кухарика: https://github.com/vitabaks/postgresql_cluster
Было бы круто увидеть сравнение с прямыми конкурентами - PosgresPRO & Arenadata. Яндекс когда пилил свой Clickhouse всеми силами креативил синтетические тесты, где он лучше Vertica (несмотря на разницу платформ) и выкладывал прямо на сайте. Было забавно, но открыто. В вашем же случае непонятно... Впрочем больше конкурентов - лучше продукты
Возможно, таких вопросов будешь меньше если станете регулярно коммитить в ядро PostgreSQL и писать об этом.
Я так понимаю, что вы взяли стандартные опенсорсные вещи, собрали стандартный HA сетап постгреса и продаёте это как уникальное российское решение? Никогда такого импортозамещения не было и вот опять.
Продукт с 2019 года, но простите где Вы были все эти 5 лет? Ни одной статьи на Хабре или еще где то. На PgConf 2024 Вас так же не было.
Сферический ProxymaDB-конь в вакууме, никак иначе.
Не newsql .....в топку этот новорожденный музейный экспонат! Зачем опять переписывать postgresql ?
Поверхностный обзор найти не сложно. Хотелось статей с конкретикой. Например, сейчас в небольшой компании (где в данный момент работаю) много проектов переходит с Windows+MS SQL на ASTRA+PostgreSQL (либо отечественное решение). Хотелось бы почитать как подружить авторизацию на базе Active Directory в Астре с вашим решением. Либо, как настроить автоматическое переключение между мастером и репликой туда-обратно при отказе мастера. Много же интересных тем можно раскрыть.
А что, обычный gss метод в pg_hba.conf не канает для аутентификации через AD, будь то астра или винды?
Аутентификацию в СУБД через AD можно настроить уже сейчас, мы помогаем настраивать это нашим клиентам, а аутентификация в UI через AD у нас в ближайших планах.
По поводу переключения между мастером и репликой туда и обратно - как раз кластер Patroni и решает задачи автоматического переключения (как в случае падения мастера, так и по запросу пользователя). Например, если есть потребность обслужить мастер, то можно "по кнопке" в веб-интерфейсе переключить мастер на одну из реплик, свободно выключить "бывший" мастер (переведя кластер в режим обслуживания), что-то в нем поменять, включить его в сеть, он сам автоматически досинхронизируется до нужного состояния, и потом так же "по кнопке" переключить роли обратно, если такое нужно (возврат ролей обратно автоматически не реализуется, и этому есть много объяснений).
Товарищу Бендеру на заметку. 401й "относительно честный" способ отъема денег.
Что такое Proxima DB? Знакомство с российской СУБД на базе PostgreSQL