Patroni Failure Stories или как да сринете вашия PostgreSQL клъстер. Алексей Лесовски

Основната цел на Patroni е да осигури висока наличност за PostgreSQL. Но Patroni е само шаблон, а не готов инструмент (което по принцип се казва в документацията). На пръв поглед, след като настроите Patroni в тестовата лаборатория, можете да видите какъв страхотен инструмент е и колко лесно се справя с опитите ни да разбием клъстера. На практика обаче в производствена среда не винаги всичко се случва толкова красиво и елегантно, колкото в тестова лаборатория.

Ще ви разкажа малко за себе си. Започнах като системен администратор. Работил в уеб разработката. Работя в Data Egret от 2014 г. Фирмата се занимава с консултации в областта на Postgres. И ние обслужваме точно Postgres и работим с Postgres всеки ден, така че имаме различен опит, свързан с операцията.

И в края на 2018 г. започнахме бавно да използваме Patroni. И се натрупа известен опит. Някак си го диагностицирахме, настроихме го, стигнахме до нашите най-добри практики. И в този доклад ще говоря за тях.

Освен Postgres, обичам Linux. Обичам да се ровя в него и да изследвам, обичам да събирам ядра. Обичам виртуализацията, контейнерите, докерите, Kubernetes. Всичко това ме интересува, защото старите администраторски навици влияят. Обичам да се занимавам с мониторинг. И аз обичам postgres неща, свързани с администриране, т.е. репликация, архивиране. А в свободното си време пиша на Go. Не съм софтуерен инженер, просто пиша за себе си в Go. И ми доставя удоволствие.

• Мисля, че много от вас знаят, че Postgres няма HA (High Availability) веднага. За да получите HA, трябва да инсталирате нещо, да го конфигурирате, да положите усилия и да го получите.
• Има няколко инструмента и Patroni е един от тях, който решава HA доста готино и много добре. Но като поставим всичко това в тестова лаборатория и го стартираме, можем да видим, че всичко работи, можем да възпроизведем някои проблеми, да видим как Patroni ги обслужва. И ще видим, че всичко работи чудесно.
• Но на практика се сблъскахме с различни проблеми. И аз ще говоря за тези проблеми.
• Ще ви кажа как го диагностицирахме, какво коригирахме - дали ни помогна или не.

• Няма да ви казвам как да инсталирате Patroni, защото можете да търсите в Google в Интернет, можете да погледнете конфигурационните файлове, за да разберете как започва всичко, как е конфигурирано. Можете да разберете схемите, архитектурите, да намерите информация за това в Интернет.
• Няма да говоря за чужд опит. Ще говоря само за проблемите, с които се сблъскахме.
• И няма да говоря за проблеми, които са извън Patroni и PostgreSQL. Ако например има проблеми, свързани с балансирането, когато нашият клъстер се е сринал, няма да говоря за това.

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

Всички тези проблеми, с които се сблъскахме, ги имахме през първите 6-7-8 месеца работа. С течение на времето стигнахме до нашите вътрешни най-добри практики. И проблемите ни изчезнаха. Следователно докладът беше обявен преди около шест месеца, когато всичко беше прясно в главата ми и го помнех перфектно.

В хода на подготовката на доклада вече повдигнах стари аутопсии, погледнах дневниците. И някои от детайлите могат да бъдат забравени или някои от някои детайли не могат да бъдат напълно проучени по време на анализа на проблемите, така че в някои моменти може да изглежда, че проблемите не са напълно разгледани или има известна липса на информация. И затова ви моля да ме извините за този момент.

Какво е Patroni?

• Това е шаблон за изграждане на HA. Така пише в документацията. И от моя гледна точка това е много правилно уточнение. Patroni не е сребърен куршум, който ще реши всичките ви проблеми, тоест трябва да положите усилия, за да работи и да носи ползи.
• Това е агентска услуга, която се инсталира на всяка услуга за база данни и е вид система за стартиране на вашия Postgres. Той стартира Postgres, спира, рестартира, преконфигурира и променя топологията на вашия клъстер.
• Съответно, за да се съхранява състоянието на клъстера, неговото текущо представяне, както изглежда, е необходимо някакво хранилище. И от тази гледна точка Patroni пое по пътя на съхраняване на състоянието във външна система. Това е разпределена система за съхранение на конфигурация. Може да бъде Etcd, Consul, ZooKeeper или kubernetes Etcd, т.е. една от тези опции.
• И една от характеристиките на Patroni е, че получавате автоматичния файл от кутията, само като го настроите. Ако вземем Repmgr за сравнение, тогава файлът е включен там. С Repmgr получаваме превключване, но ако искаме автоматичен файл, тогава трябва да го конфигурираме допълнително. Patroni вече разполага с автоматичен файл.
• И много други неща има. Например поддръжка на конфигурации, сипване на нови реплики, бекъп и т.н. Но това е извън обхвата на доклада, няма да говоря за това.

