мне как инженеру могут поставить задачу

Так вопрос не о цене был.

и одно из решений данной задачи это ММ в синхронном режиме

Цена будет вычисляться на тестах после реализации на тестовом стенде

я про бизнес цену

Можно сколько угодно дискутировать на около MM темы, но все же )

можно всё таки кейс а не эфемерные штуки? вот Дмитрий привел пример, хоть и абстрактный.

просто доводится инфа, что: 1. Решение должно иметь Резервирование 2. При падении не должно быть потерь данных вообще 3. Время восстановления ограничено 4. Ресурсы задействованные надо по максимуму использовать

И почему тут не использовать MM синхронный?

Да почему абстрактный то? Вот есть сайт. Там дохерищаа трафика. Не такая частая запись. Хочу чтобы при отказе базы, или ее обслуживании все работало как и прежде

Раскидывать запроса пгпулом ну это изврат, простите.

и почему тогда надо говорить, что право на М-М имеет только асинхронный вариант?

И почему тут не использовать MM синхронный?

А зачем тут ММ. Это решается обычной репликацией.

Репликация Синхронная?

Я хочу писать в любой инстанс базы.

Вот примерно как в RabbitMQ можно HA политики настроить, чтобы все очереди были размазаны по всему кластеру

Так и тут.

И на таком кластере мы выжимали 5k w/sec

Еще раз, реплкикация нужна синхронная? - да

Более чем достаточно в контексте маленькая запись.

т.е. пинальти на запись мы уже несем

Еще раз, реплкикация нужна синхронная? - да

Это вопрос мне? Если да, то да.

отлично

Я готов с этим жить. Бизнес это даже не заметит.

Им надо чтобы сайт показывался круглые сутки не более.

а что будет если база превысить объем хранилища ? на всех серверах пачкой ? :)

Единственное, что меня напрягает во всей этой истории, так это DDL + INSERT/UPDATE/DELETE операции на разных узлах.

теперь предположим, что у тебя не тупой инсерт данных или апдей по ключу, а идут сложные апдейты, требующие значительных ресурсов (на формирование плана запросов, на поисх данных для апдейта).

в этом случае MM даст дополнительный выигрышь по сравнению с A-S

Я просто уже словил на проде deadlock на DDL операции

И чет подозреваю, что на MM реплике все будет еще трешовее.

а с учетом того что запрос не будет на несколько нод параллелится то непонятно как это еще и спасет...

зачем один запрос на несколько нод паралелить?

быстрее данные собрать при сложном апдейте

А можно реальный кейс применения синхронного мастер-мастера?

данные для днс серверов и для почтовых серверов. Например, у нас они в мульти-мастер в мускле, к которым цепляются соответствующие контрольные панельки, а на местах - вдс с слейвом, который берет данные с какого-нибудь мастера.

Хороший пример

еще хороший пример - биллинги.

В сбере было пара датацентров забито Alpha серверами (наверное уже забыли про такую архитектуру) под управлением OpenVMS, который работал как раз, как M-M Sync

к сожалению описание тех задач, которые решались/решаются с помощью этого комплекса так же попадают под NDA

Ну и для тех, кто интересуется активно такими вопросами есть отличный ресурс http://www.availabilitydigest.com/

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

там вы найдете много интересного и наверника будет реальные примеры где используется Active-Active Sync варианты

А на самом деле речь о нагрузке на межконтинентальную ракету

данные для днс серверов и для почтовых серверов. Например, у нас они в мульти-мастер в мускле, к которым цепляются соответствующие контрольные панельки, а на местах - вдс с слейвом, который берет данные с какого-нибудь мастера.

ник, данные днс в мускуле - зашквар. и они не нуждаются в мультимастере даже если. ты странным хвастаешься

у меня другой опыт. 1) в мускле их удобно быстро обновлять и они сразу оказываются на всех днс серверах (это невероятно лучше, чем в файлах, к тому же с точки зрения ФС хорошо) 2) у меня географический мультимастер и мне критично иметь данные, если одна из сторон отпадет. Реально пишу я только в один, остальные выполняют роль активного слейва

ник, данные днс в мускуле - зашквар. и они не нуждаются в мультимастере даже если. ты странным хвастаешься

