16.10.2025 07:23
danolivo 28 2200 Источник

Одна из открытых пока задач в области баз данных - поддержание базы данных в консистентном состоянии одновременно на нескольких экземплярах СУБД (узлах), принимающих клиентские соединения независимо друг от друга. Суть проблемы заключается в том, что в случае отказа одного из узлов такой системы остальные должны продолжить свою работу без перерыва: принимать соединения, коммитить транзакции не потеряв при этом консистентность. Аналогией для случая одного экземпляра СУБД здесь может быть, к примеру, обеспечение работы при отказе планки оперативной памяти или прерывающемся доступе к нескольким ядрам процессора.

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

Я занимался созданием мультимастера несколько лет вплоть до того момента когда стало понятно, что концепция essentially consistent multimaster зашла в тупик. Сейчас, после длительного перерыва, сменив компанию я делаю ещё один заход на идею постгрессового мультимастера с целью таки закрыть гештальт и найти ему практическое применение (или, кто знает, показать что это нереализуемо).

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

Обычно, клиенты приходят к идее мультимастера, когда доходят до предела возможностей по количеству подключений в OLTP-нагрузке. У них есть большое количество клиентов, N tps производительность системы, одна база данных. Их идея заключается в том, чтобы поставить рядом ещё один такой же сервер, настроить active-active-репликацию и обеспечить себе 2xTPS нагрузку.

Бывает же, что клиент имеет распределенное приложение и хочет, чтобы коннект этого приложения к базе был стабилен и примерно одинаков в разных географических точках. А иногда люди приходят просто за надежным автоматическим фейловером. Гораздо более редкая задача (а скорее бонус) - обеспечить онлайн апгрейд, или плавный вывод одного из узлов на обслуживание. А еще бывает запрос на дополнительный мастер, имеющий прогретые кэши и состояние storage, близкое к боевому, который можно использовать в качестве тестового стенда … В общем задач хватает, однако что из этого в реальности можно обеспечить?

Следует помнить, что active-active репликация в Postgres возможна пока только на логической репликации - а это значит сетевые задержки, дополнительная нагрузка на сервер от декодинга, walsender’a и т.д. Ну и сразу появляются сетевые задержки - нам же нужно дождаться подтверждения от удалённой ноды, что транзакция была применена успешно, так? Поэтому идея масштабировать пишущую нагрузку для общего случая 100% репликации сразу упирается в тот факт, что каждый сервер обязан будет писать не только свои изменения, но ещё и изменения, приходящие с других инстансов (см. рисунок выше). Это не страшно для больших транзакций с развесистыми SELECT-ами, однако запрос на мультимастер скорее подразумевает клиентов с OLTP и очень простым DML.

Примерно с той же проблемой мы сталкиваемся, когда хотим просто обеспечить экземпляр распределенного приложения рядом стоящей базой с устойчивым коннектом. Ведь если коннект приложения с удаленной базой был плох, то и коннект двух экземпляров СУБД друг с другом также будет нестабилен. А раз так, то необходимость дожидаться подтверждения успешного коммита транзакции на удаленной ноде также потребует длительного времени ожидания.

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

С автофейловером ситуация проще, но и здесь нужно что-то изобретать, чтобы оставаться эффективным: ведь если все инстансы могут писать, то на коммит транзакции необходимо добавлять ожидание подверждения записи транзакции на каждом инстансе - иначе может статься, что при падении узлаN_x, часть его транзакций будет записана в базу на узле N_y, но не успеет попасть (или попадёт под rollback) в базе узла N_z. И как тогда исправлять подобную ситуацию - отправлять всю конфигурацию в recovery?

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

Я вижу два существенных достоинства логической репликации. Во-первых, она позволяет реплицировать данные селективно, выбирая конкретные таблицы. Также, для каждой таблицы можно настроить фильтр с условиями репликации, которые позволят быстро пропускать отдельные записи и целые транзакции ещё на самом первом этапе репликации - на этапе декодинга. Получаем весьма точечный механизм, позволяющий выделить конкретные данные, которые должны быть синхронизированы с удалённой стороной. Второе любопытное достоинство - высокоуровневость механизма. Фактически, репликация происходит на уровне реляционной алгебры, а значит, можно абстрагироваться от деталей физического хранения.