И малък резултат е, че основната задача на Patroni е да направи автофайл добре и надеждно, така че нашият клъстер да остане работещ и приложението да не забележи промени в топологията на клъстера.

Но когато започнем да използваме Patroni, системата ни става малко по-сложна. Ако по-рано имахме Postgres, тогава при използване на Patroni получаваме самия Patroni, получаваме DCS, където се съхранява състоянието. И всичко трябва да работи по някакъв начин. И така, какво може да се обърка?

Може да се счупи:

• Postgre може да се счупи. Може да е майстор или реплика, може някой от тях да се провали.
• Самият Patroni може да се счупи.
• DCS, където се съхранява състоянието, може да се повреди.
• И мрежата може да се счупи.

Всички тези точки ще разгледам в доклада.

Ще разглеждам случаите, когато стават по-сложни, а не от гледна точка, че случаят включва много компоненти. И от гледна точка на субективните усещания, че този случай ми беше труден, беше трудно да го разглобя ... и обратното, някой случай беше лек и беше лесно да го разглобя.

И първият случай е най-лесният. Такъв е случаят, когато взехме клъстер от база данни и разположихме нашето DCS хранилище на същия клъстер. Това е най-честата грешка. Това е грешка при изграждането на архитектури, т.е. комбинирането на различни компоненти на едно място.

И така, имаше файл, нека да се справим със случилото се.

И тук ни интересува кога се е случил филерът. Тоест, ние се интересуваме от този момент във времето, когато състоянието на клъстера се промени.

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

Следователно то има начален и краен час, т.е. това е непрекъснато събитие. И ние разделяме всички събития на три интервала: имаме време преди файла, по време на файла и след файла. Тоест, ние разглеждаме всички събития в тази времева линия.

И първото нещо, когато се случи филер, ние търсим причината за случилото се, каква е причината за това, което доведе до филера.

Ако погледнем трупите, те ще бъдат класически трупи Patroni. Той ни казва в тях, че сървърът е станал главен и ролята на главния е преминала към този възел. Тук е подчертано.

След това трябва да разберем защо се е случило файлирането, т.е. какви събития са настъпили, които са накарали главната роля да се премести от един възел в друг. И в този случай всичко е просто. Имаме грешка при взаимодействие със системата за съхранение. Майсторът разбра, че не може да работи с DCS, тоест има някакъв проблем с взаимодействието. И казва, че вече не може да бъде господар и си подава оставката. Този ред „понижен себе си“ казва точно това.

Ако разгледаме събитията, предшестващи файла, можем да видим там самите причини, които са причинили проблема, за да продължи съветника.

Ако погледнем регистрационните файлове на Patroni, ще видим, че имаме много грешки, изчаквания, т.е. агентът на Patroni не може да работи с DCS. В този случай това е Consul agent, който комуникира на порт 8500.

И проблемът тук е, че Patroni и базата данни работят на един и същ хост. И сървърите на Consul бяха стартирани на същия възел. Създавайки натоварване на сървъра, създадохме проблеми и на сървърите на Consul. Те не можеха да общуват правилно.

След известно време, когато натоварването намаля, нашият Патрони отново успя да комуникира с агенти. Нормалната работа беше възобновена. И същият Pgdb-2 сървър отново стана главен. Тоест имаше малък флип, поради който възелът се отказа от правомощията на капитана и след това отново ги пое, тоест всичко се върна както си беше.

И това може да се разглежда като фалшива тревога или може да се счита, че Патрони е направил всичко правилно. Тоест той разбра, че не може да поддържа състоянието на клъстера и премахна правомощията си.

И тук проблемът възникна поради факта, че сървърите на Consul са на същия хардуер като базите. Съответно всяко натоварване: независимо дали е натоварването на дискове или процесори, то също засяга взаимодействието с клъстера Consul.

