@Tishka17 помнится ты не так давно говорил о том, что

бывают нужны отдельно пулы (бд) на чтение и на запись. Интерес такой: а зачем? Это оптимизация такая?

Это если ты захочешь использовать репликацию

Если говорить про PG, то примерно так: 1. на каждое пользовательское соединение один процесс дополнительный. Сколько у типичного проекта по пользователям обычно нагрузка? Отсюда потребность в пулере, к примеру pgbouncer 2. Обычно создают кластер СУБД, где одна машинка является мастером, а другие репликами. Все по записи долбится на первую, а если она ляжет, то ее роль подхватывает одна из реплик. Отсюда вывод, чтоб реплика содержала up to date, почти up to date состояние нужно делать репликацию. чтоб не грузить лишнего мастер можно раскидать READ-операции по репликам

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

Только нужна (semi-)sync репликация, чтобы нормально разделять чтение и запись

Стоит разделять стратегию репликации и стратегию разделения запросов. Active master - passive master не сильно отличает от обычного master-slave.

Это вполне взаимосвязанные вещи, хоть и, понятно, не идентичные.

Да, но так-то и в реплику можно писать, если это предусмотрено

Вроде как неконцептуально :)

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

Зависит от конкретного софта. С логической репликацией обычно нет проблем. Тут скорее зависит от бизнес задач, которые решает реаликация. Классическое создание реплик и деление запросов - масштабирование чтения, но бывают и другие задачи

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

Ну мультимастер в zookeper из коробки работает. Можно писать/читать из любой ноды. В последних версиях xtradb cluster, вроде, нет проблем с записью на любую ноду.

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

Но с классической точки зрения, это мульти-мастер

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

Я и говорю, что зависит от целей, но чтение в зукипере распределяется, оно не требует согласование кластера. Раньше там точно был active/passive master. К сожалению, волшебства не существует :) Есть только крутой маркетинг (привет, монга)

Запись без шардирования, к сожалению, не отмасштабировать(

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

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

Ладно, меня не поняли, значит не поняли. Бывает.