Что даёт высокий уровень абстракции? - например, можно иметь различный набор индексов на синхронизируемых узлах, локально уменьшая накладные расходы на DML и перенаправлять запросы в соответствии с тем, где выполнение может быть эффективнее: нагружать один инстанс короткими точечными UPDATE'ами/DELETE'ами по первичному ключу, оставляя DML с развесистыми подзапросами (или обычно не конфликтующие с  обновлениями INSERTы) другому инстансу. Также, можно использовать стандартный Postgres heap на одном и колоночный storage на другом. Или вообще попытаться использовать разные СУБД в качестве узлов мультимастера - фантазия ограничена только возможностями протокола репликции!

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

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

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

Спроектировав схему БД так, чтобы классифицировать данные по методу репликации мы можем даже уменьшить размер базы данных на конкретном инстансе, не отправляя локальные данные на удалённые узлы. Также, большАя часть данных может реплицироваться в одну сторону асинхронным методом, избегая оверхеда на ожидании подтверждения коммита от удалённой стороны. И только для критически важной части данных нужно обеспечить строгую синхронизацию, задействуя такие механизмы как синхронный коммит, 2PC и правила видимости не ниже REPEATABLE READ, что существенно просаживает время коммита такой транзакции и повышает риск отката вследствие конфликта.

Какой пример может быть у такого варианта использования? Я не имею опыта инсталляций у заказчика, поэтому могу представлять себе, как оно может быть чисто гипотетически. Это может быть международная компания, у которой данные о сотрудниках, равно как финансовые показатели должны храниться на серверах внутри каждой отдельной страны (вроде бы нынче это типовое требование). При этом в целях аналитики на чтение они могут быть доступны и снаружи - это похоже на кейс с фильтрацией реплицируемых данных по значению ключа. Также, таблицу сотрудников компании можно расщепить, реплицируя имена, должности, зарплаты и т.д. по всем экземплярам БД, вынося в отдельную локальную таблицу идентифицирующие конкретную личность номер соц. страхования или паспорта.

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

Из опыта работы в ракетостроении я вынес привычку оценивать изучаемый эффект качественно. Попробуем прикинуть, какой процент базы может реплицироваться в режиме active-active, чтобы потенциально производительность не проседала. Пусть, для простоты, у нас имеется два филиала компании на двух континентах и варианты конфигурации: (1) один сервер и (2) два сервера в режиме мультимастер, для которых доступ всегда будет локален (см. рисунок ниже).

Введём некоторые обозначения (см. также на рисунке):

  • T_l -время выполнения транзакции в бэкенде СУБД, мс.

  • T^c_l - network round-trip time для приложения, расположенного рядом с экземпляром СУБД, мс.

  • T^c_r -network round-trip time для приложения, расположенном на другом, относительно СУБД, континенте, мс.

  • T_r -время, необходимое для получения подтверждения о факте успешного коммита с удалённого экземляра СУБД, мс.

  • X_l -доля локальных подключений.

  • N - доля транзакций с DML, которым достаточно асинхронной репликации.

Для случая с одним сервером имеем:

TPS_1 = (T_l + T^c_l)*X_l + (T_l + T^c_r) * (1 - X_l).

Для мультимастера имеем:

TPS_m = (T_l + T^c_l)*N + (T_l + T^c_l + T_r) * (1-N).

Теперь зададимся подходящими числами для наших формул. Примем долю 50% для локальных подключений (X_l = 0.5). В качестве характеристики сетевого подключения, по опыту проживания в Азии и коннекта к московским ресурсам позвольте принять следующие цифры:

T_l = 5\ мс,\ T^c_l = 10\ мс,\ T^c_r = 150\ мс\ и\ T_r = 300\ мс.

Здесь T^c_l и T^c_r - это время одного раунд-трипа, в то время как, для подтверждения удалённого коммита (T_r) будем считать, что потребуется два раунд-трипа: в 2PC-протоколе сначала следует выполнить PREPARE STATEMENT, дождавшись успешной репликации изменений и резервирования всех необходимых для коммита ресурсов, а потом уже посылать команду COMMIT.

