Увядзенне

Некаторы час таму перада мной паставілі задачу распрацаваць адмоваўстойлівасць кластар для PostgreSQL, Які працуе ў некалькіх дата-цэнтрах, аб'яднаных оптавалакном у рамках аднаго горада, і здольны вытрымаць адмову (напрыклад, абясточванне) аднаго дата-цэнтра. У якасці софту, які адказвае за адмоваўстойлівасць, абраў электракардыёстымулятараў, таму што гэта афіцыйнае рашэнне ад RedHat для стварэння адмоваўстойлівых кластараў. Яно добра тым, што RedHat забяспечвае яго падтрымку, і тым, што гэтае рашэнне ўніверсальнае (модульнае). З яго дапамогай можна будзе забяспечыць адмоваўстойлівасць не толькі PostgreSQL, але і іншых сэрвісаў, або выкарыстоўваючы стандартныя модулі, або ствараючы іх пад канкрэтныя патрэбы.

Да гэтага рашэння паўстала слушнае пытанне: наколькі адмоваўстойлівасцю будзе адмоваўстойлівасцю кластар? Каб гэта даследаваць, я распрацаваў тэставы стэнд, які імітуе розныя адмовы на вузлах кластара, чакае аднаўлення працаздольнасці, аднаўляе які адмовіў вузел і працягвае тэставанне ў цыкле. Першапачаткова гэты праект зваўся hapgsql, але з часам мне надакучыла назоў, у якім толькі адна галосная. Таму адмоваўстойлівыя базы дадзеных (і float IP, на іх якія паказваюць) я стаў называць krogan (персанаж з кампутарнай гульні, у якога ўсе важныя органы дубляваныя), а вузлы, кластары і сам праект - tuchanka (планета, дзе жывуць кроганы).

Цяпер кіраўніцтва дазволіла адкрыць праект для open source-супольнасці пад ліцэнзіяй MIT. README у хуткім часе будзе перакладзены на ангельскую мову (таму што чакаецца, што асноўнымі спажыўцамі будуць распрацоўшчыкі Pacemaker і PostgreSQL), а стары рускі варыянт README я вырашыў аформіць (часткова) у выглядзе гэтага артыкула.

Кластары разгортваюцца на віртуалка VirtualBox. Усяго будзе разгорнута 12 віртуалак (сумарна 36GiB), якія ўтвараюць 4 адмоваўстойлівасць кластара (розныя варыянты). Першыя два кластары складаюцца з двух сервераў PostgreSQL, якія размешчаны ў розных дата-цэнтрах, і агульнага сервера сведка c quorum device (размешчаны на таннай віртуалцы ў трэцім дата-цэнтры), які дазваляе нявызначанасць 50% / 50%, аддаючы свой голас адной з бакоў. Трэці кластар у трох дата-цэнтрах: адзін майстар, два рабы, без quorum device. Чацвёрты кластар складаецца з чатырох сервераў PostgreSQL, па двух на дата-цэнтр: адзін майстар, астатнія рэплікі, і таксама выкарыстоўвае сведка c quorum device. Чацвёрты вытрымлівае адмову двух сервераў ці аднаго дата-цэнтра. Гэтае рашэнне можа быць, пры неабходнасці, маштабавана на большую колькасць рэплік.

Сэрвіс дакладнага часу ntpd таксама пераналаджаны для адмоваўстойлівасці, але там выкарыстоўваюцца метад самога ntpd (orphan mode). Агульны сервер сведка выконвае ролю цэнтральнага NTP-сервера, раздаючы свой час усім кластарам, тым самым сінхранізуючы ўсе серверы паміж сабой. Калі сведка выйдзе са строю або апынецца ізаляваным, тады свой час пачне раздаваць адзін з сервераў кластара (усярэдзіне кластара). Дапаможны які кэшуе HTTP проксі таксама падняты на сведка, з яго дапамогай астатнія віртуалкі маюць доступ да Yum-рэпазітароў. У рэальнасці такія сэрвісы, як дакладны час і проксі, напэўна будуць размешчаны на выдзеленых серверах, а ў стэндзе яны размешчаны на сведка толькі для эканоміі колькасці віртуалак і месцы.

версіі

v0. Працуе з CentOS 7 і PostgreSQL 11 на VirtualBox 6.1.

Структура кластараў

