Про Multi-Master replication в RDBMS

klink0v — 30.09.2023

TL;DR: её не существует.

Логическое продолжение предыдущего поста. Вот вроде программисты. Люди не глупые. В школе (а иногда и в ВУЗе) изучали математику, демонстрировали способности к логическому мышлению. Но некоторые всё равно почему-то свято верят, что в реляционных БД возможна Master-Master репликация. Особенно в халявных. А-ха-ха!

Есть у нас один сервис. Написан был ещё при царе Горохе, даже не знаю в каком году. В качестве бэкенда использует MySQL 5.7 + InnoDB (тут дед Сергеич нецензурно выругался). С Master-Master репликацией.

Какое-то достаточно существенное время всё работало ОК. Ну или почти ОК. Но в какой-то момент одна из нод кластера чо-та про%$ала транзакцию с соседнего мастера. Причём, молча. И никто, включая разработчкика, так и не понял как и почему это случилось. Возник split-brain, которого никто не заметил. И какое то время после этого всё по-прежнему продолжало работать. Ровно до тех пор, пока бизнес-логика приложения не обратилась к той самой записи, которая "разъехалась". А дальше началась эталонная развлекуха.

Та нода, которая не смогла воспроизвести у себя "проблемную" транзакцию по причине нестыковки данных, подняла лапки кверху, сказала "сдаюсь" и тупо остановила входящую репликацию. Вот тут-то уже мониторинг заверещал. А дальше только лапами, лапами. Разбираться, искать, чинить, самостоятельно приводить в консистентное состояние.

С одной стороны, ещё повезло, что таблица оказалась не сильно большая и не очень нагруженная. С другой стороны, админ, который настраивал счетчики автоинкрементов, когда-то давно забыл сохранить результаты своих трудов в конфигурационный файл. Так что после перезапуска одной из нод в таблице начали плодиться одинаковые Primary Key. Точнее, пытаться плодиться. В этот момент уже второй мастер сказал "сдаюсь" и тоже остановил входящую репликацию. А тем временем split-brain продолжал шириться.

В общем, дальше три человека совместными усилиями в течение часа восстанавливали сервис. С помощью лома, кувалды и какой-то там матери сделали. Шосукахарактерно, MySQL не давал даже сделать TRUNCATE проблемной таблицы: кластер всё равно "рассыпался". Получается, что репликация как будто бы и логическая, но не совсем. Но моя мысль сейчас не об этом.

В реляционных базах данных Master-Master репликация — это всегда набор костылей. Следующий вопрос заключается только в количестве и качестве таких костылей. В коммерческих БД дела обстоят чуть получше, в халявных похуже, в быдлокоде наподобие MySQL — совсем плохо. Беглый поиск по всевозможным форумам показывает, что таки да, MySQL время от времени "теряет" транзакции. "ХЗ почему, просто примите это как факт". КМБУ.

Поэтому когда разработчик предлагает использовать в серьёзном нагруженном сервисе реляционную базу данных с Master-Master репликацией — это всегда плохая идея, независимо от выбора конкретных инструментов. Хватит уже верить в чудеса.

Оставить комментарий

Популярные посты:

traianus

Как получить помощь от благотворительного фонда "Нужна помощь"

nathoncharova

Секрет «Чуда в Миссури» или Почему тело монахини не разлагается спустя годы

matsam

Суперджет

katehon_s_nami

Катехон-парад !

euro_royals

Выпускной Кронпринца Кристиана.

tvin270584

Как преобразить старую кухню за неделю, обладая скромным бюджетом

nyka

Прекрасное далёко

von_hoffmann

Иван Ильин об отношении Запада к России

matsam

Донецк

• Ранее
• Архив