И решихме, че не трябва да живее заедно, отделихме отделен клъстер за Консул. А Patroni вече работеше с отделен Consul, тоест имаше отделен Postgres cluster, отделен Consul cluster. Това е основна инструкция как да носите и пазите всички тези неща, за да не живее заедно.

Като опция можете да завъртите параметрите ttl, loop_wait, retry_timeout, т.е. опитайте се да преживеете тези краткосрочни пикове на натоварване, като увеличите тези параметри. Но това не е най-подходящият вариант, тъй като това натоварване може да бъде дълго във времето. И ние просто ще излезем извън тези граници на тези параметри. И това може наистина да не помогне.

Първият проблем, както разбирате, е прост. Взехме и сложихме DCS заедно с основата, получихме проблем.

Вторият проблем е подобен на първия. Подобно е, че отново имаме проблеми с оперативната съвместимост със системата DCS.

Ако погледнем логовете, ще видим, че отново имаме грешка в комуникацията. И Patroni казва, че не мога да взаимодействам с DCS, така че текущият мастер преминава в режим на реплика.

Старият майстор става реплика, тук Patroni работи, както трябва. Той изпълнява pg_rewind, за да превърти журнала на транзакциите и след това да се свърже с новия мастер, за да навакса с новия мастер. Тук Патрони работи, както трябва.

Тук трябва да намерим мястото, което предхожда файла, т.е. тези грешки, които са ни накарали да имаме файл. И в това отношение дневниците на Patroni са доста удобни за работа. Той пише едни и същи съобщения на определен интервал. И ако започнем бързо да превъртаме тези регистрационни файлове, тогава ще видим от регистрационните файлове, че регистрационните файлове са се променили, което означава, че са започнали някои проблеми. Бързо се връщаме на това място, вижте какво ще стане.

И в нормална ситуация дневниците изглеждат по следния начин. Собственикът на ключалката се проверява. И ако собственикът, например, се е променил, тогава може да възникнат някои събития, на които Patroni трябва да реагира. Но в този случай сме добре. Търсим мястото, откъдето са започнали грешките.

И след като превъртихме до точката, където започнаха да се появяват грешките, виждаме, че сме имали автоматично прехвърляне на файлове. И тъй като нашите грешки бяха свързани с взаимодействие с DCS и в нашия случай използвахме Consul, ние също гледаме регистрационните файлове на Consul, какво се е случило там.

Сравнявайки грубо времето на файла и времето в регистрационните файлове на Consul, виждаме, че нашите съседи в клъстера Consul започнаха да се съмняват в съществуването на други членове на клъстера Consul.

И ако погледнете регистрационните файлове на други агенти на Consul, можете също да видите, че там се случва някакъв вид срив на мрежата. И всички членове на клъстера Консул се съмняват в съществуването един на друг. И това беше тласъкът за филера.

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

Най-простият отговор е да поправите мрежата. Но за мен, стоящ на подиума, е лесно да кажа това. Но обстоятелствата са такива, че не винаги клиентът може да си позволи ремонт на мрежата. Той може да живее в DC и да не може да поправи мрежата, да повлияе на оборудването. И така са необходими някои други опции.

Има опции:

• Най-простият вариант, който според мен е написан дори в документацията, е да деактивирате консулските проверки, тоест просто да прехвърлите празен масив. И ние казваме на консулския агент да не използва никакви чекове. С тези проверки можем да игнорираме тези мрежови бури и да не инициираме файл.
• Друг вариант е да проверите отново raft_multiplier. Това е параметър на самия сървър Consul. По подразбиране е зададено на 5. Тази стойност се препоръчва от документацията за сценични среди. Всъщност това се отразява на честотата на обмен на съобщения между членовете на мрежата Consul. Всъщност този параметър влияе върху скоростта на комуникация между членовете на клъстера Consul. А за производството вече се препоръчва да се намали, така че възлите да обменят съобщения по-често.
• Друг вариант, който измислихме, е да увеличим приоритета на процесите Consul сред другите процеси за планировчика на процеси на операционната система. Има такъв „хубав“ параметър, той просто определя приоритета на процесите, който се взема предвид от планировчика на ОС при планиране. Намалихме и хубавата стойност за консулските агенти, т.е. увеличи приоритета, така че операционната система дава на процесите Consul повече време за работа и изпълнение на техния код. В нашия случай това реши проблема ни.
• Друг вариант е да не използвате Consul. Имам приятел, който е голям поддръжник на Etcd. И редовно спорим с него кое е по-добро Etcd или Consul. Но по отношение на това кое е по-добро, обикновено се съгласяваме с него, че Consul има агент, който трябва да работи на всеки възел с база данни. Тоест взаимодействието на Patroni с клъстера Consul минава през този агент. И този агент се превръща в пречка. Ако нещо се случи с агента, Patroni вече не може да работи с клъстера 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 беше регистриран в autorun. Стартира Patroni. След това стартира Postgres. По-точно, преди да стартира Postgres и преди да го направи реплика, Patroni стартира процеса pg_rewind. Съответно той изтри част от регистрационните файлове на транзакциите, изтегли нови и се свърза. Тук Patroni работи умно, тоест, както се очакваше. Клъстерът е възстановен. Имахме 3 възела, след файла 3 възела - всичко е готино.

