Size: a a a

Обсуждения техдирские

2020 April 23

S

Serge in Обсуждения техдирские
Не мог бы
источник

S

Serge in Обсуждения техдирские
Голос сорван
источник

VK

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

S

Sweenota in Обсуждения техдирские
Phil Delgyado
Хм. Вот по поводу "сверхдешевого" и "избиение" - это очень сложный вопрос.
У PG в РФ есть две killer feature - дешевая внешняя поддержка 24*7 и jsonb

У прочих цена и решения и поддержки будет много выше.
Ну и мой опыт эксплуатации и Oracle и PG говорит, что PG работает гораздо стабильнее, в нем меньше идиотских ошибок и он много удобнее для разработчика. Я плохо представляю, где сейчас вообще имеет смысл брать Oracle, очень узкий спектр, когда Oracle еще справляется, а PG - нет.
Странно сравнивать операционную сложность постгреса и оракла, у постгреса она по очевидным причинам выше в разы
источник

S

Sweenota in Обсуждения техдирские
Viacheslav Kaloshin
Не, про такое речи не идет. Речь идет про то, как оно при прочих равных живет. В свое время я доводил до истерики "внедряторов кластерного постгреса" одним банальным kill -9 pid на одной из нод, после которой это "отказоустойчивое решение" рассыпалось в хлам
Боюсь, это не к внедряторам вопрос, правда?
Внедряторам какой consensus protocol дали, такой они и внедряют
источник

VK

Viacheslav Kaloshin in Обсуждения техдирские
Sweenota
Боюсь, это не к внедряторам вопрос, правда?
Внедряторам какой consensus protocol дали, такой они и внедряют
ну за давностью времен не помню, кто там внедряторы или консультанты какие. просто пришли со словами типа "у вас постгрес? давайте мы его вам сделаем отказоустойчивым и вааще". А тогда как раз у нас была боль с ним ... ну и делали 🙂
источник

S

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

S

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

VK

Viacheslav Kaloshin in Обсуждения техдирские
Sweenota
А в каком году дело происходило?
эээ .. года три или четыре назад
источник

GM

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

GM

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

S

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

S

Sweenota in Обсуждения техдирские
В RDBMS вообще как-то страшновато терабайты хранить, это все не от хорошей жизни
источник

GM

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

S

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

S

Sweenota in Обсуждения техдирские
Непонятно, правда, зачем платить команде эксплуатации
источник

GM

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

ЮВ

Юра В 🦄 in Обсуждения техдирские
Gleb Mekhrenin
к развалу ведь приводят вполне конкретные действия, список ограничений так же известен, да и вообще какая задача вызвала необходимость использовать мм решение ?
мне пока непонятно, почему разваливается, систему не увидел. бд вполне нагруженная, ее все время утюжат
источник

GM

Gleb Mekhrenin in Обсуждения техдирские
Юра В 🦄
мне пока непонятно, почему разваливается, систему не увидел. бд вполне нагруженная, ее все время утюжат
Точно не стоит делать вставки батчами, не стоит делать альтеры, дропы на тяжёлые  таблички - это приводит к блокировке записи на всем кластере.

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

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

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

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

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

GM

Gleb Mekhrenin in Обсуждения техдирские
это навскидку
источник