Поведайте за multimaster в PostgreSQL

У тебя не заработает ))

Говори почему или проваливай из треда, балаболов и так хватает

Насколько это круто, и насколько это приемлемо к текущему использованию и главный вопрос - сколько это может стоить может сказать DBA после анализа текущей базы и её нагрузки. Просто так поднять мультимастер не получится

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

Cons:

The main disadvantage of multi-master replication is its complexity.
Conflict resolution is very difficult because simultaneous writes on multiple nodes are possible.
Sometimes manual intervention is required in case of conflict.
Chance of data inconsistency.

/thread

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

Можешь попробовать какой-нибудь внешний «синхронизатор».

Мне уже и стрёмно спрашивать, таких очевидных вещей не знаю… какой например? по слову синхронизатор наверняка что то про двигатели ДВС и АКПП вылезет

MM на постгресе можно сделать, но исключительно за счет организации правильной архитектуры твоего приложения. А тебе точно нужне MM, а не failover?

Чот прямо в голоооооссс аааааа

Да, крутится на нем в моем случае будет 1С

Решения 1С по ряду причин не поддерживаются.

сама 1с пишет что то, но термин мультимастер не использует, завтра найду

Поведайте за multimaster в PostgreSQL

Всё плохо.

Поведайте за multimaster в PostgreSQL

Всё плохо

В каком смысле «плохо»? У мультимастера существуют принципиально неразрешимые проблемы, потому «плохо» там у всех, но по разному. PostgreSQL, как изначально ACID СУБД, теряет это самое ACID в мультимастере. «Плохо» ли это? Зато «хорошо» в системах, где этого ACID не было с самого начала. Но делает ли это их лучше постгреса?

У человека, который сформулировать пост не может без «за» и «wellcome» - не заработает совершенно точно.

Ты чего сказать то хотел? Я говорю, что с мультимастером всё плохо. Потому что нет реализаций нормальных хоть сколько-нибудь. Есть асинхронный мультимастер, есть синхронный. Но оно нормальо не работает, только лишнюю боль добавляет. И не ту, которая идеологически мультимастер это боль, а боль конкретных имплементаций.

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

Хорошо, давай так: у кого «нормально» работает мультимастер?

Я начитался рекламных проспектов и решил что это круто

расскажи нам, почему ты так решил, а мы посмеемся. какую проблему в твоем случае должен решить ММ?

Спецам которые умеют в ММ и хайлоад плотить по 150 в месяц, только поэтому я думаю затащить его в ынтырпрайз, но я смотрю что:

а) за такие решения 1с просит отдельных денег

б) не нашел тут ни одного человека с 1С и ММ

продолжаю наблюдения

Как всегда путаешь цель и средство. У тебя есть энергия, а вектора ты так и не нашел.

у кого «нормально» работает мультимастер?

Во всяком случае в галере приемлемый мультимастер. Пользую несколько лет. В постгресе тоже несколько лет пользовал разные мультимастеры.

не нашел тут ни одного человека с 1С и ММ

Ей не нужен ММ. Просто идеология использования не предполагает.

Забудь про мм, не осилишь продуктового решения, потом проклянут пользователи. Бери patroni/stolon и накрывай pgbouncer-ом.

Во всяком случае в галере приемлемый мультимастер. Пользую несколько лет. В постгресе тоже несколько лет пользовал разные мультимастеры

И неужели галера чем-то лучше BDR?

Ты не работаешь, и он не будет.

И неужели галера чем-то лучше BDR?

Это вообще разные вещи. Некорректно их сравнивать.

Это вообще разные вещи. Некорректно их сравнивать

В чем некорректность? Обе системы предоставляют синхронный мультимастер.

В чем некорректность? Обе системы предоставляют синхронный мультимастер.

Иди проспись. BDR это асинхронный мультимастер.

Иди проспись. BDR это асинхронный мультимастер

Проблема заключается в том, что этот «асинхронный мультимастер» по целостности данных не отличается от «синхронного» Galera:

https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster

Фактическое же внесение изменений происходит асинхронно, и при попытке запросить инфу в режиме Snapshot с нескольких узлов ты получишь нецелостные данные, даже несмотря на то, что к каждому узлу данные доходят в правильном порядке — просто, они приходят с разной задержкой.

Какая разница тогда вообще? Собственно, сами разрабы галеры эту разницу и продают — она в том, что галера из коробки самостоятельно выходит из отвала узла. В основном. Если ты будешь кидать все записи на один узел BDR, то ты получишь аналогичную по производительности и надежности систему. Аналогичную по надежности — потому что Galera точно так же пролюбит некоторое количество последних закоммиченных, но не сохраненных на постоянный носитель данных. И еще у галеры хорого продается хитрый костыль, который прикрывает факт нарушения целостности, подтормаживая быстрые узлы, чтобы за ними поспели медленные. Что не отменяет того факта, что никаких строгих гарантий целостности Galera не дает.

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