Усе кластары прызначаны для размяшчэння ў некалькіх дата-цэнтрах, аб'яднаны ў адну плоскую сетку і павінны вытрымліваць адмову або сеткавую ізаляцыю аднаго дата-цэнтра. Таму немагчыма выкарыстоўваць для абароны ад split-brain стандартную тэхналогію Pacemaker, якая называецца STONITH (Shoot The Other Node In The Head) або фехтаванне. Яе сутнасць: калі вузлы ў кластары пачынаюць падазраваць, што з нейкім вузлом адбываецца нядобрае, ён не адказвае або некарэктна сябе паводзіць, то яны прымусова яго адключаюць праз "вонкавыя" прылады, напрыклад, кіруючую картку IPMI або UPS. Але такое спрацуе толькі ў выпадках, калі пры адзінкавай адмове сервера IPMI ці UPS працягваюць працаваць. Тут жа плануецца абарона ад значна больш катастрафічнай адмовы, калі адмаўляе (напрыклад абясточваецца) увесь дата-цэнтр. А пры такой адмове ўсё stonith-прылады (IPMI, UPS і г.д.) таксама не будуць працаваць.

Замест гэтага ў аснове сыстэмы ляжыць ідэя кворуму. Усе вузлы маюць голас, і працаваць могуць толькі тыя, якія бачаць больш за палову ўсіх вузлоў. Гэтая колькасць «палова+1» называецца кворум. Калі кворум не набіраецца, то вузел вырашае, што ён знаходзіцца ў сеткавай ізаляцыі і павінен адключыць свае рэсурсы, г.зн. гэта такая абарона ад split-brain. Калі софт, які адказвае за такія паводзіны, не працуе, то павінен будзе спрацаваць watchdog, напрыклад, на базе IPMI.

Калі колькасць вузлоў цотная (кластар у двух дата-цэнтрах), то можа ўзнікнуць так званая нявызначанасць 50% / 50% (фіфці-фіфці), калі сеткавая ізаляцыя дзеліць кластар роўна напалову. Таму для цотнай колькасці вузлоў дадаецца quorum device - непатрабавальны дэман, які можа быць запушчаны на самай таннай віртуалцы ў трэцім дата-цэнтры. Ён дае свой голас аднаму з сегментаў (які бачыць), і тым самым дазваляе нявызначанасць 50% / 50%. Сервер, на якім будзе запушчаны quorum device, я назваў сведка (тэрміналогія з repmgr, мне спадабалася).

Рэсурсы могуць пераязджаць з месца на месца, напрыклад, з няспраўных сервераў на спраўныя, ці па камандзе сісадмінаў. Каб кліенты ведалі, дзе знаходзяцца патрэбныя ім рэсурсы (куды падключацца?), выкарыстоўваюцца плаваюць IP (float IP). Гэта IP, якія Pacemaker можа перамяшчаць па вузлах (усё знаходзіцца ў плоскай сетцы). Кожны з іх сімвалізуе рэсурс (сэрвіс) і будзе знаходзіцца тамака, куды трэба падлучацца, каб атрымаць доступ да гэтага сэрвісу (у нашым выпадку БД).

Tuchanka1 (схема з ушчыльненнем)

Структура

Ідэя была ў тым, што ў нас ёсць шмат дробных баз дадзеных з нізкай нагрузкай, для якіх невыгодна ўтрымоўваць вылучаны slave-сервер у рэжыме hot standby для read only-транзакцый (няма неабходнасці ў такой растраце рэсурсаў).

У кожным дата-цэнтры па адным серверы. На кожным серверы па двух інстансу PostgreSQL (у тэрміналогіі PostgreSQL яны завуцца кластарамі, але ў пазбяганне блытаніны я буду іх зваць інстансамі (па аналогіі з іншымі БД), а кластарамі буду зваць толькі кластары Pacemaker). Адзін інстанс працуе ў рэжыме майстра, і толькі ён аказвае паслугі (толькі на яго вядзе float IP). Другі інстанс працуе рабом для другога дата-цэнтра, і будзе аказваць паслугі толькі калі яго майстар выйдзе са строю. Паколькі большую частку часу аказваць паслугі (выконваць запыты) будзе толькі адзін інстанс з двух (майстар), усе рэсурсы сервера аптымізуюцца на майстар (вылучаецца памяць пад кэш shared_buffers і г.д.), але так, каб на другую інстанс таксама хапіла рэсурсаў ( хай і для неаптымальнай працы праз кэш файлавай сістэмы) на выпадак адмовы аднаго з дата-цэнтраў. Раб не аказвае паслугі (не выконвае read only-запыты) пры нармальнай працы кластара, каб не было вайны за рэсурсы з майстрам на той жа самай машыне.

