Коротко — что это, как заметить и что с этим делать.
1) Что такое split‑brain
Split‑brain — состояние кластерной/распределённой системы при сетевом разделении, когда обе (или несколько) разъединённых подгруппы считают себя «мастером/первичным» и продолжают принимать записи, в результате чего реплики расходятся и возникает конфликт данных.
2) Причины
- сетевые разрывы/фильтрация (partition), высокая задержка;
- отказ координатора/арбитра без корректной переизбрации;
- некорректная конфигурация (отсутствие механизма разделения ответственности);
- ручные операции/временные сбои синхронизации.
3) Как обнаружить (метрики и механизмы)
- детекторы отказа/heartbeat: потеря heartbeats между узлами;
- рассинхронизация логов/индексов: разные последние лог‑индексы у реплик;
- контроль согласованности: checksum/меркле‑деревья (Merkle trees) — обнаружение различий в диапазонах данных;
- версии/векторные часы: обнаружение конкурентных версий (vector clocks, version vectors);
- системы мониторинга/алерты: внезапный рост конфликтов, расходящиеся метрики записи/числа лидов.
Практическое правило: сочетать сердцебиения + сравнение состояний (логов или checksums).
4) Стратегии предотвращения и смягчения
A. Архитектурные выборы (предотвратить появление нескольких primaries)
- Консенсусные алгоритмы (Raft/Paxos): гарантируют не более одного лидера через избирательный процесс;
- Кворумы: требовать записи/чтения из кворума размера $Q$, например $Q=\lfloor \frac{N}{2}\rfloor +1$ или условие $Q>\frac{N}{2}$. Тогда любые два кворума пересекаются: $|Q_1|+|Q_2|>N\Rightarrow Q_1\cap Q_2\ne \varnothing$.
- Арбитры/третий участник (witness): небольшая «разрешающая» нода, чтобы сломать ничью при чётных N.
- Lease/фенсинг (fencing): лидер получает временную лицензию; по потере связи лицензия истекает и другая сторона не может бесконтрольно писать. Аппаратный fencing (STONITH) гарантирует, что старый мастер физически изолирован.
- Weighted quorum / placement: для геораспределённых кластеров назначать веса/кворумы так, чтобы один центр не мог стать одновременно «первичным».
B. Работа с конфликтами (когда раздел всё‑таки случился)
- Отказ на запись в меньшей части (minority partition becomes read‑only): безопасно предотвратить дальнейшее расхождение;
- Автоматическое слияние: CRDTs или детерминированные стратегии (last‑write‑wins с логической меткой/временем) — применимы если допустимы потери истории;
- Ручное/полуавтоматическое разрешение: при критичных данных требовать операторского вмешательства;
- Anti‑entropy / синхронизация: меркле‑деревья + обмен диапазонами для быстрых исправлений после восстановления сети.
5) Практические рекомендации и порядок действий при обнаружении split‑brain
- немедленно остановить приём записей в одной из частей (обычно в меньшей/без кворума);
- сохранить логи/снимки (перед слиянием) для аудита;
- выбрать авторитетную сторону (по кворуму/epoch/мастер‑токен);
- выполнить reconcile: применить детерминированные правила слияния (CRDT, LWW, merge scripts) или ручную коррекцию;
- восстановить нормальный membership и провести проверку согласованности (checksum/Merkle);
- ввести мониторинг и автоматические правила (fencing, арбитр, read‑only minority) чтобы предотвратить повтор.
6) Компромиссы и выбор политики
- CP (консистентность + partition tolerance): жертвуете доступностью в разделении, но избегаете конфликтов;
- AP (доступность + partition tolerance): разрешаете отдельные примарии и потом сливаете/решаете конфликты (подходит для менее критичных данных или CRDT).
Выбор зависит от требований: если потеря/конфликты данных недопустимы — используйте консенсус/кворумы/фенсинг; если важнее доступность — проектируйте корректные стратегии слияния (CRDT) и мониторинг.
Кратко: чтобы не допустить split‑brain — применяйте консенсусные алгоритмы или кворумы с fencing/арбитром, делайте minority‑partition read‑only, используйте механизмы обнаружения (heartbeat, Merkle, версии) и имейте предопределённые стратегии слияния (CRDT/детерминированные правила или ручная резолюция).