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

хотя это мысль - попробовать к keepalived привязать фэйловер скрипт, который стартанёт кворумный нод мускуля на том сервере, где сейчас активный айпишник 😂

Лучше скриптом тогда уж в любое стороннее место писать переключение

Типа witness

чтобы алертить когда 1 может записать, второй может прочитать - но произошло переключение

В итоге без полноценной третьей ноды будет хотя бы предупреждение, что что-то не так пошло

Значит у тебя обе ноды живые, а вот между ними связи нет, готовимся к split brain

можно автоматом на обоих дампы делать по такому случаю

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

у заказчика как-то сервера произвольно перестартовали из-за ошибки в биосе. за два месяца 3 рестарта самопроизвольных - но за серверами заказчики смотрели слабо, они даже не заметили ;)

>но такого не произойдёт
А еще дети обещают маме, что больше никогда не будут кушать/какать

да, ты прав. но за 7 лет не произошло ни разу.

Все что угодно произойдет, вопрос в том насколько готов и насколько больно

У меня вот обновление нод на aws раз в неделю где-то было. Инстансы падали 3 раза за 2 года

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

А процедура эта на 5 минут

везунчик 😆

И вот именно в это окно и попало, хотя вероятность тоже никакая

в этом плане близость к своему железу помогает. знаешь, что никакой хрени на соседних вмках никто не делает.

Есть имхо, что просто мастер-мастер схема, даже с galeradb и подобными (не знаю про vitess), или недостаточно надежна, или слишком сложна (нужны всякие скрипты-костыли для проверки целостности данных).
Нет гарантии того, что запись прошла прям на все узлы нашего мастер-мастер.
Я б добавил какой-то буфер (типа Кафки), в котором данные хранятся, пока не придет подтверждение завершенной транзакции от всех узлов ДБ кластера.

И я тут кидал ссылку на митап Mysql@Scale, там чуваки из Баду и Авито говорили про их опыт:
- В основном master-slave схемы, а не мастер-мастер. Это просто проще.
- ProxySQL на каждом узле, который обращается к базе
- Запросы чз ProxySQL балансятся по нодам мускула, и proxysql выкидывает сдохшие узлы из списков балансировки. Тут вопрос про балансировку, раз они в основном используют мастер-слейв, видимо, мастеров все-таки обычно много.
- И тут деталь, которую я или не досмотрел, или не понял - как мы убеждаемся, что транзакции успешно прошли на всех узлах