Приказни за неуспех на Patroni или како да го срушите вашиот кластер PostgreSQL. Алексеј Лесовски

Главната цел на Patroni е да обезбеди висока достапност за PostgreSQL. Но, Патрони е само шаблон, а не готова алатка (што, генерално, е кажано во документацијата). На прв поглед, откако го поставивме Patroni во лабораторијата за тестирање, можете да видите каква одлична алатка е тоа и колку лесно се справува со нашите обиди да го разбиеме кластерот. Меѓутоа, во пракса, во производствена средина, сè не се случува секогаш толку убаво и елегантно како во тест лабораторија.

Ќе ви кажам малку за себе. Почнав како системски администратор. Работел во развој на веб. Работам во Data Egret од 2014 година. Компанијата се занимава со консалтинг во областа на Postgres. И ние опслужуваме токму Postgres, и работиме со Postgres секој ден, така што имаме различна експертиза поврзана со операцијата.

И на крајот на 2018 година почнавме полека да го користиме Patroni. И акумулирано е одредено искуство. Некако го дијагностициравме, го штимавме, дојдовме до нашите најдобри практики. И во овој извештај ќе зборувам за нив.

Освен Postgres, го сакам Linux. Сакам да ѕиркам во него и да истражувам, сакам да собирам јадра. Сакам виртуелизација, контејнери, докер, Кубернет. Сето ова ме интересира, бидејќи старите администраторски навики влијаат. Сакам да се занимавам со мониторинг. И јас сакам постгрес работи поврзани со администрација, т.е. репликација, резервна копија. И во слободно време пишувам во Го. Јас не сум софтверски инженер, само пишувам за себе во Go. И тоа ми причинува задоволство.

• Мислам дека многумина од вас знаат дека Postgres нема HA (висока достапност) надвор од кутијата. За да добиете HA, треба да инсталирате нешто, да го конфигурирате, да се потрудите и да го добиете.
• Има неколку алатки и Патрони е една од нив што ја решава HA прилично кул и многу добро. Но, со ставање на сето тоа во тест лабораторија и водење, можеме да видиме дека сето тоа функционира, можеме да репродуцираме некои проблеми, да видиме како Патрони им служи. И ќе видиме дека сето тоа функционира одлично.
• Но, во пракса, се соочивме со различни проблеми. И јас ќе зборувам за овие проблеми.
• Ќе ви кажам како го дијагностициравме, што сменивме - дали ни помогна или не.

• Нема да ви кажам како да го инсталирате Patroni, бидејќи можете да гуглате на Интернет, можете да ги погледнете датотеките за конфигурација за да разберете како започнува сè, како е конфигурирано. Можете да ги разберете шемите, архитектурите, да најдете информации за тоа на Интернет.
• Нема да зборувам за туѓо искуство. Ќе зборувам само за проблемите со кои се соочивме.
• И нема да зборувам за проблеми кои се надвор од Patroni и PostgreSQL. Ако, на пример, има проблеми поврзани со балансирањето, кога нашиот кластер се распаднал, нема да зборувам за тоа.

И мало оградување пред да започнеме со нашиот извештај.

Сите овие проблеми со кои наидовме, ги имавме во првите 6-7-8 месеци од работењето. Со текот на времето, дојдовме до нашите внатрешни најдобри практики. И нашите проблеми исчезнаа. Затоа, извештајот беше објавен пред околу шест месеци, кога сето тоа ми беше свежо во главата и совршено се сеќавав на сето тоа.

Во текот на подготовката на извештајот, јас веќе подигнав стари посмртници, ги погледнав трупците. И некои од деталите би можеле да се заборават, или некои од некои детали не би можеле целосно да се истражат при анализата на проблемите, па во некои моменти може да изгледа дека проблемите не се целосно разгледани или има недостиг од информации. И затоа ве замолувам да ме извините за овој момент.

Што е Патрони?

• Ова е шаблон за градење HA. Така пишува во документацијата. И од моја гледна точка, ова е многу правилно појаснување. Патрони не е сребрен куршум што ќе ви ги реши сите проблеми, односно треба да се потрудите да функционира и да донесе корист.
• Ова е сервис за агент кој е инсталиран на секоја база на податоци и е еден вид иницијален систем за вашиот Postgres. Го стартува Postgres, запира, рестартира, реконфигурира и ја менува топологијата на вашиот кластер.
• Соодветно на тоа, за да се зачува состојбата на кластерот, неговата моментална претстава, како што изгледа, потребен е некој вид складирање. И од оваа гледна точка, Патрони тргна по патот на складирање на државата во надворешен систем. Тоа е систем за складирање на дистрибуирана конфигурација. Може да биде Etcd, Consul, ZooKeeper или kubernetes Etcd, т.е. една од овие опции.
• А една од карактеристиките на Patroni е тоа што го вадите автофилерот од кутијата, само со негово поставување. Ако го земеме Repmgr за споредба, тогаш фајлерот е вклучен таму. Со Repmgr добиваме префрлување, но ако сакаме автофилер, тогаш треба дополнително да го конфигурираме. Патрони веќе има автоматско пополнување надвор од кутијата.
• И има многу други работи. На пример, одржување на конфигурации, истурање нови реплики, резервна копија итн. Но, ова е надвор од опсегот на извештајот, нема да зборувам за тоа.

И мал резултат е тоа што главната задача на Patroni е добро и сигурно да направи авто-датотека за нашиот кластер да остане оперативен и апликацијата да не забележува промени во топологијата на кластерот.

