Комментарии 34
Что думаете про этот подход? https://habr.com/ru/articles/956154/
Обычно, клиенты приходят к идее мультимастера, когда доходят до предела возможностей по количеству подключений в OLTP-нагрузке. У них есть большое количество клиентов, N tps производительность системы, одна база данных. Их идея заключается в том, чтобы поставить рядом ещё один такой же сервер, настроить active-active-репликацию и обеспечить себе 2xTPS нагрузку.
для них, думаю, оптимальны программно-аппаратные комплексы.
выжило решение patroni+etcd. Попытка встроить консенсус в экземпляр, думаю, тоже тупиковая.
идея active-active кажется простой и соблазнитльной, но это не то, что кажется
Следует помнить, что active-active репликация в Postgres возможна пока только на логической репликации - а это значит сетевые задержки, дополнительная нагрузка на сервер от декодинга, walsender’a и т.д. Ну и сразу появляются сетевые задержки - нам же нужно дождаться подтверждения от удалённой ноды, что транзакция была применена успешно, так?
durability обеспечивается физической репликой или pg_receivewal. Попытка это сделать это логической репликацией тупиковая - это только кажется, что добавив 2pc, фенсинг найдётся решение. Логическая асинхронна и чем больше лаг в двунаправленной логической репликации, тем больше вероятность конфликта.
то, что мультимастер не оправдал себя, бывает. Такое и с i/o шедулерами линукс было - какие красивые алгоритмы и cfq и bfq, с каким интересом, наверное, их кодили. По инерции пытались воскресить киберами, скрестить что-то. Но практика - критерий истины, всё кончилось шедулером none: победило программно-аппаратное решение, контроллер плашек шедулит лучше.
победило программно-аппаратное решение
Это я бы сразу вынес за скобки: если будет возможность реализовывать сложную логику аппаратно, то я голосую за аппаратный коммит - это сразу решит кучу проблем и ускорит базы настолько, что может и мультимастеры будут не нужны.
выжило решение patroni+etcd
Ну, моя идея здесь подискутировать, вдруг ещё просто технологии не доросли? Так часто бывает. Просто так отказываться, без фактов и доводов на руках не интересно - иначе не стал бы время терять.
durability обеспечивается физической репликой
Хм, а я здесь не это поднимал на щит (хотя это приятный бонус), а другие плюшки мультимастера.
Логическая асинхронна
Так здесь основная идея и есть в том, чтобы классифицировать данные на те, которые не боятся разрешения конфликта по типу "Last update wins", и на те, что нужно коммитить синхронно, препареными стэйтментами + 2PC. Вопрос в долях таких данных и механике разделения.
В целом, меня лично привлекает независимость от физического представления - роутить запросы можно и на уровне приложения: например инсерты с апдейтами конкурируют редко.
Так здесь основная идея и есть в том, чтобы классифицировать данные на те, которые не боятся разрешения конфликта по типу "Last update wins", и на те, что нужно коммитить синхронно, препареными стэйтментами + 2PC. Вопрос в долях таких данных и механике разделения.
сложность высока, даже если можно реализовать и реализует гений, то продукт не смогут дорабатывать. Например, строки меняются в транзакциях, а даже в уровнях изоляции нет согласия: Oracle уровень serializable понимает по-своему, пропуская insertы, а PostgreSQL понимает по-другому. При разделении данных и синхронном коммите большая вероятность появления взаимоблокировок. Надо что-то простое.
большая вероятность появления взаимоблокировок
Вот это я не понял. Глобальный дедлок разрешается также, как локальный, только чуть дольше - есть же код пгпрошного мультимастера по ссылке.
сложность высока
Ну ок, схемы данных вроде простые инженеры составляют. В чем проблема маркировать таблицы по типу репликации?
проблема в маркировке в том, что все таблицы обычно связаны внешними ключами. Если хоть одна таблица должна меняться синхронно, то и остальные синхронно. Если асинхронно, то блокировки могут браться в произвольном порядке, а это появление взаимоблокировок. То есть получится, что на одном экземпляре взаимоблокировок нет, внедрили мультимастер они появились. То есть идея вычленения того, что может меняться асинхронно вряд ли хорошая. Вы написали, что не всем нужна конситентнось, не все - это nosql, нереляционные базы и это другой рынок.
одна таблица должна меняться синхронно, то и остальные синхронно
Отлично, здесь подбираемся к сути дискуссии. Само собой, одна их технологий, которую нужно ещё изобрести - это определение, должна ли транзакция заканчиваться "тяжёлым" 2PC или нет. В Postgres подобные механизмы уже существуют - например, проверка дерева запроса на то, что он может быть выполнен параллельными воркерами. Или вот ванильный DDL Replication упёрся пока в то же самое - определить, какие части DDL должны реплицироваться, а какие затрагивают только локальные объекты. В том и цель, чтобы определиться с объёмом необходимых изменений.
я трачу время на подготовку именно ради обмена знаниями и фактами
это главное. Можно посмотреть, как это решалось "до нас". Если бы технология была выигрышная, её бы попытались реализовать компании с большими ресурсами или купили бы стартап.
В Goldengate репликация асинхронная, синхронной нет. Исходные транзакции на подписчике могут разбиваться на мелкие и объединяться в крупные автоматически. Если возникнет ошибка, то эта исходная транзакция проводится в том порядке, как на источнике. Это пример, как практически улучшается производительность.
Двунаправленная (на практике 2 или 3 узла, так как при 4 узлах будет 12 маршрутов) есть и автоматическое разрешение конфликтов и прописываемое вручную, лучше сделать нельзя. Мало кто понимает, как работают директивы автоматического разрешения конфликтов - это о сложности. Вероятность конфликтов прямо зависит от лага. Лаги, при загрузках данных достигают часов. В часто встречающихся случаях (столбец с остатками товара или балансе) прописать правила разрешения конфликтов нельзя даже имея old и new. Политкорректно: ее мало кто использует и рекомендует. Неполиткорректно было по ссылке, которую приводил shurutov - это шарлатанство, так же, как распределённые очереди, о которых тоже мечтают. По моему мнению, о Мастер-Мастере могут задумываться только платёжные системы. Еще особенность - в Goldengate передача подписчику идёт после фиксации транзакции. С виду это глупость, но, думаю, как то позволяет избегать проблем на подписчике с теми же блокировками и разбиением транзакций. В PostgreSQL поначалу так же сделали, но так как логика простаяи откаты быстрые, дали возможность передавать подписчику до фиксации транзакции, что для PostgreSQL разумно.
Отлично, за Goldengate спасибо.
попытались реализовать компании с большими ресурсами или купили бы стартап
Так я ж про то и писал! В статье же все есть: multimaster - первопроходец, pgactive - продукт большого брата AWS, spock - стартап с кучей клиентов. Стал бы я два вечера на написание этого убивать иначе.
Лаги, при загрузках данных достигают часов
Хм, я пока таких больших лагов не видел. Хотя схема загрузки у них - сразу через все мастера. Получается на ощупь сильно быстрее, хотя я понимаю, что это трюк, и потом еще долго логическая репликация догоняет. Но благодаря batch insert replication в протоколе оно работает действительно быстро.
прописать правила разрешения конфликтов нельзя
То, что я вижу - клиенты просят авто уведомление о конфликте (с описанием, что триггернуло) обратно в приложение, и им этого достаточно.
о Мастер-Мастере могут задумываться только платёжные системы
Хм, а моё мнение - они последние в очереди. Пока что основные пользователи - склады, больницы, вояки всякие - те у кого конфликтов на обновление мало, да и те eventually можно разрешить, база нужна и рядом, а коннект постоянно рвется.
Возможно, здесь ещё дело в менталитете: сколько помню свой российский опыт разработки, всегда считалось, что приложение менять нельзя. А тут наоборот: хотите реальный профит - подстройте приложение под возможности СУБД ;).
Пример со складами и больницами был качественно решён в Siebel на промежуточном уровне. Там центральная база, с которой работают, когда находятся в офисе. Но продавцы часто ездят, в самолетах в то время интернета не было. Хотелось, чтобы продавец сидел с ноутбуком в пути и работал с opportunities - составлял планы, activities. Решено было локальным приложением, которое было обрезанным сервером приложения (один в один, это нетрудоемко) и локальной реляционной базой (sql anywhere потом oracle XE). При нахождении в офисе (подсоединении к сети компании) запускалась синхронизация локальной базы с общей (oracle или sqlserver) через промежуточные таблицы. Когда интернет появился везде, потребность в локальном приложении отпала, да и к тому времени лицензия (уже у оракл, купившей siebel) на sql anywhere закончилась, но стандартный функционал еще долго работал. А вот популярность кастомизации синхронизации быстро ушла: прописывать потаблично как, что синхронизировать трудоемко и неприятно. Поэтому идею выделения таблиц и выбора типа репликации считаю тупиковой. Траты на реализацию задачи синхронизации были оправданы только для Siebel Sales - автоматизации работы тех, кто дает доход компаниям. Ну еще компании готовы тратиться на обслуживание топов, но у них эксель и красные папочки.
Если канал связи слабый, то, наверное, оптимальнее это на уровне приложения учитывать.
качественно решён в Siebel
Кейс интересный, спасибо
интернет появился везде
Чёрт, где же сейчас есть такое, в Москве? Что в Челябинске, что в Чианг-Мае интернет - это большая проблема. Особенно после каких-нибудь циклонов. Даже когда канал-так есть, проблема в том, что клиенты ходят по общедоступным каналам, а DBMS может рентовать быстрый CDN. По мему опыту, это цифры порядка 100 мс V/S 600 мс, а это уже большая разница.
синхронизировать трудоемко и неприятно.
Хм, а какие есть варианты? Подозреваю, регулятор РФ не позволит реплицировать перс данные в какую-нибудь Францию, и обратное тоже верно. Вроде бы это уже дефолтное поведение, что нужно настраивать ограничения на размещение данных, и регулятор будет счастлив, если это будет прям явно прописываться, нет?
У вас не будет проблем с конфликтами, если вместо конкурентного консенсуса использовать конвергентный.
Я просто оставлю это здесь: https://ru-postgres.livejournal.com/57460.html
И добавлю от себя. Задайтесь простым вопросом: - а какие задачи решает мультимастер? Потом сядьте, возьмите ручку, бумажку и попытайтесь вдумчиво ответить СЕБЕ на поставленный выше вопрос. И, самое главное, какой ценой. Про масштабирование в геораспределённых системах говорить не надо - я немножко знаком с подобными системами, доводилось, знаете, эксплуатировать. Подробностей не будет - подписка, однако.
Почитал, спасибо.
Там почему-то постулируется навозможность сохранения консистентности. Существование мультимастера в PGPro Enterprise разрушает этот стэйтмент, нет? А если имеется кейс, которой способен поломать 2PC+Raft, то стоит его продемонстрировать - уверен, коллеги из Postgres Professional подарят вам за это бесплатную лицензию :)))
Ну и без подробностей это все так себе выглядит. В конце концов, мы тратим свое время на публикации здесь ради подробностей, маркетологи заседают в другом месте. А как выглядят продукты с буквами грифа секретности я ещё помню - это точно не про технологии.
Существование мультимастера в PGPro Enterprise разрушает этот стэйтмент, нет?
Существует? В виде открытого свободного расширения: https://github.com/postgrespro/mmts
Коммерчески выгодные, прибыльные и, самое главное, работающие возможности, например, автономные транзакции, из ПгПро в открытый доступ не переносятся. Почему бы это?
И да, моя рекомендация про прикинуть цену с ручкой и бумажкой, как я посмотрю, пропала втуне. Увы, но на дискуссии ради дискуссии у меня нет ни времени, ни здоровья, ни сил, ни желания.
Скажу лишь, что для масштабирования люди успешно используют секционирование и шардирование.
PS. У логической репликации в постгресе есть недостаток, который ставит крест на её использовании в большинстве случаев. Если не в подавляющем большинстве. Вопрос на засыпку: какой? Ответьте, пожалуйста, СЕБЕ, на этот вопрос, мне не надо, я постгресом в промышленной эксплуатации в различных ОТРАСЛЯХ занимаюсь с 2006-го года.
Шардирование
Шардированию нужны глобальные транзакции, если мы играем в консистентность. Я делал шардман уже несколько раз и должен сказать - это посложнее мультимастера будет. Так что альтернатива спорная.
на дискуссии ради дискуссии у меня нет ни времени
Ок, я трачу время на подготовку именно ради обмена знаниями и фактами, так что просто стоит пропускать мои публикации сразу.
Вопрос на засыпку: какой?
Было бы продуктивно, если бы ответ был дан, желательно с разьяснениями и ссылками, иначе в чем смысл?
В виде открытого свободного расширения
Расширение старое, но все технологии подглядеть там можно. А если есть критика - так можно всегда договориться и взять актуальный продукт потестить. Сомневаюсь, что коллеги не дадут такое провернуть, это к их выгоде и пиару.
автономные транзакции
Чистая коммерция с узким применением. Сообществу эта поделка не нужна точно, смысл её публиковать?
рекомендация про прикинуть цену с ручкой и бумажкой
Так с того-то все и началось! Народ приходит и активно покупает, пока под соусом active-active репликации, но до мультимастера здесь пара шагов. Вот я и задался целью прояснить, что они покупают и зачем.
Шардированию нужны глобальные транзакции
Шардирование необязательно реализовавать на уровне БД.
просто стоит пропускать мои публикации сразу.
Не пиши вы в блоге компании Постгрес Профессиональный - никаких вопросов (я именно так и делаю). А т.к. компания является непререкаемым авторитетом (для далёких от тем СУБД-строения и использования лиц), то любые доводы по поводу мультимастера разбиваются об аргумент: - а вот у постгреса профессионального мульимастер есть! В Enterprise-версии.
И, да, чтобы не вставать. Деньги вам платят не за то, что вы - весь из себя такой красивый, а за
Чистая коммерция с узким применением.
Ну и рассказывать про сферу применения автономных транзакций человеку, который эти автономные транзакции рекламировал: https://pgconf.ru/talk/1587881
пусть это будет на вашей совести.
разбиваются об аргумент
Не об это они разбиваются, а о то, что никто ж не демонстрирует, как этот мультимастер ломает консистентность. Хотя оппоненты по рынку могли бы прикупить лицензию на безвестное ООО, добиться расхождения по данным и демонстрировать на всех ивентах. А раз нет, то значит работает.
Мне эта его идея 100% консистентности самому не нравится - уж слишком идеализировано, большинству это не нужно. Поэтому и рефлексирую здесь.
пусть это будет на вашей совести
Хм, от внедренца было бы интересно послушать про применение, а вот от маркетолога ... Впрочем изложите - обсудим, ведь мы именно для этого здесь. Я эту штуку сопровождал в коде - это один большой геморрой, ломающий концепцию транзакционности и создающий огромные затраты на разработку и поддержку всего, что должно с ATX сосуществовать и тормозящий инновации. При этом окромя побочных задач логирования и отслеживания изменений я лично о других применениях не слышал. Какой-нибудь колоночный сторадж имеет сильно более широкую сферу применения чем это самое.
непререкаемым авторитетом
Вот с этим вообще рекомендую поаккуратнее. Любой авторитет - только для справки.
маркетолога
челодлань.жЫпег. Вы бы хоть внутри компании поинтересовались, кто я такой. :(((
Ну, в моей компании по-русски говорю я один, из российских деятелей там разве что Андрея Бородина могут знать, ну и может Олега Бартунова.
Так распишешь, в каких случаях применяют ATX?
в моей компании по-русски говорю я один
Так вы ещё и не из ПгПро?
Так распишешь, в каких случаях применяют ATX?
Нет. В докладе есть. И да, даже логирование и отслеживание изменений в фин.секторе - это достаточно частая задача, чтобы говорить о её необходимости. Я уже после увольнения из ПгПро нередко сталкивался с необходимостью ATX, каковая костылилась dblink-ом.
каковая костылилась
dblink
Хм, значит имеем trade-off: тормозить разработку, ломать транзакционную целостность, поддерживать хак уровней изоляции V/S костылить для финансистов логирование через dblink.
Учитывая стоимость разработки и проблемы, каждый раз, когда СУБД падает в SEGFAULT, я лично выберу второй вариант.
Нет. В докладе есть.
Изучил. Есть там короткий раздел про область применения из трёх пунктов. Один из них я даже могу понять ;). Подозреваю, что у инженеров внедрения есть свой Суржик , на котором они общаются быстрее, понимая друг друга и экономя время - в разработке такой язык точно есть.
Однако, поскольку запрос был на вывод ATX из закрытого энтерпрайза в open-source, то думаю имело бы смыл изложить идеи более универсальным методом, привести подробно набор кейсов для OSS-разработчиков, чтобы мы могли вообще понять, почему есть потребность в таком инструменте, выявить, чем принципиально ограничены текущие широкие возможности регистрации изменений, предоставляемые механизмом расширений Postgres. Возможно, просто пока никто не взялся сделать такое расширение ...
Андрея Бородина
кто такой, чем знаменит? (шучу)
В ПгПро уже несколько поколений сменилось. Там очень круто вырастают новые специалисты.
Тут в комментах люди пишут по делу, и я с ними согласен. Как я и написал в комментах в линкедине - multimaster это способ сделать tradeoff пожертвовав консистентностью ради доступности на запись.
Если не окрапить алтарь кровью консистентности - доступности не появится, отказы отдельных узлов будут влиять на доступность также как и в репликации с лидером.
Такова теория, опровержений ей нет.
ради доступности на запись
Так кто бы спорил? Я ж про другое совсем писал. Насколько нужна доступность при развале конфигурации - это пусть клиент решает. Кому-то из них (я точно знаю) важнее иметь возможность фиксировать изменения локально, с последующим, хотя б и ручным слиянием, нежели теоретические гарантии.
А у некоторых только 20% данных пишутся со всех сторон, а 80% только локально, в зоне нахождения сервера - и конфликтов почти нет, и лаг (небольшой) не играет роли. На кой чёрт закладываться на репликацию всего тогда?
Многие понимают под мульти-мастером то, что если один инстанс упал, то коннекты переводятся на другой. Я черт возьми устал повторять, что это (часто) не тот случай - у каждого свои пользователи, но часть данных должна быть общая.
аж олдскулы свело... я был там же, в том же зале, чета рассказывал
Когда у меня кто то спрашивает про мультимастер в PG, я обычно спрашиваю в ответ, что он знает о теореме CAP. Как правило оказываеться ничего, и отправляется читать википедию. Мне это неплохо экономит время.
Хм, и что с того?
Помнится, когда занимался я тепловыми расчётами, мой заслуженный научрук (без иронии), декан и член-корр всяких академий тоже в пух и прах разносил модель градиента тепла в погранслое - математически некорректно, недостоверно ... Но вот мои поделия как работали, так и работают. И на стендах расчеты подтверждаются экспериментально.
САР-теорема - это замечательно и must have. Однако в жизни можно ставить задачу не столь идеалистично. Вроде бы весь пост именно про это написан. В конце-концов, если мы 100% полагаемся на математику, зачем люди до сих пор делают бэкапы? ;)
Однако в жизни можно ставить задачу не столь идеалистично.
Так я именно про это же. Человек задумывается над теоремой и понимает, что нужна реализация каких то конретных метрик. И вопросы про сферический мультимастер отпадают, так как наступает хоть какое-то начальное понимание о возможностях и ограничениях в реализации.
Пересматривая концепцию мультимастера на Postgres