Wprowadzenie

Jakiś czas temu dostałem zadanie opracowania klastra pracy awaryjnej dla PostgreSQL, działające w kilku centrach danych połączonych światłowodem w obrębie jednego miasta i zdolne wytrzymać awarię (np. zanik napięcia) jednego centrum danych. Jako oprogramowanie odpowiedzialne za odporność na awarie wybrałem Stymulator sercaponieważ jest to oficjalne rozwiązanie firmy RedHat do tworzenia klastrów pracy awaryjnej. I dobrze, bo RedHat zapewnia jego wsparcie i dlatego, że to rozwiązanie jest uniwersalne (modułowe). Za jego pomocą możliwe będzie zapewnienie odporności na awarie nie tylko PostgreSQL, ale także innych usług, czy to przy użyciu standardowych modułów, czy też tworząc je pod konkretne potrzeby.

Decyzja ta zrodziła uzasadnione pytanie: jak odporny na awarie będzie klaster pracy awaryjnej? Aby to zbadać, opracowałem stanowisko testowe, które symuluje różne awarie węzłów klastra, czeka na przywrócenie usługi, odzyskuje uszkodzony węzeł i kontynuuje testowanie w pętli. Projekt ten pierwotnie nazywał się hapgsql, lecz z czasem znudziła mi się nazwa, która zawierała tylko jedną samogłoskę. Dlatego zacząłem wywoływać odporne na awarie bazy danych (i wskazywać na nie zmienny adres IP) krogański (postać z gry komputerowej, w której zduplikowane są wszystkie ważne narządy), a węzły, klastry i sam projekt są tuchanka (planeta, na której żyją kroganie).

Teraz zarząd pozwolił udostępnić projekt społeczności open source na licencji MIT. Plik README zostanie wkrótce przetłumaczony na język angielski (ponieważ oczekuje się, że głównymi odbiorcami będą programiści Pacemaker i PostgreSQL), dlatego zdecydowałem się przedstawić starą rosyjską wersję README (częściowo) w formie tego artykułu.

Klastry są wdrażane na maszynach wirtualnych VirtualBox. Wdrożonych zostanie łącznie 12 maszyn wirtualnych (w sumie 36GiB), które utworzą 4 klastry odporne na błędy (różne opcje). Pierwsze dwa klastry składają się z dwóch serwerów PostgreSQL, które są zlokalizowane w różnych centrach danych, oraz wspólnego serwera świadek c urządzenie kworum (hostowane na taniej maszynie wirtualnej w trzecim centrum danych), co eliminuje niepewność 50% / 50%, oddając swój głos na jedną z partii. Trzeci klaster w trzech centrach danych: jeden master, dwa slave, nr urządzenie kworum. Czwarty klaster składa się z czterech serwerów PostgreSQL, po dwa na centrum danych: jeden master, reszta replik i także korzysta świadek c urządzenie kworum. Czwarty może wytrzymać awarię dwóch serwerów lub jednego centrum danych. W razie potrzeby rozwiązanie to można skalować do większej liczby replik.

Dokładna obsługa czasu ntpd również ponownie skonfigurowany pod kątem odporności na błędy, ale wykorzystuje samą metodę ntpd (tryb sieroty). Wspólny serwer świadek pełni rolę centralnego serwera NTP, rozdzielając swój czas na wszystkie klastry, synchronizując w ten sposób wszystkie serwery ze sobą. Jeśli świadek ulegnie awarii lub zostanie odizolowany, wtedy jeden z serwerów klastra (w klastrze) zacznie rozdzielać swój czas. Buforowanie pomocnicze proxy HTTP również podniesiony do świadekza jego pomocą inne maszyny wirtualne mają dostęp do repozytoriów Yum. W rzeczywistości usługi takie jak dokładny czas i proxy najprawdopodobniej będą hostowane na serwerach dedykowanych, ale w budce są hostowane na świadek tylko po to, aby zaoszczędzić liczbę maszyn wirtualnych i miejsce.

Wersje

v0. Współpracuje z CentOS 7 i PostgreSQL 11 na VirtualBox 6.1.

Struktura klastra