Но, кога ќе почнеме да го користиме Patroni, нашиот систем станува малку покомплициран. Ако порано имавме Postgres, тогаш кога користиме Patroni го добиваме самиот Patroni, добиваме DCS каде што е зачувана состојбата. И сето тоа мора некако да функционира. Значи, што може да тргне наопаку?

Може да се скрши:

• Постгресот може да се скрши. Може да биде мајстор или реплика, еден од нив може да пропадне.
• Самиот патрони може да се скрши.
• DCS каде што е зачувана состојбата може да се скрши.
• И мрежата може да се скрши.

Сите овие точки ќе ги разгледам во извештајот.

Случаите ќе ги разгледувам како што стануваат посложени, а не од гледна точка дека случајот вклучува многу компоненти. И од гледна точка на субјективни чувства, дека овој случај ми беше тежок, беше тешко да го расклопам ... и обратно, некој случај беше лесен и лесно беше да се расклопи.

А првиот случај е најлесниот. Ова е случај кога земавме кластер на база на податоци и го распоредивме нашето складирање DCS на истиот кластер. Ова е најчестата грешка. Ова е грешка во градењето архитектури, т.е. комбинирање на различни компоненти на едно место.

Значи, имаше датотека, ајде да се справиме со тоа што се случи.

И овде нè интересира кога се случил филерот. Односно, ние сме заинтересирани за овој момент во времето кога се промени состојбата на кластерот.

Но, датотеката не е секогаш моментална, т.е. не одзема единица време, може да се одложи. Може да биде долготраен.

Затоа, има време на почеток и време на завршување, односно е континуиран настан. И ние ги делиме сите настани во три интервали: имаме време пред датотеката, за време на датотеката и по датотеката. Односно, ги разгледуваме сите настани во оваа временска рамка.

И првото нешто, кога се случил датотеката, ја бараме причината за тоа што се случило, која била причината за она што довело до подигнувачот.

Ако ги погледнеме трупците, тие ќе бидат класични трупци Патрони. Тој ни кажува во нив дека серверот станал господар, а улогата на господарот преминала на овој јазол. Тука е истакнато.

Следно, треба да разбереме зошто се случи датотеката, т.е. какви настани се случија што предизвикаа главната улога да се пресели од еден јазол во друг. И во овој случај, сè е едноставно. Имаме грешка во интеракцијата со системот за складирање. Мајсторот сфатил дека не може да работи со DCS, односно има некаков проблем со интеракцијата. И вели дека повеќе не може да биде мајстор и дава оставка. Овој ред „деградиран себе“ го кажува токму тоа.

Ако ги погледнеме настаните што му претходеа на датотеката, таму ќе ги видиме токму причините што беа проблем за продолжување на волшебникот.

Ако ги погледнеме Patroni логовите, ќе видиме дека имаме многу грешки, тајмаути, односно агентот Patroni не може да работи со DCS. Во овој случај, ова е агент на конзулот, кој комуницира на пристаништето 8500.

И проблемот овде е што Patroni и базата работат на истиот хост. И серверите конзул беа лансирани на истиот јазол. Со креирање на оптоварување на серверот, направивме проблеми и за серверите на Конзулот. Тие не можеа да комуницираат правилно.

По некое време, кога товарот се смири, нашиот Патрони повторно можеше да комуницира со агентите. Нормалната работа продолжи. И истиот Pgdb-2 сервер повторно стана господар. Тоа е, имаше мал преврт, поради што јазолот ги отстапи овластувањата на господарот, а потоа ги презеде повторно, односно сè се врати како што беше.

И ова може да се смета за лажна тревога, или може да се смета дека Патрони направил сè како што треба. Односно, сфатил дека не може да ја одржи состојбата на кластерот и го отстранил авторитетот.

И тука проблемот настана поради фактот што серверите на Consul се на истиот хардвер како и базите. Соодветно на тоа, секое оптоварување: без разлика дали е оптоварување на дискови или процесори, тоа исто така влијае на интеракцијата со кластерот конзул.

И решивме да не живее заедно, одвоивме посебен кластер за конзул. А Патрони веќе работеше со посебен Конзул, односно имаше посебен кластер Postgres, посебен конзул кластер. Ова е основна инструкција како да ги носите и чувате сите овие работи за да не живее заедно.

Како опција, можете да ги извртите параметрите ttl, loop_wait, retry_timeout, т.е. да се обидете да ги преживеете овие краткорочни врвови на оптоварување со зголемување на овие параметри. Но, ова не е најсоодветната опција, бидејќи ова оптоварување може да биде долго време. И ние едноставно ќе ги надминеме овие граници на овие параметри. И тоа можеби навистина нема да помогне.

Првиот проблем, како што разбирате, е едноставен. Зедовме и го ставивме DCS заедно со основата, добивме проблем.

Вториот проблем е сличен на првиот. Слично е по тоа што повторно имаме проблеми со интероперабилноста со системот DCS.

Ако ги погледнеме дневниците, ќе видиме дека повторно имаме грешка во комуникацијата. И Патрони вели дека не можам да комуницирам со DCS, така што сегашниот господар оди во режим на реплика.

Стариот мајстор станува реплика, овде Патрони работи, како што треба. Работи pg_rewind за да го премотува дневникот на трансакции наназад и потоа да се поврзе со новиот господар за да го достигне новиот господар. Тука Патрони работи како што треба.

