Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как CAP теорема, весьма мешающая сделать серебряную пулю.
Ладно, ближе к делу.
Самая большая проблема с автоматическим failover СУБД - решить, что уже пора переключаться. Для чего необходимо выяснить, а что вообще происходит, не развалилась ли сеть, не вернётся ли через пару секунд мастер обратно - если в сети в результате окажется два мастера, то нет никакого разумного способа определить, где данные актуальны. Худшее что можно представить - это split brain: когда часть приложений ходит в один мастер, часть в другой и данные стремительно расходятся в разные стороны. Есть такая байка про гуглдиск "у нас всё отказоустойчиво, все данные хранятся в 4 экземплярах. Правда, у нас была авария и мы теперь понятий не имеем, какая из копий актуальная"
Переключение мастера на 90% - решение административное и человеческое. Автоматика же добавляет головной боли. Зачастую - больше головной боли, чем без неё. Особенно если железо адекватное серверное, которое "вдруг" выпадает очень редко.
Обычно автоматики нет, и есть детальная инструкция по переключению мастера БД, по которой и в ночи можно переключиться.
Если всё ещё хочется походить по граблям - посмотрите patroni. Есть пара кластеров с ним на поддержке, при наличии мониторинга особых проблем не припоминаю. До split brain по крайней мере не придумал как довести, вроде все варианты прикрыты. В худшем случае в readonly уходит.
Средний
