Для начала задаёте себе и отвечаете на вопрос "зачем?"
Потому что геморроя, проблем и граблей
очень много. Бонусы - сомнительны. Основной пласт проблем - как решить, что пора переключать мастер на другой хост, а не вернётся старый мастер из-за недолгого (а то и вовсе планового) лага сети? Это организационный вопрос и автоматикой он не решается. Самое счастье с автоматикой - схлопотать split brain и получить на этом долгий и увлекательный квест "как бы разъехавшиеся данные теперь подружить воедино"
мастер-мастер = головная боль перманентно. Потому что фундаментальная CAP теорема, которую никто пока внятно не решил. Или у вас проблемы с консистентностью или с медленной из-за распределённых транзакций записью.
Автоматика для failover'а, которую я не придумал как спровоцировать на split brain -
patroni. Вроде работает. Но в продакшене видел пока только однажды.
Процедуры (да и вообще запросы) имеет смысл делить:
- пишущие. Любые, какие что-то пишут в базе (включая create temporary table). Это должны роутиться строго на мастер
- читающие. Идут на реплики
- долго читающие. Идут на отдельные slow реплики, которые могут заметно отставать от мастера, но которые не будут мешать деятельности проекта