Wszystkie klastry są zaprojektowane tak, aby można je było zlokalizować w wielu centrach danych, połączyć w jedną płaską sieć i muszą wytrzymać awarię lub izolację sieci pojedynczego centrum danych. Dlatego jest niemożliwe używać do ochrony przed rozszczepiony mózg standardowa technologia rozrusznika zwana STONIT (Strzelaj w drugi węzeł w głowę) lub ogrodzenie. Jej istota: jeśli węzły w klastrze zaczną podejrzewać, że z jakimś węzłem jest coś nie tak, ten nie odpowiada lub zachowuje się nieprawidłowo, to na siłę go wyłączają za pomocą urządzeń „zewnętrznych”, np. karty sterującej IPMI lub UPS . Ale to zadziała tylko w przypadkach, gdy po pojedynczej awarii serwer IPMI lub UPS będzie nadal działał. Tutaj planujemy zabezpieczyć się przed dużo bardziej katastrofalną awarią, gdy całe centrum danych ulegnie awarii (np. straci zasilanie). A przy takiej odmowie wszystko kamień-urządzenia (IPMI, UPS itp.) również nie będą działać.

Zamiast tego system opiera się na idei kworum. Wszystkie węzły mają głos i mogą działać tylko te, które widzą więcej niż połowę wszystkich węzłów. Nazywa się tę ilość „połowa + 1”. kworum. Jeżeli nie zostanie osiągnięte kworum, węzeł podejmuje decyzję o izolacji sieci i musi wyłączyć swoje zasoby, tj. to jest to ochrona podzielonego mózgu. Jeżeli oprogramowanie odpowiedzialne za to zachowanie nie działa, to zadziałać będzie musiał watchdog, np. oparty na IPMI.

Jeśli liczba węzłów jest parzysta (klaster w dwóch centrach danych), może pojawić się tzw. niepewność 50% / 50% (pół na pół), gdy izolacja sieci dzieli klaster dokładnie na pół. Dlatego dla parzystej liczby węzłów dodajemy urządzenie kworum to mało wymagający demon, który można uruchomić na najtańszej maszynie wirtualnej w trzecim centrum danych. Oddaje swój głos na jeden z segmentów (który widzi) i w ten sposób rozwiązuje niepewność 50%/50%. Podałem nazwę serwera, na którym zostanie uruchomione urządzenie kworum świadek (terminologia z repmgr, podobało mi się).

Zasoby można przenosić z miejsca na miejsce, na przykład z uszkodzonych serwerów na sprawne, lub na polecenie administratorów systemu. Aby klienci wiedzieli, gdzie znajdują się potrzebne im zasoby (gdzie się podłączyć?), pływające IP (pływające IP). Są to adresy IP, które Pacemaker może przenosić pomiędzy węzłami (wszystko jest w płaskiej sieci). Każdy z nich symbolizuje zasób (usługę) i będzie zlokalizowany w miejscu, w którym należy się połączyć, aby uzyskać dostęp do tej usługi (w naszym przypadku bazy danych).

Tuchanka1 (obwód z zagęszczeniem)

Struktura

Pomysł był taki, że mamy wiele małych baz danych o niskim obciążeniu, dla których nieopłacalne jest utrzymywanie dedykowanego serwera podrzędnego w trybie hot standby dla transakcji tylko do odczytu (nie ma potrzeby aż takiego marnowania zasobów).

Każde centrum danych ma jeden serwer. Każdy serwer ma dwie instancje PostgreSQL (w terminologii PostgreSQL nazywane są one klastrami, ale żeby uniknąć nieporozumień będę je nazywał instancjami (analogicznie do innych baz danych), a klastry Pacemakera będę nazywał tylko klastrami). Jedna instancja pracuje w trybie master i tylko ona świadczy usługi (prowadzi do niej tylko float IP). Druga instancja działa jako urządzenie podrzędne dla drugiego centrum danych i będzie świadczyć usługi tylko w przypadku awarii urządzenia głównego. Ponieważ w większości przypadków tylko jedna instancja na dwie (master) będzie świadczyć usługi (wykonywać żądania), wszystkie zasoby serwera są zoptymalizowane dla mastera (pamięć jest przydzielana na pamięć podręczną Shared_buffers itp.), ale tak, aby druga instancja ma również wystarczające zasoby (aczkolwiek do nieoptymalnego działania poprzez pamięć podręczną systemu plików) na wypadek awarii jednego z centrów danych. Slave nie świadczy usług (nie realizuje żądań tylko do odczytu) podczas normalnej pracy klastra, dzięki czemu nie ma wojny o zasoby z masterem na tej samej maszynie.

W przypadku dwóch węzłów odporność na błędy jest możliwa tylko w przypadku replikacji asynchronicznej, ponieważ w przypadku replikacji synchronicznej awaria urządzenia podrzędnego doprowadzi do zatrzymania urządzenia nadrzędnego.