Овде мора да го најдеме местото што му претходело на датотеката, односно оние грешки што предизвикале да имаме датотека. И во овој поглед, Patroni логовите се доста погодни за работа. Тој ги пишува истите пораки во одреден интервал. И ако почнеме брзо да се движиме низ овие дневници, тогаш од дневниците ќе видиме дека дневниците се смениле, што значи дека некои проблеми започнале. Брзо се враќаме на ова место, видете што ќе се случи.

И во нормална ситуација, трупците изгледаат вака. Се проверува сопственикот на бравата. И ако сопственикот, на пример, се променил, тогаш може да се појават некои настани на кои Патрони мора да одговори. Но, во овој случај, ние сме добро. Го бараме местото каде што започнаа грешките.

И откако скролувавме до точката каде што почнаа да се појавуваат грешките, гледаме дека сме имале автоматско префрлање датотеки. И бидејќи нашите грешки беа поврзани со интеракцијата со DCS и во нашиот случај користевме Consul, ги разгледуваме и дневниците на конзулот, што се случи таму.

Грубо споредувајќи го времето на поднесувачот и времето во дневниците на конзулот, гледаме дека нашите соседи во кластерот Конзул почнаа да се сомневаат во постоењето на други членови на кластерот конзул.

И ако ги погледнете и дневниците на другите агенти на Конзулот, можете исто така да видите дека таму се случува некаков колапс на мрежата. И сите членови на кластерот конзул се сомневаат меѓусебно во постоењето. И ова беше поттик за датотеката.

Ако погледнете што се случило пред овие грешки, можете да видите дека има секакви грешки, на пример, рокот, RPC падна, односно јасно е дека постои некаков проблем во интеракцијата на членовите на кластерот конзул едни со други. .

Наједноставниот одговор е да се поправи мрежата. Но, за мене, стоејќи на подиумот, лесно е да го кажам ова. Но, околностите се такви што не секогаш клиентот може да си дозволи да ја поправи мрежата. Тој може да живее во DC и да не може да ја поправи мрежата, да влијае на опремата. И затоа се потребни некои други опции.

Постојат опции:

• Наједноставната опција, која е напишана, според мене, дури и во документацијата, е да се оневозможат проверките на конзулот, односно едноставно да се помине празна низа. И му кажуваме на агентот на конзулот да не користи никакви чекови. Со овие проверки, можеме да ги игнорираме овие мрежни бури и да не иницираме датотека.
• Друга опција е двојно да се провери raft_multiplier. Ова е параметар на самиот сервер конзул. Стандардно, таа е поставена на 5. Оваа вредност е препорачана од документацијата за средини за поставување. Всушност, ова влијае на зачестеноста на пораките помеѓу членовите на мрежата на Конзул. Всушност, овој параметар влијае на брзината на услугата комуникација помеѓу членовите на кластерот Конзул. И за производство, веќе се препорачува да се намали, така што јазлите почесто разменуваат пораки.
• Друга опција што ја смисливме е да го зголемиме приоритетот на процесите на Конзул меѓу другите процеси за распоредувачот на процеси на оперативниот систем. Има таков „убав“ параметар, тој само го одредува приоритетот на процесите што го зема предвид распоредувачот на ОС при закажувањето. Ја намаливме и убавата вредност за агентите на Конзулот, т.е. го зголеми приоритетот, така што оперативниот систем им дава повеќе време на процесите на Конзулот да работат и да го извршат нивниот код. Во нашиот случај, ова ни го реши проблемот.
• Друга опција е да не се користи конзул. Имам пријател кој е голем поддржувач на Etcd. И ние редовно се расправаме со него што е подобро Etcd или Consul. Но, во однос на тоа што е подобро, ние обично се согласуваме со него дека конзулот има агент кој треба да работи на секој јазол со база на податоци. Односно, интеракцијата на Патрони со кластерот конзул оди преку овој агент. И овој агент станува тесно грло. Ако нешто се случи со агентот, тогаш Патрони повеќе не може да работи со кластерот конзул. И ова е проблемот. Нема агент во планот Etcd. Patroni може директно да работи со список на сервери Etcd и веќе да комуницира со нив. Во овој поглед, ако користите Etcd во вашата компанија, тогаш Etcd веројатно ќе биде подобар избор од Consul. Но, ние кај нашите клиенти секогаш сме ограничени од она што клиентот го избрал и користи. И ние имаме конзул во најголем дел за сите клиенти.
• И последната точка е да се ревидираат вредностите на параметрите. Можеме да ги подигнеме овие параметри со надеж дека нашите краткорочни мрежни проблеми ќе бидат кратки и нема да бидат надвор од опсегот на овие параметри. На овој начин можеме да ја намалиме агресивноста на Patroni во автоматска датотека доколку се појават некои мрежни проблеми.

Мислам дека многумина кои користат Patroni се запознаени со оваа команда.

Оваа команда ја покажува моменталната состојба на кластерот. И на прв поглед, оваа слика може да изгледа нормална. Имаме мајстор, имаме реплика, нема задоцнување на репликацијата. Но, оваа слика е нормална точно додека не знаеме дека овој кластер треба да има три јазли, а не два.

Соодветно на тоа, имаше авто-датотека. И по оваа авто-датотека, нашата реплика исчезна. Треба да откриеме зошто исчезна и да ја вратиме, да ја вратиме. И повторно одиме во дневниците и гледаме зошто имавме автоматско префрлање датотеки.

Во овој случај, втората реплика стана господар. Сè е во ред овде.

