Sprawny serwer może celowo odmówić zapisu, bo znalazł się po niewłaściwej stronie podziału sieci
Wyobraźmy sobie pięć serwerów tworzących jeden klaster. Sieć dzieli je na grupę trzech i grupę dwóch. Wszystkie maszyny są fizycznie sprawne, ale system consensusowy nie może pozwolić obu grupom niezależnie zatwierdzać zmian, bo powstałyby dwie sprzeczne historie. Dlatego strona mająca większość może działać dalej, a mniejszość przestaje zatwierdzać zapisy. etcd opisuje to wprost: przy partycji część z większością pozostaje dostępnym klastrem, a część mniejszościowa jest niedostępna. Odmowa pracy nie jest więc awarią algorytmu — jest mechanizmem chroniącym dane przed split-brain.
Najgroźniejsza sytuacja to dwie prawdy naraz
Jeżeli po rozcięciu sieci obie grupy przyjmują nowe zapisy, każda może wybrać własnego lidera i stworzyć własną sekwencję zmian. Po odzyskaniu łączności trzeba byłoby zdecydować, którą historię zachować. Dla wielu systemów konfiguracyjnych i baz metadanych taka utrata jednoznaczności jest niedopuszczalna.
Większość działa jak dowód wyłączności
W pięcioelementowym klastrze dwie różne grupy większościowe muszą mieć wspólny węzeł. Jeżeli każdy węzeł głosuje tylko zgodnie z regułami protokołu, dwie rozłączne strony partycji nie mogą jednocześnie mieć większości. To prosta własność matematyczna, która staje się fundamentem bezpieczeństwa.
Mniejszość może być zdrowa i bezużyteczna
Dwa odizolowane węzły mogą mieć sprawne procesory, dyski i sieć lokalną. Mimo to nie powinny zatwierdzić zmiany wymagającej consensusu. Użytkownik widzi więc paradoksalną sytuację: maszyna odpowiada na ping, proces działa, ale system celowo mówi „nie”.
etcd wybiera bezpieczeństwo zamiast dwóch liderów
Dokumentacja etcd opisuje partycję jako podział na stronę większościową i mniejszościową. Większość pozostaje dostępnym klastrem, a mniejszość jest niedostępna. Jeśli dawny lider znalazł się po stronie mniejszościowej, ustępuje, a większość wybiera nowego. Po naprawieniu sieci mniejszość synchronizuje stan.
To przykład kontrolowanej niedostępności
W systemach niezawodnych czasem najlepszą odpowiedzią na awarię jest odmowa wykonania pracy. Chwilowa niedostępność części klastra jest łatwiejsza do naprawienia niż dwie legalne, ale sprzeczne wersje prawdy. Z punktu widzenia użytkownika może to wyglądać jak ograniczenie, ale z punktu widzenia integralności danych jest zabezpieczeniem.
Odczyty i zapisy mogą mieć różne zasady
To, że mniejszość nie może zatwierdzać zmian consensusowych, nie oznacza automatycznie, że każda możliwa operacja musi zniknąć. Niektóre systemy potrafią nadal udostępniać lokalne, potencjalnie starsze informacje albo operacje niewymagające wspólnej decyzji. Dokładne zachowanie zależy od produktu. Najważniejsza jest granica: operacja, która ma zmienić wspólny stan objęty consensusem, potrzebuje quorum.
Powrót łączności nie wymaga głosowania nad dwiema historiami
Ponieważ mniejszość nie mogła legalnie stworzyć konkurencyjnego logu zatwierdzonych zmian, po naprawie partycji może dogonić większość. To właśnie korzyść z celowej niedostępności. System nie musi rozwiązywać konfliktu dwóch równie legalnych światów; jedna strona zachowała autorytatywną linię decyzji. Koszt chwilowego „nie” upraszcza późniejsze odzyskanie.
Ten mechanizm bywa szczególnie ważny w systemach przechowujących konfigurację innych usług. Jeśli dwie strony split-brain mogłyby równocześnie zmieniać informację o tym, kto jest liderem, gdzie leży shard albo jakie uprawnienia obowiązują, błąd rozprzestrzeniłby się na warstwy wyżej. Dlatego małe systemy consensusowe, takie jak etcd, często wybierają bardzo konserwatywną semantykę: wolą przestać przyjmować zmiany bez quorum niż przekazać całej platformie dwie sprzeczne wersje konfiguracji.
Ten wybór wpływa też na doświadczenie operatora podczas incydentu. Monitoring może pokazywać, że dwa serwery są „up”, ale endpoint zapisów zwraca błędy. To nie sprzeczność, lecz różnica między zdrowiem procesu a zdrowiem quorum. Dobre alerty muszą rozróżniać te warstwy: dostępność pojedynczych członków, możliwość wyboru lidera i zdolność klastra do commitowania nowych wpisów.