Естественно, и Galera, и BDR свой подход выбрали потому, что жесткое поддержание ACID гарантий загоняют производительность кластера на днище, и, самое главное, угрожают фактору доступности, ради которого мультимастер и делался, поскольку работа люто тупящего кластера мало чем отличается от полного отказа. В конечном итоге, если у тебя есть много пишущий клиент, которому важно видеть актуальные и целостные данные, то единственный практически приемлимый способ это сделать для общего случая — это писать и читать этим клиентом в один-два узла, которые станут эталонными для кластера. Именно поэтому, например, в PostgreSQL из коробки есть поддержка синхронного двухмастера.

Какая разница тогда вообще?

Ну, если пробовал, ты эту разницу ощущешь. :) Если не пробовал, то да, какая разница? Подумаешь, репликация и там, и там.

PostgreSQL из коробки есть поддержка синхронного двухмастера.

И в чём же заключается эта поддержка?

PostgreSQL из коробки есть поддержка синхронного двухмастера.

И в чём же заключается эта поддержка?

https://www.postgresql.org/docs/9.2/warm-standby.html

«Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server»

Ну, если пробовал, ты эту разницу ощущешь. :) Если не пробовал, то да, какая разница? Подумаешь, репликация и там, и там

Ты мне напоминаешь поклонников докера, которые сначала выбрали докер, а потом придумывают, почему лучше докера ничего нет. Мол «у меня получается пользоваться этим инструментам — зачем мне выискивать в нем недостатки?». ACID гарантий нет и при отвале узла кластер окажется в хер пойми каком состоянии — но мультимастер зато, похвастаюсь начальству на митинге. В том же яндексе, чтобы не строить иллюзий на тему, устраивают регулярные отвалы кластеров.

А тем временем альтернативные решения с eventual consistency (так называется модель целостности данных кластера Galera) позволяют достигать намного большей производительности записи за счет тех же безконфликтных слияний изменений за счет тех же Conflict-free_replicated_data_type, в которые, внезапно, умеет BDR, но не умеет Galera. А если тебе не нужна целостность данных и не нужно масштабирование записи — зачем тебе мультимастер? Чтобы масштабировать read-only доступ к БД с одной записью в секунду? Асинхронной репликации в таком раскладе выше крыши.

«Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server»

Я почему-то в уме держал контекст ММ, а это да, есть такое, но в разрезе ММ его не хватает.

Мол «у меня получается пользоваться этим инструментам — зачем мне выискивать в нем недостатки?»

Может, наоборот? У меня не получается пользоваться этими инструментами и я много чего перепробовал, чтобы оно получилось. :)

В том же яндексе

Ну, ясно…

в которые, внезапно, умеет BDR

И который не умеет работать и не падать с трудностями восстановления. Ты сам то его пробовал? На каких объёмах?

Чтобы масштабировать read-only доступ к БД с одной записью в секунду?

Спасибо, посмеялся.

Асинхронной репликации в таком раскладе выше крыши.

Что значит выше крыши? :) Интер-ДЦ репликацию сможет только асинхронная. Галера, которая «почти то же самое, что и BDR» на больших рассояниях между нодами колом встанет.

Я почему-то в уме держал контекст ММ, а это да, есть такое, но в разрезе ММ его не хватает

Не хватает для чего? Для бурных оваций смузихлебов? Я даже развернуто описал, почему ничего больше, чем это, ты получить не сможешь.

У меня не получается пользоваться этими инструментами и я много чего перепробовал, чтобы оно получилось

Это то же самое. Под таким же соусом по миру шагал PHP, но даже в в 2021 никому в голову не придет говорить, что PHP тогда был лучшим инструментом в индустрии.

В том же яндексе

Ну, ясно…

У нас кластер из трех мускулей на галере под наплывом пишущих запросов с завидной регулярностью ложился из-за того, что после введения очередной фичи нагрузка превышала критическую. Не то чтоб там была какая-то прям потеря данных — просто, состояние системы было равносильно полному отказу, и пофигу, сколько там мастеров — хоть двадцать, потому что модель репликации галеры позволяет потопить бесконечное число «мастеров». Можешь считать меня галерохейтером. Не то, чтобы BDR позволяла решить эту же задачу сильно лучше — мультимастер имеет принципиальные ограничения, которые никаким инструментом не решаются.

в которые, внезапно, умеет BDR

И который не умеет работать и не падать с трудностями восстановления. Ты сам то его пробовал? На каких объёмах?

Не довелось. Однако, даже не имея этого «опыта», я прекрасно понимаю, про что ты говоришь, и почему без участия програмиста репликацию на BDR нельзя просто так поднять. А вот к вам как раз возникает вопрос: почему так получилось, что вы реализовали репликацию на BDR, не предусмотрев сценария восстановления из безконфликтных слияний? Я даже сомневаюсь, что ваши кодомакаки использовали CRDT.

