Обновить

Комментарии 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 в него выглядит пока довольно прочно и в эксплуатации с проблемами к нам не приходили.

А Jepsen тестам не пробовали потыкать?

  • не про масштабирование записи, а про масштабирование чтения;

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

может, но обычно ценой консистентности

что случится с консистентностью, если разные транзакции пишут в разные строки по своим pk

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

уточню свой предыдущий комментарий:

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

"но не изменяя этот PK, или любую uniq колонку, которая используется для FK."

В вашем случае произойдет комит только одной транзакции. Транзакции вставки, удаления, изменения РК итд, не масштабируются. Но можно сделать такие транзакции менее токсичными:

  1. insert с минимальными данными

  2. soft delete

  3. не изменять РК

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Информация

Сайт
www.postgrespro.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия
Представитель
Иван Панченко