Загубихме някои данни. И трябва да разберем колко сме загубили. Търсим точно момента, в който имахме пренавиване. Можем да го намерим в такива записи в дневника. Превъртането започна, направи нещо там и приключи.

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

Взимаме обичайния pg_wal_lsn_diff и сравняваме тези две марки. И в този случай получаваме 17 мегабайта. Много или малко, всеки решава за себе си. Защото за някой 17 мегабайта не е много, за някой е много и неприемливо. Тук всеки сам определя според нуждите на бизнеса.

Но какво разбрахме за себе си?

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

И едва след това трябва да решим дали можем да изхвърлим тези данни или можем да ги възстановим, свързвайки този възел като реплика към нашия клъстер.

Освен това има параметър "maximum_lag_on_failover". По подразбиране, ако не ме лъже паметта, този параметър има стойност от 1 мегабайт.

Как работи той? Ако нашата реплика изостава с 1 мегабайт данни в репликационния лаг, тогава тази реплика не участва в изборите. И ако внезапно има файловър, Patroni разглежда кои реплики изостават. Ако изостават с голям брой регистрационни файлове на транзакции, те не могат да станат господар. Това е много добра защитна функция, която ви предпазва от загуба на много данни.

Но има проблем в това, че забавянето на репликацията в клъстера Patroni и DCS се актуализира на определен интервал. Мисля, че 30 секунди е ttl стойността по подразбиране.

Съответно, може да има ситуация, при която има едно забавяне на репликация за реплики в DCS, но всъщност може да има напълно различно забавяне или може изобщо да няма забавяне, т.е. това нещо не е в реално време. И не винаги отразява реалната картина. И не си струва да правите фантастична логика върху него.

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

И има добри новини. Когато старият майстор е продължил, той може да продължи поради някои фонови процеси. Тоест имаше някакъв автовакуум, той записа данните, записа ги в регистъра на транзакциите. И лесно можем да пренебрегнем и загубим тези данни. Няма проблем в това.

Ето как изглеждат регистрационните файлове, ако е зададено maximum_lag_on_failover и е възникнал файл и трябва да изберете нов главен файл. Репликата се оценява като неспособна да участва в изборите. И тя отказва да участва в надпреварата за лидер. И чака да бъде избран нов мастер, за да може да се свърже с него. Това е допълнителна мярка срещу загуба на данни.

Тук имаме продуктов екип, който написа, че техният продукт има проблеми с Postgres. В същото време самият мастер не може да бъде достъпен, тъй като не е достъпен чрез SSH. И автофайлът също не става.

Този хост беше принуден да се рестартира. Поради рестартирането се случи автоматичен файл, въпреки че беше възможно да се направи ръчно автоматично файл, както сега разбирам. И след рестартирането вече ще видим какво имахме с текущия мастер.

В същото време знаехме предварително, че имаме проблеми с дисковете, тоест вече знаехме от мониторинга къде да копаем и какво да търсим.

Влязохме в журнала на postgres и започнахме да виждаме какво се случва там. Видяхме комити, които продължават там една, две, три секунди, което изобщо не е нормално. Видяхме, че нашият автовакуум стартира много бавно и странно. И видяхме временни файлове на диска. Тоест, това са всички индикатори за проблеми с дисковете.