Сценарий этой параши один и тот же: нам нужна СУБД, чо брать? Ну конечно же надежный и проверенный SQL, там всё быстро работает и готовых решений полно, а еще больше программистов, которые с этим умеют работать; а раз у нас SQL RDBMS, то, конечно же, мы будем нормализовывать его вусмерть и пользоваться самыми тонкими механизмами организации логических связей; проходит год-два, система обрастает очередями операций, в которых лежат все последние данные пользователей с неясными гарантиями, клиенты (они же бизнес-логика бэка) в нескольких местах отваливаются при конфликте транзакций без повторного запроса, из-за чего иногда «загадочным» образом пропадают данные, что сваливается на сбой каналов связи или «пользователь забыл на сохранение нажать».

Под такой адок Galera с автоповторами и автовосстановлением узла в стиле «ниче не произошло» подходит как нельзя лучше. Потерялись последние транзакции? А докажи! Что оно не масштабируется и производительность падает с ростом размера кластера? Да ничего страшного, введем ограничение по числу запросов и одновременных подключений.

Чтобы масштабировать read-only доступ к БД с одной записью в секунду?

Спасибо, посмеялся

Ну давай, расскажи мне, при какой интенсивности записей умирает ваш кластер?

Интер-ДЦ репликацию сможет только асинхронная. Галера, которая «почти то же самое, что и BDR» на больших рассояниях между нодами колом встанет

А вот теперь я вообще ничего не понял. Какой магический смысл держать большое число мастеров в одном датацентре? Два хоста с зеркальным массивом обеспечивают более чем достаточную надежность; производительность записей не растет, а очень даже падает; производительность же чтений нарастить зеркалом и оперативой на одной машине проще и эффективнее, чем любиться с многохостами, особенно учитывая тот факт, что канал один.

Не хватает для чего? Для бурных оваций смузихлебов?

Не, то, что ты описал, его вообще в контексте нашего обсуждения не нужно было.

под наплывом пишущих запросов с завидной регулярностью ложился

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

Однако, даже не имея этого «опыта»

Дальше можно не читать.

Ну давай, расскажи мне, при какой интенсивности записей умирает ваш кластер?

Галера или BDR? Галеру не знаю, там интенсивность небольшая. BDR не умирает от интенсивности записи. Он просто сам по себе умирает.

Какой магический смысл держать большое число мастеров в одном датацентре?

Чтобы не было single point of failure?

Однако, даже не имея этого «опыта»

Дальше можно не читать

Ага, гнилые отмазы. Я тебе даже описал, откуда ваши проблемы брались и как у вас падал BDR, но ты продолжаешь занимать позицию манагера «у меня не работает! Всё сломалось». Я подозреваю, что ваша команда таки до сих пор не поняла, что произошло и почему оно умерло. Именно потому я ставлю вас в один ряд с успешными стартаперами, которые сделали биржу на MongoDB, а потом удивленно смотрели, как их обчистили через одновременный многократный вывод средств с аккаунта.

Галеру не знаю, там интенсивность небольшая

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

Какой магический смысл держать большое число мастеров в одном датацентре?

Чтобы не было single point of failure?

Датацентр и является этой единственной точкой отказа. Да, шанс небольшой — но прикинь, каков он по сравнению с шансом отказа сразу двух серверов? По итогу все равно самым значимым фактором станет криворукость какого-то кодера или админа, который случайно уронит всю систему целиком.

Я тебе даже описал, откуда ваши проблемы брались и как у вас падал BDR

У нас не так BDR падал. В том то и дело.

Я подозреваю, что ваша команда таки до сих пор не поняла, что произошло и почему оно умерло.

Телепаты в треде. :) Только жаль, что ненастоящие.

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

Нет, не угадал. И что галерой удовлетворён тоже. У меня неудовлетворённость BDR и это не связано с интенсивностью записи. Он может поломаться и при небольшой.

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

И тут не угадал.

Датацентр и является этой единственной точкой отказа. Да, шанс небольшой — но прикинь, каков он по сравнению с шансом отказа сразу двух серверов?

Ну, зависит от многих факторов. А ещё и последовательный отказ серверов. Не обязательно сразу.

Я тебе даже описал, откуда ваши проблемы брались и как у вас падал BDR

У нас не так BDR падал. В том то и дело

Ты мог бы написать как, и я оказался бы уничтожен твоими аргументами — потому что свой сценарий я описал. А пока что «у нас ничего не работает».

Ты мог бы написать как, и я оказался бы уничтожен твоими аргументами

Я же писал - баговый он. Сам по себе. Может поломаться вообще без нагрузки. И это ещё мы до проблем с ММ не добрались. Я где-то это писал. Проблема с ММ - оно понятно, что есть и без них в реальной жизни нет, но падает то он и без этого. Я бы тебе описал сценарий, и даже мог бы показать ссылки на код BDR, но это так долго и муторно, а пользы видимой никакой. Ты же не будешь мне код этот править, верно?

Я же писал - баговый он. Сам по себе. Может поломаться вообще без нагрузки

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

Ты же не будешь мне код этот править, верно?

Конечно не буду — это ж closed source, а опенсорснуты только нулевые версии под 9.6.

Ну ты бы хоть версию написал.

Не помню. Но где-то 9.6, наверное, и есть.