Brak bycia świadkiem

Brak bycia świadkiem (urządzenie kworum) Rozważę tylko klaster Tuchanka1, w przypadku wszystkich pozostałych będzie to ta sama historia. Jeśli świadek zawiedzie, nic nie zmieni się w strukturze klastra, wszystko będzie nadal działać tak samo jak dotychczas. Ale kworum wyniesie 2 z 3, dlatego każda kolejna porażka będzie fatalna dla klastra. Trzeba będzie to jeszcze pilnie naprawić.

Tuchanka1 odmowa

Awaria jednego z data center dla Tuchanka1. W tym przypadku świadek oddaje swój głos na drugi węzeł w drugim centrum danych. Tam dawny niewolnik zamienia się w mastera, w wyniku czego oba mastery pracują na tym samym serwerze i oba ich pływające adresy IP wskazują na nich.

Tuchanka2 (klasyczna)

Struktura

Klasyczny schemat dwóch węzłów. Master pracuje na jednym, slave na drugim. Obydwa mogą wykonywać żądania (slave jest tylko do odczytu), więc oba są wskazywane przez zmiennoprzecinkowy adres IP: krogan2 to master, krogan2s1 to slave. Zarówno master, jak i slave będą odporne na błędy.

W przypadku dwóch węzłów odporność na błędy jest możliwa tylko przy replikacji asynchronicznej, ponieważ przy replikacji synchronicznej awaria urządzenia podrzędnego doprowadzi do zatrzymania urządzenia nadrzędnego.

Tuchanka2 odmowa

Jeśli jedno z centrów danych ulegnie awarii świadek głosuje na tę drugą. W jedynym działającym centrum danych master zostanie podniesiony i oba pływające adresy IP będą na niego wskazywać: master i slave. Oczywiście instancja musi być skonfigurowana w taki sposób, aby posiadała wystarczające zasoby (limity połączeń itp.), aby jednocześnie akceptować wszystkie połączenia i żądania z adresu IP master i slave. Oznacza to, że podczas normalnej pracy powinien mieć wystarczający zapas limitów.

Tuchanka4 (wielu niewolników)

Struktura

Już kolejna skrajność. Istnieją bazy danych, które otrzymują wiele żądań tylko do odczytu (typowy przypadek witryny o dużym obciążeniu). Tuchanka4 to sytuacja, w której może być trzech lub więcej niewolników do obsługi takich żądań, ale wciąż nie jest ich zbyt wielu. Przy bardzo dużej liczbie niewolników konieczne będzie wynalezienie hierarchicznego systemu replikacji. W minimalnym przypadku (na zdjęciu) każde z dwóch centrów danych posiada dwa serwery, każdy z instancją PostgreSQL.

Inną cechą tego schematu jest to, że istnieje już możliwość zorganizowania jednej replikacji synchronicznej. Jest skonfigurowany tak, aby, jeśli to możliwe, replikować do innego centrum danych, a nie do repliki w tym samym centrum danych, co serwer główny. Master i każdy slave są wskazywani przez zmiennoprzecinkowy adres IP. Na szczęście pomiędzy niewolnikami trzeba będzie jakoś zrównoważyć żądania proxy sqlna przykład po stronie klienta. Różne typy klientów mogą wymagać różnych typów proxy sqli tylko programiści klienta wiedzą, kto czego potrzebuje. Funkcjonalność tę można zaimplementować za pomocą zewnętrznego demona lub biblioteki klienta (puli połączeń) itp. Wszystko to wykracza poza temat klastra bazy danych pracy awaryjnej (failover Serwer proxy SQL mogą być wdrażane niezależnie, wraz z odpornością na błędy klienta).

Tuchanka4 odmowa

Jeśli jedno centrum danych (tj. dwa serwery) ulegnie awarii, świadek głosuje na drugie. W rezultacie w drugim centrum danych działają dwa serwery: na jednym działa serwer główny, a główny adres IP wskazuje na niego (w celu odbierania żądań odczytu i zapisu); a na drugim serwerze znajduje się serwer podrzędny z replikacją synchroniczną i jeden z pływających adresów IP podrzędnych wskazuje na niego (w przypadku żądań tylko do odczytu).

