Про Multi-Master replication в RDBMS
TL;DR: её не существует.
Логическое продолжение предыдущего поста. Вот вроде программисты. Люди не глупые. В школе (а иногда и в ВУЗе) изучали математику, демонстрировали способности к логическому мышлению. Но некоторые всё равно почему-то свято верят, что в реляционных БД возможна Master-Master репликация. Особенно в халявных. А-ха-ха!
Есть у нас один сервис. Написан был ещё при царе Горохе, даже не знаю в каком году. В качестве бэкенда использует MySQL 5.7 + InnoDB (тут дед Сергеич нецензурно выругался). С Master-Master репликацией.
Какое-то достаточно существенное время всё работало ОК. Ну или почти ОК. Но в какой-то момент одна из нод кластера чо-та про%$ала транзакцию с соседнего мастера. Причём, молча. И никто, включая разработчкика, так и не понял как и почему это случилось. Возник split-brain, которого никто не заметил. И какое то время после этого всё по-прежнему продолжало работать. Ровно до тех пор, пока бизнес-логика приложения не обратилась к той самой записи, которая "разъехалась". А дальше началась эталонная развлекуха.
Та нода, которая не смогла воспроизвести у себя "проблемную" транзакцию по причине нестыковки данных, подняла лапки кверху, сказала "сдаюсь" и тупо остановила входящую репликацию. Вот тут-то уже мониторинг заверещал. А дальше только лапами, лапами. Разбираться, искать, чинить, самостоятельно приводить в консистентное состояние.
С одной стороны, ещё повезло, что таблица оказалась не сильно большая и не очень нагруженная. С другой стороны, админ, который настраивал счетчики автоинкрементов, когда-то давно забыл сохранить результаты своих трудов в конфигурационный файл. Так что после перезапуска одной из нод в таблице начали плодиться одинаковые Primary Key. Точнее, пытаться плодиться. В этот момент уже второй мастер сказал "сдаюсь" и тоже остановил входящую репликацию. А тем временем split-brain продолжал шириться.
В общем, дальше три человека совместными усилиями в течение часа восстанавливали сервис. С помощью лома, кувалды и какой-то там матери сделали. Шосукахарактерно, MySQL не давал даже сделать TRUNCATE проблемной таблицы: кластер всё равно "рассыпался". Получается, что репликация как будто бы и логическая, но не совсем. Но моя мысль сейчас не об этом.
В реляционных базах данных Master-Master репликация - это всегда набор костылей. Следующий вопрос заключается только в количестве и качестве таких костылей. В коммерческих БД дела обстоят чуть получше, в халявных похуже, в быдлокоде наподобие MySQL - совсем плохо. Беглый поиск по всевозможным форумам показывает, что таки да, MySQL время от времени "теряет" транзакции. "ХЗ почему, просто примите это как факт". КМБУ.
Поэтому когда разработчик предлагает использовать в серьёзном нагруженном сервисе реляционную базу данных с Master-Master репликацией - это всегда плохая идея, независимо от выбора конкретных инструментов. Хватит уже верить в чудеса.