3) но давай не будем тут про это спорить - у нас есть соседний чатик про хостинг. К тому же о чем вообще спорить - каждый раз оказывается, что я единственный вообще человек, у которого мускульный мультимастер работает без проблем уже почти 10 лет.

Ну тут вообще заявляется, что Мастер-Мастре Синхронный не имеет применения

и пока им не предоставят реальный пример (пример чего, кстати?) они не поверят

любые критичные данные, например - биллинг.

нужно пример использования M-M Sync?

или пример того, где без него не обойтись?

так вот, обойтись можно безо всего

даже вообще без резервирования и бэкапа

но это тож не аргумент

причем для биллинга - это в первую очередь активный слейв.

Опять полемика )) Так в итоге, про BDR кто может сказать конкрентно?

Или путь один - идти и самому пробовать?

про BDR вряд ли. Я пытался получить хоть какой-то фидбэк по pglogical

у меня другой опыт. 1) в мускле их удобно быстро обновлять и они сразу оказываются на всех днс серверах (это невероятно лучше, чем в файлах, к тому же с точки зрения ФС хорошо) 2) у меня географический мультимастер и мне критично иметь данные, если одна из сторон отпадет. Реально пишу я только в один, остальные выполняют роль активного слейва

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

их же производства

даже писал им

но никаких ответов

в общем тут надо самому брать и пробовать

тестировать

и решать, подходит ли тебе или нет

3) но давай не будем тут про это спорить - у нас есть соседний чатик про хостинг. К тому же о чем вообще спорить - каждый раз оказывается, что я единственный вообще человек, у которого мускульный мультимастер работает без проблем уже почти 10 лет.

потому что у тебя полторы калеки в клиентах без претензий к днс

Фил, ты не понял основной мессадж

по dns тебе предлагается обсуждать в другом месте

по dns тебе предлагается обсуждать в другом месте

я к тому, что это очень синтетический и плохой пример. или наоборот хороший - показывает, что примеры все имеют много "но"

Мы размазываем нагрузку на запись, чтобы её уменьшить. Получаем пенальти, блокировки и падение производительности. Замкнутый круг какой-то...

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

у меня не бывает плохой связности. Она или есть или нет. Когда большие потери пакетов - оно как-то само разруливается.

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

если асинхронно, то в мускле надо делать автоинкримент с шагом в число мастеров и тогда тоже всё работает (но зависит от данных если есть форинкеи)

Мне кажется не важно, какая репликация: синхронная или асинхронная. Пока ММ без заранее спроектированной архитектуры приложения несёт больше проблем чем пользы. Кстати в Oracle RAC та же картина. Если приложение писалось без учета работы на кластере - кластер можно разбирать.

а вот не согласен. Есть то ли proxysql, то ли greensql - и всё это разруливается на их уровне, а приложение вообще ничего про них не знает

ну скажем так, адаптировать/разработать приложение под Oracle RAC или M-M Sync несколько проще, а порой и вообще не надо, чем под случай с M-M Async

скажем, если много чтения, то N слейвов и раскидывать запросы - самое то

и уже это может стать поводом обратиться к MM Sync

Кто нибудь из присуствующих на текущем пгконе скажет что либо про ММ ? :)

Ваше право, но я как дба, в свой продакшен такую систему не пустил бы.

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

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

да я не против ММ Асинк

я за него

т.е. это например большой класс задач собирания около-логов и всякой статистики

но для каждой задачи есть свой инструмент

а заявлять голосолвно, что ММ Синк не нужен, т.к. "я бы такую систему не пустил бы к себе" или "я в финансах работаю и не встечал такого" - вот это, ИМХО, неверно

MM-async это как? сплитбрейн мне в бороду.

кто-то так не любит свои данные?

не знаю, есть ли в постгри такое, а в мускле чтобы не было сплитбрейна - достаточно задать шаг автоинкримента

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

Ух... вот это заявления тут проскакивают

ох лол, что значит досинкается? на машине же не полные данные :D и агрегаты, да идут по ...

Говорите "в моем случае, для моего решения, ничего старшного не случится" или "я пока в моей практике не натыкался на эти проблемы"

M-M Async это очень распространненный вариант

ох лол, что значит досинкается? на машине же не полные данные :D и агрегаты, да идут по ...

второй мастер поднимется/сеть появится - его данные дольются.