Pierwszą rzeczą, na którą należy zwrócić uwagę, jest to, że nie wszystkie adresy IP typu slave będą pracownikami, ale tylko jeden. Aby poprawnie z nim pracować, będzie to konieczne proxy sql przekierował wszystkie żądania do jedynego pozostałego pływającego adresu IP; i jeśli proxy sql nie, możesz wyświetlić listę wszystkich urządzeń podrzędnych typu float IP oddzielonych przecinkami w adresie URL połączenia. W tym przypadku z biblioteka połączenie zostanie nawiązane z pierwszym działającym adresem IP, odbywa się to w systemie automatycznego testowania. Być może w innych bibliotekach, na przykład JDBC, nie będzie to działać i jest konieczne proxy sql. Dzieje się tak, ponieważ zabrania się jednoczesnego podnoszenia adresów IP typu float dla urządzeń podrzędnych na jednym serwerze, dzięki czemu są one równomiernie rozdzielane pomiędzy serwery podrzędne, jeśli działa ich kilka.

Po drugie: nawet w przypadku awarii centrum danych replikacja synchroniczna zostanie zachowana. I nawet jeśli wystąpi awaria wtórna, czyli awaria jednego z dwóch serwerów w pozostałym centrum danych, klaster, choć przestanie świadczyć usługi, nadal zachowa informację o wszystkich zatwierdzonych transakcjach, dla których dał potwierdzenie zatwierdzenia (w przypadku awarii wtórnej nie będzie informacji o stratach).

Tuchanka3 (3 centra danych)

Struktura

Jest to klaster na wypadek, gdyby istniały trzy w pełni funkcjonujące centra danych, z których każde posiada w pełni funkcjonujący serwer baz danych. W tym przypadku urządzenie kworum nie są potrzebne. Jedno centrum danych jest obsługiwane przez mistrza, a pozostałe dwa przez niewolników. Replikacja jest synchroniczna, wpisz ANY (slave1, slave2), co oznacza, że ​​klient otrzyma potwierdzenie zatwierdzenia, gdy którykolwiek z urządzeń slave jako pierwszy odpowie, że zaakceptował zatwierdzenie. Zasoby są wskazywane przez jeden pływający adres IP dla urządzenia głównego i dwa dla urządzenia podrzędnego. W przeciwieństwie do Tuchanka4, wszystkie trzy pływające adresy IP są odporne na błędy. Aby zrównoważyć zapytania SQL tylko do odczytu, możesz użyć proxy sql (z oddzielną tolerancją na błędy) lub przypisz jeden adres IP typu slave połowie klientów, a drugą połowę.

Tuchanka3 odmowa

Jeśli jedno z centrów danych ulegnie awarii, pozostaną dwa. W jednym podnoszone są adresy IP master i float z mastera, w drugim - adresy IP float slave i obu slave (instancja musi mieć podwójną rezerwę zasobów, aby akceptować wszystkie połączenia z obu float adresów slave). Synchroniczna replikacja pomiędzy urządzeniami master i slave. Klaster będzie także zapisywał informacje o zatwierdzonych i potwierdzonych transakcjach (nie będzie utraty informacji) w przypadku zniszczenia dwóch centrów danych (o ile nie zostaną one zniszczone jednocześnie).

Zdecydowałem się nie zamieszczać szczegółowego opisu struktury plików i wdrożenia. Każdy, kto chce się pobawić, może przeczytać wszystko w pliku README. Podaję jedynie opis testów automatycznych.

Automatyczny system testowania

Aby przetestować odporność klastrów na uszkodzenia poprzez symulację różnych usterek, stworzono automatyczny system testowania. Uruchamiany przez skrypt test/failure. Skrypt może przyjąć jako parametry liczbę klastrów, które chcesz przetestować. Na przykład to polecenie:

test/failure 2 3

przetestuje tylko drugi i trzeci klaster. Jeżeli parametry nie zostaną określone, testowane będą wszystkie klastry. Wszystkie klastry są testowane równolegle, a wynik wyświetlany jest w panelu tmux. Tmux używa dedykowanego serwera tmux, więc skrypt można uruchomić z poziomu domyślnego tmux, co skutkuje zagnieżdżeniem tmux. Polecam używać terminala w dużym oknie i z małą czcionką. Przed rozpoczęciem testowania wszystkie maszyny wirtualne są przywracane do migawki w momencie zakończenia skryptu setup.

Terminal podzielony jest na kolumny w zależności od liczby testowanych klastrów, domyślnie (na zrzucie ekranu) są ich cztery. Zawartość kolumn opiszę na przykładzie Tuchanki2. Panele na zrzucie ekranu są ponumerowane:

1. Tutaj wyświetlane są statystyki testu. Kolumny:
   • brak — nazwa testu (funkcji w skrypcie), który emuluje błąd.
   • reakcja — średni arytmetyczny czas w sekundach, podczas którego klaster odzyskał swoją funkcjonalność. Jest mierzony od uruchomienia skryptu emulującego błąd do momentu, w którym klaster przywróci swoją funkcjonalność i będzie mógł kontynuować świadczenie usług. Jeśli czas jest bardzo krótki, na przykład sześć sekund (dzieje się to w klastrach z kilkoma urządzeniami podrzędnymi (Tuchanka3 i Tuchanka4)), oznacza to, że usterka wystąpiła w urządzeniu podrzędnym asynchronicznym i nie miała żadnego wpływu na wydajność; nie było żadnych przełączniki stanu klastra.
   • odchylenie — pokazuje rozrzut (dokładność) wartości reakcja stosując metodę odchylenia standardowego.
   • liczyć — ile razy przeprowadzono to badanie.
2. Krótki dziennik pozwala ocenić, co aktualnie robi klaster. Wyświetlany jest numer iteracji (testu), znacznik czasu i nazwa operacji. Zbyt długie działanie (> 5 minut) wskazuje na problem.
3. serce (serce) - aktualny czas. Do wizualnej oceny wydajności mistrzowie Bieżący czas jest stale zapisywany w tablicy przy użyciu pływającego wzorca IP. Jeśli operacja się powiedzie, wynik zostanie wyświetlony w tym panelu.
4. bić (impuls) - „aktualny czas”, który został wcześniej zarejestrowany przez skrypt serce do opanowania, teraz czytaj z niewolnik poprzez swój pływający adres IP. Umożliwia wizualną ocenę wydajności urządzenia podrzędnego i replikacji. W Tuchance1 nie ma slaveów z float IP (żadnych slaveów świadczących usługi), ale są dwie instancje (DB), więc nie będzie to tutaj pokazane bićI serce druga instancja.
5. Monitorowanie kondycji klastra za pomocą narzędzia pcs mon. Pokazuje strukturę, rozkład zasobów pomiędzy węzłami i inne przydatne informacje.
6. Tutaj wyświetlane jest monitorowanie systemu z każdej maszyny wirtualnej w klastrze. Takich paneli może być więcej w zależności od liczby maszyn wirtualnych znajdujących się w klastrze. Dwa wykresy Obciążenie procesora (maszyny wirtualne mają dwa procesory), nazwę maszyny wirtualnej, Obciążenie systemu (nazywany Load Average, ponieważ jest uśredniany w ciągu 5, 10 i 15 minut), danych procesowych i alokacji pamięci.
7. Ślad skryptu wykonującego testowanie. W przypadku awarii - nagłej przerwy w działaniu lub niekończącego się cyklu oczekiwania - tutaj możesz zobaczyć przyczynę takiego zachowania.

Testowanie odbywa się w dwóch etapach. Najpierw skrypt przechodzi wszystkie typy testów, losowo wybierając maszynę wirtualną, do której ma zostać zastosowany ten test. Następnie wykonywany jest nieskończony cykl testów, za każdym razem losowo wybierane są maszyny wirtualne i usterka. Nagłe zakończenie skryptu testowego (dolny panel) lub niekończąca się pętla oczekiwania na coś (> 5 minut czasu wykonania jednej operacji, widać to w śladzie) oznacza, że ​​część testów na tym klastrze zakończyła się niepowodzeniem.

Każdy test składa się z następujących operacji:

1. Uruchom funkcję emulującą błąd.
2. Gotowi? — oczekiwanie na przywrócenie klastra (kiedy wszystkie usługi zostaną udostępnione).
3. Pokazuje limit czasu odzyskiwania klastra (reakcja).
4. Fix — klaster jest w „naprawie”. Po czym powinien powrócić do stanu w pełni funkcjonalnego i być gotowym na kolejną awarię.

Oto lista testów wraz z opisem ich działania:

• WidelecBomba: Tworzy „Brak pamięci” za pomocą bomby widełkowej.
• Za mało miejsca: Dysk twardy jest pełny. Ale test jest raczej symboliczny; przy niewielkim obciążeniu powstającym podczas testowania PostgreSQL zwykle nie zawodzi, gdy dysk twardy jest pełny.
• Postgres-KILL: zabija PostgreSQL za pomocą polecenia killall -KILL postgres.
• Postgres-STOP: zawiesza polecenie PostgreSQL killall -STOP postgres.
• Wyłączanie: „odłącza zasilanie” maszyny wirtualnej za pomocą polecenia VBoxManage controlvm "виртуалка" poweroff.
• Zresetuj: przeciąża maszynę wirtualną poleceniem VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: zawiesza demona SBD za pomocą polecenia killall -STOP sbd.
• Zamknąć: wysyła polecenie do maszyny wirtualnej przez SSH systemctl poweroff, system zamyka się płynnie.
• Odczepić: izolacja sieci, polecenie VBoxManage controlvm "виртуалка" setlinkstate1 off.

Zakończenie testowania przy użyciu standardowego polecenia tmux „kill-window” Ctrl-b &lub polecenie „odłącz-klienta”. Ctrl-b d: w tym momencie testowanie się kończy, tmux zostaje zamknięty, maszyny wirtualne są wyłączone.

Problemy zidentyfikowane podczas testów

• Obecnie demon stróżujący sbd działa na zatrzymanie obserwowanych demonów, ale nie na ich zamrażanie. A w rezultacie usterki, które prowadzą tylko do zamrożenia Korosync и Stymulator serca, ale nie wisi sbd. Do sprawdzenia Korosync ma już PR # 83 (na GitHubie o godz sbd), zaakceptowane w wątku mistrz. Obiecali (w PR#83), że będzie coś podobnego dla Pacemaker, mam nadzieję, że do Czerwony Kapelusz 8 zrobi. Jednak takie „awarie” mają charakter spekulacyjny i można je łatwo sztucznie zasymulować, na przykład za pomocą killall -STOP corosync, ale nigdy nie spotkałem się w prawdziwym życiu.

• У Stymulator serca w wersji dla 7 CentOS nieprawidłowo ustawiony czas_synchronizacji у urządzenie kworum, w rezultacie jeśli jeden węzeł uległ awarii, z pewnym prawdopodobieństwem drugi węzeł również został ponownie uruchomiony, do którego miał się przenieść mistrz. Wyleczony przez powiększenie czas_synchronizacji у urządzenie kworum podczas wdrażania (w skrypcie setup/setup1). Poprawka ta nie została zaakceptowana przez twórców Stymulator sercazamiast tego obiecali przeprojektować infrastrukturę w taki sposób (w bliżej nieokreślonej przyszłości), aby ten limit czasu był obliczany automatycznie.

• Jeśli konfiguracja bazy danych to określa LC_MESSAGES (wiadomości tekstowe) Można zastosować Unicode m.in. ru_RU.UTF-8, a następnie przy uruchomieniu Postgres w środowisku, w którym ustawienia regionalne nie są UTF-8, powiedzmy w pustym środowisku (tutaj stymulator serca+pgsqlms(paf) biegnie Postgres) następnie dziennik będzie zawierał znaki zapytania zamiast liter UTF-8. Twórcy PostgreSQL nie zgodzili się, co zrobić w tej sprawie. To kosztuje, musisz zainstalować LC_MESSAGES=en_US.UTF-8 podczas konfigurowania (tworzenia) instancji bazy danych.

• Jeżeli ustawiony jest wal_receiver_timeout (domyślnie jest to 60s), to podczas testu PostgreSQL-STOP na masterze w klastrach tuchanka3 i tuchanka4 replikacja nie łączy się ponownie z nowym wzorcem. Replikacja jest tam synchroniczna, więc zatrzymuje się nie tylko slave, ale także nowy master. Działa, ustawiając wal_receiver_timeout=0 podczas konfigurowania PostgreSQL.

• Czasami zaobserwowałem zawieszanie się replikacji w PostgreSQL w teście ForkBomb (przepełnienie pamięci). Po ForkBomb czasami urządzenia podrzędne mogą nie łączyć się ponownie z nowym mistrzem. Spotkałem się z tym tylko w klastrach tuchanka3 i tuchanka4, gdzie master zamarł z powodu synchronicznej replikacji. Po dłuższym czasie (około dwóch godzin) problem zniknął samoistnie. Aby to skorygować, potrzebne są dalsze badania. Objawy są podobne do poprzedniego błędu, który jest spowodowany inną przyczyną, ale z takimi samymi konsekwencjami.

Zdjęcie Krogana zaczerpnięte z Art dewiacyjne za zgodą autora:

Źródło: www.habr.com