Potrzebny jest dodatkowy monitoring pracy failover, a mamy 12 shard\u00f3w PostgreSQL, co oznacza, \u017ce musimy monitorowa\u0107 12 klastr\u00f3w. Przy zwi\u0119kszaniu liczby shard\u00f3w nie mo\u017cemy zapomnie\u0107 o aktualizacji failover.<\/li>\n<\/ul>\nSamodzielne rozwi\u0105zanie failover wydaje si\u0119 skomplikowane i wymaga nietrywialnego wsparcia. W przypadku jednego klastra PostgreSQL b\u0119dzie to najprostsza opcja, ale nie scala si\u0119, wi\u0119c nie b\u0119dzie odpowiednia dla nas.<\/p>\n
Repmgr<\/h3>\n Menad\u017cer replikacji dla klastr\u00f3w PostgreSQL, kt\u00f3ry potrafi zarz\u0105dza\u0107 dzia\u0142aniem klastra PostgreSQL. Nie ma automatycznego failover \u201ez pude\u0142ka\u201d, wi\u0119c aby to dzia\u0142a\u0142o, trzeba napisa\u0107 w\u0142asn\u0105 \u201eowijk\u0119\u201d nad gotowym rozwi\u0105zaniem. Dlatego mo\u017ce by\u0107 to nawet bardziej skomplikowane ni\u017c z samodzielnie napisanymi skryptami, a wi\u0119c Repmgr nawet nie pr\u00f3bowali\u015bmy.<\/p>\n
AWS RDS<\/h3>\n Obs\u0142uguje wszystko, co jest nam potrzebne, potrafi robi\u0107 kopie zapasowe i obs\u0142uguje pul\u0119 po\u0142\u0105cze\u0144. Ma automatyczne prze\u0142\u0105czanie: po \u015bmierci g\u0142\u00f3wnego w\u0119z\u0142a replika staje si\u0119 nowym g\u0142\u00f3wnym, a AWS zmienia rekord DNS na nowego g\u0142\u00f3wnego, przy czym repliki mog\u0105 znajdowa\u0107 si\u0119 w r\u00f3\u017cnych AZ.<\/p>\n
Do minus\u00f3w mo\u017cna zaliczy\u0107 brak drobnych ustawie\u0144. Jako przyk\u0142ad drobnych ustawie\u0144: na naszych instancjach obowi\u0105zuj\u0105 ograniczenia dla po\u0142\u0105cze\u0144 TCP, czego niestety nie mo\u017cna zrobi\u0107 w RDS:<\/p>\n
net.ipv4.tcp_keepalive_time=10\nnet.ipv4.tcp_keepalive_intvl=1\nnet.ipv4.tcp_keepalive_probes=5\nnet.ipv4.tcp_retries2=3\n<\/code><\/pre>\nPonadto cena AWS RDS jest prawie dwa razy dro\u017csza od standardowej ceny instancji, co by\u0142o g\u0142\u00f3wnym powodem rezygnacji z tego rozwi\u0105zania.<\/p>\n
Patroni<\/h3>\n To jest szablon w Pythonie do zarz\u0105dzania PostgreSQL z dobr\u0105 dokumentacj\u0105, automatycznym failover i kodem \u017ar\u00f3d\u0142owym na GitHubie.<\/p>\n
Zalety Patroni:<\/p>\n
\nKa\u017cdy parametr konfiguracji jest dok\u0142adnie opisany, jasno jak to dzia\u0142a;<\/li>\n Automatyczny failover dzia\u0142a z pude\u0142ka;<\/li>\n Napisany w Pythonie, a poniewa\u017c sami du\u017co piszemy w Pythonie, \u0142atwiej b\u0119dzie nam zajmowa\u0107 si\u0119 problemami i by\u0107 mo\u017ce nawet pom\u00f3c w rozwoju projektu;<\/li>\n Ca\u0142kowicie zarz\u0105dza PostgreSQL, pozwala na zmian\u0119 konfiguracji na wszystkich w\u0119z\u0142ach klastra, a je\u015bli nowa konfiguracja wymaga ponownego uruchomienia klastra, mo\u017cna to zrobi\u0107 ponownie za pomoc\u0105 Patroni.<\/li>\n<\/ul>\nWady:<\/p>\n
\nZ dokumentacji nie jest jasne, jak prawid\u0142owo pracowa\u0107 z PgBouncer. Chocia\u017c trudno to nazwa\u0107 wad\u0105, poniewa\u017c zadaniem Patroni jest zarz\u0105dzanie PostgreSQL, a jak b\u0119d\u0105 odbywa\u0107 si\u0119 po\u0142\u0105czenia z Patroni \u2014 to ju\u017c nasz problem;<\/li>\n Ma\u0142o przyk\u0142ad\u00f3w wdro\u017cenia Patroni przy du\u017cych obj\u0119to\u015bciach, przy tym wiele przyk\u0142ad\u00f3w wdro\u017cenia od zera.<\/li>\n<\/ul>\nW rezultacie do stworzenia odpornego na awarie klastra wybrali\u015bmy w\u0142a\u015bnie Patroni.<\/p>\n
Proces wdra\u017cania Patroni<\/h2>\n Przed wprowadzeniem Patroni mieli\u015bmy 12 shard\u00f3w PostgreSQL w konfiguracji z jednym masterem i jedn\u0105 replik\u0105 z asynchroniczn\u0105 replikacj\u0105. Serwery aplikacji \u0142\u0105czy\u0142y si\u0119 z bazami danych poprzez Network Load Balancer, za kt\u00f3rym sta\u0142y dwa instancje z PgBouncer, a za nimi znajdowa\u0142y si\u0119 wszystkie serwery PostgreSQL.
Aby wdro\u017cy\u0107 Patroni, musieli\u015bmy wybra\u0107 rozproszone magazynowanie konfiguracji klastra. Patroni dzia\u0142a z rozproszonymi systemami magazynowania konfiguracji, takimi jak etcd, Zookeeper, Consul. Mamy w\u0142a\u015bnie w produkcji pe\u0142noprawny klaster Consul, kt\u00f3ry wsp\u00f3\u0142pracuje z Vault, a nie u\u017cywamy go w \u017caden inny spos\u00f3b. To doskona\u0142a okazja, aby zacz\u0105\u0107 u\u017cywa\u0107 Consul zgodnie z przeznaczeniem.<\/p>\n
Jak dzia\u0142a Patroni z Consul<\/h3>\n Mamy klaster Consul, kt\u00f3ry sk\u0142ada si\u0119 z trzech w\u0119z\u0142\u00f3w oraz klaster Patroni, kt\u00f3ry sk\u0142ada si\u0119 z lidera i repliki (w Patroni master nazywany jest liderem klastra, a slave'y \u2013 replikami). Ka\u017cda instancja klastra Patroni nieustannie przesy\u0142a do Consul informacje o stanie klastra. Dlatego z Consul mo\u017cna zawsze uzyska\u0107 aktualn\u0105 konfiguracj\u0119 klastra Patroni i to, kto jest obecnie liderem.<\/p>\n
Aby po\u0142\u0105czy\u0107 Patroni z Consul, wystarczy zapozna\u0107 si\u0119 z oficjaln\u0105 dokumentacj\u0105, w kt\u00f3rej napisane jest, \u017ce nale\u017cy wskaza\u0107 host w formacie http lub https, w zale\u017cno\u015bci od tego, jak pracujemy z Consul, oraz opcjonalnie schemat po\u0142\u0105czenia:<\/p>\n
host: host:port dla punktu ko\u0144cowego Consul, w formacie: http(s):\/\/host:port\nscheme: (opcjonalnie) http lub https, domy\u015blnie http<\/code><\/pre>\nWygl\u0105da prosto, ale tutaj zaczynaj\u0105 si\u0119 problemy. Z Consul pracujemy za pomoc\u0105 zabezpieczonego po\u0142\u0105czenia przez https, a nasza konfiguracja po\u0142\u0105czenia b\u0119dzie wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/p>\n
consul:\n host: https:\/\/server.production.consul:8080 \n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nAle to nie dzia\u0142a. Przy uruchamianiu Patroni nie mo\u017ce po\u0142\u0105czy\u0107 si\u0119 z Consul, poniewa\u017c wci\u0105\u017c pr\u00f3buje po\u0142\u0105czy\u0107 si\u0119 za po\u015brednictwem http.<\/p>\n
Zrozumienie problemu u\u0142atwi\u0142 kod \u017ar\u00f3d\u0142owy Patroni. Dobrze, \u017ce jest napisany w Pythonie. Okazuje si\u0119, \u017ce parametr host w \u017caden spos\u00f3b nie jest analizowany, a protok\u00f3\u0142 musi by\u0107 wskazany w schemacie. Oto jak wygl\u0105da dzia\u0142aj\u0105cy blok konfiguracji do pracy z Consul u nas:<\/p>\n
consul:\n host: server.production.consul:8080\n scheme: https\n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nConsul-template<\/h3>\n Wi\u0119c wybrali\u015bmy magazyn konfiguracyjny. Teraz musimy zrozumie\u0107, jak PgBouncer b\u0119dzie prze\u0142\u0105cza\u0142 swoj\u0105 konfiguracj\u0119 w momencie zmiany lidera w klastrze Patroni. W dokumentacji na ten temat nie ma odpowiedzi, poniewa\u017c zasadniczo nie opisano wsp\u00f3\u0142pracy z PgBouncer.<\/p>\n
W poszukiwaniu rozwi\u0105zania znale\u017ali\u015bmy artyku\u0142 (tytu\u0142 niestety nie pami\u0119tam), w kt\u00f3rym napisano, \u017ce Consul-template bardzo pom\u00f3g\u0142 w po\u0142\u0105czeniu PgBouncer i Patroni. To zach\u0119ci\u0142o nas do zbadania dzia\u0142ania Consul-template.<\/p>\n
Okaza\u0142o si\u0119, \u017ce Consul-template nieustannie monitoruje konfiguracj\u0119 klastra PostgreSQL w Consul. W momencie zmiany lidera aktualizuje konfiguracj\u0119 PgBouncer i wysy\u0142a polecenie do jej prze\u0142adowania.<\/p>\n
Wielk\u0105 zalet\u0105 template jest to, \u017ce jest przechowywany w postaci kodu, dzi\u0119ki czemu w przypadku dodania nowego shardu wystarczy wykona\u0107 nowy commit i zaktualizowa\u0107 template w trybie automatycznym, zachowuj\u0105c zasady Infrastructure as code.<\/p>\n
Nowa architektura z Patroni<\/h3>\n W rezultacie uzyskali\u015bmy tak\u0105 schem\u0119 pracy:
Wszystkie serwery aplikacji kieruj\u0105 zapytania do balancera \u2192 za nim stoj\u0105 dwa instancje PgBouncer \u2192 na ka\u017cdej instancji dzia\u0142a Consul-template, kt\u00f3ry monitoruje stan ka\u017cdego klastra Patroni i dba o aktualno\u015b\u0107 konfiguracji PgBouncer, kt\u00f3ry kieruje zapytania do aktualnego lidera ka\u017cdego klastra.<\/p>\n
R\u0119czne testowanie<\/h3>\n Przed wdro\u017ceniem na produkcj\u0119 uruchomili\u015bmy t\u0119 schem\u0119 w ma\u0142ym \u015brodowisku testowym i sprawdzili\u015bmy dzia\u0142anie automatycznego prze\u0142\u0105czania. Otwierali\u015bmy tablic\u0119, przesuwali\u015bmy naklejk\u0119 i w tym momencie \u201ezabijali\u015bmy\u201d lidera klastra. W AWS wystarczy wy\u0142\u0105czy\u0107 instancj\u0119 przez konsol\u0119.<\/p>\n
Naklejka wraca\u0142a w ci\u0105gu 10-20 sekund, a nast\u0119pnie zaczyna\u0142a ponownie normalnie si\u0119 przesuwa\u0107. Oznacza to, \u017ce klaster Patroni zadzia\u0142a\u0142 prawid\u0142owo: zmieni\u0142 lidera, przekaza\u0142 informacje do Consul, a Consul-template natychmiast przej\u0105\u0142 te informacje, zaktualizowa\u0142 konfiguracj\u0119 PgBouncer i wys\u0142a\u0142 polecenie do prze\u0142adowania.<\/p>\n
Jak przetrwa\u0107 przy wysokim obci\u0105\u017ceniu i zachowa\u0107 minimalny czas przestoju?<\/h2>\n Wszystko dzia\u0142a \u015bwietnie! Ale pojawiaj\u0105 si\u0119 nowe pytania: Jak to zadzia\u0142a przy wysokim obci\u0105\u017ceniu? Jak szybko i bezpiecznie wdro\u017cy\u0107 wszystko na produkcj\u0119?<\/p>\n
Odpowied\u017a na pierwsze pytanie daje nam \u015brodowisko testowe, w kt\u00f3rym przeprowadzamy testy obci\u0105\u017ceniowe. Jest ono ca\u0142kowicie identyczne z produkcyjnym pod wzgl\u0119dem architektury i ma wygenerowane dane testowe, kt\u00f3rych obj\u0119to\u015b\u0107 jest mniej wi\u0119cej r\u00f3wna obj\u0119to\u015bci danych produkcyjnych. Postanawiamy po prostu \"zabi\u0107\" jednego z master\u00f3w PostgreSQL podczas testu i zobaczy\u0107, co si\u0119 stanie. Ale przed tym wa\u017cne jest, aby sprawdzi\u0107 automatyczne wypuszczanie, poniewa\u017c w tym \u015brodowisku mamy kilka shard\u00f3w PostgreSQL, wi\u0119c zyskamy doskona\u0142e testowanie skrypt\u00f3w konfiguracyjnych przed produkcj\u0105.<\/p>\n
Oba zadania wydaj\u0105 si\u0119 ambitne, ale mamy PostgreSQL 9.6. Mo\u017ce od razu zaktualizujemy do 11.2?<\/p>\n
Zdecydowali\u015bmy si\u0119 to zrobi\u0107 w dw\u00f3ch etapach: najpierw zaktualizowa\u0107 wersj\u0119 do 11.2, a potem uruchomi\u0107 Patroni.<\/p>\n
Aktualizacja PostgreSQL<\/h3>\n Aby szybko zaktualizowa\u0107 wersj\u0119 PostgreSQL, nale\u017cy u\u017cy\u0107 opcji -k<\/b>, w kt\u00f3rej tworzone s\u0105 twarde linki na dysku i nie ma potrzeby kopiowania Twoich danych. Na bazach o wielko\u015bci 300-400 GB aktualizacja zajmuje 1 sekund\u0119.<\/p>\n
Mamy wiele shard\u00f3w, dlatego aktualizacja musi by\u0107 przeprowadzona automatycznie. W tym celu napisali\u015bmy playbook Ansible, kt\u00f3ry wykonuje ca\u0142y proces aktualizacji za nas:<\/p>\n
\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n<b>--link <\/b>\n--old-datadir='' --new-datadir='' \n --old-bindir='' --new-bindir='' \n --old-options=' -c config_file=' \n --new-options=' -c config_file='<\/code><\/pre>\nWa\u017cne jest, aby przed rozpocz\u0119ciem aktualizacji wykona\u0107 j\u0105 z parametrem \u2014sprawd\u017a<\/b>, aby upewni\u0107 si\u0119 w mo\u017cliwo\u015bciach aktualizacji. Nasz skrypt r\u00f3wnie\u017c dokonuje wymiany plik\u00f3w konfiguracyjnych na czas aktualizacji. Skrypt zako\u0144czy\u0142 si\u0119 po 30 sekundach, co jest doskona\u0142ym wynikiem.<\/p>\nUruchomienie Patroni<\/h3>\n
Aby rozwi\u0105za\u0107 drugi problem, wystarczy spojrze\u0107 na konfiguracj\u0119 Patroni. W oficjalnym repozytorium znajduje si\u0119 przyk\u0142ad konfiguracji z initdb, kt\u00f3ry odpowiada za inicjalizacj\u0119 nowej bazy podczas pierwszego uruchomienia Patroni. Ale poniewa\u017c mamy ju\u017c gotow\u0105 baz\u0119, po prostu usun\u0119li\u015bmy ten segment z konfiguracji.<\/p>\n
Kiedy zacz\u0119li\u015bmy instalowa\u0107 Patroni na gotowym klastrze PostgreSQL i uruchamia\u0107 go, napotkali\u015bmy nowy problem: oba serwery uruchamia\u0142y si\u0119 jako liderzy. Patroni nic nie wie o wczesnym stanie klastra i pr\u00f3buje uruchomi\u0107 oba serwery jako dwa osobne klastry o tej samej nazwie. Aby rozwi\u0105za\u0107 ten problem, nale\u017cy usun\u0105\u0107 katalog danych na slave:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nNale\u017cy to zrobi\u0107 tylko na slave!<\/b><\/p>\n
Podczas pod\u0142\u0105czania czystej repliki, Patroni wykonuje kopi\u0119 zapasow\u0105 bazy lidera i przywraca j\u0105 na replik\u0119, a nast\u0119pnie synchronizuje aktualny stan na podstawie log\u00f3w wal.<\/p>\n
Kolejnym wyzwaniem, z kt\u00f3rym si\u0119 zmierzyli\u015bmy, jest to, \u017ce wszystkie klastry PostgreSQL domy\u015blnie nazywaj\u0105 si\u0119 main. Kiedy ka\u017cdy klaster nic nie wie o innym \u2014 to w porz\u0105dku. Ale gdy chcesz u\u017cywa\u0107 Patroni, wszystkie klastry musz\u0105 mie\u0107 unikaln\u0105 nazw\u0119. Rozwi\u0105zaniem jest zmiana nazwy klastra w konfiguracji PostgreSQL.<\/p>\n
Test obci\u0105\u017ceniowy<\/h3>\n Przeprowadzili\u015bmy test, kt\u00f3ry imituje prac\u0119 u\u017cytkownik\u00f3w na tablicach. Gdy obci\u0105\u017cenie osi\u0105gn\u0119\u0142o nasz\u0105 \u015bredni\u0105 dzienn\u0105 warto\u015b\u0107, powt\u00f3rzyli\u015bmy dok\u0142adnie ten sam test, wy\u0142\u0105czaj\u0105c jedn\u0105 instancj\u0119 z liderem PostgreSQL. Automatyczny failover zadzia\u0142a\u0142 zgodnie z naszymi oczekiwaniami: Patroni zmieni\u0142 lidera, Consul-template zaktualizowa\u0142 konfiguracj\u0119 PgBouncer i wys\u0142a\u0142 polecenie do reload. Na naszych wykresach w Grafanie by\u0142o wida\u0107 op\u00f3\u017anienia trwaj\u0105ce od 20 do 30 sekund oraz niewielk\u0105 liczb\u0119 b\u0142\u0119d\u00f3w zwi\u0105zanych z po\u0142\u0105czeniem z baz\u0105. To normalna sytuacja, takie warto\u015bci s\u0105 dopuszczalne dla naszego failover i s\u0105 zdecydowanie lepsze ni\u017c przestoje serwisu.<\/p>\n
Wdro\u017cenie Patroni w produkcji<\/h2>\n Ostatecznie otrzymali\u015bmy nast\u0119puj\u0105cy plan:<\/p>\n
\nWdro\u017cenie Consul-template na serwery PgBouncer i uruchomienie;<\/li>\n Aktualizacja PostgreSQL do wersji 11.2;<\/li>\n Zmiana nazwy klastra;<\/li>\n Uruchomienie klastra Patroni.<\/li>\n<\/ul>\nNasza schemat pozwala na realizacj\u0119 pierwszego punktu praktycznie w dowolnym momencie, mo\u017cemy kolejno wy\u0142\u0105cza\u0107 ka\u017cdy PgBouncer z pracy i przeprowadza\u0107 na nim wdro\u017cenie oraz uruchomienie consul-template. Tak w\u0142a\u015bnie zrobili\u015bmy.<\/p>\n
Do szybkiego wdro\u017cenia u\u017cyli\u015bmy Ansible, poniewa\u017c wszystkie playbooki przetestowali\u015bmy ju\u017c w \u015brodowisku testowym, a czas wykonania pe\u0142nego scenariusza wynosi\u0142 od 1,5 do 2 minut dla ka\u017cdego shardu. Mogli\u015bmy wprowadza\u0107 zmiany po kolei na ka\u017cdym sharde bez zatrzymywania naszego serwisu, ale musieliby\u015bmy na kilka minut wy\u0142\u0105czy\u0107 ka\u017cdy PostgreSQL. W takiej sytuacji u\u017cytkownicy, kt\u00f3rzy maj\u0105 dane na tym shardzie, nie mogliby normalnie pracowa\u0107 w tym czasie, co jest dla nas nieakceptowalne.<\/p>\n
Wyj\u015bciem z tej sytuacji by\u0142 planowy maintenance, kt\u00f3ry odbywa si\u0119 co 3 miesi\u0105ce. To okno na prace konserwacyjne, kiedy ca\u0142kowicie wy\u0142\u0105czamy nasz serwis i aktualizujemy instancje baz danych. Do kolejnego okna pozosta\u0142 tydzie\u0144, postanowili\u015bmy wi\u0119c po prostu poczeka\u0107 i dodatkowo si\u0119 przygotowa\u0107. W czasie oczekiwania dodatkowo si\u0119 zabezpieczyli\u015bmy: dla ka\u017cdego shardu PostgreSQL uruchomili\u015bmy zapasow\u0105 replik\u0119 na wypadek awarii, aby zachowa\u0107 najnowsze dane, oraz dodali\u015bmy now\u0105 instancj\u0119 dla ka\u017cdego shardu, kt\u00f3ra ma sta\u0107 si\u0119 now\u0105 replik\u0105 w klastrze Patroni, aby nie wykonywa\u0107 polecenia do usuni\u0119cia danych. Wszystko to pomog\u0142o maksymalnie zredukowa\u0107 ryzyko b\u0142\u0119du.
Uruchomili\u015bmy nasz serwis ponownie, wszystko dzia\u0142a\u0142o jak nale\u017cy, u\u017cytkownicy kontynuowali prac\u0119, ale na wykresach zauwa\u017cyli\u015bmy nienaturalnie wysokie obci\u0105\u017cenie serwer\u00f3w Consul.
Dlaczego nie zauwa\u017cyli\u015bmy tego w \u015brodowisku testowym? Problem ten doskonale ilustruje, \u017ce nale\u017cy przestrzega\u0107 zasady Infrastructure as code i rozwija\u0107 ca\u0142\u0105 infrastruktur\u0119, zaczynaj\u0105c od \u015brodowisk testowych, a ko\u0144cz\u0105c na produkcji. W przeciwnym razie bardzo \u0142atwo napotka\u0107 taki problem, jaki mieli\u015bmy. Co si\u0119 sta\u0142o? Consul najpierw pojawi\u0142 si\u0119 w produkcji, a potem w \u015brodowiskach testowych, w rezultacie w \u015brodowiskach testowych wersja Consul by\u0142a wy\u017csza ni\u017c w produkcji. W\u0142a\u015bnie w jednej z wersji rozwi\u0105zano wyciek CPU podczas pracy z consul-template. Dlatego po prostu zaktualizowali\u015bmy Consul, w ten spos\u00f3b rozwi\u0105zuj\u0105c problem.<\/p>\n
Restartuj klaster Patroni<\/h3>\n Jednak napotkali\u015bmy nowy problem, o kt\u00f3rym nawet nie mieli\u015bmy poj\u0119cia. Podczas aktualizacji Consul po prostu usuwamy w\u0119ze\u0142 Consul z klastra za pomoc\u0105 polecenia consul leave \u2192 Patroni \u0142\u0105czy si\u0119 z innym serwerem Consul \u2192 wszystko dzia\u0142a. Ale kiedy dotarli\u015bmy do ostatniej instancji klastra Consul i wys\u0142ali\u015bmy mu polecenie consul leave, wszystkie klastry Patroni po prostu si\u0119 zrestartowa\u0142y, a w logach zobaczyli\u015bmy nast\u0119puj\u0105cy b\u0142\u0105d:<\/p>\n
B\u0141\u0104D: get_cluster\n\u015alad stosu (ostatnie wywo\u0142anie ostatnie):\n...\nRetryFailedError: 'Przekroczono termin ponownego próby'\nB\u0141\u0104D: B\u0142\u0105d w komunikacji z DCS\n<b>LOG: system bazy danych zosta\u0142 zamkni\u0119ty<\/b><\/code><\/pre>\nKlaster Patroni nie m\u00f3g\u0142 uzyska\u0107 informacji o swoim klastrze i zrestartowa\u0142 si\u0119.<\/p>\n
Aby znale\u017a\u0107 rozwi\u0105zanie, skontaktowali\u015bmy si\u0119 z autorami Patroni poprzez zg\u0142oszenie na Githubie. Zaproponowali poprawki naszych plik\u00f3w konfiguracyjnych:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nUda\u0142o nam si\u0119 powt\u00f3rzy\u0107 problem w \u015brodowisku testowym i przetestowa\u0107 te parametry, ale niestety nie zadzia\u0142a\u0142y.<\/p>\n
Problem nadal nie jest rozwi\u0105zany. Planujemy spr\u00f3bowa\u0107 nast\u0119puj\u0105cych opcji rozwi\u0105zania:<\/p>\n
\nU\u017cy\u0107 agenta Consul na ka\u017cdym instancie klastra Patroni;<\/li>\n Naprawi\u0107 problem w kodzie.<\/li>\n<\/ul>\nRozumiemy miejsce wyst\u0105pienia b\u0142\u0119du: prawdopodobnie problem le\u017cy w u\u017cyciu domy\u015blnego timeoutu, kt\u00f3ry nie jest nadpisywany przez plik konfiguracyjny. Po usuni\u0119ciu ostatniego serwera Consul z klastra, ca\u0142y klaster Consul zawiesza si\u0119 na d\u0142u\u017cej ni\u017c sekund\u0119, przez co Patroni nie mo\u017ce uzyska\u0107 stanu klastra i ca\u0142kowicie restartuje ca\u0142y klaster.<\/p>\n
Na szcz\u0119\u015bcie nie napotkali\u015bmy wi\u0119cej \u017cadnych b\u0142\u0119d\u00f3w.<\/p>\n
Podsumowanie u\u017cycia Patroni<\/h2>\n Po pomy\u015blnym uruchomieniu Patroni dodali\u015bmy dodatkow\u0105 replik\u0119 w ka\u017cdym klastrze. Teraz w ka\u017cdym klastrze wyst\u0119puje co\u015b w rodzaju kworum: jeden lider i dwie repliki, dla zabezpieczenia na wypadek split-brain podczas prze\u0142\u0105czania.
Na produkcji Patroni dzia\u0142a od ponad trzech miesi\u0119cy. W tym czasie zd\u0105\u017cy\u0142 nam pom\u00f3c. Niedawno w AWS lider jednego z klastr\u00f3w przesta\u0142 dzia\u0142a\u0107, automatyczny failover zadzia\u0142a\u0142 i u\u017cytkownicy mogli kontynuowa\u0107 prac\u0119. Patroni wykona\u0142 swoje g\u0142\u00f3wne zadanie.<\/p>\n
Ma\u0142e podsumowanie u\u017cycia Patroni:<\/b><\/p>\n\nWygoda zmiany konfiguracji. Wystarczy zmieni\u0107 konfiguracj\u0119 na jednym instancie, a ona zostanie przekazana na ca\u0142y klaster. Je\u015bli do zastosowania nowej konfiguracji potrzebny jest restart, Patroni o tym poinformuje. Patroni mo\u017ce zrestartowa\u0107 ca\u0142y klaster za pomoc\u0105 jednej komendy, co r\u00f3wnie\u017c jest bardzo wygodne.<\/li>\n Automatyczny failover dzia\u0142a i ju\u017c zd\u0105\u017cy\u0142 nam pom\u00f3c.<\/li>\n Aktualizacja PostgreSQL bez przestoj\u00f3w w aplikacji. Najpierw nale\u017cy zaktualizowa\u0107 repliki do nowej wersji, nast\u0119pnie zmieni\u0107 lidera w klastrze Patroni i zaktualizowa\u0107 starego lidera. Przy tym przeprowadzane s\u0105 niezb\u0119dne testy automatycznego failover.<\/li>\n<\/ul>\n\u0179r\u00f3d\u0142o: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c. \u0423 \u043d\u0430\u0441 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441: 2,5 \u043c\u043b\u043d \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, 50\u041a+ \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u0436\u0434\u044b\u0439 \u0434\u0435\u043d\u044c. \u0421\u0435\u0440\u0432\u0435\u0440\u0430 \u043d\u0430\u0445\u043e\u0434\u044f\u0442\u0441\u044f \u0432 Amazone \u0432 \u043e\u0434\u043d\u043e\u043c \u0440\u0435\u0433\u0438\u043e\u043d\u0435 \u0418\u0440\u043b\u0430\u043d\u0434\u0438\u0438: \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e 100+ \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432, \u0438\u0437 \u043d\u0438\u0445 \u043f\u043e\u0447\u0442\u0438 50 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26749,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"Odporna](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n