Задавшись такими цифрами мы получаем:

TPS_1 = (5+10)*0.5+(5+150)*0.5 = 7.5+77.5=85,

TPS_m =15*N + 315*(1-N)=315-300*N,

315-300*N < 85 => N > \frac{230}{300}\approx 76\%.

А теперь, представим, что количество удалённых подключений у нас выросло до 80%:

TPS_1=15*0.2+155*0.8=127,

N>188/300\approx 62%.

А что, если нужно обеспечить полную синхронную 2PC-синхронизацию всей базы данных? Посчитаем: N=0, X_l = 0.2, \frac{TPS_1}{TPS_m} = \frac{127}{315}. Получается потеря производительности в \approx2.7 раза для позитивного сценария. Не очень перспективно, но может кому-то этого вполне достаточно?

Такой грубый расчёт приводит нас к выводу, что при примерно 25% транзакций с DML, которым требуется подтверждение на удаленной стороне, мультимастер не почувствует просадки производительности. А в случае, когда большая часть трафика приходит откуда-то из удалённых регионов, то доля надёжно реплицируемых данных может достигать 40%, но будем консервативны и будем ориентироваться на N = 25%. При этом, мы снимаем половину нагрузки на дисковую подсистему, локи и прочее, что может быть использовано в локальных операциях, таких как вакуум, или в  read-only запросы. Кажется, здесь появляется рациональное зерно, нет?

Оборотная сторона медали заключается в том, что репликация, даже асинхронная, должна потенциально не отставать от потока коммитов. Очевидно, что если полное время на локальное выполнение транзакции составляет 15 мс, а one-way delay до удаленного сервера - 75 мс, то даже если не ждать подтверждения с той стороны, то в последовательном случае очередь изменений для репликации будет копиться.

25%  DML в нашей задаче коммитятся с подтверждением на удаленной стороне, значит остается 75%. 75\ мс*0.75=56\ мс. Чтобы покрыть эту разницу между темпом локальных коммитов и скоростью передачи данных на удаленный сервер, необходимо воспользоваться шириной канала: отправлять, а на удалённом сервере принимать данные параллельно (т.е. нужна параллельная репликация). И в нашей грубой модели выходит так, что передавать изменения достаточно в четыре потока. С учётом высвободившихся на сервере ресурсов (от распределения коннектов между инстансами) выглядит достаточно реалистично.

Итого, в сухом остатке имеем, что разнося географически данные в режиме мультимастера мы в теории можем рассчитывать на сравнимый TPS. При этом уменьшается количество бэкендов и потребление ресурсов на каждом конкретном сервере. Эти ресурсы могут быть высвобождены под системные процессы и различную аналитику. Не забудем и про возможность оптимизации индексов, storage и прочих атрибутов физического размещения данных на каждом узле системы независимо. Дополнительный бонус заключается в том, что в случае нарушения связи можно будет обеспечить врЕменную работу каждой из подсетей с расчетом, что после восстановления та или иная стратегия разрешения конфликтов поможет восстановить целостность базы.

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

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

  • Replication sets - чтобы классифицировать данные для репликации, отдельно обеспечивать синхронную и асинхронную репликацию.

  • Коммит с подтверждением (по аналогии с 2PC).

  • Протокол распределенного консенсуса для определения работоспособного подмножества нод и фенсинга сбоящих нод в 3+ конфигурациях.

  • Параллельная репликация - распараллеливание как отправки DML, так и их применения на удалённой стороне.

  • Automatic Conflict Resolution для автономного режима работы.

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

Давайте теперь посмотрим, что из вышеназванного реализуют текущие известные проекты мультимастера:

Технология

pgactive1

spock2

multimaster3

Replication sets

+

+

-

Guaranteed Commit

-

+/- (recovery slots ?)

+

Concensus protocol, fencing
(3+ configurations)

-

-

+

Parallel Replication

-

+

+/-

Automatic Conflict Resolution

