Głównym celem Patroni jest zapewnienie wysokiej dostępności dla PostgreSQL. Ale Patroni to tylko szablon, a nie gotowe narzędzie (o czym ogólnie mówi się w dokumentacji). Już na pierwszy rzut oka, po skonfigurowaniu Patroni w laboratorium testowym, widać, jakie to świetne narzędzie i jak łatwo radzi sobie z naszymi próbami rozbicia klastra. Jednak w praktyce w środowisku produkcyjnym nie zawsze wszystko dzieje się tak pięknie i elegancko, jak w laboratorium testowym.
Opowiem ci trochę o sobie. Zaczynałem jako administrator systemu. Pracował w tworzeniu stron internetowych. W Data Egret pracuję od 2014 roku. Firma zajmuje się konsultingiem w zakresie Postgres. A my obsługujemy dokładnie Postgres, z Postgresem pracujemy na co dzień, więc mamy różne ekspertyzy związane z operacją.
A pod koniec 2018 roku zaczęliśmy powoli korzystać z Patroni. I zebrano trochę doświadczenia. Jakoś to zdiagnozowaliśmy, dostroiliśmy, doszliśmy do naszych najlepszych praktyk. I o nich opowiem w tym raporcie.
Poza Postgresem kocham Linuksa. Lubię w nim grzebać i eksplorować, lubię zbierać rdzenie. Uwielbiam wirtualizację, kontenery, dockera, Kubernetesa. Interesuje mnie to wszystko, bo stare przyzwyczajenia administratora wpływają. Lubię zajmować się monitoringiem. A poza tym uwielbiam postgresowe rzeczy związane z administracją, czyli replikacja, backup. A w wolnym czasie piszę w Go. Nie jestem inżynierem oprogramowania, po prostu piszę dla siebie w Go. I sprawia mi to przyjemność.
- Myślę, że wielu z was wie, że Postgres nie ma HA (High Availability) od razu po wyjęciu z pudełka. Aby uzyskać HA, musisz coś zainstalować, skonfigurować, zadać sobie trud i zdobyć.
- Istnieje kilka narzędzi, a Patroni jest jednym z nich, które rozwiązuje HA całkiem fajnie i bardzo dobrze. Ale umieszczając to wszystko w laboratorium testowym i uruchamiając, możemy zobaczyć, że wszystko działa, możemy odtworzyć niektóre problemy, zobaczyć, jak Patroni im służy. I zobaczymy, że wszystko działa świetnie.
- Ale w praktyce napotkaliśmy różne problemy. I będę mówić o tych problemach.
- Opowiem, jak to zdiagnozowaliśmy, co poprawiliśmy - czy nam to pomogło, czy nie.
- Nie powiem ci, jak zainstalować Patroni, ponieważ możesz googlować w Internecie, możesz zajrzeć do plików konfiguracyjnych, aby zrozumieć, jak to wszystko się zaczyna, jak jest skonfigurowane. Możesz zrozumieć schematy, architektury, znaleźć informacje na ten temat w Internecie.
- Nie będę mówić o czyimś doświadczeniu. Powiem tylko o problemach, z którymi się borykaliśmy.
- I nie będę mówić o problemach, które są poza Patroni i PostgreSQL. Jeśli np. pojawią się problemy związane z balansowaniem, gdy nasz klaster padnie, nie będę o tym mówił.
I małe zastrzeżenie, zanim zaczniemy nasz raport.
Wszystkie te problemy, które napotkaliśmy, mieliśmy je w ciągu pierwszych 6-7-8 miesięcy działalności. Z czasem doszliśmy do naszych wewnętrznych najlepszych praktyk. I nasze problemy zniknęły. Dlatego raport został ogłoszony około pół roku temu, kiedy wszystko było świeże w mojej głowie i wszystko doskonale pamiętałem.
W trakcie przygotowywania raportu podniosłem już stare sekcje, przejrzałem logi. A niektóre szczegóły mogły zostać zapomniane lub niektórych szczegółów nie można było w pełni zbadać podczas analizy problemów, więc w niektórych momentach może się wydawać, że problemy nie są w pełni rozważone lub brakuje informacji. Dlatego proszę o wybaczenie mi tej chwili.
Co to jest Patroni?
- To jest szablon do budowania HA. Tak jest napisane w dokumentacji. I z mojego punktu widzenia jest to bardzo poprawne wyjaśnienie. Patroni to nie srebrna kula, która rozwiąże wszystkie Twoje problemy, czyli trzeba się postarać, aby zadziałało i przyniosło korzyści.
- Jest to usługa agenta, która jest instalowana w każdej usłudze bazy danych i jest rodzajem systemu init dla twojego Postgres. Uruchamia Postgres, zatrzymuje, restartuje, rekonfiguruje i zmienia topologię twojego klastra.
- W związku z tym, aby przechowywać stan klastra, jego aktualną reprezentację, jak wygląda, potrzebny jest jakiś rodzaj pamięci. I z tego punktu widzenia Patroni poszedł drogą przechowywania stanu w systemie zewnętrznym. Jest to rozproszony system przechowywania konfiguracji. Może to być Etcd, Consul, ZooKeeper lub kubernetes Etcd, czyli jedna z tych opcji.
- Jedną z cech Patroni jest to, że autofiler można wyjąć z pudełka, tylko poprzez jego skonfigurowanie. Jeśli weźmiemy Repmgr do porównania, to filer jest tam zawarty. Z Repmgr otrzymujemy przełączanie, ale jeśli chcemy mieć autofiler, to musimy go dodatkowo skonfigurować. Patroni ma już autofiler po wyjęciu z pudełka.
- I jest wiele innych rzeczy. Np. utrzymanie konfiguracji, wlanie nowych replik, backup itp. Ale to wykracza poza zakres raportu, nie będę o tym mówił.
A drobnym skutkiem jest to, że głównym zadaniem Patroni jest dobrze i rzetelnie zrobić autoplik, aby nasz klaster działał, a aplikacja nie zauważała zmian w topologii klastra.
Ale kiedy zaczynamy używać Patroni, nasz system staje się nieco bardziej skomplikowany. Jeśli wcześniej mieliśmy Postgres, to używając Patroni otrzymujemy samego Patroni, otrzymujemy DCS, w którym przechowywany jest stan. I to wszystko musi jakoś działać. Co może pójść nie tak?
Przerwa majowa:
- Postgres może się zepsuć. Może to być master lub replika, jedna z nich może zawieść.
- Sam Patroni może się zepsuć.
- System DCS, w którym przechowywany jest stan, może się zepsuć.
- A sieć może się zepsuć.
Wszystkie te punkty rozważę w raporcie.
Będę rozpatrywał sprawy w miarę jak stają się one bardziej złożone, a nie z punktu widzenia tego, że sprawa składa się z wielu elementów. I z punktu widzenia subiektywnych odczuć, że ta obudowa była dla mnie trudna, trudno ją było rozebrać… i odwrotnie, niektóre obudowy były lekkie i łatwo było je zdemontować.
A pierwszy przypadek jest najłatwiejszy. Tak jest w przypadku, gdy wzięliśmy klaster bazy danych i wdrożyliśmy naszą pamięć DCS w tym samym klastrze. To najczęstszy błąd. To błąd w budowaniu architektur, czyli łączeniu różnych komponentów w jednym miejscu.
Więc był zgłaszający, chodźmy zająć się tym, co się stało.
I tutaj interesuje nas, kiedy wystąpił plik. Oznacza to, że interesuje nas ten moment w czasie, kiedy zmienił się stan klastra.
Ale filer nie zawsze jest natychmiastowy, tj. nie zajmuje żadnej jednostki czasu, może być opóźniony. Może być długotrwały.
Ma więc czas rozpoczęcia i czas zakończenia, czyli jest zdarzeniem ciągłym. I dzielimy wszystkie zdarzenia na trzy interwały: mamy czas przed wnioskodawcą, w trakcie wnioskodawcy i po wnioskodawcy. Oznacza to, że bierzemy pod uwagę wszystkie wydarzenia na tej osi czasu.
A pierwszą rzeczą, kiedy zdarzyło się zgłaszającemu, jest szukanie przyczyny tego, co się stało, jaka była przyczyna tego, co doprowadziło do zgłaszającego.
Jeśli spojrzymy na logi, będą to klasyczne logi Patroni. Mówi nam w nich, że serwer stał się masterem, a rola mastera przeszła na ten węzeł. Tutaj jest to zaznaczone.
Następnie musimy zrozumieć, dlaczego wystąpił filer, tj. jakie zdarzenia miały miejsce, które spowodowały przeniesienie roli master z jednego węzła do drugiego. I w tym przypadku wszystko jest proste. Wystąpił błąd podczas interakcji z systemem przechowywania. Mistrz zdał sobie sprawę, że nie może pracować z DCS, to znaczy, że był jakiś problem z interakcją. A on mówi, że nie może już być panem i rezygnuje. Ten wers „zdegradowane ja” mówi dokładnie to.
Jeśli spojrzymy na zdarzenia, które poprzedziły filer, zobaczymy tam same przyczyny, które spowodowały, że kreator kontynuował problem.
Jeśli spojrzymy na logi Patroni, zobaczymy, że mamy dużo błędów, timeoutów, czyli agent Patroni nie może współpracować z DCS. W tym przypadku jest to agent konsula, który komunikuje się na porcie 8500.
Problem polega na tym, że Patroni i baza danych działają na tym samym hoście. A serwery Consul zostały uruchomione na tym samym węźle. Tworząc obciążenie serwera, stworzyliśmy problemy również dla serwerów Consul. Nie mogli się właściwie komunikować.
Po pewnym czasie, gdy obciążenie opadło, nasz Patroni mógł ponownie komunikować się z agentami. Wznowiono normalną pracę. I ten sam serwer Pgdb-2 ponownie został masterem. Czyli doszło do małego przewrotu, w wyniku którego węzeł zrezygnował z uprawnień mistrza, a następnie ponownie je przejął, czyli wszystko wróciło po staremu.
I można to uznać za fałszywy alarm, albo można uznać, że Patroni zrobił wszystko jak należy. Oznacza to, że zdał sobie sprawę, że nie może utrzymać stanu klastra i usunął swoje uprawnienia.
I tu pojawił się problem z uwagi na to, że serwery Consul są na tym samym sprzęcie co bazy. W związku z tym każde obciążenie: niezależnie od tego, czy jest to obciążenie dysków, czy procesorów, wpływa również na interakcję z klastrem Consul.
I zdecydowaliśmy, że nie powinno mieszkać razem, przeznaczyliśmy osobny klaster dla Konsula. A Patroni już pracował z osobnym Consulem, czyli był osobny klaster Postgres, osobny klaster Consul. Jest to podstawowa instrukcja, jak nosić i przechowywać te wszystkie rzeczy, aby nie mieszkała razem.
Opcjonalnie możesz przekręcić parametry ttl, loop_wait, retry_timeout, czyli spróbować przetrwać te krótkotrwałe szczyty obciążenia poprzez zwiększenie tych parametrów. Ale to nie jest najbardziej odpowiednia opcja, ponieważ to obciążenie może być długie w czasie. I po prostu wyjdziemy poza te granice tych parametrów. A to może nie do końca pomóc.
Pierwszy problem, jak rozumiesz, jest prosty. Wzięliśmy i złożyliśmy DCS razem z bazą, mamy problem.
Drugi problem jest podobny do pierwszego. Podobnie jest z tym, że znowu mamy problemy z interoperacyjnością systemu DCS.
Jeśli spojrzymy na logi, zobaczymy, że znowu mamy błąd komunikacji. A Patroni mówi, że nie mogę wchodzić w interakcje z DCS, więc obecny master przechodzi w tryb repliki.
Stary mistrz staje się repliką, tutaj Patroni sprawdza się tak, jak powinno. Uruchamia pg_rewind, aby przewinąć dziennik transakcji, a następnie połączyć się z nowym masterem, aby dogonić nowego mastera. Tutaj Patroni sprawdza się tak, jak powinien.
Tutaj musimy znaleźć miejsce, które poprzedziło filer, czyli te błędy, które spowodowały, że mieliśmy filer. I pod tym względem dzienniki Patroni są dość wygodne w obsłudze. Pisze te same wiadomości w określonych odstępach czasu. A jeśli zaczniemy szybko przeglądać te dzienniki, zobaczymy z dzienników, że dzienniki się zmieniły, co oznacza, że \uXNUMXb\uXNUMXbzaczęły się pewne problemy. Szybko wracamy w to miejsce, zobaczymy co się stanie.
A w normalnej sytuacji logi wyglądają mniej więcej tak. Sprawdzany jest właściciel zamka. A jeśli na przykład zmienił się właściciel, mogą wystąpić pewne zdarzenia, na które Patroni musi zareagować. Ale w tym przypadku jesteśmy w porządku. Szukamy miejsca, w którym zaczęły się błędy.
Po przewinięciu do punktu, w którym zaczęły pojawiać się błędy, widzimy, że mamy automatyczne przeładowanie. A ponieważ nasze błędy były związane z interakcją z DCS iw naszym przypadku skorzystaliśmy z Consul, zaglądamy też do logów Consula, co tam się działo.
Z grubsza porównując czas zgłaszającego i czas w dziennikach konsula, widzimy, że nasi sąsiedzi w klastrze konsulów zaczęli wątpić w istnienie innych członków klastra konsulów.
A jeśli spojrzysz także na logi innych agentów konsula, to też zobaczysz, że tam ma miejsce jakieś załamanie sieci. A wszyscy członkowie gromady Konsulów wątpią w swoje istnienie. I to był bodziec dla filera.
Jeśli spojrzysz na to, co wydarzyło się przed tymi błędami, możesz zobaczyć, że są różnego rodzaju błędy, na przykład termin, RPC spadło, to znaczy, że jest wyraźnie jakiś problem w interakcji członków klastra Consul między sobą .
Najprostszą odpowiedzią jest naprawa sieci. Ale mnie, stojącemu na podium, łatwo to powiedzieć. Ale okoliczności są takie, że nie zawsze klienta stać na naprawę sieci. Może mieszkać w DC i może nie być w stanie naprawić sieci, wpłynąć na sprzęt. Potrzebne są więc inne opcje.
Dostępne są opcje:
- Najprostszą opcją, która jest moim zdaniem zapisana nawet w dokumentacji, jest wyłączenie kontroli konsula, czyli po prostu przekazanie pustej tablicy. I mówimy konsulowi, żeby nie używał żadnych czeków. Dzięki tym kontrolom możemy zignorować te burze sieciowe i nie inicjować filtrowania.
- Inną opcją jest podwójne sprawdzenie raft_multiplier. Jest to parametr samego serwera Consul. Domyślnie jest ona ustawiona na 5. Ta wartość jest zalecana w dokumentacji dla środowisk pomostowych. W rzeczywistości wpływa to na częstotliwość przesyłania wiadomości między członkami sieci Consul. W rzeczywistości parametr ten wpływa na szybkość komunikacji usługi pomiędzy członkami klastra Consul. A w przypadku produkcji zaleca się już jego zmniejszenie, aby węzły częściej wymieniały wiadomości.
- Inną opcją, którą wymyśliliśmy, jest zwiększenie priorytetu procesów Consul wśród innych procesów dla harmonogramu procesów systemu operacyjnego. Istnieje taki „miły” parametr, który po prostu określa priorytet procesów, który jest brany pod uwagę przez harmonogram systemu operacyjnego podczas planowania. Zmniejszyliśmy również wartość nice dla agentów konsulów, tj. zwiększono priorytet, aby system operacyjny dał procesom Consul więcej czasu na pracę i wykonanie ich kodu. W naszym przypadku rozwiązało to nasz problem.
- Inną opcją jest niekorzystanie z Konsula. Mam przyjaciela, który jest wielkim zwolennikiem Etcd. I regularnie się z nim kłócimy, co jest lepsze Etcd czy Consul. Ale pod względem tego, co jest lepsze, zwykle zgadzamy się z nim, że Consul ma agenta, który powinien działać na każdym węźle z bazą danych. Oznacza to, że interakcja Patroni z klastrem Consul odbywa się za pośrednictwem tego agenta. A ten agent staje się wąskim gardłem. Jeśli coś stanie się z agentem, Patroni nie może już pracować z klastrem Consul. I to jest problem. W planie Etcd nie ma agenta. Patroni może pracować bezpośrednio z listą serwerów Etcd i już się z nimi komunikować. Pod tym względem, jeśli używasz Etcd w swojej firmie, to prawdopodobnie Etcd będzie lepszym wyborem niż Consul. Ale my, nasi klienci, jesteśmy zawsze ograniczeni tym, co klient wybrał i z czego korzysta. I mamy konsula w większości dla wszystkich klientów.
- Ostatnim punktem jest zmiana wartości parametrów. Możemy podnieść te parametry w nadziei, że nasze krótkoterminowe problemy z siecią będą krótkotrwałe i nie wypadną poza zakres tych parametrów. W ten sposób możemy zredukować agresywność Patroni do automatycznego archiwizowania w przypadku wystąpienia problemów z siecią.
Myślę, że wielu, którzy używają Patroni, zna to polecenie.
To polecenie pokazuje bieżący stan klastra. I na pierwszy rzut oka ten obraz może wydawać się normalny. Mamy mastera, mamy replikę, nie ma opóźnienia replikacyjnego. Ale ten obraz jest dokładnie normalny, dopóki nie wiemy, że ten klaster powinien mieć trzy węzły, a nie dwa.
W związku z tym istniał autofile. A po tym autofile nasza replika zniknęła. Musimy dowiedzieć się, dlaczego zniknęła, sprowadzić ją z powrotem, przywrócić. Ponownie przechodzimy do dzienników i sprawdzamy, dlaczego wystąpiło automatyczne przeładowanie.
W tym przypadku druga replika stała się masterem. Tutaj wszystko jest w porządku.
I musimy spojrzeć na replikę, która odpadła i której nie ma w klastrze. Otwieramy logi Patroni i widzimy, że mieliśmy problem podczas procesu łączenia się z klastrem na etapie pg_rewind. Aby połączyć się z klastrem, musisz przewinąć dziennik transakcji, zażądać wymaganego dziennika transakcji od mastera i użyć go do dogonienia mastera.
W takim przypadku nie mamy dziennika transakcji i replika nie może się uruchomić. W związku z tym zatrzymujemy Postgres z błędem. I dlatego nie ma go w klastrze.
Musimy zrozumieć, dlaczego nie ma go w klastrze i dlaczego nie było dzienników. Idziemy do nowego mistrza i patrzymy, co ma w logach. Okazuje się, że po zakończeniu pg_rewind wystąpił punkt kontrolny. Po prostu zmieniono nazwy niektórych starych dzienników transakcji. Kiedy stary mistrz próbował połączyć się z nowym mistrzem i zapytać o te dzienniki, ich nazwy zostały już zmienione, po prostu nie istniały.
Porównałem znaczniki czasu, kiedy te zdarzenia miały miejsce. A tam różnica to dosłownie 150 milisekund, czyli punkt kontrolny ukończony w 369 milisekund, zmieniono nazwy segmentów WAL. I dosłownie w 517, po 150 milisekundach, na starej replice zaczęło się cofanie. Czyli dosłownie 150 milisekund nam wystarczyło, żeby replika nie mogła się połączyć i zarobić.
Jakie są opcje?
Początkowo używaliśmy gniazd replikacji. Myśleliśmy, że to było dobre. Chociaż na pierwszym etapie działania wyłączyliśmy automaty. Wydawało nam się, że jeśli sloty zbiorą dużo segmentów WAL, możemy odrzucić mastera. Upadnie. Przez jakiś czas cierpieliśmy bez slotów. I zdaliśmy sobie sprawę, że potrzebujemy automatów, zwróciliśmy automaty.
Ale jest tu problem, że kiedy master idzie do repliki, usuwa sloty i usuwa segmenty WAL wraz ze slotami. Aby wyeliminować ten problem, zdecydowaliśmy się podnieść parametr wal_keep_segments. Domyślnie jest to 8 segmentów. Podnieśliśmy go do 1 i sprawdziliśmy, ile mamy wolnego miejsca. I przekazaliśmy 000 gigabajtów dla wal_keep_segments. Oznacza to, że podczas przełączania zawsze mamy rezerwę 16 gigabajtów dzienników transakcji na wszystkich węzłach.
I plus - nadal jest odpowiedni do długotrwałych zadań konserwacyjnych. Powiedzmy, że musimy zaktualizować jedną z replik. I chcemy to wyłączyć. Musimy zaktualizować oprogramowanie, może system operacyjny, coś jeszcze. A kiedy wyłączamy replikę, usuwane jest również miejsce na tę replikę. A jeśli użyjemy małego wal_keep_segments, to przy dłuższej nieobecności repliki logi transakcji zostaną utracone. Podniesiemy replikę, poprosi o te dzienniki transakcji, w których się zatrzymała, ale mogą one nie znajdować się na serwerze głównym. A replika też nie będzie mogła się połączyć. Dlatego przechowujemy duże zapasy czasopism.
Posiadamy bazę produkcyjną. Są już projekty w toku.
Był pilnik. Weszliśmy i spojrzeliśmy - wszystko jest w porządku, repliki są na swoim miejscu, nie ma opóźnienia replikacji. W logach też nie ma błędów, wszystko jest w porządku.
Zespół produktowy mówi, że powinny być jakieś dane, ale widzimy je z jednego źródła, ale nie widzimy ich w bazie danych. I musimy zrozumieć, co się z nimi stało.
Oczywiste jest, że pg_rewind je przegapił. Od razu to zrozumieliśmy, ale poszliśmy zobaczyć, co się dzieje.
W logach zawsze możemy znaleźć kiedy filer się zdarzył, kto został masterem, oraz możemy określić kto był starym masterem i kiedy chciał zostać repliką, czyli potrzebujemy tych logów aby dowiedzieć się ile logów transakcji zaginął.
Nasz stary mistrz zrestartował się. A Patroni był zarejestrowany w autorunie. Uruchomił Patroni. Następnie założył Postgres. Mówiąc dokładniej, przed uruchomieniem Postgres i zrobieniem z niego repliki, Patroni uruchomił proces pg_rewind. W związku z tym usunął część dzienników transakcji, pobrał nowe i połączył się. Tutaj Patroni działał elegancko, czyli zgodnie z oczekiwaniami. Klaster został przywrócony. Mieliśmy 3 węzły, po filerze 3 węzły - wszystko jest fajne.
Straciliśmy część danych. I musimy zrozumieć, jak wiele straciliśmy. Szukamy właśnie momentu, w którym mieliśmy przewinięcie. Możemy to znaleźć w takich wpisach do dziennika. Rozpoczęło się przewijanie do tyłu, coś tam zrobiło i skończyło się.
Musimy znaleźć pozycję w dzienniku transakcji, w której przerwał stary mistrz. W tym przypadku jest to znak. I potrzebujemy drugiego znaku, czyli odległości, o jaką stary mistrz różni się od nowego.
Bierzemy zwykły pg_wal_lsn_diff i porównujemy te dwa znaki. I w tym przypadku otrzymujemy 17 megabajtów. Dużo czy mało, każdy decyduje sam. Bo dla kogoś 17 megabajtów to mało, dla kogoś to dużo i nie do przyjęcia. Tutaj każdy indywidualnie określa dla siebie zgodnie z potrzebami firmy.
Ale czego się sami dowiedzieliśmy?
Najpierw musimy sami zdecydować - czy Patroni zawsze potrzebuje autostartu po restarcie systemu? Często zdarza się, że musimy iść do starego mistrza, zobaczyć, jak daleko zaszedł. Być może sprawdź segmenty dziennika transakcji, zobacz, co tam jest. I zrozumieć, czy możemy utracić te dane, czy też musimy uruchomić starego mistrza w trybie autonomicznym, aby wyciągnąć te dane.
I dopiero potem musimy zdecydować, czy możemy odrzucić te dane, czy możemy je przywrócić, podłączyć ten węzeł jako replikę do naszego klastra.
Ponadto istnieje parametr „maximum_lag_on_failover”. Domyślnie, o ile mnie pamięć nie myli, parametr ten ma wartość 1 megabajta.
Jak on pracuje? Jeśli nasza replika spóźnia się o 1 megabajt danych w opóźnieniu replikacji, to ta replika nie bierze udziału w wyborach. A jeśli nagle nastąpi przeładowanie, Patroni sprawdza, które repliki pozostają w tyle. Jeśli są w tyle za dużą liczbą dzienników transakcji, nie mogą zostać mistrzem. Jest to bardzo dobra funkcja bezpieczeństwa, która zapobiega utracie dużej ilości danych.
Ale jest problem polegający na tym, że opóźnienie replikacji w klastrze Patroni i DCS jest aktualizowane w określonych odstępach czasu. Myślę, że 30 sekund to domyślna wartość ttl.
W związku z tym może dojść do sytuacji, że dla replik w DCS jest jedno opóźnienie replikacji, ale w rzeczywistości może być zupełnie inne opóźnienie lub może go w ogóle nie być, czyli to coś nie jest w czasie rzeczywistym. I nie zawsze odzwierciedla to rzeczywisty obraz. I nie warto robić na tym fantazyjnej logiki.
A ryzyko straty zawsze pozostaje. A w najgorszym przypadku jedna formuła, aw średnim przypadku inna formuła. Czyli planując wdrożenie Patroni i oceniając, ile danych możemy stracić, musimy polegać na tych formułach i z grubsza wyobrazić sobie, ile danych możemy stracić.
I jest dobra wiadomość. Kiedy stary mistrz poszedł naprzód, może iść naprzód dzięki pewnym procesom w tle. To znaczy, było coś w rodzaju autovacuum, zapisał dane, zapisał je w dzienniku transakcji. I możemy łatwo zignorować i utracić te dane. Nie ma w tym żadnego problemu.
A tak wyglądają logi, jeśli ustawiono maximum_lag_on_failover i wystąpił filer i trzeba wybrać nowego mastera. Replika ocenia się jako niezdolna do udziału w wyborach. I odmawia udziału w wyścigu o lidera. I czeka na wybranie nowego mastera, aby mogła się z nim połączyć. Jest to dodatkowe zabezpieczenie przed utratą danych.
Tutaj mamy zespół ds. produktu, który napisał, że jego produkt ma problemy z Postgres. Jednocześnie nie można uzyskać dostępu do samego mastera, ponieważ nie jest on dostępny przez SSH. A autofile też się nie dzieje.
Ten host został zmuszony do ponownego uruchomienia. Z powodu ponownego uruchomienia nastąpił automatyczny plik, chociaż możliwe było wykonanie ręcznego automatycznego pliku, jak teraz rozumiem. A po ponownym uruchomieniu już zobaczymy, co mieliśmy z obecnym mistrzem.
Jednocześnie z góry wiedzieliśmy, że mamy problemy z dyskami, czyli już z monitoringu wiedzieliśmy, gdzie kopać i czego szukać.
Weszliśmy do logu postgresa, zaczęliśmy sprawdzać co się tam dzieje. Widzieliśmy zatwierdzenia trwające tam jedną, dwie, trzy sekundy, co wcale nie jest normalne. Widzieliśmy, że nasza autopróżnia uruchamia się bardzo wolno i dziwnie. I widzieliśmy pliki tymczasowe na dysku. Oznacza to, że są to wszystkie wskaźniki problemów z dyskami.
Zajrzeliśmy do systemu dmesg (dziennik jądra). I zobaczyliśmy, że mamy problemy z jednym z dysków. Podsystemem dysku był program Raid. Spojrzeliśmy na /proc/mdstat i zobaczyliśmy, że brakuje nam jednego dysku. Oznacza to, że istnieje Raid z 8 dyskami, brakuje nam jednego. Jeśli uważnie przyjrzysz się slajdowi, to na wyjściu zobaczysz, że nie mamy tam sde. U nas, warunkowo mówiąc, dysk wypadł. Spowodowało to problemy z dyskiem, a aplikacje również napotkały problemy podczas pracy z klastrem Postgres.
I w tym przypadku Patroni by nam w żaden sposób nie pomógł, bo Patroni nie ma za zadanie monitorowania stanu serwera, stanu dysku. I musimy monitorować takie sytuacje poprzez monitoring zewnętrzny. Szybko dodaliśmy monitoring dysku do monitoringu zewnętrznego.
I pojawiła się taka myśl - czy oprogramowanie szermiercze lub stróżujące może nam pomóc? Myśleliśmy, że w tym przypadku raczej by nam nie pomógł, ponieważ w czasie problemów Patroni nadal współdziałał z klastrem DCS i nie widział żadnego problemu. Czyli z punktu widzenia DCS i Patroni z klastrem wszystko było w porządku, choć faktycznie były problemy z dyskiem, były problemy z dostępnością bazy.
Moim zdaniem jest to jeden z najdziwniejszych problemów, które badałem przez bardzo długi czas, przeczytałem wiele logów, ponownie wybrałem i nazwałem to symulatorem klastra.
Problem polegał na tym, że stary master nie mógł stać się normalną repliką, tzn. Patroni go uruchomił, Patroni pokazał, że ten węzeł był obecny jako replika, ale jednocześnie nie była to normalna replika. Teraz zobaczysz dlaczego. Tego właśnie ustrzegłem się przed analizą tego problemu.
A jak to się wszystko zaczęło? Zaczęło się, podobnie jak w poprzednim zadaniu, od hamulców tarczowych. Mieliśmy zobowiązania przez sekundę, dwie.
Były przerwy w połączeniach, czyli klienci byli rozdarci.
Były blokady o różnym nasileniu.
W związku z tym podsystem dyskowy nie jest bardzo responsywny.
A najbardziej tajemniczą rzeczą jest dla mnie żądanie natychmiastowego zamknięcia, które przyszło. Postgres ma trzy tryby zamykania:
- Miło jest czekać, aż wszyscy klienci sami się rozłączą.
- Jest szybko, kiedy zmuszamy klientów do rozłączenia, ponieważ zamierzamy zamknąć.
- I natychmiastowe. W tym przypadku natychmiastowe nawet nie każe klientom się zamknąć, po prostu wyłącza się bez ostrzeżenia. A do wszystkich klientów system operacyjny wysyła już komunikat RST (wiadomość TCP, że połączenie zostało przerwane i klient nie ma już nic do złapania).
Kto wysłał ten sygnał? Procesy działające w tle Postgres nie wysyłają do siebie takich sygnałów, czyli jest to kill-9. Nie wysyłają sobie takich rzeczy, tylko reagują na takie rzeczy, czyli jest to awaryjny restart Postgresa. Kto to wysłał, nie wiem.
Spojrzałem na "ostatnią" komendę i zobaczyłem jedną osobę, która również zalogowała się u nas na tym serwerze, ale byłem zbyt nieśmiały, żeby zadać pytanie. Być może było to zabicie -9. Zobaczyłbym kill -9 w dziennikach, ponieważ Postgres mówi, że zajęło to kill -9, ale nie widziałem tego w dziennikach.
Patrząc dalej, zobaczyłem, że Patroni nie zapisywał do logu dość długo - 54 sekundy. A jeśli porównamy dwa znaczniki czasu, nie było żadnych wiadomości przez około 54 sekundy.
I w tym czasie istniał autofile. Patroni znów wykonał tutaj świetną robotę. Nasz stary mistrz był niedostępny, coś mu się stało. I rozpoczęły się wybory nowego pana. Tutaj wszystko dobrze się ułożyło. Nasz pgsql01 został nowym liderem.
Mamy replikę, która stała się mistrzem. I jest druga odpowiedź. A z drugą repliką były problemy. Spróbowała przekonfigurować. Jak rozumiem, próbowała zmienić plik recovery.conf, zrestartować Postgres i połączyć się z nowym masterem. Co 10 sekund pisze wiadomości, które próbuje, ale jej się to nie udaje.
Podczas tych prób do starego urządzenia nadrzędnego dociera sygnał natychmiastowego wyłączenia. Master jest restartowany. A także odzyskiwanie zatrzymuje się, ponieważ stary mistrz uruchamia się ponownie. Oznacza to, że replika nie może się z nią połączyć, ponieważ jest w trybie wyłączenia.
W pewnym momencie zadziałało, ale replikacja się nie rozpoczęła.
Domyślam się tylko, że w pliku recovery.conf znajdował się stary adres główny. A kiedy pojawił się nowy master, druga replika nadal próbowała połączyć się ze starym masterem.
Kiedy Patroni uruchomił się na drugiej replice, węzeł uruchomił się, ale nie mógł się replikować. I powstało opóźnienie replikacji, które wyglądało mniej więcej tak. Oznacza to, że wszystkie trzy węzły były na miejscu, ale drugi węzeł pozostawał w tyle.
Jednocześnie, jeśli spojrzysz na zapisane dzienniki, możesz zobaczyć, że replikacja nie mogła się rozpocząć, ponieważ dzienniki transakcji były inne. A te dzienniki transakcji, które oferuje master, które są określone w recovery.conf, po prostu nie pasują do naszego obecnego węzła.
I tutaj popełniłem błąd. Musiałem przyjść i zobaczyć, co jest w pliku recovery.conf, aby sprawdzić moją hipotezę, że łączymy się z niewłaściwym masterem. Ale wtedy po prostu sobie z tym radziłem i nie przyszło mi to do głowy, albo widziałem, że replika się spóźnia i trzeba będzie ją uzupełnić, czyli jakoś niedbale pracowałem. To był mój joint.
Po 30 minutach admin już przyszedł, czyli zrestartowałem Patroni na replice. Już położyłem temu kres, pomyślałem, że trzeba będzie go uzupełnić. I pomyślałem - zrestartuję Patroni, może coś dobrego się okaże. Rozpoczęło się odzyskiwanie. A baza nawet się otworzyła, była gotowa do przyjmowania połączeń.
Replikacja została uruchomiona. Ale minutę później odpadła z błędem, że logi transakcji nie są dla niej odpowiednie.
Pomyślałem, że ponownie uruchomię. Zrestartowałem ponownie Patroni i nie zrestartowałem Postgres, ale zrestartowałem Patroni w nadziei, że magicznie uruchomi bazę danych.
Replikacja ruszyła ponownie, ale oznaczenia w dzienniku transakcji były inne, nie były takie same jak przy poprzedniej próbie uruchomienia. Replikacja ponownie zatrzymana. A przekaz był już trochę inny. I nie było to dla mnie zbyt pouczające.
I wtedy przychodzi mi do głowy - co jeśli zrestartuję Postgres, w tym czasie zrobię punkt kontrolny na bieżącym wzorcu, aby przesunąć punkt w dzienniku transakcji trochę do przodu, aby odzyskiwanie zaczęło się od innego momentu? Poza tym nadal mieliśmy zapasy WAL.
Zrestartowałem Patroni, zrobiłem kilka punktów kontrolnych na masterze, kilka punktów restartu na replice, kiedy się otworzyła. I to pomogło. Długo myślałem, dlaczego to pomogło i jak działa. I replika ruszyła. A replikacja nie była już rozdarta.
Taki problem jest dla mnie jednym z bardziej tajemniczych, nad którymi ciągle się zastanawiam co tam naprawdę się stało.
Jakie są tutaj implikacje? Patroni może działać zgodnie z przeznaczeniem i bez żadnych błędów. Ale jednocześnie nie jest to 100% gwarancja, że wszystko jest u nas w porządku. Replika może się uruchomić, ale może być w stanie półdziałającym, a aplikacja nie może pracować z taką repliką, bo będą stare dane.
A po filerze zawsze trzeba sprawdzić, czy wszystko jest w porządku z klastrem, to znaczy, że jest wymagana liczba replik, nie ma opóźnienia replikacji.
Gdy przejdziemy przez te problemy, przedstawię zalecenia. Spróbowałem połączyć je w dwa slajdy. Prawdopodobnie wszystkie historie można by połączyć w dwa slajdy i tylko opowiedzieć.
Kiedy korzystasz z Patroni, musisz mieć monitoring. Powinieneś zawsze wiedzieć, kiedy wystąpiło autofileover, ponieważ jeśli nie wiesz, że miałeś autofileover, nie masz kontroli nad klastrem. A to źle.
Po każdym filerze zawsze musimy ręcznie sprawdzić klaster. Musimy mieć pewność, że zawsze mamy aktualną liczbę replik, nie ma lagów replikacyjnych, nie ma błędów w logach związanych z replikacją strumieniową, z Patroni, z systemem DCS.
Automatyzacja może działać z powodzeniem, Patroni to bardzo dobre narzędzie. Może działać, ale to nie doprowadzi klastra do pożądanego stanu. A jeśli się o tym nie dowiemy, będziemy mieli kłopoty.
A Patroni nie jest srebrną kulą. Nadal musimy zrozumieć, jak działa Postgres, jak działa replikacja i jak współpracuje Patroni z Postgresem oraz jak zapewniana jest komunikacja między węzłami. Jest to konieczne, aby móc rozwiązać problemy z rękami.
Jak podejść do kwestii diagnozy? Tak się złożyło, że pracujemy z różnymi klientami i nikt nie ma stosu ELK, a my musimy uporządkować logi otwierając 6 konsol i 2 zakładki. W jednej zakładce są to logi Patroni dla każdego węzła, w drugiej zakładce są to logi Consul lub Postgres jeśli to konieczne. Bardzo trudno jest to zdiagnozować.
Jakie podejścia opracowałem? Po pierwsze, zawsze patrzę, kiedy przybył filolog. A dla mnie to przełom. Patrzę na to, co wydarzyło się przed filer, podczas filer i po filer. Fileover ma dwa znaki: jest to czas rozpoczęcia i zakończenia.
Następnie szukam w logach zdarzeń przed filerem, które poprzedziły filera, czyli szukam przyczyn, dla których filer się wydarzył.
A to daje obraz zrozumienia tego, co się stało i co można zrobić w przyszłości, żeby takie okoliczności nie miały miejsca (a w efekcie nie ma windykatora).
A gdzie zwykle patrzymy? Patrzę:
- Najpierw do dzienników Patroni.
- Następnie przeglądam logi Postgres lub logi DCS, w zależności od tego, co zostało znalezione w logach Patroni.
- A dzienniki systemowe czasami pozwalają zrozumieć, co spowodowało plik filer.
Co myślę o Patronim? Mam bardzo dobre relacje z Patronim. Moim zdaniem to jest najlepsze z dzisiejszych. Znam wiele innych produktów. Są to Stolon, Repmgr, Pg_auto_failover, PAF. 4 narzędzia. Próbowałem ich wszystkich. Patroni jest moim ulubieńcem.
Jeśli zapytają mnie: „Czy polecam Patroni?”. Powiem tak, bo lubię Patroni. I myślę, że nauczyłem się go gotować.
Jeśli chcesz zobaczyć, jakie inne problemy występują z Patroni oprócz problemów, o których wspomniałem, zawsze możesz sprawdzić stronę na GitHubie. Jest tam wiele różnych historii i poruszanych jest wiele ciekawych kwestii. W rezultacie wprowadzono i rozwiązano niektóre błędy, co oznacza, że jest to interesująca lektura.
Istnieje kilka ciekawych historii o ludziach strzelających sobie w stopę. Bardzo informujące. Czytasz i rozumiesz, że nie jest to konieczne. Zaznaczyłem sobie.
I chciałbym bardzo podziękować firmie Zalando za opracowanie tego projektu, a mianowicie Aleksandrowi Kukushkinowi i Alexeyowi Klyukinowi. Aleksey Klyukin jest jednym ze współautorów, już nie pracuje w Zalando, ale to dwie osoby, które zaczęły pracować z tym produktem.
A ja uważam, że Patroni to bardzo fajna rzecz. Cieszę się, że istnieje, jest z nią ciekawie. I wielkie podziękowania dla wszystkich współtwórców, którzy piszą łatki dla Patroni. Mam nadzieję, że Patroni z wiekiem stanie się bardziej dojrzały, fajny i sprawny. Już działa, ale mam nadzieję, że będzie jeszcze lepiej. Dlatego jeśli planujesz korzystać z Patroni, nie bój się. To dobre rozwiązanie, można je wdrożyć i stosować.
To wszystko. Jeśli masz pytania, zapytaj.
pytania
Dzięki za raport! Jeśli po filerze nadal musisz tam bardzo uważnie szukać, to po co nam automatyczny filer?
Bo to nowość. Jesteśmy z nią dopiero rok. Lepiej być bezpiecznym. Chcemy wejść i zobaczyć, że wszystko naprawdę działa tak, jak powinno. To jest poziom nieufności dorosłych - lepiej sprawdzić dwa razy i zobaczyć.
Na przykład poszliśmy rano i patrzyliśmy, prawda?
Nie rano, zwykle o autofile dowiadujemy się niemal od razu. Otrzymujemy powiadomienia, widzimy, że wystąpił autofile. Niemal natychmiast idziemy i patrzymy. Ale wszystkie te kontrole powinny zostać sprowadzone do poziomu monitorowania. Jeśli uzyskujesz dostęp do Patroni przez REST API, istnieje historia. W historii możesz zobaczyć znaczniki czasu, kiedy wystąpił plik. Na tej podstawie można przeprowadzić monitoring. Możesz zobaczyć historię, ile było wydarzeń. Jeśli mamy więcej zdarzeń, wystąpił autofile. Możesz iść i zobaczyć. Albo nasza automatyzacja monitoringu sprawdziła, czy mamy wszystkie repliki na miejscu, nie ma lagów i wszystko jest w porządku.
Dziękuję!
Wielkie dzięki za super historię! Jeśli przenieśliśmy klaster DCS gdzieś daleko od klastra Postgres, to ten klaster też wymaga okresowego serwisowania? Jakie są najlepsze praktyki, że niektóre elementy klastra DCS muszą zostać wyłączone, coś z nimi zrobić itp.? Jak ta cała struktura przetrwa? A jak robisz te rzeczy?
Dla jednej firmy konieczne było wykonanie matrycy problemów, co się stanie, jeśli jeden z komponentów lub kilka komponentów ulegnie awarii. Zgodnie z tą matrycą kolejno przeglądamy wszystkie komponenty i budujemy scenariusze na wypadek awarii tych komponentów. W związku z tym dla każdego scenariusza awarii można opracować plan działania w celu odzyskania sprawności. A w przypadku DCS jest częścią standardowej infrastruktury. Administruje nim administrator, a my już polegamy na administratorach, którzy nim administrują i na ich zdolności do naprawy w razie wypadku. Jeśli w ogóle nie ma DCS, to go wdrażamy, ale jednocześnie specjalnie go nie monitorujemy, bo nie odpowiadamy za infrastrukturę, tylko dajemy rekomendacje, jak i co monitorować.
To znaczy, czy dobrze zrozumiałem, że muszę wyłączyć Patroni, wyłączyć filtr, wyłączyć wszystko, zanim zrobię cokolwiek z hostami?
To zależy od tego, ile mamy węzłów w klastrze DCS. Jeśli węzłów jest wiele i wyłączymy tylko jeden z nich (replikę), wówczas klaster zachowuje kworum. A Patroni nadal działa. I nic się nie uruchamia. Jeśli mamy jakieś złożone operacje, które wpływają na więcej węzłów, których brak może zrujnować kworum, to – tak, może warto wstrzymać Patroni. Ma odpowiednie polecenie - pauza patronictl, wznowienie patronictl. Po prostu robimy pauzę, a autofiler nie działa w tym czasie. Robimy konserwację klastra DCS, następnie zdejmujemy pauzę i żyjemy dalej.
Dziękuję bardzo!
Dziękuję bardzo za zgłoszenie! Co zespół ds. produktu sądzi o utracie danych?
Zespoły produktowe nie przejmują się tym, a liderzy zespołów są zmartwieni.
Jakie są gwarancje?
Gwarancje są bardzo trudne. Alexander Kukushkin ma raport „Jak obliczyć RPO i RTO”, czyli czas odzyskiwania i ile danych możemy stracić. Myślę, że musimy znaleźć te slajdy i je przestudiować. O ile pamiętam, istnieją konkretne kroki, jak obliczyć te rzeczy. Ile transakcji możemy stracić, ile danych możemy stracić. Opcjonalnie możemy zastosować replikację synchroniczną na poziomie Patroni, ale jest to miecz obosieczny: albo mamy niezawodność danych, albo tracimy prędkość. Jest replikacja synchroniczna, ale też nie gwarantuje 100% ochrony przed utratą danych.
Aleksiej, dzięki za wspaniały raport! Jakieś doświadczenia z używaniem Patroni do ochrony na poziomie zerowym? To znaczy w połączeniu z synchronicznym trybem gotowości? To jest pierwsze pytanie. I drugie pytanie. Zastosowałeś różne rozwiązania. Użyliśmy Repmgr, ale bez autofilera, a teraz planujemy włączyć autofiler. I rozważamy Patroni jako rozwiązanie alternatywne. Co możesz powiedzieć o zaletach w porównaniu z Repmgr?
Pierwsze pytanie dotyczyło replik synchronicznych. Nikt tu nie stosuje replikacji synchronicznej, bo wszyscy się boją (kilku klientów już z niej korzysta, w zasadzie nie zauważyli problemów z wydajnością - Notatka prelegenta). Ale opracowaliśmy sobie regułę, że w klastrze replikacji synchronicznej powinny być co najmniej trzy węzły, bo jeśli mamy dwa węzły i w przypadku awarii mastera lub repliki to Patroni przełącza ten węzeł w tryb Standalone, aby aplikacja dalej działała praca. W takim przypadku istnieje ryzyko utraty danych.
Jeśli chodzi o drugie pytanie, korzystaliśmy z Repmgr i nadal korzystamy z niektórych klientów ze względów historycznych. Co można powiedzieć? Patroni jest dostarczany z autofilerem od razu po wyjęciu z pudełka, Repmgr jest dostarczany z autofilerem jako dodatkową funkcją, którą należy włączyć. Musimy uruchomić demona Repmgr na każdym węźle, a następnie możemy skonfigurować autofiler.
Repmgr sprawdza, czy węzły Postgres są aktywne. Procesy Repmgr sprawdzają wzajemne istnienie, nie jest to bardzo wydajne podejście. mogą wystąpić złożone przypadki izolacji sieci, w których duży klaster Repmgr może rozpaść się na kilka mniejszych i kontynuować pracę. Od dłuższego czasu nie śledzę Repmgr, może zostało to naprawione… a może nie. Ale usunięcie informacji o stanie klastra w DCS, jak robi to Stolon, Patroni, jest najbardziej realną opcją.
Alexey, mam pytanie, może głupsze. W jednym z pierwszych przykładów przeniosłeś DCS z komputera lokalnego na zdalny host. Rozumiemy, że sieć to rzecz, która ma swoje własne cechy, żyje własnym życiem. A co się stanie, jeśli z jakiegoś powodu klaster DCS stanie się niedostępny? Powodów nie powiem, może ich być wiele: od krzywych rąk networkerów po realne problemy.
Nie powiedziałem tego na głos, ale klaster DCS też musi być failover, czyli nieparzysta liczba węzłów, żeby kworum zostało spełnione. Co się stanie, jeśli klaster DCS stanie się niedostępny lub nie zostanie osiągnięte kworum, np. jakiś rodzaj podziału sieci lub awaria węzła? W takim przypadku klaster Patroni przechodzi w tryb tylko do odczytu. Klaster Patroni nie może określić stanu klastra ani tego, co należy zrobić. Nie może skontaktować się z DCS i zapisać tam nowego stanu klastra, więc cały klaster przechodzi w tryb tylko do odczytu. I czeka albo na ręczną interwencję operatora, albo na powrót systemu DCS.
Z grubsza mówiąc, DCS staje się dla nas usługą równie ważną jak sama baza?
Tak tak. W tak wielu nowoczesnych firmach Service Discovery jest integralną częścią infrastruktury. Jest wdrażany jeszcze zanim w infrastrukturze pojawiła się baza danych. Relatywnie rzecz biorąc, infrastruktura została uruchomiona, wdrożona w DC i od razu mamy Service Discovery. Jeśli jest to Konsul, można na nim zbudować DNS. Jeśli jest to Etcd, może istnieć część z klastra Kubernetes, w której zostanie wdrożona cała reszta. Wydaje mi się, że Service Discovery jest już integralną częścią nowoczesnych infrastruktur. I myślą o tym dużo wcześniej niż o bazach danych.
Dziękuję!
Źródło: www.habr.com