Не мог бы

Голос сорван

Не, про такое речи не идет. Речь идет про то, как оно при прочих равных живет. В свое время я доводил до истерики "внедряторов кластерного постгреса" одним банальным kill -9 pid на одной из нод, после которой это "отказоустойчивое решение" рассыпалось в хлам

Странно сравнивать операционную сложность постгреса и оракла, у постгреса она по очевидным причинам выше в разы

Боюсь, это не к внедряторам вопрос, правда?
Внедряторам какой consensus protocol дали, такой они и внедряют

ну за давностью времен не помню, кто там внедряторы или консультанты какие. просто пришли со словами типа "у вас постгрес? давайте мы его вам сделаем отказоустойчивым и вааще". А тогда как раз у нас была боль с ним ... ну и делали 🙂

А в каком году дело происходило?

Мне кажется, отказоустойчивый постгрес не так давно появился (да и появился ли?)

эээ .. года три или четыре назад

была такая шутка типа postgres-xl очень специфическая и фактически мертворожденная, есть заландо патрони, но оно по факту даже в компании заладно в серьёзных проектах не используется по их же словам из докладов. Цитус опять же очень своеобразен и чистым постгресом его назвать нельзя так же как и гринплам. Коммерческое решение от постгрес энтерпрайз стоит таких денег что можно и про оракл или mssql подумать и как бы выходит так что широко доступное решение сейчас отсутствует. Опять же вопрос о каких объёмах данных мы говорим - десятки- сотни гб и не особо высокие нагрузки в плане записи- работать будет что угодно. Для mysql есть vitess например и если речь опять же идет от сотнях гб или считанных террабайтах то оно вполне себе работает и ограничений меньше чем у той же галеры

для постгреса есть еще stolon, но у кого есть адекватный опыт эксплуатации хз, опять же на сотнях гб оно более чем рабочее как и все остальное если в принципе против здравого смысла не идти и нет элементарных проблем вроде сетевых или "проблем" с схд

Когда речь заходит о высоких нагрузках, я сразу представляю себе канатную дорогу от Земли до Марса
Каким образом софт может отменить физические ограничения платформы, для меня загадка до сих пор
Как будто, у оракл бесконечные возможности для масштабирования

В RDBMS вообще как-то страшновато терабайты хранить, это все не от хорошей жизни

тем не менее оракл на десятки террабайт особо головных болей не вызывает, конечно разработчики могут делать странное и все такое, тут же конечно и вопрос изначальных требований к железу - пользователи mysql и postgresql привыкли что их можно поставить на что угодно, а потом уже последствия пытаться разгребать и вообще понять что и как работает, а в случае с тырпрайзом самф факт того  что цепочка от проектирования до эксплуатации по такому сценарию будет развиваться практически нонсенс

Если нечто не вызывает головных болей, его, по идее, можно один раз настроить, а потом вообще никогда не проверять, как тот замурованный роутер с OpenBSD

Непонятно, правда, зачем платить команде эксплуатации

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

мне пока непонятно, почему разваливается, систему не увидел. бд вполне нагруженная, ее все время утюжат

Точно не стоит делать вставки батчами, не стоит делать альтеры, дропы на тяжёлые  таблички - это приводит к блокировке записи на всем кластере.

Однозначно есть какие-то проблемы со свопом и так же начинаются проблемы с синхронизацией данных.

Время в кластере обязательно должно быть синхронизировано, небольшой рассинхрон в течении нескольких часов максимум легко вызывает проблемы.

Если ноды в разных дц и между каждым из дц больше 5-10 мсек лейтенси - это так же периодически гарантированные проблемы.

Если у вас ноды не 3, а 2+арбитр то шансы на ловлю проблем из-за сети опять же резко возрастают.

Если вы пишите одновременно больше чем в 1 инстанс то это тоже проблемы - запись не масштабируется - при такой схеме скорость работы снижается и доходит опять же до блокировок

это навскидку