Разгледахме системния dmesg (дневник на ядрото). И видяхме, че имаме проблеми с един от дисковете. Дисковата подсистема беше софтуерен Raid. Разгледахме /proc/mdstat и видяхме, че ни липсва едно устройство. Тоест има Raid от 8 диска, липсва ни един. Ако внимателно погледнете слайда, тогава в изхода можете да видите, че нямаме sde там. При нас, условно казано, дискът е отпаднал. Това предизвика проблеми с диска и приложенията също изпитаха проблеми при работа с клъстера на Postgres.

И в този случай Patroni няма да ни помогне по никакъв начин, защото Patroni няма задачата да следи състоянието на сървъра, състоянието на диска. И ние трябва да наблюдаваме такива ситуации чрез външно наблюдение. Бързо добавихме мониторинг на диск към външен мониторинг.

И имаше такава мисъл - може ли фехтовката или софтуерът за наблюдение да ни помогне? Мислехме, че той едва ли щеше да ни помогне в този случай, защото по време на проблемите Patroni продължи да взаимодейства с DCS клъстера и не видя никакъв проблем. Тоест от гледна точка на DCS и Patroni всичко беше наред с клъстера, въпреки че всъщност имаше проблеми с диска, имаше проблеми с наличността на базата данни.

По мое мнение това е един от най-странните проблеми, които съм изследвал от много дълго време, прочетох много журнали, избрах отново и го нарекох клъстерен симулатор.

Проблемът беше, че старият мастер не можеше да стане нормална реплика, т.е. Patroni го стартира, Patroni показа, че този възел присъства като реплика, но в същото време не беше нормална реплика. Сега ще видите защо. Това е, което запазих от анализа на този проблем.

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

Имаше прекъсвания на връзките, т.е. клиентите бяха разкъсани.

Имаше запушвания с различна тежест.

И съответно дисковата подсистема не е много отзивчива.

И най-мистериозното нещо за мен е пристигналата заявка за незабавно изключване. Postgres има три режима на изключване:

• Красиво е, когато чакаме всички клиенти да прекъснат връзката сами.
• Има бързо, когато принудим клиентите да прекъснат връзката, защото ще се изключим.
• И незабавно. В този случай immediate дори не казва на клиентите да се изключат, а просто се изключва без предупреждение. И на всички клиенти операционната система вече изпраща RST съобщение (TCP съобщение, че връзката е прекъсната и клиентът няма какво повече да хване).

Кой изпрати този сигнал? Фоновите процеси на Postgres не изпращат такива сигнали един на друг, т.е. това е kill-9. Те не изпращат такива неща един на друг, те реагират само на такива неща, т.е. това е спешно рестартиране на Postgres. Кой го изпрати, не знам.

Погледнах командата „последна“ и видях един човек, който също влезе в този сървър с нас, но бях твърде срамежлив да задам въпрос. Може би беше убийствено -9. Бих видял kill -9 в регистрационните файлове, защото Postgres казва, че отнема kill -9, но не го видях в регистрационните файлове.

Поглеждайки по-нататък, видях, че Patroni не пише в дневника доста дълго време - 54 секунди. И ако сравним две времеви марки, няма съобщения за около 54 секунди.

И през това време имаше автофайл. Patroni отново свърши страхотна работа. Старият ни господар не беше на разположение, нещо му се случи. И започна изборът на нов господар. Тук всичко се получи добре. Нашият pgsql01 стана новият лидер.

Имаме реплика станала майстор. И има втори отговор. И имаше проблеми с втората реплика. Тя се опита да преконфигурира. Доколкото разбирам, тя се опита да промени recovery.conf, да рестартира Postgres и да се свърже с новия мастер. На всеки 10 секунди пише съобщения, че се опитва, но не успява.

И по време на тези опити при стария господар пристига сигнал за незабавно изключване. Мастерът се рестартира. И също така възстановяването спира, защото старият майстор отива в рестартиране. Тоест репликата не може да се свърже с него, защото е в режим на изключване.

В един момент проработи, но репликацията не стартира.

Единственото ми предположение е, че имаше стар главен адрес в recovery.conf. И когато се появи нов мастер, втората реплика все още се опитваше да се свърже със стария мастер.

Когато Patroni стартира на втората реплика, възелът стартира, но не може да се репликира. И се образува репликационен лаг, който изглеждаше нещо подобно. Тоест и трите възела бяха на мястото си, но вторият възел изоставаше.

