В percona xtradb cluster арбитр не нужен, если количество год <= 3. Т.е. ты можешь использовать перконовскую galera с мастер-мастер репликацией и не поднимать garbd (или как его там).

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

В galera всё primary, ибо мастер-мастер, т.е. так как ты написал не будет. Split-brain возможен, да. Поэтому, рекомендуется нечётное число нод. Ну или таки поднять арбитра, это не рокет сайенс.

Да, если ты таки решишь попробовать galera, не поленись почитать, в чем разница с обычным мускулам, ибо принципиально. Банальный пример - большие транзакции в galera - ад и смерть, оч. рекомендуется избегать их и все апдейты делать маленькими кусками.

Работает

Эм...робит там Мастер/Слейв. Полет нормальный. Решение мне больше понравилось, в сравнении с голым MySQL. Утилитки и плюшки есть всякие

мастер/слейв там искаропки вполне рабочий. Читай доки на Maria/MySQL, там всё расписано вполне нормально.

Геморрой начнётся когда захочешь равноценных нод и FT с HA.

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

Остановился на решении от PERCONA MASTER/MASTER. Сбоку поставил арбитра. Есть кучу утилит для мониторинга. Работает вроде хорошо.

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

Мастер-слейв для такого вообще мало пригоден. Оно скорее для разгрузки, если select'ов слишком много или они сложные и одна машина не справляется.

Для Fault Tolerance вам нужен мастер-мастер. Найдите таки третью машину и поднимите галеру. Оно хоть как-то работает.

ЗЫ: Была хорошая штука, которая могла бы решить вообще все подобные проблемы - remus + xen + виртуалка. Получается виртуальная машина которая не останавливаясь и даже не обрывая соединений может прыгать по разным железкам. Но из-за уродов пилящих DRBD (который, кстати, кроме как для remus'а-то и непригоден ни для чего) всё в итоге заглохло, потому что DRBD очень сильно завязан на конкретные версии ядер, и там всё время что-то очень прилично меняли, а те, кто писал remus просто не успевали ещё и постоянно патчи для каждой новой версии DRBD делать. А писатели DRBD как последние говнюки напрочь отказались Protocol D принять в основную ветку по чисто сектантским соображениям.