И треба да ја погледнеме репликата што падна и која не е во кластерот. Ги отвораме логовите на Patroni и гледаме дека сме имале проблем при процесот на поврзување со кластерот во фазата pg_rewind. За да се поврзете со кластерот, треба да го премотате дневникот на трансакции, да го побарате потребниот дневник на трансакции од главниот и да го користите за да го достигнете главниот.

Во овој случај, немаме дневник за трансакции и репликата не може да започне. Според тоа, го запираме Postgres со грешка. И затоа не е во кластерот.

Треба да разбереме зошто не е во кластерот и зошто немаше логови. Одиме кај новиот господар и гледаме што има во дневниците. Излегува дека кога беше направено pg_rewind, се случи контролен пункт. И некои од старите дневници за трансакции беа едноставно преименувани. Кога стариот господар се обиде да се поврзе со новиот господар и да ги побара овие дневници, тие веќе беа преименувани, едноставно не постоеја.

Ги споредив временските печати кога се случија овие настани. И таму разликата е буквално 150 милисекунди, односно контролниот пункт завршен за 369 милисекунди, сегментите WAL беа преименувани. И буквално во 517 година, по 150 милисекунди, започнало премотувањето на старата реплика. Односно ни беа доволни буквално 150 милисекунди за да не може репликата да се поврзе и да заработи.

Кои се опциите?

Првично користевме слотови за репликација. Мислевме дека е добро. Иако во првата фаза на работа ги исклучивме слотовите. Ни се чинеше дека ако слотовите акумулираат многу сегменти на WAL, можеме да го отфрлиме господарот. Тој ќе падне. Страдавме некое време без слотови. И сфативме дека ни требаат слотови, ги вративме слотовите.

Но, тука има проблем, што кога господарот оди до репликата, ги брише слотовите и ги брише WAL сегментите заедно со слотовите. И за да го отстраниме овој проблем, решивме да го подигнеме параметарот wal_keep_segments. Стандардно е 8 сегменти. Го подигнавме на 1 и погледнавме колку слободен простор имаме. И дониравме 000 гигабајти за wal_keep_segments. Односно, при префрлување, секогаш имаме резерва од 16 гигабајти дневници за трансакции на сите јазли.

И плус - сè уште е релевантен за долгорочни задачи за одржување. Да речеме дека треба да ажурираме една од репликите. И ние сакаме да го исклучиме. Треба да го ажурираме софтверот, можеби оперативниот систем, нешто друго. И кога ќе исклучиме реплика, отворот за таа реплика исто така се отстранува. И ако користиме мали wal_keep_segments, тогаш со долго отсуство на реплика, дневниците на трансакциите ќе бидат изгубени. Ќе подигнеме реплика, таа ќе ги побара оние дневници на трансакции каде што застана, но тие можеби не се на главниот. А ни репликата нема да може да се поврзе. Затоа, чуваме голема залиха на списанија.

Имаме производствена база. Веќе има проекти во тек.

Имаше фајл. Влеговме и погледнавме - се е во ред, репликите се на место, нема заостанување на репликацијата. Ниту во дневниците нема грешки, се е во ред.

Тимот на производи вели дека треба да има некои податоци, но ние ги гледаме од еден извор, но не ги гледаме во базата на податоци. И ние треба да разбереме што се случи со нив.

Јасно е дека pg_rewind ги пропушти. Веднаш го разбравме ова, но отидовме да видиме што се случува.

Во дневниците, секогаш можеме да откриеме кога се случил подигнувачот, кој станал господар, и можеме да одредиме кој бил стариот господар и кога сакал да стане реплика, т.е. овие дневници ни требаат за да ја дознаеме количината на дневници за трансакции што беше изгубен.

Нашиот стар господар се рестартира. И Патрони беше регистриран во авторун. Лансиран Patroni. Потоа го започна Postgres. Поточно, пред да започне Postgres и пред да го направи реплика, Patroni го лансираше процесот pg_rewind. Соодветно на тоа, тој избриша дел од дневниците на трансакциите, преземаше нови и се поврза. Тука Патрони работеше паметно, односно очекувано. Кластерот е обновен. Имавме 3 јазли, по филер 3 јазли - сè е кул.

Изгубивме некои податоци. И треба да разбереме колку сме изгубиле. Го бараме само моментот кога имавме премотување. Можеме да го најдеме во такви записи во списанието. Rewind започна, направи нешто таму и заврши.

Треба да ја најдеме позицијата во дневникот на трансакции каде што застанал стариот господар. Во овој случај, ова е ознаката. И ни треба втора ознака, односно растојанието по кое стариот мајстор се разликува од новиот.

Ги земаме вообичаените pg_wal_lsn_diff и ги споредуваме овие две ознаки. И во овој случај, добиваме 17 мегабајти. Многу или малку, секој одлучува за себе. Затоа што за некого 17 мегабајти не се многу, за некого се многу и неприфатливи. Овде секој поединец сам си одредува во согласност со потребите на бизнисот.

Но, што откривме сами?

Прво, мора да одлучиме сами - дали секогаш ни треба Patroni за автоматско стартување по рестартирање на системот? Често се случува да треба да одиме кај стариот мајстор, да видиме до каде стигнал. Можеби прегледајте ги сегментите од дневникот на трансакциите, видете што има таму. И да разбереме дали можеме да ги изгубиме овие податоци или дали треба да го извршиме стариот господар во самостоен режим за да ги извлечеме овие податоци.

И само после тоа мора да одлучиме дали можеме да ги отфрлиме овие податоци или можеме да ги вратиме, да го поврземе овој јазол како реплика со нашиот кластер.

