Есть такая шука, CAP-теорема.
C - консистентность
A - доступность
P - устойчивость к разделению
Выбрать можно только любые 2 из 3 пунктов.
Мультимастер реплика, две ноды. Первая нода получила запрос:
Что будет в результате и почему?
Ладно, сделаем распределённый коммит. Тогда пришедшему вторым будет отлуп. Обе ноды работают, приложение нормально коммитится.
Вдруг хоп, у нас пропал второй мастер. Вариант раз: ждать его возвращения к жизни. Стоп, а зачем нам тогда мультимастер? Вариант два - ага, говорим мы и продолжаем работать на первом мастере. Второй потом поднимется, догонит по бинлогу, думаем мы. И вдруг второй мастер появляется, а у него свои данные. Оказывается, он не упал, а пропала связь между железками. Часть клиентов ходила на один мастер, часть - на другой.
Оп-па... У нас два мастера, каждый со своими данными. Классика split brain. Реплика встала, есть два противоречивых набора данных и, самое интересное, оба из них верны!
Мультимастер - это философский камень мира СУБД. О нём много кто говорит, все этого хотят - а его не существует.
В принципе не верьте никому, кто обещает мультимастер на двух нодах. Split brain неизбежен и принципиально никак не предотвращается. На трёх нодах и больше - кворум возможно организовать. Когда третий мастер потеряв своих соседей добровольно выключается или переходит в read-only. Лишь бы не split brain.
Это в теории.
Ближе к практике - достаточно просто реплики в mysql для интересной жизни вообще не касаясь мультимастера. Граблей много в любом режиме реплики, будь то логическая, физическая или смешанная, и слава ктулху, я с ними всеми не встречался лично. https://www[dot]youtube[dot]com/watch?v=[dot][dot][dot]oHU&index=38
(Добавление)
Долго писал, не обновил страницу =)
armancho7777777 пишет:
Один Master и множество подчинённых (slave) серверов?
Да, один мастер резко сокращает количество граблей. Но их остаётся ещё достаточно.