Комментарии 18
Извините за наивный вопрос, я с MSSQL.
То что вы описали это аналог AlwaysOn with synchronous replica
А есть ли Asynchronous mode?
И как копились WAL файлы если это synchronous commit? Если узел прекратил потреблять изменения, то и основной узел не может ничего закомиттить, и все встанет колом, но ничего не будет накапливаться?
не про масштабирование записи, но масштабирование чтения;
а зачем вообще тогда мультимастер, если просто master-slave достаточно для масщтабирования чтения
На Slave-е можно только читать. Там нельзя создать даже временной таблицы. А иногда хочется создать временные таблицы при формировании временного отчёт.
Моё личное ощущение что мультимастер прекрасен свой отказоустойчивостью:
Не надо думать где реплика а где мастер и городить балансировщики аля HAProxy
Не надо переживать за недоступность сервиса пока реплика будет превращаться в мастер при failover/switchover
Не надо думать в каком порядке обновлять базы и как обновлять. Особенно с учётом major upgrade
Первое, что ломается - это кластер (мультимастер). Это прям аксиома. Я не видел ни одной реализации кластера (мультимастера) которая бы не падала и не разваливалась, да еще так громко, больно и в самый неподходящий момент.
можно узнать вкратце, что именно и у кого ломается? EDB,Postgres Pro или что другое?
В MSSQL все фатальные развалы кластера были связаны с физическими проблемами дисков
Временные проблемы были связаны либо с нехваткой памяти для кластерного сервиса, либо нехваткой для него CPU, когда SQL выжирал 100
Интересно сравнить
Сплитбрейн и запись в развалившиеся ноды = каша в данных, боль, страдания, и другой геморой.
Достигнуть этого можно к подавляющем большинстве реализаций кластеров.
не понятно - достигнуть сплитбрейна?
кластер или решил сплитбрейн, или не надо такой кластер трогать.
Понимаю эту боль. Когда всё разъехалось - это адовая боль.
Но если получится сломать PostgresPro Multimaster (виртуалка с ним выше доступна в самой статье), то прошу дать знать. Не говорю, что это сделать нельзя, но заложенный 3PC в него выглядит пока довольно прочно и в эксплуатации с проблемами к нам не приходили.
не про масштабирование записи, а про масштабирование чтения;
Правильный мультимастер может масштабирование записи
может, но обычно ценой консистентности
что случится с консистентностью, если разные транзакции пишут в разные строки по своим pk
Например, может случиться нарушение уникальности, если оно есть. И даже если писать в разные таблицы, ссылающиеся друг на друга, может случиться нарушение ссылочной целостности (и у меня про то есть вопрос авторам, вы его видели)
уточню свой предыдущий комментарий:
в разные строки по своим pk
"но не изменяя этот PK, или любую uniq колонку, которая используется для FK."
В вашем случае произойдет комит только одной транзакции. Транзакции вставки, удаления, изменения РК итд, не масштабируются. Но можно сделать такие транзакции менее токсичными:
insert с минимальными данными
soft delete
не изменять РК
Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL. Часть. 3