Опубликованы исходные тексты проекта Kubegres, предназначенного для создания кластера реплицированных серверов с СУБД PostgreSQL, развёртываемого в инфраструктуре контейнерной изоляции на базе платформы Kubernetes. Пакет также позволяет управлять репликацией данных между серверами, создавать отказоустойчивые конфигурации и организовать резервное копирование. Код проекта написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55023
Ждём инсталлятора pythorust. Чтобы 2 в 1
"В случае сбоя на первичном узле" и почему может быть сбой в первичном узле? Накопитель? Так мега raid можно сделать. Сеть? Так тогда переконфигурировать master-slave не выйдет.
Кубер грознит постгрю за превышение лимитов?
Физически сервер выгорит?
Да мало ли- не?
> "В случае сбоя на первичном узле" и почему может быть сбой в первичном узле?Стандартный процесс вывода физического сервера на maintenance: kubectl drain --ignore-daemonsets --delete-local-data $NODENAME
Никто не гарантирует, что поды будут жить вечно. Это же продовое окружение, а не подкроватный сервер Васи, который проработает пять лет без обновлений, а потом помрет из-за износа SSD.
Да хоть обновление ядра. На одном узле, конечно, можно пытаться сделать отказоустойчивую систему, но любое её обслуживание превратится в ад. Малейшая ошибка админа - и всё рассыпалось, ювелирная работа, перед которой нужно ещё и учения делать.В распределенный системе типичный сценарий обслуживания - вывел сервер из кластера автоматикой, поэкспериментировал ручками, сделал что хотел, протестировал, ввёл обратно в строй. Никакого стресса.
К первичному серверу наведалось ФСБ/обэп по доброте душевной с конфискацией оборудования. Или ваш любимый датацентр сгорел.На одном хосте ты ничего вменяемого никогда сделать не сможешь, это уже понятно всем лет как 10.
> К первичному серверу наведалось ФСБ/обэп по доброте душевной с конфискацией оборудования.
> Или ваш любимый датацентр сгорел.
> На одном хосте ты ничего вменяемого никогда сделать не сможешь, это уже
> понятно всем лет как 10.Я даже несколько стесняюсь спросить, но надо свои комплексы преодолевать! А про CAP теорему Вы слышали?
Я - не слышал. Расскажи.
Всякие умнообразные любят формулировки "а вы слышали?"
Яви нам свой ум.
Рассказывай.
ну про яйца и корзину человечество знает уже несколько сот тысяч лет :)
А есть KubeMySQL?🤔
https://blogs.oracle.com/developers/introducing-the-oracle-m...
Чем это лучше классики (zalando/postgres-operator)?Насколько я могу судить, разве что возможностью задать StorageClass без лишних плясок с бубном.
Ну и держать полноценную дисковую БД (будь то постгрес или эластик) имеет смысл только на локальных физических носителях (в крайнем случае, на дисковой полке). В облаках будет работать весьма неторопливо.
Взяли хорошй, годный PostgreSQL и обернули его во всякую гадость: Go, Docker, Kubernetes, YAML... ещё какого-нибудь фронт-енда на java/node.js не хватает.
Попробуйте сделать на этом "хорошем, годном" мульти-мастер, например.
>Попробуйте сделать на этом "хорошем, годном" мульти-мастерзачем вообще мультимастер? это по определнию тормоза и/или косяки с потерей данных.
даже в божественной монге не делают мультимастер )
> зачем вообще мультимастер? это по определнию тормоза и/или косяки с потерей данных.Для постгреса - да. Потому что он "хороший, годный". И может обрабатывать (upsert, например) ровно такой объем данных, с которым может справиться один физический сервер. Круто, правда?
Нагрузку на запись обычно масштабируют шардированием. Мультимастер не даёт существенного горизонтального масштабирования. Мультимастер -- это скорее про удобство.
> Нагрузку на запись обычно масштабируют шардированием.Да, наиболее очевидный путь.
> Мультимастер не даёт существенного горизонтального масштабирования. Мультимастер -- это скорее про удобство.
Когда приходится решать типовую задачу "раз в полчаса нужно сделать SELECT с кучей JOIN-ов из нескольких десятков таблиц и применить к этому хитрые правила агрегации, а потом записать это в ещё одну таблицу, тоже шардированную, потому что данных дофига" - начинаешь задумываться об удобстве.
Возможно стоит задуматься о дизайне приложения и о дизайне хранения данных. И не всегда данные изначально надо хранить нормализованными. В общем надо смотреть на конкретный случай и искать умное решение.Но что важнее, multimaster тут не добавляет удобства. Он добавляет удобства в том смысле, что не приходится заморачиваться с master-slave схемами, когда хочется тупо HA.
> Возможно стоит задуматься о дизайне приложения и о дизайне хранения данных. И не всегда данные изначально надо хранить нормализованными. В общем надо смотреть на конкретный случай и искать умное решение.И в итоге в таких случаях умным решением окажется не постгрес, а кликхаус (если юзкейс позволяет не обновлять таблицы, а пересоздавать их) или эластик, со слоем кэширования в виде редиса.
И вся логика по хитровыделанной обработке данных уходит на сторону приложения, которое можно масштабировать хоть до посинения (если разработчики слышали про map-reduce и прочие умные слова).
А в РСУБД остается только минимальный объём данных, где действительно необходимы транзакции.
Для многих приложений скорее всего так и будет. А для, например, крупной социалочки будет просто шардированный master-slave mysql:)
Только если нужно тащить легаси. Если делать такой проект с чистого листа - никаких РСУБД среди основных компонентов там не будет.
Работал некоторое время на один проект, который в принципе можно назвать крупной социалочкой, и который около 2015 года (как раз в начале активного роста) переехал с монги на эластик. Это не xUSSR, конечно.
ты не из подольска случаем?
Правильно тебе минус поставили за эластик с редисом
И это уже не говоря о том, как весело будет выглядеть реализация репликации, фейловера и backup/restore для шардированных данных в постгресе.
Легким (на самом деле нет) движением ваши проблемы увеличиваются в 10 (или сколько там шардов) раз.
Полагаю, для этого и делают все эти оркестраторы (хотя не пользовался). Чтобы взрослые конфигурации могли себе позволить не только большие компании, но и маленькие.
Не видел ни одного более-менее готового оркестратора, облегчающего работу в плане шардирования.Для нешардированных данных - да, тот же Patroni. А шардирование в постгресе настолько тяжко, что обычно проще выкинуть постгрес.
В таких случаях часто разумно не делать селект раз в полчаса, а повесить триггеры и делать денормализацию/агрегацию на лету. Тут, кстати, бывает полезен fdw.
Такие костыли не от хорошей жизни делаются. На все несколько десятков таблиц триггер вешать? И пусть при вставке весь мир подождёт?
> реплицированных в режиме реального времени вторичных pod-узлов, синхронизированных с первичным узломРазве это мультимастер? Емнип, в ПГ мультимастера пока нет, есть герой-одиночка Коити Сузуки, который пилит то ли Postgres-XL, то ли Postgres-XC, то ли Postgres-X2, то ли ещё под каким-то названием, но до продакшона там как до Токио раком.
> Разве это мультимастер?Нет, конечно. Для РСУБД с ACID, насколько я знаю, задача мультимастера в настоящее время не решена.
И вряд ли будет решена в обозримом будущем.
Это просто был довольно толстый стёб над "хорошим, годным" постгресом, который сдыхает уже на 1 Тб независимо от крутизны сервера.
С чего бы постгресу на 1 ТБ сдыхать? Вполне себе работает с 1,3Тб уже и не парится, прирастая по 3-5 Гб в сутки. Причём на совершенно не крутом сервере.
Даже не знаю, как криво надо поставить Постгрес, чтобы он на 1 ТБ сдыхал.
> Даже не знаю, как криво надо поставить Постгрес, чтобы он на 1 ТБ сдыхал.Достаточно просто с ним более-менее интенсивно работать. Набить данных и хранить их можно хоть в SQLite (фанаты не-хипсторства и по 30 Тб туда засовывают).
Вполне нормальная нагрузка (банк).
Есть федеральный проект, но тут ещё только к 1ТБ приближается объём (пока только миграция данных со старых систем), но в проекте 8-12 ТБ (возможно увеличение проекта с соотв.ростом базы до 20-30ТБ).
С высокой долей вероятности вас ждёт уникальный и незабываемый опыт.
Я это уже прошёл, и больше повторять не хочу.
Я один такой неудачник, что в ОПСОС 30+ТБ в одно рыло разработал и тащу?
~500ГБ, >2e9 записей в сутки, шардирования нет, но проверял - работает через postgres_fdw, но там даже 10Гб линков нет, нет смысла :(
Кто хочет - ищет возможности, кто не хочет - ищет отговорки.
Вау. Вот всегда к постгресу приглядывался, но до дела никак ни доходило. А тут такое пишут. Терабайт. Охренеть. У нас на говномонге сейчас этих терабайт уже около 80. И мы еще думали куда-то сваливать.
Неужели все так плохо?
> Неужели все так плохо?Сказать, что "всё плёхо" - это ещё не есть "всё плёхо".
Автор "всё плёхо" пока свои слова никак не доказал.
Смотря кто будет проектировать систему. С постгресом можно сколько угодно, но надо понимать его ограничения, чтобы не упереться в них. С монгой, впрочем, то же самое.Если, скажем, Бартунов с Сигаевым, то все будет хорошо. Если аноним с опеннета, все будет плохо. Ну и все промежуточные варианты. :)
А чем плох percona cluster для мультимастера?
Тем, что mysql - недобд. Вы хочите бд - идите к нам (с) оракле
> Тем, что mysql - недобд. Вы хочите бд - идите к нам (с) ораклеПотом вы, конечно, сильно огребёте из-за нашей политики, цен и необходимости иметь ДБА за немалую зарплату (да, мы - Ынтерпрайз, но без постоянного пригляда ваша БД долго работать не сможет), но это - потом. Зато мы круты! (С) Оракля
>> Тем, что mysql - недобд. Вы хочите бд - идите к нам (с) оракле
> Потом вы, конечно, сильно огребёте из-за нашей политики, цен
> и необходимости иметь ДБА за немалую зарплату (да, мы - Ынтерпрайз,
> но без постоянного пригляда ваша БД долго работать не сможет), но
> это - потом. Зато мы круты! (С) ОракляЯ не про это исходно, но перкона - это про зарабатывание денег.
попробуй сделать что-нибудь на божественном глобальном и надёжном ораклЕ
о ретрограда локалхостов порвало
Ну да, надо же размазать базу по нодам (чем больше, тем круче) и гордо об этом заявлять на смузи вечеринках, при этом хранить в базе goвнокомментарии какого-нибудудь goвносайта.
> при этом хранить в базе goвнокомментарии какого-нибудудь goвносайта.Нет, как раз для с этим прекрасно справляются мускуль и постгрес, благо объёмы и нагрузки там смешные.
Да и олдовые труЪ-программисты на своём пыхе умеют только с PDO работать.
На самом деле, с этим в больших объёмах справляется эластик. Но это сама по себе головная боль с его тягой выеданию памяти. Но это потому что java.
> На самом деле, с этим в больших объёмах справляется эластик. Но это
> сама по себе головная боль с его тягой выеданию памяти. Но это потому что java.Эластик под другие задачи заточен, чем обычно РСУБД используется.
Многие люди любят совать РСУБД там, где достаточно более простого хранилища.
Потому что в РСУБД можно запихать очень много бизнес-логики. Для всеми забытого интернет-магазина это работает, для нагруженных проектов - нет.
Выкиньте вы уже этот ваш эластик. Из головы, для начала. Пользуйтесь lucene, это несложно, а возможностей больше.
>Пользуйтесь lucene, это несложно, а возможностей большеГалоперидол не выпил? lucene это мотор, ES мотоцикл... можно конечно и мотор эмбеднуть в какую-то микроподелку и даже радоваться, но чтобы хаять ES это мощно )
Любопытства ради, а как вообще обрабатывать серьёзный большой продакшн без "размазывания"? "Смузи вечеринки", блин.
По слухам, в постгреспро умеют.
А так-то:
1. Найти человека(компанию), который знает, что вам нужно, лучше вас. Да, обычно это дорого. Иногда очень дорого.
2. Обучить своего человека, сильно менее дорого, но сильно более долго. А потом понять, что на хрен нам такая музыка.
3. Еще раз подумать.
> По слухам, в постгреспро умеют.
> А так-то:
> 1. Найти человека(компанию), который знает, что вам нужно, лучше вас. Да, обычно это дорого. Иногда очень дорого.
> 2. Обучить своего человека, сильно менее дорого, но сильно более долго. А потом понять, что на хрен нам такая музыка.
> 3. Еще раз подумать.А есть годные решения, работающие "как хочется" из коробки? Постгрес, как и любой технический объект универсального применения, требует подстройки под конкретный проект. Но каких-то мегатайн там нет: документация - отличная. Надо набираться опыта. Без опыта и с кубером особо не поработаешь. Даже развернуть его для продуктивной площадки - весьма не тривиальная задача.
> А есть годные решения, работающие "как хочется" из коробки?
> Постгрес, как и любой технический объект универсального применения, требует подстройки
> под конкретный проект. Но каких-то мегатайн там нет: документация - отличная.
> Надо набираться опыта. Без опыта и с кубером особо не поработаешь.
> Даже развернуть его для продуктивной площадки - весьма не тривиальная задача.Ну сколько раз объяснять?
1. Вася, который пришел и ушел
2. Вася, который пришел, научился, "спасибо", см. п. 1
3. Вася, который пришел, научился, вас всех в юх не ставитДругие варианты стоят денег.
> Ну сколько раз объяснять?
> 1. Вася, который пришел и ушел
> 2. Вася, который пришел, научился, "спасибо", см. п. 1
> 3. Вася, который пришел, научился, вас всех в юх не ставит
> Другие варианты стоят денег.В чём разница, если вместо Постгреса указать тот же Кубер или любое другое сложное ПО?
Это вопрос организационный, причём совсем не обязательно, что Вася п.2 станет Васей п.3.
Если этот gовносайт - фейсбук, то без размазывания вряд ли получится. ;)
Срач про модное и не_модное в другой ветке
о мамонт вылез.
вы еще не померли, любители все героически настраивать руками?
Нет, профессионалы писать софт на Си.
Не стоит применять опыт написания программ учёта для небольших складов к проектам, работающим с большими объёмами данных. Это делает вас выглядеть глупо.
Не стоит применять опыт написания на английском языке небольших комментариев на форчане к русскому языку. Это выставляет вас к крайне глупом положении.Не стоит применять опыт телепатии или угадывания если он отсутствует. Это выставляет вас к крайне глупом положении.
Не стоит применять иронию/юмор/сарказм/гротеск, если она/он отсутствует.
А по-моему наоборот - взяли падучий кусок г-на, так и не научившийся надежной и просто настраиваемой репликации/фэйловеру (никакого multimaster тут нет, если что), и облепив его достаточно тривиальными и простыми _стандартными_ обертками - добились таки возможности использовать без риска что оно развалится само по себе или ему не хватит мощности.Редкий случай, когда я не могу придраться к использованию kubernetes, все вроде бы в соответствии с общепринятыми практиками и по делу.
> А по-моему наоборот - взяли падучий кусок г-на, так и не научившийся
> надежной и просто настраиваемой репликации/фэйловеру (никакого multimaster тут нет, если
> что).Что не так с hot standby в PostgreSQL?
то что костылякать всю кучу подпорок тебе надо вручную. Вручную же следить за ее живостью, вручную костылить переключение если вдруг чего, вручную восстанавливать сдохшее.Тут все за тебя сделает инуитивно приятный скриптик на игого, и не забудет свой ботинок на красной кнопке. Предполагая, разумеется, что у тебя и так есть k8s кластер для всего остального.
Даже про бэкапы не забыли, понимая, что рано или поздно понадобятся все равно ;-)
То что в новости описано не делает из постгреса мультимастер. Также как сделать это с помощью go и др хипстерства не выйдет. Это все не более чем оркестратор.
это лучше, чем goto?
> То что в новости описано не делает из постгреса мультимастер.
> Это все не более чем оркестратор.Спасибо, Капитан!
> Также как сделать это с помощью go и др хипстерства не выйдет.
С помощью PHP, немытой головы и обгрызенных ногтей, которыми гордятся не-хипстеры - тоже, увы.
Если админ оракла все данные и логику пхают в базы, то фаны кубернетса, пхают все что можно в кубер.А потом оказывается, что часто кубер самый overprovisioned
https://www.itproportal.com/news/majority-of-cloud-spend-is-.../
Админы как раз ничего в базу не отправляют просто так.
А кубер реально во многих случаях не нужен, если это небольшая система, уж проще через композ, если на то пошло.
> А потом оказывается, что часто кубер самый overprovisionedЕсли у меня в шкафу семь рубашек, но каждый раз я надеваю не более одной - это значит, что у меня рубашки overprovisioned, и шесть надо выкинуть?
Тут скорее больше подойдет аналогия с самолетами:
У тебя 6 самолетов, летаешь ты на одном - а остальные 5 простаивают и жрут деньги. В то время как достаточно иметь 1 борт + 1 запасной.
Мне больше нравится другая аналогия...
Вот у тебя есть 6 любовниц... одновременно ты проводишь время только с одной... (можно и больше на самом деле, но мы ужесточим условия задачи :) а 5 томятся в ожидании...Ну и нормально чувак, просто попробуй ... :)
Нравиться может что угодно. Самая близкая из трех - аналогия с самолетами. А с любовницами - вообще мимо. У тебя инстансы постгреса должны быть все в одинаковом состоянии. Никаких "томятся" здесь быть не может.
А, так вы выступаете против идеи репликации.И против идеи бэкапов, очевидно, тоже, потому что это overprovisioning дискового пространства.
и очевидно против идеи виртуализации тоже... даже не смотря на то что как только компании начинают виртуализировать ресурсы- перерасход ресурсов сразу же становится в 3-4 раза.. а у хостеров так в десятки раз...странный чел.... лучше бы любовницу себе завел... ну даже если не 6, а хоть одну :)
> и очевидно против идеи виртуализации тоже... даже не смотря на то что
> как только компании начинают виртуализировать ресурсы- перерасход ресурсов сразу
> же становится в 3-4 раза.. а у хостеров так в десятки
> раз...
> странный чел.... лучше бы любовницу себе завел... ну даже если не 6,
> а хоть одну :)Вы, погромисты, странные люди. У каждой любовницы еще по 5 пахарей, тут проблема ортимизации :)
>тут проблема ортимизации :)Именно.
Но судя по постам - они либо слова такого не знают, либо его значение для них сродни табу.
>>тут проблема ортимизации :)
> Именно.
> Но судя по постам - они либо слова такого не знают, либо
> его значение для них сродни табу.Почему же табу, очепятка :))))) Да и про "табу" есть сомнения.
Эк меня сегодня на поговорить расперло :)
Вот, вы правильно понимаете аналогию и состояние дел в виртаулизации и облаках... а про самолеты- ахинея оторванная от жизни...
> Вот, вы правильно понимаете аналогию и состояние дел в виртаулизации и облаках...
> а про самолеты- ахинея оторванная от жизни...А про самолеты - это Вы про что? Я, конечно, не против поуправлять государством, но при этом не логинлюсь, обознатушки?
> как только компании начинают виртуализировать ресурсы- перерасход ресурсов сразу же становится в 3-4 раза.. а у хостеров так в десятки раз...ваши оценки сомнительны. в наиболее виртуало-скептических источниках я видел другие цифры - оверхед на виртуализацию максимум 25-30%.
Вы похоже вообще не понимаете о чем идет разговор...
А разговор идет о том, что там вверху этой нитки, некто дал ссылку на чейто выхлоп в духе "один канадский, английский, чукотский, китайский, чубушский ученый заявил", в которой утверждается, что "Организации ежегодно тратят миллиарды долларов на неиспользуемые облачные решения" ну и далее по тексту статьи...
На что, я и привел оценку, на основе знания работы реальных датацентров а не тех что исследовал тот чубушский ученый, и облачные решения не то что "неиспользуемые" ка кутверждает автор той статьи - они вкалывают с загрузкой 300-1000%. В промышленных компаниях - выделеные ресурсы на порой 3 раза превышают имеющиеся физические, в хостинге - до 10 раз легко.а "оверхед НА виртуализацию" - это совсем совсем другой параметр, ортогональный теме.
Да почему же - с любовницами какраз в точку - обеспечивать нужно всех одинаково, время проводишь с одной, а все остальные "томятся" без тебя, но с кем то другим (для поддержания одинакового состояния однако ;) )
> А с любовницами - вообще мимо.Да, там должно быть
"Вот ты известный дизайнер одежды и у тебя есть 6 любовников... одновременно ты проводишь время только с одной... (можно и больше на самом деле, но мы ужесточим условия задачи :) а 5 томятся в ожидании и тянут бабки... а на самом деле тебе и один нахрен не сдался, потому что тебя к женщинам тянет - но "не поймут-с", сразу без клиентов останешся.
>> А с любовницами - вообще мимо.
> Да, там должно быть
> "Вот ты известный дизайнер одежды и у тебя есть 6 любовников... одновременно
> ты проводишь время только с одной... (можно и больше на самом
> деле, но мы ужесточим условия задачи :) а 5 томятся в
> ожидании и тянут бабки... а на самом деле тебе и один
> нахрен не сдался, потому что тебя к женщинам тянет - но
> "не поймут-с", сразу без клиентов останешся.С одним, тогда уж. Гадко, но надо :(
Никогда не понимал очеловечивания железа. Все эти женские имена серверов вызывают :)
Вот ты - изветный админ/программер (БД/Unix/Network/Java/C+++), очередь выстраиваться должна из коллег, которые тебя ждут. Очередь работодателей - это для мартышек, которые сегодня здесь, завтра там, а даже год у одного платителя денег провести не могут.
Вот! Вот он тот самый случай когда айтишники рассуждают о том, о чем не имеют ни понятия, ни предмета, который приводят в аналонию.А потом, а потом они с умным видом собеседуют аналогичных персонажей с попыткой изображать супермегапсихологов (это в лучшем случае), и в итоге мы имеем то, что имеем.
Айти сдохло en masse лет 20 назад. Ничего нового не ждите.
Действительно, откуда у айтишника любовницы... :) Айтишнику хотябы одну.. где нибудь, как нибудь... :)
>Если у меня в шкафу семь рубашекна одной вешалке.
>это значит, чтосм. выше
> Если админ оракла все данные и логику пхают в базы, то фаны
> кубернетса, пхают все что можно в кубер.
> А потом оказывается, что часто кубер самый overprovisioned
> https://www.itproportal.com/news/majority-of-cloud-spend-is-.../Недавно видел забор логов с удаленных систем и отправку их в агрегатор через кубрнет, да еще и со ссылкой на тытрубу, где он этому научился. Слов нет.
Чем это отличается от stolon или patroni?
https://blog.flant.com/comparing-kubernetes-operators-for-po.../