Истории за провал на Patroni или как да сринете кластер на PostgreSQL. Алексей Лесовски

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

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

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

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

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

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

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

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

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

Какво е Patroni?

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

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

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

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

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

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

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

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

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

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

Но файловерът не винаги е мигновен, т.е. не отнема определено време, той може да се проточи. Може да продължи дълго.

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

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

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

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

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

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

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

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

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

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

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

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

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

Втората проблема е подобна на първата. Тя е подобна, защото отново имаме проблеми с взаимодействието с DCS системата.

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

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

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

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

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

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

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

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

Най-простият отговор е да се поправи мрежата. Но на мен, стоейки на трибуната, ми е лесно да заявя това. Но обстоятелствата се развиват така, че не винаги клиентът може да си позволи да поправи мрежата. Може да се намира в ДЦ и да няма възможности да поправи мрежата или да влияе на оборудването. Затова са нужни някакви други варианти.

Има варианти:

• Най-простият вариант, който е записан, мисля дори в документацията, е да се изключат проверките на Consul, т.е. просто да се предаде празен масив. И ние казваме на агента на Consul да не използва никакви проверки. Чрез тези проверки можем да игнорираме тези мрежови бурі и да не иницираме смяна.
• Друг вариант е да се пре провери raft_multiplier. Това е параметър на самия Consul сървър. По подразбиране той е зададен на 5. Това значение е препоръчано в документацията за staging среди. Всъщност това влияе на честотата на обмена на съобщения между участниците в мрежата на Consul. Всъщност, този параметър влияе на скоростта на служебното общуване между участниците в кластера на Consul. И за production вече се препоръчва да се намали, така че възлите да обменят съобщения по-често.
• Друг вариант, който започнахме да използваме, е увеличаването на приоритета на процесите на Consul спрямо другите процеси за планиращия процес на операционната система. Има такъв параметър „nice“, който точно определя приоритета на процесите, което се взима предвид от ОС при планирането. Ние намалихме стойността на nice за агентите на Consul, т.е. повишихме приоритета, за да може операционната система да предостави на процесите на Consul повече време за работа и изпълнение на кода си. В нашия случай това реши проблема ни.
• Друг вариант е да не използвате Consul. Имам приятел, който е голям привърженик на Etcd. И ние редовно спорим за това кое е по-добре – Etcd или Consul. Но по отношение на това кое е по-добро, обикновено достигаме до споразумение, че Consul има агент, който трябва да бъде стартиран на всеки възел с база данни. Тоест, взаимодействието на Patroni с клъстера на Consul става чрез този агент. И този агент става „тесен момент“. Ако нещо се случи с агента, Patroni вече не може да работи с клъстера на Consul. И това е проблем. При Etcd няма такъв агент. Patroni може директно да работи със списъка на Etcd-сървърите и да комуникира с тях. В това отношение, ако използвате Etcd в компанията си, Etcd вероятно ще бъде по-добрият избор от Consul. Но ние при нашите клиенти винаги сме ограничени от това, което клиентът е избрал и използва. И при нас по-голямата част от клиентите имат Consul.
• И последната точка е да прегледате стойностите на параметрите. Можем да увеличим тези параметри в голямо направление с надеждата, че нашите краткотрайни мрежови проблеми ще бъдат кратки и няма да попаднат в интервала на тези параметри. По този начин можем да намалим агресивността на Patroni при извършването на автоматичен фейловер, ако възникнат някакви мрежови проблеми.

Мисля, че мнозина, които използват Patroni, са запознати с тази команда.

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

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

В този случай втората реплика стана мастер. Тук всичко е наред.

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

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

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

Сравнявах времевите печати, когато се случиха тези събития. И там разликата е буквално 150 милисекунди, т.е. в 369 милисекунди завърши checkpoint, бяха преименувани WAL-сегментите. И буквално в 517, след 150 милисекунди стартира rewind на старата реплика. Т.е. буквално 150 милисекунди ни стигнаха, за да не може репликата да се свърже и да заработи.

Какви са вариантите?

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

Но тук има проблем, че, когато мастерът се премести в реплику, той изтрива слотове и заедно с тях изтрива WAL-сегменти. И за да избегнем появата на този проблем, решихме да увеличим параметъра wal_keep_segments. По подразбиране той е 8 сегмента. Ние го увеличихме до 1000 и наблюдавахме колко свободно място имаме. И ние дарихме 16 гигабайта за wal_keep_segments. Тоест, при превключване винаги имаме резерв от 16 гигабайта журнални транзакции на всички възли.

И плюс – това е актуално и за продължителни задачи по поддръжка. Да кажем, трябва да обновим една от репликите. Искаме да я изключим. Трябва да обновим софтуера, може би операционната система, още нещо. И когато изключваме репликата, за нея също се изтрива слот. И ако използваме малък wal_keep_segments, при продължително отсъствие на репликата, журналите на транзакции ще бъдат изгубени. Ние ще възстановим репликата, тя ще поиска онези журнални транзакции, на които е спряла, но на мастера може да не ги има. И репликата също няма да може да се свърже. Затова поддържаме голям запас от журнални записи.

Имаме production-база. Там вече работят проекти.

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

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

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

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

Нашият стар мастер се рестартира. И в автозапускането беше вписан Patroni. Patroni се стартира. След това стартира Postgres. По-точно, преди стартирането на Postgres и преди да го направи реплика, Patroni стартира процеса pg_rewind. Съответно, той изтри част от журналите на транзакции, изтегли нови и се свърза. Тук Patroni работи отлично, тоест, както е предвидено. Кластърът ни се възстанови. Имахме 3 нода, след файловера 3 нода – всичко е страхотно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И най-загадъчното за мен – това беше дошлия моментален shutdown request. При Postgres има три режима на изключване:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И изведнъж ми хрумва – а какво, ако рестартирам Postgres, докато на текущия майстор направя checkpoint, за да изместя точката в журнала на транзакциите малко напред, за да започне възстановяването от друга точка? Плюс там още имахме резерви на WAL.

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

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

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

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

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

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

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

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

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

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

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

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

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

Къде обикновено гледаме? Аз гледам:

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

Как възприемам Patroni? Възприемам Patroni много положително. Според мен, това е най-доброто, което имаме днес. Знам много други продукти. Това са Stolon, Repmgr, Pg_auto_failover, PAF. Четири инструмента. Опитвал съм всички тях. Patroni ми хареса най-много.

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

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

Там има интересни истории за това как хората си вредят сами. Много поучително. Читеш и разбираш, че така не трябва да се прави. Поставил си отметка.

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

И смятам, че Patroni е много страхотно нещо. Доволен съм, че съществува, работи е интересно. И голямо благодаря на всички контрибутори, които пишат пачове за 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 за защита на ниво нула? Т.е. в съчетание с синхронен standby? Това е първият въпрос. И вторият въпрос. Вие използвахте различни решения. Ние използвахме Repmgr, но без автофайловер и сега планираме да включим автофайловер. И разглеждаме Patroni като алтернативно решение. Какво можете да кажете за предимствата по отношение на Repmgr?

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

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

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

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

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

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

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

Благодаря!

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