Ответ
В Master-Master репликации (также известной как двунаправленная репликация) обычно участвуют два сервера (мастера). Ключевая особенность этой архитектуры в том, что оба сервера могут принимать запросы на запись и реплицировать свои изменения друг на друга.
Это повышает доступность системы: если один мастер выходит из строя, второй может продолжать обрабатывать все запросы.
Пример базовой настройки в MySQL:
Для предотвращения конфликтов первичных ключей (primary key) часто используют настройки auto_increment_increment и auto_increment_offset.
-- На первом сервере (Master 1)
-- Генерировать ID: 1, 3, 5, ...
SET GLOBAL auto_increment_increment=2;
SET GLOBAL auto_increment_offset=1;
CHANGE MASTER TO MASTER_HOST='master2_ip', ...;
-- На втором сервере (Master 2)
-- Генерировать ID: 2, 4, 6, ...
SET GLOBAL auto_increment_increment=2;
SET GLOBAL auto_increment_offset=2;
CHANGE MASTER TO MASTER_HOST='master1_ip', ...;Основные проблемы и нюансы:
- Разрешение конфликтов: Главная сложность. Что делать, если одна и та же строка изменена одновременно на обоих мастерах?
- Согласованность данных: Возможны временные расхождения данных между мастерами.
- Сложность в масштабировании: Добавление третьего и более мастеров значительно усложняет топологию и управление.
Ответ 18+ 🔞
Давай разберём эту вашу Master-Master репликацию, она же двунаправленная. Представь, что у тебя два сервера, оба — главные, оба могут и читать, и писать. Как два начальника в одном отделе, только, в теории, не дерутся за власть.
Суть в чём? Если один из этих мастеров накроется медным тазом, второй спокойно продолжает работать, и система в целом не падает. Доступность, блядь, повышается — звучит как охуенная идея, да?
Но тут, как всегда, есть подводный ебень. Главная засада — конфликты. Что будет, если на обоих серверах одновременно попытаются изменить одну и ту же запись? А хуй его знает! Система-то не волшебная, ей надо объяснять, кто тут прав. Это основная головная боль.
Ещё одна классическая проблема — автогенерируемые ID. Чтобы они не пересекались и не устраивали пиздец, их нужно развести. В MySQL, например, делают так:
-- На первом мастере (Master 1)
-- Пусть генерит ID: 1, 3, 5, ...
SET GLOBAL auto_increment_increment=2;
SET GLOBAL auto_increment_offset=1;
CHANGE MASTER TO MASTER_HOST='master2_ip', ...;
-- На втором мастере (Master 2)
-- Пусть генерит ID: 2, 4, 6, ...
SET GLOBAL auto_increment_increment=2;
SET GLOBAL auto_increment_offset=2;
CHANGE MASTER TO MASTER_HOST='master1_ip', ...;Видишь? Сделали чёткие чётные и нечётные, чтобы не мешались. Но это, блядь, цветочки.
А теперь ягодки, то есть основные грабли:
- Разрешение конфликтов: Это пиздец, а не проблема. Кто кого перезапишет, если оба мастера обновили одну строку? Без чёткой стратегии — гарантированный рассинхрон и битые данные. Нужно или очень аккуратное приложение, или кастомная логика на триггерах, или специальные инструменты вроде Galera — волнение ебать.
- Согласованность данных (Consistency): Может быть так, что на одном мастере данные уже обновились, а на втором — ещё нет. Пользователь, переключившийся между ними, просто обоссается от удивления. Eventual consistency, ёпта.
- Сложность масштабирования: Захотел добавить третьего мастера? Ну, удачи тебе, чувак. Топология превращается в ёбаную паутину, где каждый должен реплицировать данные на каждого. Администрирование такого зоопарка — терпения ноль ебать.
Короче, архитектура на вид простая, но требует, чтобы ты, как слон в посудной лавке, не ходил. Один неверный запрос — и пиши пропало. Используется, но там, где без неё реально никак, и команда готова с этим возиться.