Покрај тоа, постои параметар „maximum_lag_on_failover“. Стандардно, ако ме опслужува меморијата, овој параметар има вредност од 1 мегабајт.

Како работи тој? Ако нашата реплика заостанува со 1 мегабајт податоци во заостанувањето на репликацијата, тогаш оваа реплика не учествува на изборите. И ако одеднаш дојде до датотека, Патрони гледа кои реплики заостануваат. Ако заостануваат со голем број логови на трансакции, тие не можат да станат господар. Ова е многу добра безбедносна карактеристика што ве спречува да изгубите многу податоци.

Но, постои проблем во тоа што доцнењето на репликацијата во кластерот Patroni и DCS се ажурира на одреден интервал. Мислам дека 30 секунди е стандардната вредност ttl.

Соодветно, може да има ситуација кога има едно задоцнување за репликација за репликите во DCS, но всушност може да има сосема поинакво задоцнување или може да нема воопшто задоцнување, т.е. ова нешто не е во реално време. И тоа не секогаш ја одразува реалната слика. И не вреди да се прави фенси логика на тоа.

И ризикот од загуба секогаш останува. И во најлош случај, една формула, а во просечен случај, друга формула. Односно, кога ја планираме имплементацијата на Patroni и проценуваме колку податоци можеме да изгубиме, мора да се потпреме на овие формули и грубо да замислиме колку податоци можеме да изгубиме.

И има добри вести. Кога стариот господар отиде напред, тој може да продолжи поради некои процеси во позадина. Односно, имаше некаков автовакуум, ги напиша податоците, ги зачува во дневникот на трансакциите. И лесно можеме да ги игнорираме и да ги изгубиме овие податоци. Нема проблем во ова.

И вака изгледаат дневниците ако се постави maximum_lag_on_failover и се појавил датотеката, и треба да изберете нов главен. Репликата се оценува како неспособна да учествува на изборите. И таа одбива да учествува во трката за лидер. И таа чека да се избере нов господар, за потоа да се поврзе со него. Ова е дополнителна мерка против губење на податоци.

Овде имаме тим за производи кој напиша дека нивниот производ има проблеми со Postgres. Во исто време, самиот господар не може да се пристапи, бидејќи не е достапен преку SSH. И авто-датотеката не се случува.

Овој домаќин беше принуден да се рестартира. Поради рестартирањето, се случи автоматска датотека, иако беше можно да се направи рачна автоматска датотека, како што сега разбрав. И по рестартирањето, веќе ќе видиме што имавме со сегашниот мајстор.

Во исто време, однапред знаевме дека имаме проблеми со дисковите, односно веќе знаевме од мониторинг каде да копаме и што да бараме.

Влеговме во дневникот на постгрес, почнавме да гледаме што се случува таму. Видовме заложби кои таму траат една, две, три секунди, што воопшто не е нормално. Видовме дека нашиот автовакуум се вклучува многу бавно и чудно. И видовме привремени датотеки на дискот. Тоа е, сите овие се показатели за проблеми со дисковите.

Го разгледавме системот dmesg (дневник на кернелот). И видовме дека имаме проблеми со еден од дисковите. Подсистемот на дискот беше софтверски Raid. Погледнавме во /proc/mdstat и видовме дека ни недостасува еден диск. Односно има Raid од 8 дискови, еден ни фали. Ако внимателно го погледнете слајдот, тогаш на излезот можете да видите дека немаме sde таму. Кај нас, условно кажано, испадна дискот. Ова предизвика проблеми со дискот, а апликациите исто така имаа проблеми при работа со кластерот Postgres.

И во овој случај, Patroni не би ни помогнал никако, бидејќи Patroni нема задача да ја следи состојбата на серверот, состојбата на дискот. А таквите ситуации мора да ги следиме со надворешен мониторинг. Брзо додадовме мониторинг на дискот на надворешен мониторинг.

И имаше таква мисла - дали софтверот за мечување или чувар на кучиња може да ни помогне? Мислевме дека тешко дека ќе ни помогне во овој случај, бидејќи за време на проблемите Патрони продолжи да комуницира со кластерот DCS и не виде никаков проблем. Тоа е, од гледна точка на DCS и Patroni, сè беше во ред со кластерот, иако всушност имаше проблеми со дискот, имаше проблеми со достапноста на базата на податоци.

Според мене, ова е еден од најчудните проблеми што ги истражував долго време, прочитав многу логови, повторно избрав и го нареков симулатор на кластери.

Проблемот беше што стариот мајстор не можеше да стане нормална реплика, т.е. Сега ќе видите зошто. Ова го задржав од анализата на тој проблем.

И како сето тоа започна? Почна, како и во претходниот проблем, со диск сопирачки. Имавме обврски за секунда, две.

Имаше прекини во врските, т.е. клиенти беа искинати.

Имаше блокади со различна тежина.

И, соодветно, потсистемот на дискот не реагира многу.

И најмистериозната работа за мене е барањето за моментално исклучување што пристигна. Postgres има три режими на исклучување:

• Добро е кога чекаме сите клиенти сами да се исклучат.
• Има брзо кога ги принудуваме клиентите да се исклучат затоа што ќе се исклучиме.
• И веднаш. Во овој случај, immediate дури и не им кажува на клиентите да се исклучат, туку само се исклучува без предупредување. И на сите клиенти, оперативниот систем веќе испраќа RST порака (порака TCP дека врската е прекината и клиентот нема што повеќе да фати).