У выпадку з двума вузламі адмоваўстойлівасць магчымая толькі пры асінхроннай рэплікацыі, бо пры сінхроннай адмова раба прывядзе да прыпынку майстра.

Адмова witness

Адмова witness (quorum device) я разгледжу толькі для кластара Tuchanka1, з усімі астатнімі будзе тая ж гісторыя. Пры адмове witness у структуры кластара нічога не зменіцца, усё працягне працаваць гэтак жа, як і працавала. Але кворум стане роўны 2 з 3, і таму любая наступная адмова стане фатальнай для кластара. Усё роўна давядзецца тэрмінова правіць.

Адмова Tuchanka1

Адмова аднаго з дата-цэнтраў для Tuchanka1. У гэтым выпадку сведка аддае свой голас другому вузлу на другім дата-цэнтры. Там былы раб ператвараецца ў майстры, у выніку на адным серверы працуюць абодва майстры і на іх паказваюць абодва іх float IP.

Tuchanka2 (класічная)

Структура

Класічная схема з двух вузлоў. На адным працуе майстар, на другім раб. Абодва могуць выконваць запыты (раб толькі read only), таму на абодвух паказваюць float IP: krogan2 - на майстар, krogan2s1 - на раба. Адмаўстойлівасць будзе і ў майстра, і ў раба.

У выпадку з двума вузламі адмоваўстойлівасць магчымая толькі пры асінхроннай рэплікацыі, таму што пры сінхроннай адмова раба прывядзе да прыпынку майстра.

Адмова Tuchanka2

Пры адмове аднаго з дата-цэнтраў сведка галасуе за другі. На адзіным які працуе дата-цэнтры будзе падняты майстар, і на яго будуць паказваць абодва float IP: майстэрні і рабскі. Зразумела, інстанс павінен быць наладжаны такім чынам, каб у яго хапіла рэсурсаў (лімітаў пад connection і т.д.) адначасова прымаць усе падлучэнні і запыты ад майстэрні і рабскага float IP. Гэта значыць, пры нармальнай працы ў яго павінен быць дастатковы запас па лімітах.

Tuchanka4 (шмат рабоў)

Структура

Ужо іншая крайнасць. Бываюць БД, на якія ідзе вельмі шмат запытаў read-only (тыповы выпадак высоканагружанага сайта). Tuchanka4 - гэта сітуацыя, калі рабоў можа быць тры ці больш для апрацоўкі такіх запытаў, але ўсё ж не занадта шмат. Пры вельмі вялікай колькасці рабоў трэба будзе вынаходзіць іерархічную сістэму рэплікавання. У мінімальным выпадку (на малюнку) у кожным з двух дата-цэнтраў знаходзіцца па два сервера, на кожным з якіх па інстансе PostgreSQL.

Яшчэ адной асаблівасцю гэтай схемы з'яўляецца тое, што тут ужо можна арганізаваць адну сінхронную рэплікацыю. Яна настроена так, каб рэпліцыраваць, па магчымасці, у іншы дата-цэнтр, а не на рэпліку ў тым жа дата-цэнтры, дзе і майстар. На майстар і на кожны раб паказвае float IP. На добры погляд, паміж рабамі трэба будзе рабіць балансаванне запытаў якім-небудзь. sql proxy, напрыклад, на баку кліента. Рознаму тыпу кліентаў можа патрабавацца розны тып sql proxy, і толькі распрацоўшчыкі кліентаў ведаюць, каму які патрэбен. Гэта функцыянальнасць можа быць рэалізавана як вонкавым дэманам, так і бібліятэкай кліента (connection pool), і г.д. Усё гэта выходзіць за рамкі тэмы адмоваўстойлівага кластара БД (адмоўаўстойлівасць SQL проксі можна будзе рэалізаваць незалежна, разам з адмоваўстойлівасцю кліента).

Адмова Tuchanka4

Пры адмове аднаго дата-цэнтра (г.зн. двух сервераў) witness галасуе за другі. У выніку ў другім дата-цэнтры працуюць два серверы: на адным працуе майстар, і на яго паказвае майстэрскі float IP (для прыёму read-write запытаў); а на другім серверы працуе раб з сінхроннай рэплікацыяй, і на яго паказвае адзін з рабскіх float IP (для read only-запытаў).