В същото време, ако погледнете регистрационните файлове, които са записани, можете да видите, че репликацията не може да започне, защото регистрационните файлове на транзакциите са различни. И тези регистрационни файлове на транзакциите, които главният предлага, които са посочени в recovery.conf, просто не отговарят на текущия ни възел.

И тук направих грешка. Трябваше да дойда и да видя какво има в recovery.conf, за да тествам хипотезата си, че се свързваме с грешния мастер. Но тогава просто се занимавах с това и не ми хрумна, или видях, че репликата изостава и ще трябва да се напълни отново, тоест някак си работих небрежно. Това беше моят джойнт.

След 30 минути вече дойде админът, т.е. рестартирах Patroni на репликата. Вече го сложих край, мислех си, че ще трябва да го напълня отново. И си помислих - ще рестартирам Patroni, може би ще се получи нещо добро. Възстановяването започна. И базата дори отвори, беше готова да приема връзки.

Репликацията е започнала. Но минута по-късно тя падна с грешка, че регистрационните файлове на транзакциите не са подходящи за нея.

Мислех да рестартирам отново. Рестартирах Patroni отново и не рестартирах Postgres, но рестартирах Patroni с надеждата, че магически ще стартира базата данни.

Репликацията започна отново, но маркировките в регистъра на транзакциите бяха различни, не бяха същите като предишния опит за стартиране. Репликацията отново спря. И посланието вече беше малко по-различно. И не ми беше много информативно.

И тогава ми хрумва - какво ще стане, ако рестартирам Postgres, в този момент направя контролна точка на текущия мастер, за да преместя точката в регистъра на транзакциите малко напред, така че възстановяването да започне от друг момент? Освен това все още имахме запаси от WAL.

Рестартирах Patroni, направих няколко контролни точки на главния, няколко точки за рестартиране на репликата, когато се отвори. И това помогна. Дълго мислих защо помогна и как работи. И репликата започна. И репликацията вече не беше разкъсана.

Такъв проблем за мен е един от по-мистериозните, над които още си лутам главата какво наистина се е случило там.

Какви са изводите тук? Patroni може да работи по предназначение и без никакви грешки. Но в същото време това не е 100% гаранция, че при нас всичко е наред. Репликата може да стартира, но може да е в полуработно състояние и приложението да не работи с такава реплика, защото ще има стари данни.

И след файла винаги трябва да проверявате дали всичко е наред с клъстера, тоест има необходимия брой реплики, няма забавяне на репликацията.

И докато разглеждаме тези проблеми, ще направя препоръки. Опитах се да ги комбинирам в два слайда. Вероятно всички истории могат да бъдат комбинирани в два слайда и само разказани.

Когато използвате Patroni, трябва да имате мониторинг. Винаги трябва да знаете кога е настъпило автоматично прехвърляне на файлове, защото ако не знаете, че сте имали автоматично прехвърляне на файлове, нямате контрол над клъстера. И това е лошо.

След всеки файл винаги трябва ръчно да проверяваме клъстера. Трябва да се уверим, че винаги имаме актуален брой реплики, няма забавяне на репликацията, няма грешки в регистрационните файлове, свързани с поточно репликиране, с Patroni, със системата DCS.

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

А Патрони не е сребърен куршум. Все още трябва да разберем как работи Postgres, как работи репликацията и как Patroni работи с Postgres и как се осигурява комуникацията между възлите. Това е необходимо, за да можете да отстраните проблеми с ръцете си.

Как да подходя към въпроса за диагнозата? Така се случи, че работим с различни клиенти и никой няма ELK стек и трябва да сортираме логовете, като отворим 6 конзоли и 2 раздела. В един раздел това са регистрационните файлове на Patroni за всеки възел, в другия раздел това са регистрационните файлове на Consul или Postgres, ако е необходимо. Много е трудно да се диагностицира това.

Какви подходи съм разработил? Първо, винаги гледам кога е пристигнал файлът. И за мен това е вододел. Гледам какво се случи преди филера, по време на филера и след филера. Fileover има два знака: това е началният и крайният час.

След това гледам в логовете за събития преди файла, които са предшествали файла, т.е. търся причините, поради които се е случил файлът.

И това дава картина на разбиране какво се е случило и какво може да се направи в бъдеще, за да не се случват подобни обстоятелства (и в резултат на това няма файл).

И къде търсим обикновено? Гледам:

• Първо, в регистрационните файлове на Patroni.
• След това разглеждам регистрационните файлове на Postgres или регистрационните файлове на DCS, в зависимост от това какво е намерено в регистрационните файлове на Patroni.
• И системните регистрационни файлове също понякога дават разбиране какво е причинило файла.

Какво чувствам към Patroni? Имам много добри отношения с Patroni. Според мен това е най-доброто, което има днес. Знам много други продукти. Това са Stolon, Repmgr, Pg_auto_failover, PAF. 4 инструмента. Опитах ги всичките. Patroni ми е фаворит.

Ако ме попитат: "Препоръчвам ли Patroni?". Ще кажа да, защото харесвам Patroni. И мисля, че се научих да го готвя.

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

Има някои интересни истории за хора, които се прострелват в краката. Много информативен. Четете и разбирате, че не е необходимо да го правите. Отметнах се.

И бих искал да кажа голямо благодаря на Zalando за разработването на този проект, а именно на Александър Кукушкин и Алексей Клюкин. Алексей Клюкин е един от съавторите, той вече не работи в Zalando, но това са двама души, които започнаха да работят с този продукт.

И мисля, че Patroni е много готино нещо. Радвам се, че я има, интересно е с нея. И голямо благодаря на всички сътрудници, които пишат пачове за Patroni. Надявам се Патрони да стане по-зрял, готин и ефективен с възрастта. Вече функционира, но се надявам да стане още по-добър. Ето защо, ако планирате да използвате Patroni, не се страхувайте. Това е добро решение, може да се приложи и използва.

Това е всичко. Ако имате въпроси питайте.

Въпроси

Благодаря за доклада! Ако след файл все пак трябва да погледнете там много внимателно, тогава защо се нуждаем от автоматичен файл?

Защото са нови неща. С нея сме само от година. По-добре да сте в безопасност. Искаме да влезем и да видим, че всичко наистина се е получило както трябва. Това е нивото на недоверие на възрастните - по-добре е да проверите отново и да видите.

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

Не сутрин, обикновено научаваме за автофайла почти веднага. Получаваме известия, виждаме, че е възникнал автофайл. Почти веднага отиваме и гледаме. Но всички тези проверки трябва да бъдат доведени до ниво мониторинг. Ако получите достъп до Patroni чрез REST API, има история. Чрез хронологията можете да видите времевите клейма, когато се е случило файлирането. Въз основа на това може да се направи мониторинг. Можете да видите историята, колко събития е имало. Ако имаме повече събития, значи е възникнал автофайл. Можеш да отидеш и да видиш. Или нашата автоматизация в мониторинга провери дали имаме всички реплики на място, няма забавяне и всичко е наред.

Благодаря ви!

Благодаря много за страхотния разказ! Ако преместим DCS клъстера някъде далеч от клъстера на Postgres, тогава този клъстер също трябва да се обслужва периодично? Какви са най-добрите практики, че някои части от DCS клъстера трябва да бъдат изключени, да се направи нещо с тях и т.н.? Как оцелява цялата тази структура? И как ги правиш тези неща?

За една компания беше необходимо да се направи матрица от проблеми, какво се случва, ако един от компонентите или няколко компонента се повредят. Съгласно тази матрица ние последователно преминаваме през всички компоненти и изграждаме сценарии в случай на повреда на тези компоненти. Съответно за всеки сценарий на повреда можете да имате план за действие за възстановяване. А в случая на DCS, той идва като част от стандартната инфраструктура. И админа го администрира, а ние вече разчитаме на админите, които го администрират и тяхната способност да го оправят при инциденти. Ако изобщо няма DCS, тогава го внедряваме, но в същото време не го наблюдаваме особено, защото не носим отговорност за инфраструктурата, но даваме препоръки как и какво да наблюдаваме.

Тоест, правилно ли разбрах, че трябва да деактивирам Patroni, да деактивирам файла, да деактивирам всичко, преди да направя нещо с хостовете?

Зависи от това колко възли имаме в DCS клъстера. Ако има много възли и ако деактивираме само един от възлите (репликата), тогава клъстерът поддържа кворум. И Patroni продължава да работи. И нищо не се задейства. Ако имаме някои сложни операции, които засягат повече възли, липсата на които може да съсипе кворума, тогава - да, може би има смисъл да поставим Patroni на пауза. Има съответна команда - patronictl pause, patronictl resume. Ние просто правим пауза и автоматичният файл не работи в този момент. Извършваме поддръжка на DCS клъстера, след което премахваме паузата и продължаваме да живеем.