-

+

не требуется

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

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

Ссылки

  1. https://github.com/aws/pgactive

  2. https://github.com/pgEdge/spock

  3. https://github.com/postgrespro/mmts

THE END.
Испания, Мадрид, 15 октября 2025 года.

Комментарии (28)


  1. nin-jin
    16.10.2025 09:05
    #28968908

    Что думаете про этот подход? https://habr.com/ru/articles/956154/


    1. danolivo Автор
      16.10.2025 09:05
      #28968996

      Я в целом за существование любого подхода, который можно придумать и реализовать. Если он есть, зачем он кому-то полезен ;).


      1. nin-jin
        16.10.2025 09:05
        #28969318

        Очень жаль, что вам плевать.


  1. OlegIct
    16.10.2025 09:05
    #28971288

    Обычно, клиенты приходят к идее мультимастера, когда доходят до предела возможностей по количеству подключений в OLTP-нагрузке. У них есть большое количество клиентов, N tps производительность системы, одна база данных. Их идея заключается в том, чтобы поставить рядом ещё один такой же сервер, настроить active-active-репликацию и обеспечить себе 2xTPS нагрузку.

    для них, думаю, оптимальны программно-аппаратные комплексы.

    выжило решение patroni+etcd. Попытка встроить консенсус в экземпляр, думаю, тоже тупиковая.

    идея active-active кажется простой и соблазнитльной, но это не то, что кажется

    Следует помнить, что active-active репликация в Postgres возможна пока только на логической репликации - а это значит сетевые задержки, дополнительная нагрузка на сервер от декодинга, walsender’a и т.д. Ну и сразу появляются сетевые задержки - нам же нужно дождаться подтверждения от удалённой ноды, что транзакция была применена успешно, так?

    durability обеспечивается физической репликой или pg_receivewal. Попытка это сделать это логической репликацией тупиковая - это только кажется, что добавив 2pc, фенсинг найдётся решение. Логическая асинхронна и чем больше лаг в двунаправленной логической репликации, тем больше вероятность конфликта.

    то, что мультимастер не оправдал себя, бывает. Такое и с i/o шедулерами линукс было - какие красивые алгоритмы и cfq и bfq, с каким интересом, наверное, их кодили. По инерции пытались воскресить киберами, скрестить что-то. Но практика - критерий истины, всё кончилось шедулером none: победило программно-аппаратное решение, контроллер плашек шедулит лучше.


    1. danolivo Автор
      16.10.2025 09:05
      #28971674

      победило программно-аппаратное решение

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

      выжило решение patroni+etcd

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

      durability обеспечивается физической репликой

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

      Логическая асинхронна

      Так здесь основная идея и есть в том, чтобы классифицировать данные на те, которые не боятся разрешения конфликта по типу "Last update wins", и на те, что нужно коммитить синхронно, препареными стэйтментами + 2PC. Вопрос в долях таких данных и механике разделения.

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


      1. OlegIct
        16.10.2025 09:05
        #28971982

        Так здесь основная идея и есть в том, чтобы классифицировать данные на те, которые не боятся разрешения конфликта по типу "Last update wins", и на те, что нужно коммитить синхронно, препареными стэйтментами + 2PC. Вопрос в долях таких данных и механике разделения.

        сложность высока, даже если можно реализовать и реализует гений, то продукт не смогут дорабатывать. Например, строки меняются в транзакциях, а даже в уровнях изоляции нет согласия: Oracle уровень serializable понимает по-своему, пропуская insertы, а PostgreSQL понимает по-другому. При разделении данных и синхронном коммите большая вероятность появления взаимоблокировок. Надо что-то простое.


        1. danolivo Автор
          16.10.2025 09:05
          #28973056

          большая вероятность появления взаимоблокировок

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

          сложность высока

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


          1. OlegIct
            16.10.2025 09:05
            #28975398

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


            1. danolivo Автор
              16.10.2025 09:05
              #28975466

              одна таблица должна меняться синхронно, то и остальные синхронно

              Отлично, здесь подбираемся к сути дискуссии. Само собой, одна их технологий, которую нужно ещё изобрести - это определение, должна ли транзакция заканчиваться "тяжёлым" 2PC или нет. В Postgres подобные механизмы уже существуют - например, проверка дерева запроса на то, что он может быть выполнен параллельными воркерами. Или вот ванильный DDL Replication упёрся пока в то же самое - определить, какие части DDL должны реплицироваться, а какие затрагивают только локальные объекты. В том и цель, чтобы определиться с объёмом необходимых изменений.


              1. OlegIct
                16.10.2025 09:05
                #28975658

                я трачу время на подготовку именно ради обмена знаниями и фактами

                это главное. Можно посмотреть, как это решалось "до нас". Если бы технология была выигрышная, её бы попытались реализовать компании с большими ресурсами или купили бы стартап.

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

                Двунаправленная (на практике 2 или 3 узла, так как при 4 узлах будет 12 маршрутов) есть и автоматическое разрешение конфликтов и прописываемое вручную, лучше сделать нельзя. Мало кто понимает, как работают директивы автоматического разрешения конфликтов - это о сложности. Вероятность конфликтов прямо зависит от лага. Лаги, при загрузках данных достигают часов. В часто встречающихся случаях (столбец с остатками товара или балансе) прописать правила разрешения конфликтов нельзя даже имея old и new. Политкорректно: ее мало кто использует и рекомендует. Неполиткорректно было по ссылке, которую приводил shurutov - это шарлатанство, так же, как распределённые очереди, о которых тоже мечтают. По моему мнению, о Мастер-Мастере могут задумываться только платёжные системы. Еще особенность - в Goldengate передача подписчику идёт после фиксации транзакции. С виду это глупость, но, думаю, как то позволяет избегать проблем на подписчике с теми же блокировками и разбиением транзакций. В PostgreSQL поначалу так же сделали, но так как логика простаяи откаты быстрые, дали возможность передавать подписчику до фиксации транзакции, что для PostgreSQL разумно.


                1. danolivo Автор
                  16.10.2025 09:05
                  #28975834

                  Отлично, за Goldengate спасибо.

                  попытались реализовать компании с большими ресурсами или купили бы стартап

                  Так я ж про то и писал! В статье же все есть: multimaster - первопроходец, pgactive - продукт большого брата AWS, spock - стартап с кучей клиентов. Стал бы я два вечера на написание этого убивать иначе.

                  Лаги, при загрузках данных достигают часов

                  Хм, я пока таких больших лагов не видел. Хотя схема загрузки у них - сразу через все мастера. Получается на ощупь сильно быстрее, хотя я понимаю, что это трюк, и потом еще долго логическая репликация догоняет. Но благодаря batch insert replication в протоколе оно работает действительно быстро.

                  прописать правила разрешения конфликтов нельзя

                  То, что я вижу - клиенты просят авто уведомление о конфликте (с описанием, что триггернуло) обратно в приложение, и им этого достаточно.

                  о Мастер-Мастере могут задумываться только платёжные системы

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

                  Возможно, здесь ещё дело в менталитете: сколько помню свой российский опыт разработки, всегда считалось, что приложение менять нельзя. А тут наоборот: хотите реальный профит - подстройте приложение под возможности СУБД ;).


                  1. OlegIct
                    16.10.2025 09:05
                    #28978920

                    Пример со складами и больницами был качественно решён в Siebel на промежуточном уровне. Там центральная база, с которой работают, когда находятся в офисе. Но продавцы часто ездят, в самолетах в то время интернета не было. Хотелось, чтобы продавец сидел с ноутбуком в пути и работал с opportunities - составлял планы, activities. Решено было локальным приложением, которое было обрезанным сервером приложения (один в один, это нетрудоемко) и локальной реляционной базой (sql anywhere потом oracle XE). При нахождении в офисе (подсоединении к сети компании) запускалась синхронизация локальной базы с общей (oracle или sqlserver) через промежуточные таблицы. Когда интернет появился везде, потребность в локальном приложении отпала, да и к тому времени лицензия (уже у оракл, купившей siebel) на sql anywhere закончилась, но стандартный функционал еще долго работал. А вот популярность кастомизации синхронизации быстро ушла: прописывать потаблично как, что синхронизировать трудоемко и неприятно. Поэтому идею выделения таблиц и выбора типа репликации считаю тупиковой. Траты на реализацию задачи синхронизации были оправданы только для Siebel Sales - автоматизации работы тех, кто дает доход компаниям. Ну еще компании готовы тратиться на обслуживание топов, но у них эксель и красные папочки.

                    Если канал связи слабый, то, наверное, оптимальнее это на уровне приложения учитывать.


    1. nin-jin
      16.10.2025 09:05
      #28971740

      У вас не будет проблем с конфликтами, если вместо конкурентного консенсуса использовать конвергентный.


  1. shurutov
    16.10.2025 09:05
    #28972378

    Я просто оставлю это здесь: https://ru-postgres.livejournal.com/57460.html
    И добавлю от себя. Задайтесь простым вопросом: - а какие задачи решает мультимастер? Потом сядьте, возьмите ручку, бумажку и попытайтесь вдумчиво ответить СЕБЕ на поставленный выше вопрос. И, самое главное, какой ценой. Про масштабирование в геораспределённых системах говорить не надо - я немножко знаком с подобными системами, доводилось, знаете, эксплуатировать. Подробностей не будет - подписка, однако.


    1. danolivo Автор
      16.10.2025 09:05
      #28973032

      Почитал, спасибо.

      Там почему-то постулируется навозможность сохранения консистентности. Существование мультимастера в PGPro Enterprise разрушает этот стэйтмент, нет? А если имеется кейс, которой способен поломать 2PC+Raft, то стоит его продемонстрировать - уверен, коллеги из Postgres Professional подарят вам за это бесплатную лицензию :)))

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


      1. shurutov
        16.10.2025 09:05
        #28973542

        Существование мультимастера в PGPro Enterprise разрушает этот стэйтмент, нет?

        Существует? В виде открытого свободного расширения: https://github.com/postgrespro/mmts
        Коммерчески выгодные, прибыльные и, самое главное, работающие возможности, например, автономные транзакции, из ПгПро в открытый доступ не переносятся. Почему бы это?
        И да, моя рекомендация про прикинуть цену с ручкой и бумажкой, как я посмотрю, пропала втуне. Увы, но на дискуссии ради дискуссии у меня нет ни времени, ни здоровья, ни сил, ни желания.
        Скажу лишь, что для масштабирования люди успешно используют секционирование и шардирование.
        PS. У логической репликации в постгресе есть недостаток, который ставит крест на её использовании в большинстве случаев. Если не в подавляющем большинстве. Вопрос на засыпку: какой? Ответьте, пожалуйста, СЕБЕ, на этот вопрос, мне не надо, я постгресом в промышленной эксплуатации в различных ОТРАСЛЯХ занимаюсь с 2006-го года.


        1. danolivo Автор
          16.10.2025 09:05
          #28973632

          Шардирование

          Шардированию нужны глобальные транзакции, если мы играем в консистентность. Я делал шардман уже несколько раз и должен сказать - это посложнее мультимастера будет. Так что альтернатива спорная.

          на дискуссии ради дискуссии у меня нет ни времени

          Ок, я трачу время на подготовку именно ради обмена знаниями и фактами, так что просто стоит пропускать мои публикации сразу.

          Вопрос на засыпку: какой?

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

          В виде открытого свободного расширения

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

          автономные транзакции

          Чистая коммерция с узким применением. Сообществу эта поделка не нужна точно, смысл её публиковать?

          рекомендация про прикинуть цену с ручкой и бумажкой

          Так с того-то все и началось! Народ приходит и активно покупает, пока под соусом active-active репликации, но до мультимастера здесь пара шагов. Вот я и задался целью прояснить, что они покупают и зачем.


          1. dbax
            16.10.2025 09:05
            #28973704

            Шардированию нужны глобальные транзакции

            Шардирование необязательно реализовавать на уровне БД.


            1. danolivo Автор
              16.10.2025 09:05
              #28973724

              Тогда и мы, разработчики СУБД, здесь ни при чём - инженерам хватит инструментов. Мы же здесь про случай, когда пользователь ожидает гарантии от системы баз данных.


          1. shurutov
            16.10.2025 09:05
            #28974732

            просто стоит пропускать мои публикации сразу.

            Не пиши вы в блоге компании Постгрес Профессиональный - никаких вопросов (я именно так и делаю). А т.к. компания является непререкаемым авторитетом (для далёких от тем СУБД-строения и использования лиц), то любые доводы по поводу мультимастера разбиваются об аргумент: - а вот у постгреса профессионального мульимастер есть! В Enterprise-версии.
            И, да, чтобы не вставать. Деньги вам платят не за то, что вы - весь из себя такой красивый, а за

            Чистая коммерция с узким применением.

            Ну и рассказывать про сферу применения автономных транзакций человеку, который эти автономные транзакции рекламировал: https://pgconf.ru/talk/1587881
            пусть это будет на вашей совести.


            1. danolivo Автор
              16.10.2025 09:05
              #28974862

              разбиваются об аргумент

              Не об это они разбиваются, а о то, что никто ж не демонстрирует, как этот мультимастер ломает консистентность. Хотя оппоненты по рынку могли бы прикупить лицензию на безвестное ООО, добиться расхождения по данным и демонстрировать на всех ивентах. А раз нет, то значит работает.

              Мне эта его идея 100% консистентности самому не нравится - уж слишком идеализировано, большинству это не нужно. Поэтому и рефлексирую здесь.

              пусть это будет на вашей совести

              Хм, от внедренца было бы интересно послушать про применение, а вот от маркетолога ... Впрочем изложите - обсудим, ведь мы именно для этого здесь. Я эту штуку сопровождал в коде - это один большой геморрой, ломающий концепцию транзакционности и создающий огромные затраты на разработку и поддержку всего, что должно с ATX сосуществовать и тормозящий инновации. При этом окромя побочных задач логирования и отслеживания изменений я лично о других применениях не слышал. Какой-нибудь колоночный сторадж имеет сильно более широкую сферу применения чем это самое.

              непререкаемым авторитетом

              Вот с этим вообще рекомендую поаккуратнее. Любой авторитет - только для справки.


              1. shurutov
                16.10.2025 09:05
                #28977580

                маркетолога

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


                1. danolivo Автор
                  16.10.2025 09:05
                  #28977666

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

                  Так распишешь, в каких случаях применяют ATX?


                  1. shurutov
                    16.10.2025 09:05
                    #28978734

                    в моей компании по-русски говорю я один

                    Так вы ещё и не из ПгПро?

                    Так распишешь, в каких случаях применяют ATX?

                    Нет. В докладе есть. И да, даже логирование и отслеживание изменений в фин.секторе - это достаточно частая задача, чтобы говорить о её необходимости. Я уже после увольнения из ПгПро нередко сталкивался с необходимостью ATX, каковая костылилась dblink-ом.


  1. gsl23
    16.10.2025 09:05
    #28973010

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


    1. danolivo Автор
      16.10.2025 09:05
      #28973102

      Хм, и что с того?

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

      САР-теорема - это замечательно и must have. Однако в жизни можно ставить задачу не столь идеалистично. Вроде бы весь пост именно про это написан. В конце-концов, если мы 100% полагаемся на математику, зачем люди до сих пор делают бэкапы? ;)


      1. gsl23
        16.10.2025 09:05
        #28973708

         Однако в жизни можно ставить задачу не столь идеалистично.

        Так я именно про это же. Человек задумывается над теоремой и понимает, что нужна реализация каких то конретных метрик. И вопросы про сферический мультимастер отпадают, так как наступает хоть какое-то начальное понимание о возможностях и ограничениях в реализации.


        1. danolivo Автор
          16.10.2025 09:05
          #28973744

          Значит мы говорим на одном языке. Может быть просто слово "мультимастер" ангажировано? Давайте обсуждать публикацию, заменив это слово на "ХАБРАХАБРАХАБР" к примеру ;). Мне всё же важна критика основной идеи.