Кој го испрати овој сигнал? Позадинските процеси на Postgres не испраќаат такви сигнали едни на други, т.е. ова е kill-9. Тие не си праќаат такви работи, туку само реагираат на такви работи, односно ова е итен рестарт на Постгрес. Кој го испрати, не знам.

Ја погледнав командата „последна“ и видов едно лице кое исто така се најави на овој сервер со нас, но бев премногу срамежлив да поставам прашање. Можеби тоа беше убие -9. Ќе видам убие -9 во дневниците, затоа што Postgres вели дека е потребно убие -9, но јас не го видов во дневниците.

Гледајќи понатаму, видов дека Патрони не пишуваше во дневникот доста долго - 54 секунди. И ако споредиме два временски печати, немаше пораки околу 54 секунди.

И за тоа време имаше авто-датотека. Патрони повторно заврши одлична работа овде. Нашиот стар господар беше недостапен, нешто му се случи. И започна изборот на нов мајстор. Сè функционираше добро овде. Нашиот pgsql01 стана нов лидер.

Имаме реплика која стана мајстор. И има втор одговор. И имаше проблеми со втората реплика. Таа се обиде да се реконфигурира. Како што разбрав, таа се обиде да го смени recovery.conf, да го рестартира Postgres и да се поврзе со новиот господар. На секои 10 секунди пишува пораки дека се труди, но не успева.

И за време на овие обиди, сигнал за итно исклучување пристигнува до стариот господар. Мајсторот се рестартира. И, исто така, закрепнувањето престанува бидејќи стариот мајстор оди во рестартирање. Односно, репликата не може да се поврзе со неа, бидејќи е во режим на исклучување.

Во одреден момент, тоа функционираше, но репликацијата не започна.

Мојата единствена претпоставка е дека имаше стара мастер адреса во закрепнувањето.conf. И кога се појави нов мајстор, втората реплика сè уште се обидуваше да се поврзе со стариот мајстор.

Кога Patroni стартуваше на втората реплика, јазолот започна, но не можеше да се реплицира. И се формираше заостанување на репликацијата, што изгледаше отприлика вака. Тоа е, сите три јазли беа на место, но вториот јазол заостануваше.

Во исто време, ако ги погледнете дневниците што беа напишани, можете да видите дека репликацијата не може да започне бидејќи дневниците на трансакциите беа различни. И оние дневници за трансакции што ги нуди мајсторот, кои се наведени во recovery.conf, едноставно не одговараат на нашиот моментален јазол.

И тука згрешив. Морав да дојдам и да видам што е во обновувањето.conf за да ја тестирам мојата хипотеза дека се поврзуваме со погрешен господар. Но, тогаш само се занимавав со ова и не ми текна, или видов дека репликата заостанува и ќе треба да се наполни, односно некако работев безгрижно. Ова беше мојот зглоб.

После 30 минути веќе дојде админот, т.е го рестартирав Patroni на репликата. Веќе ставив крај, мислев дека ќе треба да се дополни. И си помислив - ќе го рестартирам Патрони, можеби ќе испадне нешто добро. Закрепнувањето започна. И базата дури се отвори, беше подготвена да прифати врски.

Репликацијата започна. Но, една минута подоцна, таа падна со грешка дека дневниците за трансакции не се соодветни за неа.

Мислев дека ќе рестартирам повторно. Повторно го рестартирав Patroni и не го рестартирав Postgres, туку го рестартирав Patroni со надеж дека магично ќе ја стартува базата на податоци.

Репликацијата започна повторно, но ознаките во дневникот на трансакциите беа различни, тие не беа исти како претходниот обид за почеток. Репликацијата повторно престана. А пораката веќе беше малку поинаква. И не ми беше многу информативно.

И тогаш ми текнува - што ако го рестартирам Postgres, во ова време направам контролен пункт на тековниот господар за да ја поместам точката во дневникот на трансакции малку нанапред за да започне опоравувањето од друг момент? Плус, сè уште имавме залихи на WAL.

Го рестартирав Patroni, направив неколку контролни точки на мајсторот, неколку точки за рестартирање на репликата кога се отвори. И помогна. Долго размислував зошто помогна и како функционира. И репликата започна. И репликацијата повеќе не беше искината.

Таков проблем за мене е еден од помистериозните, околу кој сè уште се загатка што навистина се случило таму.

Кои се импликациите овде? Патрони може да работи според планираното и без никакви грешки. Но, во исто време, ова не е 100% гаранција дека сè е во ред со нас. Репликата може да почне, но може да е во полуработна состојба, а апликацијата не може да работи со таква реплика, бидејќи ќе има стари податоци.

И после датотеката, секогаш треба да проверите дали сè е во ред со кластерот, односно има потребниот број на реплики, нема задоцнување на репликацијата.

И додека поминуваме низ овие прашања, јас ќе дадам препораки. Се обидов да ги комбинирам во два слајдови. Веројатно, сите приказни би можеле да се спојат во два слајдови и само да се раскажат.

Кога користите Patroni, мора да имате мониторинг. Секогаш треба да знаете кога се случило автоматско префрлање на датотеки, бидејќи ако не знаете дека сте имале автоматско префрлање, немате контрола врз кластерот. И тоа е лошо.

По секоја датотека, секогаш мораме рачно да го провериме кластерот. Треба да се погрижиме секогаш да имаме ажуриран број на реплики, да нема задоцнување на репликацијата, да нема грешки во дневниците поврзани со репликација на стриминг, со Patroni, со системот DCS.