Благодаря ви много!

Благодаря ви много за доклада! Как се чувства продуктовият екип относно загубата на данни?

Продуктовите екипи не се интересуват, а ръководителите на екипи са притеснени.

Какви гаранции има?

Гаранциите са много трудни. Александър Кукушкин има доклад „Как да изчислим RPO и RTO“, т.е. времето за възстановяване и колко данни можем да загубим. Мисля, че трябва да намерим тези слайдове и да ги проучим. Доколкото си спомням, има конкретни стъпки за изчисляване на тези неща. Колко транзакции можем да загубим, колко данни можем да загубим. Като опция можем да използваме синхронна репликация на ниво Patroni, но това е нож с две остриета: или имаме надеждност на данните, или губим скорост. Има синхронна репликация, но тя също не гарантира 100% защита срещу загуба на данни.

Алексей, благодаря за страхотния репортаж! Имате ли опит с използването на Patroni за защита от нулево ниво? Тоест, във връзка със синхронен режим на готовност? Това е първият въпрос. И вторият въпрос. Използвали сте различни решения. Използвахме Repmgr, но без autofiler, а сега планираме да включим autofiler. И ние разглеждаме Patroni като алтернативно решение. Какво можете да кажете като предимства в сравнение с Repmgr?

Първият въпрос беше за синхронните реплики. Никой не използва синхронна репликация тук, защото всички се страхуват (Няколко клиента вече го използват, по принцип не са забелязали проблеми с производителността - Бележка на лектора). Но ние разработихме правило за себе си, че трябва да има поне три възела в клъстер за синхронна репликация, защото ако имаме два възела и ако главният или репликата се провалят, тогава Patroni превключва този възел в самостоятелен режим, така че приложението да продължи работа. В този случай съществува риск от загуба на данни.

По отношение на втория въпрос, използвахме Repmgr и все още го използваме с някои клиенти поради исторически причини. Какво може да се каже? Patroni идва с автоматичен файл, Repmgr идва с автоматичен файл като допълнителна функция, която трябва да бъде активирана. Трябва да стартираме демона Repmgr на всеки възел и след това можем да конфигурираме автоматичния файл.

Repmgr проверява дали възлите на Postgres са живи. Repmgr процесите проверяват за съществуването един на друг, това не е много ефективен подход. може да има сложни случаи на мрежова изолация, при които голям Repmgr клъстер може да се разпадне на няколко по-малки и да продължи да работи. Не следя Repmgr от дълго време, може би беше коригирано ... или може би не. Но премахването на информация за състоянието на клъстера в DCS, както прави Stolon, Patroni, е най-жизнеспособният вариант.

Алексей, имам един въпрос, може би ламерски. В един от първите примери преместихте DCS от локалната машина към отдалечен хост. Разбираме, че мрежата е нещо, което има свои собствени характеристики, живее самостоятелно. И какво се случва, ако по някаква причина DCS клъстерът стане недостъпен? Няма да казвам причините, може да има много от тях: от кривите ръце на мрежите до реални проблеми.

Не съм го казал на глас, но DCS клъстерът също трябва да бъде failover, т.е. това е нечетен брой възли, за да бъде постигнат кворум. Какво се случва, ако DCS клъстерът стане недостъпен или не може да бъде постигнат кворум, т.е. някакъв вид мрежово разделяне или повреда на възел? В този случай клъстерът Patroni преминава в режим само за четене. Клъстерът Patroni не може да определи състоянието на клъстера и какво да прави. Той не може да се свърже с DCS и да съхрани там новото състояние на клъстера, така че целият клъстер преминава в режим само за четене. И чака или ръчна намеса от оператора, или DCS да се възстанови.

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

Да да. В толкова много модерни компании, Service Discovery е неразделна част от инфраструктурата. Внедрява се още преди да има дори база данни в инфраструктурата. Относително казано, инфраструктурата беше стартирана, разгърната в DC и веднага имаме Service Discovery. Ако е Consul, тогава DNS може да бъде изграден върху него. Ако това е Etcd, тогава може да има част от клъстера Kubernetes, в която ще бъде разположено всичко останало. Струва ми се, че Service Discovery вече е неразделна част от съвременните инфраструктури. И те мислят за това много по-рано, отколкото за бази данни.

Благодаря ви!

Източник: www.habr.com