Першае, што трэба адзначыць: працоўнымі рабская float IP будуць не ўсе, а толькі адзін. І для карэктнай працы з ім трэба будзе, каб sql proxy перанакіроўваў усе запыты на адзіна пакінуты float IP; а калі sql proxy не, то можна пералічыць усе float IP рабоў праз коску ў URL для падлучэння. У такім выпадку з libpq падлучэнне будзе да першага працоўнага IP, так зроблена ў сістэме аўтаматычнага тэсціравання. Магчыма, у іншых бібліятэках, напрыклад, JDBC, так працаваць не будзе і неабходны sql proxy. Так зроблена таму, што ў float IP для рабоў варта забарона адначасова паднімацца на адным серверы, каб яны раўнамерна размяркоўваліся па рабскіх серверах, калі іх працуе некалькі.

Другое: нават у выпадку адмовы дата-цэнтра будзе захоўвацца сінхронная рэплікацыя. І нават калі адбудзецца другасная адмова, гэта значыць у пакінутым дата-цэнтры выйдзе са строю адзін з двух сервераў, кластар хоць і перастане аказваць паслугі, але ўсё ж захавае інфармацыю аб усіх закаммічаных транзакцыях, на якія ён даў пацвярджэнне аб коміце (не будзе страты інфармацыі пры другаснай адмове).

Tuchanka3 (3 дата-цэнтра)

Структура

Гэта кластар для сітуацыі, калі ёсць тры паўнавартасна якія працуюць дата-цэнтра, у кожным з якіх ёсць паўнавартасна які працуе сервер БД. У гэтым выпадку quorum device не патрэбны. У адным дата-цэнтры працуе майстар, у двух іншых - рабы. Рэплікацыя сінхронная, тыпу ANY (slave1, slave2), гэта значыць кліенту будзе прыходзіць пацверджанне коміта, калі любы з рабоў першым адкажа, што ён прыняў коміт. На рэсурсы паказвае адзін float IP для майстра і два для рабоў. У адрозненне ад Tuchanka4 усе тры float IP адмоваўстойлівыя. Для балансавання read-only SQL-запытаў можна выкарыстоўваць sql proxy (з асобнай адмоваўстойлівасцю), альбо палове кліентаў прызначыць адзін рабскі float IP, а іншы палове – другі.

Адмова Tuchanka3

Пры адмове аднаго з дата-цэнтраў застаюцца два. У адным падняты майстар і float IP ад майстра, у другім - раб і абодва рабскіх float IP (на інстансе павінен быць двухразовы запас па рэсурсах, каб прыняць усе падлучэнні з абодвух рабскіх float IP). Паміж майстроў і рабом сінхронная рэплікацыя. Таксама кластар захавае інфармацыю аб закаммічаных і пацверджаных транзакцыях (не будзе страты інфармацыі) у выпадку знішчэння двух дата-цэнтраў (калі яны знішчаны не адначасова).

Падрабязнае апісанне файлавай структуры і разгортванні я вырашыў не ўстаўляць. Хто захоча пагуляцца, можаце ўсё гэта прачытаць у README. Я прыводжу толькі апісанне аўтаматычнага тэсціравання.

Сістэма аўтаматычнага тэсціравання

Для праверкі адмоваўстойлівасці кластараў з імітацыяй розных няспраўнасцяў зроблена сістэма аўтаматычнага тэсціравання. Запускаецца скрыптам test/failure. Скрыпт можа прымаць у якасці параметраў нумара кластараў, якія жадаецца патэсціраваць. Напрыклад, гэтая каманда:

test/failure 2 3

будзе тэсціраваць толькі другі і трэці кластар. Калі параметры не пазначаны, то тэсціравацца будуць усе кластары. Усе кластары тэстуюцца раўналежна, а вынік выводзіцца ў панэлі tmux. Tmux выкарыстоўвае выдзелены tmux сервер, таму скрыпт можна запускаць з-пад default tmux, атрымаецца ўкладзены tmux. Рэкамендую прымяняць тэрмінал у вялікім акне і з маленькім шрыфтам. Перад пачаткам тэставання ўсе віртуалкі адкочваюцца на снэпшот на момант завяршэння скрыпту. setup.

Тэрмінал разбіты на калонкі па колькасці тэстоўваных кластараў, па змаўчанні (на скрыншоце) іх чатыры. Змесціва калонак я распішу на прыкладзе Tuchanka2. Панэлі на скрыншоце пранумараваны:

1. Тут выводзіцца статыстыка па тэстах. Калонкі:
   • правал - Назва тэсту (функцыі ў скрыпце), які эмулюе няспраўнасць.
   • рэакцыя - сярэдні арыфметычны час у секундах, за які кластар аднавіў сваю працаздольнасць. Замяраецца ад пачатку працы скрыпту, які эмулюе няспраўнасць, і да моманту, калі кластар аднаўляе сваю працаздольнасць і здольны працягваць аказваць паслугі. Калі час вельмі маленькі, напрыклад, шэсць секунд (так бывае ў кластарах з некалькімі рабамі (Tuchanka3 і Tuchanka4)), гэта азначае, што няспраўнасць апынулася на асінхронным рабе і ніяк не паўплывала на працаздольнасць, пераключэння стану кластара не было.
   • адхіленне - паказвае роскід (дакладнасць) значэння рэакцыя метадам "стандартная дэвіяцыя".
   • лічыць - колькі разоў быў выкананы гэты тэст.
2. Кароткі часопіс дазваляе ацаніць, чым займаецца кластар у бягучы момант. Выводзіцца нумар ітэрацыі (тэсту), часовая метка і назва аперацыі. Занадта доўгае выкананне (>5 хвілін) кажа аб нейкай праблеме.
3. сэрца (сэрца) - бягучы час. Для візуальнай ацэнкі працаздольнасці майстры у яго табліцу стала пішацца бягучы час з выкарыстаннем float IP майстра. У выпадку поспеху вынік выводзіцца ў гэтай панэлі.
4. біць (пульс) - «бягучы час», якое раней было запісана скрыптам сэрца у майстар, зараз счытваецца з раба праз яго float IP. Дазваляе візуальна ацаніць працаздольнасць раба і рэплікацыі. У Tuchanka1 няма рабоў з float IP (няма рабоў, якія аказваюць паслугі), але затое там два инстанса (БД), таму тут будзе паказвацца не біць, А сэрца другога інстансу.
5. Маніторынг стану кластара з дапамогай утыліты pcs mon. Паказвае структуру, размеркаванне рэсурсаў па вузлах і іншую карысную інфармацыю.
6. Тут выводзіцца сістэмны маніторынг з кожнай віртуалкі кластара. Такіх панэляў можа быць і больш - колькі віртуалак у кластара. Два графікі Загрузка працэсара (у віртуалках па два працэсары), імя віртуалкі, Загрузка сістэмы (названы як Load Average, таму што ён асераднёны за 5, 10 і 15 хвілін), дадзеныя па працэсах і размеркаванне памяці.
7. Трасіроўка скрыпту, які выконвае тэставанні. У выпадку няспраўнасці - раптоўнага перапынення працы або бясконцага цыклу чакання - тут можна будзе ўбачыць прычыну такіх паводзін.

Тэсціраванне праводзіцца ў два этапы. Спачатку скрыпт праходзіць па ўсіх разнавіднасцях тэстаў, выпадковым чынам выбіраючы віртуалку, да якой гэты тэст прымяніць. Затым выконваецца бясконцы цыкл тэсціравання, віртуалкі і няспраўнасць кожны раз выбіраюцца выпадковым чынам. Раптоўнае завяршэнне скрыпту тэсціравання (ніжняя панэль) або бясконцы цыкл чакання чаго-небудзь (> 5 хвілін час выканання адной аперацыі, гэта відаць у трасіроўцы) кажа аб тым, што нейкі з тэстаў на гэтым кластары праваліўся.

Кожны тэст складаецца з наступных аперацый:

1. Запуск функцыі, якая эмулюе няспраўнасць.
2. Гатовыя? - Чаканне аднаўлення працаздольнасці кластара (калі аказваюцца ўсе паслугі).
3. Паказваецца час чакання аднаўлення кластара (рэакцыя).
4. Фіксаваць - кластар "чыніцца". Пасля чаго ён павінен вярнуцца ў поўнасцю працаздольны стан і гатоўнасці да наступнай няспраўнасці.

Вось спіс тэстаў з апісаннем, што яны робяць:

• ForkBomb: стварае "Out of memory" з дапамогай форк-бомбы.
• OutOfSpace: перапаўняе вінчэстар. Але тэст, хутчэй, сімвалічны, пры той малаважнай нагрузцы, якая ствараецца пры тэставанні, пры перапаўненні вінчэстара адмовы PostgreSQL звычайна не адбываецца.
• Postgres-KILL: забівае PostgreSQL камандай killall -KILL postgres.
• Postgres-STOP: падвешвае PostgreSQL камандай killall -STOP postgres.
• Выключэнне харчавання: «абясточвае» віртуалку камандай VBoxManage controlvm "виртуалка" poweroff.
• Скід: перагружае віртуалку камандай VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: падвешвае дэман SBD камандай killall -STOP sbd.
• Выключэнне: праз SSH пасылае на віртуалку каманду systemctl poweroff, сістэма карэктна завяршае працу.
• UnLink: сеткавая ізаляцыя, каманда VBoxManage controlvm "виртуалка" setlinkstate1 off.

Завяршэнне тэсціраванне або з дапамогай стандартнай камандай tmux "kill-window" Ctrl-b &, альбо камандай "detach-client" Ctrl-b d: пры гэтым тэсціраванне завяршаецца, tmux закрываецца, віртуалкі выключаюцца.

Выяўленыя пры тэсціраванні праблемы

• На бягучы момант watchdog дэман sbd адпрацоўвае спыненне назіраных дэманаў, але не іх завісанне. І, як следства, некарэктна адпрацоўваюцца няспраўнасці, якія прыводзяць да завісання толькі Corosync и электракардыёстымулятараў, але пры гэтым не падвешваюць сбд. Для праверкі Corosync ўжо ёсць PR#83 (у GitHub у сбд), прыняты ў галінку майстар. Абяцалі (у PR#83), што і для Pacemaker будзе нешта падобнае, спадзяюся, што да RedHat 8 зробяць. Але падобныя "няспраўнасці" абстрактныя, лёгка імітуюцца штучна з дапамогай, напрыклад, killall -STOP corosync, Але ніколі не сустракаюцца ў рэальным жыцці.

• У электракардыёстымулятараў у версіі для CentOS 7 няправільна выстаўлены sync_timeout у quorum device, у выніку пры адмове аднаго вузла з некаторай верагоднасцю перазагружаўся і другі вузел, на які павінен быў пераехаць майстар. Вылечылася павелічэннем sync_timeout у quorum device падчас разгортвання (у скрыпце setup/setup1). Гэтая папраўка не была прынята распрацоўшчыкамі электракардыёстымулятараў, замест гэтага яны паабяцалі перапрацаваць інфраструктуру такім чынам (у некаторай нявызначанай будучыні), каб гэты таймаўт вылічаўся аўтаматычна.

• Калі пры канфігураванні базы дадзеных паказана, што ў LC_MESSAGES (тэкставыя паведамленні) можа выкарыстоўвацца Юнікод, напрыклад, ru_RU.UTF-8, то пры запуску Postgres у асяроддзі, дзе locale не UTF-8, дапусцім, у пустым асяроддзі (тут кардыёстымулятар+pgsqlms(paf) запускае Postgres), то у логу замест літар UTF-8 будуць знакі пытання. Распрацоўнікі PostgreSQL так і не дамовіліся, што рабіць у гэтым выпадку. Гэта абыходзіцца, трэба ставіць LC_MESSAGES=en_US.UTF-8 пры канфігураванні (стварэнні) інстансу БД.

• Калі выстаўлены wal_receiver_timeout (па змаўчанні ён 60s), то пры тэсце PostgreSQL-STOP на майстру ў кластарах tuchanka3 і tuchanka4 не адбываецца перападлучэнне рэплікацыі да новага майстра. Рэплікацыя тамака сінхронная, таму спыняецца не толькі раб, але і новы майстар. Абыходзіцца ўсталёўкай wal_receiver_timeout=0 пры наладзе PostgreSQL.

• Зрэдку назіраў падвісанне рэплікацыі ў PostgreSQL у цесцю ForkBomb (перапаўненне памяці). Пасля ForkBomb часам рабы могуць не перападключаць да новага майстра.. Я сустракаў такое толькі ў кластарах tuchanka3 і tuchanka4, дзе з-за таго, што рэплікацыя сінхронная, падвісаў майстар. Праблема праходзіла сама, праз нейкі працяглы час (каля дзвюх гадзін). Патрабуецца дадатковае даследаванне, каб выправіць. Па сімптомах падобна на папярэдні баг, які выклікаецца іншым чыннікам, але з аднолькавымі наступствамі.

Малюнак крогана ўзятая з Deviant Art з дазволу аўтара:

Крыніца: habr.com