Автоматизацијата може успешно да работи, Patroni е многу добра алатка. Може да работи, но тоа нема да го доведе кластерот до посакуваната состојба. И ако не дознаеме за тоа, ќе бидеме во неволја.

И Патрони не е сребрен куршум. Сè уште треба да разбереме како функционира Postgres, како функционира репликацијата и како Patroni работи со Postgres и како се обезбедува комуникација помеѓу јазлите. Ова е неопходно за да можете да ги решите проблемите со вашите раце.

Како да му пристапам на прашањето за дијагноза? Се случи да работиме со различни клиенти и никој да нема ELK стек, а ние мора да ги средиме логовите со отворање 6 конзоли и 2 јазичиња. Во едното јазиче, ова се логовите на Patroni за секој јазол, во другиот таб, ова се дневниците на конзулот или Postgres доколку е потребно. Многу е тешко да се дијагностицира ова.

Какви пристапи презедов? Прво, секогаш гледам кога ќе пристигнат фајлерот. И за мене ова е слив. Гледам што се случило пред датотеката, за време на датотеката и по датотеката. Прегледот на датотеки има две ознаки: ова е времето на почеток и крај.

Следно, барам во дневниците за настани пред датотеката, кои му претходеле на датотеката, односно ги барам причините зошто се случил датотеката.

И ова дава слика за разбирање што се случило и што може да се направи во иднина за да не се појават такви околности (и како резултат на тоа, нема датотека).

И каде обично гледаме? Гледам:

• Прво, до трупците Патрони.
• Следно, ги гледам дневниците на Postgres, или дневниците на DCS, во зависност од тоа што е пронајдено во дневниците на Patroni.
• И системските дневници, исто така, понекогаш даваат разбирање за тоа што го предизвикало датотеката.

Како се чувствувам за Патрони? Имам многу добри односи со Патрони. Според мене, ова е најдоброто што постои денес. Знам многу други производи. Тоа се Stolon, Repmgr, Pg_auto_failover, PAF. 4 алатки. Ги пробав сите. Патрони ми е омилен.

Ако ме прашаат: „Дали го препорачувам Патрони?“. Ќе кажам да, затоа што ми се допаѓа Патрони. И мислам дека научив како да го готвам.

Ако сте заинтересирани да видите какви други проблеми има со Patroni, освен проблемите што ги споменав, секогаш можете да ја проверите страницата прашања на GitHub. Има многу различни приказни и многу интересни прашања се дискутираат таму. И како резултат на тоа, некои грешки беа воведени и решени, односно, ова е интересно читање.

Има неколку интересни приказни за луѓе кои си пукаат во нога. Многу информативно. Читате и разбирате дека тоа не е неопходно. Се штиклирав.

И би сакал да му кажам голема благодарност на Заландо за развојот на овој проект, имено на Александар Кукушкин и Алексеј Кљукин. Алексеј Кљукин е еден од коавторите, тој повеќе не работи во Заландо, но тоа се двајца луѓе кои почнаа да работат со овој производ.

И мислам дека Патрони е многу кул работа. Среќен сум што постои, интересно е со неа. И голема благодарност до сите соработници кои пишуваат закрпи на Patroni. Се надевам дека Патрони ќе стане позрел, покул и поефикасен со годините. Веќе е функционален, но се надевам дека ќе стане уште подобар. Затоа, ако планирате да користите Patroni, тогаш не плашете се. Ова е добро решение, може да се имплементира и користи.

Тоа е се. Ако имате прашања, прашајте.

прашања

Ви благодариме за извештајот! Ако по датотеката сè уште треба да погледнете таму многу внимателно, тогаш зошто ни е потребен автоматски фајлер?

Затоа што тоа е нова работа. Со неа сме само една година. Подобро да се биде безбеден. Сакаме да влеземе и да видиме дека навистина сè функционира како што треба. Ова е нивото на недоверба на возрасните - подобро е да се провери и да се види.

На пример, отидовме наутро и погледнавме, нели?

Не наутро, обично учиме за авто-датотеката речиси веднаш. Добиваме известувања, гледаме дека се појави автоматска датотека. Речиси веднаш одиме и гледаме. Но, сите овие проверки треба да се доведат на ниво на мониторинг. Ако пристапите до Patroni преку REST API, постои историја. Според историјата, можете да ги видите временските ознаки кога се случил датотеката. Врз основа на ова, може да се направи мониторинг. Можете да ја видите историјата, колку настани имало таму. Ако имаме повеќе настани, тогаш се појавила автоматска датотека. Можете да одите и да видите. Или нашата автоматизација за следење провери дали ги имаме сите реплики на место, нема заостанување и се е во ред.

Ви благодариме!

Ви благодариме многу за одличната приказна! Ако го преместивме кластерот DCS некаде далеку од кластерот Postgres, тогаш и овој кластер треба периодично да се сервисира? Кои се најдобрите практики што некои делови од кластерот DCS треба да се исклучат, нешто да се прави со нив итн.? Како опстојува целата оваа структура? И како ги правите овие работи?

За една компанија беше потребно да се направи матрица на проблеми, што ќе се случи ако пропадне една од компонентите или неколку компоненти. Според оваа матрица, ние последователно ги поминуваме сите компоненти и градиме сценарија во случај на дефект на овие компоненти. Според тоа, за секое сценарио за неуспех, можете да имате акционен план за закрепнување. А во случајот со DCS, тој доаѓа како дел од стандардната инфраструктура. И администраторот го администрира, а ние веќе се потпираме на администраторите кои го администрираат и нивната способност да го поправат во случај на несреќи. Ако воопшто нема DCS, тогаш го распоредуваме, но во исто време не го следиме особено, бидејќи не сме одговорни за инфраструктурата, туку даваме препораки како и што да следиме.

Односно, дали добро разбрав дека треба да го оневозможам Patroni, да го оневозможам фајлерот, да оневозможам сè пред да направам нешто со хостовите?

Зависи од тоа колку јазли имаме во кластерот DCS. Ако има многу јазли и ако оневозможиме само еден од јазлите (репликата), тогаш кластерот одржува кворум. И Патрони останува во функција. И ништо не се активира. Ако имаме некои сложени операции кои влијаат на повеќе јазли, чие отсуство може да го уништи кворумот, тогаш - да, можеби има смисла да се стави Патрони на пауза. Има соодветна команда - patronictl пауза, patronictl резиме. Само паузираме и автоматскиот пополнувач не работи во тоа време. Правиме одржување на кластерот DCS, потоа ја тргаме паузата и продолжуваме да живееме.

Ви благодарам многу!

Ви благодариме многу за вашиот извештај! Како се чувствува тимот на производи за изгубени податоци?

На тимовите за производи не им е грижа, а лидерите на тимот се загрижени.

Какви гаранции постојат?

Гаранциите се многу тешки. Александар Кукушкин има извештај „Како да се пресметаат RPO и RTO“, т.е. време за обновување и колку податоци можеме да изгубиме. Мислам дека треба да ги најдеме овие слајдови и да ги проучиме. Колку што се сеќавам, има конкретни чекори како да се пресметаат овие работи. Колку трансакции можеме да изгубиме, колку податоци можеме да изгубиме. Како опција, можеме да користиме синхрона репликација на ниво на Patroni, но ова е меч со две острици: или имаме доверливост на податоците, или губиме брзина. Постои синхрона репликација, но исто така не гарантира 100% заштита од губење на податоци.

Алексеј, благодарам за одличниот извештај! Имате искуство со користење на Patroni за заштита на нула ниво? Тоа е, во врска со синхроно мирување? Ова е првото прашање. И второто прашање. Сте користеле различни решенија. Го користевме Repmgr, но без автоматско пополнување, а сега планираме да го вклучиме и автофилерот. А Патрони го сметаме за алтернативно решение. Што можете да кажете како предности во споредба со Repmgr?

Првото прашање беше за синхрони реплики. Никој не користи синхрона репликација овде, бидејќи сите се исплашени (неколку клиенти веќе го користат, во принцип, тие не забележаа проблеми со изведбата - Забелешка на говорникот). Но, ние за себе развивме правило дека треба да има најмалку три јазли во кластерот за синхрона репликација, бидејќи ако имаме два јазли и ако мастерот или репликата не успеат, тогаш Patroni го префрла овој јазол во самостоен режим, така што апликацијата продолжува да работа. Во овој случај, постои ризик од губење на податоци.

Во однос на второто прашање, ние користевме Repmgr и сè уште го користиме со некои клиенти од историски причини. Што може да се каже? Patroni доаѓа со автоматско пополнување надвор од кутијата, Repmgr доаѓа со автоматско пополнување како дополнителна функција што треба да се овозможи. Треба да го извршиме демонот Repmgr на секој јазол и потоа можеме да го конфигурираме автофилерот.

Repmgr проверува дали Postgres јазлите се живи. Процесите Repmgr го проверуваат постоењето на едни со други, ова не е многу ефикасен пристап. може да има сложени случаи на изолација на мрежата во кои голем кластер Repmgr може да се распадне на неколку помали и да продолжи да работи. Одамна не го следам Repmgr, можеби се среди ... или можеби не. Но, отстранувањето на информациите за состојбата на кластерот во DCS, како што тоа го прави Столон, Патрони, е најостварливата опција.

Алексеј, имам едно прашање, можеби побавно. Во еден од првите примери, го преместивте DCS од локалната машина на оддалечен домаќин. Ние разбираме дека мрежата е нешто што има свои карактеристики, живее самостојно. И што се случува ако поради некоја причина кластерот DCS стане недостапен? Нема да ги кажам причините, може да ги има многу: од искривени раце на мрежни до вистински проблеми.

Не го кажав тоа гласно, но мора да биде и кластерот DCS кој е отстапен, односно тоа е непарен број на јазли, за да се постигне кворум. Што ќе се случи ако кластерот DCS стане недостапен или ако не може да се исполни кворум, т.е. некој вид мрежна поделба или неуспех на јазол? Во овој случај, кластерот Patroni оди во режим само за читање. Патрони кластерот не може да ја одреди состојбата на кластерот и што да прави. Не може да контактира со DCS и да ја складира новата состојба на кластерот таму, така што целиот кластер оди во само за читање. И чека или рачна интервенција од операторот или DCS да се опорави.

Грубо кажано, DCS станува услуга за нас исто толку важна како и самата база?

Да Да. Во толку многу модерни компании, Service Discovery е составен дел од инфраструктурата. Се спроведува уште пред да има база на податоци во инфраструктурата. Релативно кажано, инфраструктурата беше лансирана, распоредена во DC и веднаш имаме Service Discovery. Ако е конзул, тогаш на него може да се изгради DNS. Ако ова е Etcd, тогаш може да има дел од кластерот Kubernetes, во кој сè друго ќе биде распоредено. Ми се чини дека Service Discovery е веќе составен дел на модерните инфраструктури. И тие размислуваат за тоа многу порано отколку за бази на податоци.

Ви благодариме!

Извор: www.habr.com