Патронијев главни циљ је да обезбеди високу доступност за ПостгреСКЛ. Али Патрони је само шаблон, а не готов алат (што, генерално, каже документација). На први поглед, након што сте конфигурисали Патрони у тестној лабораторији, можете видети какав је то диван алат и како лако подноси наше покушаје да уништимо кластер. Међутим, у пракси у производном окружењу, све се не дешава увек тако лепо и елегантно као у лабораторији за тестирање.
Рећи ћу вам мало о себи. Почео сам као систем администратор. Радио у веб развоју. У Дата Егрету радим од 2014. године. Компанија се бави консалтингом у области Постгреса. Ми посебно сервисирамо Постгрес и радимо са Постгресом сваки дан, тако да имамо разноврсну оперативну експертизу.
И крајем 2018. почели смо полако да користимо Патрони. И стечено је неко специфично искуство. Некако смо то дијагностиковали, подесили и дошли до наших најбољих пракси. И у овом извештају ћу говорити о њима.
Поред Постгреса, волим LinuxВолим да се петљам са тим и истражујем, и волим да правим језгра. Волим виртуелизацију, контејнере, Докер и Кубернетес. Занима ме све ово јер ме моје старе администраторске навике сустижу. Волим да се петљам са праћењем. Такође волим ствари везане за Постгрес, а које се тичу администрације, попут репликације и резервних копија. А у слободно време пишем у Гоу. Нисам софтверски инжењер, пишем у Гоу само за себе. И уживам у томе.
- Мислим да многи од вас знају да Постгрес нема ХА (Хигх Аваилабилити) ван кутије. Да бисте добили ХА, морате нешто да убаците, конфигуришете, уложите напор и добијете то.
- Постоји неколико алата и Патрони је један од њих, који решава ХА прилично цоол и веома добро. Али ако све то ставимо у тестну лабораторију и покренемо, можемо видети да све функционише, можемо да репродукујемо неке проблеме, видимо како их Патрони сервисира. И видећемо да све то одлично функционише.
- Али у пракси смо наишли на различите проблеме. И ја ћу говорити о овим проблемима.
- Рећи ћу вам како смо то дијагностиковали, шта смо подесили – да ли нам је помогло или није.
- Нећу вам рећи како да инсталирате Патрони, јер можете да га прогуглате на Интернету, можете погледати конфигурационе датотеке да бисте разумели како све почиње и како се конфигурише. Можете разумети дијаграме и архитектуре тако што ћете пронаћи информације о њима на Интернету.
- Нећу да причам о туђим искуствима. Говорићу само о проблемима са којима смо се суочили.
- И нећу говорити о проблемима који су изван Патронија и ПостгреСКЛ-а. Ако, на пример, постоје проблеми у вези са балансирањем када се наш кластер срушио, нећу о томе.
И мало одрицање одговорности пре него што почнемо са нашим извештајем.
Све ове проблеме са којима смо наишли, имали смо их у првих 6-7-8 месеци рада. Временом смо дошли до сопствене интерне најбоље праксе. И наши проблеми су нестали. Дакле, извештај је поднет пре неких шест месеци, када ми је све било свеже у глави и све сам се савршено сећао.
Током припреме извештаја, већ сам покупио старе обдукције и погледао трупце. А неки од детаља су можда заборављени, или неки детаљи можда нису у потпуности истражени током анализе проблема, па се у неким моментима може чинити да проблеми нису у потпуности размотрени, или постоји нека врста мањак информација. И зато вас молим да ми опростите за овај тренутак.
Шта је Патрони?
- Ово је шаблон за изградњу ХА. Тако пише у документацији. И са моје тачке гледишта, ово је врло исправно појашњење. Патрони није сребрни метак који ће решити све ваше проблеме, односно потребно је да се потрудите да проради и буде користан.
- Ово је сервис агента који је инсталиран на сваком сервису са базом података и који је нека врста инит система за ваш Постгрес. Покреће Постгрес, зауставља га, поново покреће, мења конфигурацију и мења топологију вашег кластера.
- Сходно томе, да би се сачувало стање кластера, његова тренутна репрезентација, како изгледа, потребна је нека врста складиштења. И са ове тачке гледишта, Патрони је кренуо путем чувања стања у спољном систему. То је дистрибуирани систем за складиштење конфигурације. Ово може бити Етцд, Цонсул, ЗооКеепер или кубернетес Етцд, тј. једна од ових опција.
- А једна од карактеристика Патронија је да аутоматски пребацујете фајлове из кутије, тек након што га подесите. Ако узмемо Репмгр за поређење, филер је ту укључен. Са Репмгр-ом добијамо пребацивање, али ако желимо аутофилеовер, онда га треба даље конфигурисати. Патрони већ има аутофилеовер из кутије.
- И има још много других ствари. На пример, одржавање конфигурација, додавање нових реплика, резервних копија итд. Али ово је ван оквира извештаја, нећу о томе да причам.
А мали резултат је да је главни задатак Патронија да добро и поуздано изврши аутофилеовер како би наш кластер остао оперативан и апликација не примети промене у топологији кластера.
Али када почнемо да користимо Патрони, наш систем постаје мало сложенији. Ако смо раније имали Постгрес, онда када користимо Патрони добијамо сам Патрони, добијамо ДЦС, где се стање чува. И све то мора некако да функционише. Дакле, шта се може сломити?
Може да се прекине:
- Постгрес се може покварити. То може бити мајстор или реплика, један од њих може пропасти.
- Сам Патрони се може покварити.
- ДЦС, где је стање ускладиштено, може да се поквари.
- И мрежа се може покварити.
Све ове тачке ћу размотрити у извештају.
Разматраћу случајеве како постану сложенији, а не са становишта да предмет укључује много компоненти. И са становишта субјективних осећања, овај кофер ми је био сложен, тешко га је било раставити...и обрнуто, неки кофер је био лаган и лако се растављао.
А први случај је најједноставнији. Ово је случај када смо узели кластер базе података и распоредили наше ДЦС складиште на истом кластеру. Ово је најчешћа грешка. Ово је грешка у изградњи архитектуре, односно комбиновање различитих компоненти на једном месту.
Дакле, десио се фајл, хајде да схватимо шта се догодило.
И овде нас интересује када се десио филер. Односно, занима нас овај тренутак када се стање кластера променило.
Али филер није увек тренутан, тј. не траје одређену јединицу времена, може се повући. Може бити дуготрајан.
Дакле, има време почетка и време завршетка, односно то је континуирани догађај. И све догађаје делимо на три интервала: имамо време пре филера, током филера и после филера. Односно, разматрамо све догађаје у овој временској линији.
И пре свега, када се десио филер, тражимо разлог, шта се догодило, шта је изазвало оно што је довело до филера.
Ако погледамо трупце, ово су класични Патрони трупци. У њима нам он говори да је сервер постао мастер, а улога мастера је прешла на овај чвор. Овде је истакнуто.
Затим, морамо да разумемо зашто је дошло до филера, тј. који догађаји су се десили због којих се главна улога помера са једног чвора на други. А у овом случају све је једноставно. Имамо грешку у интеракцији са системом за складиштење. Мајстор је схватио да не може да ради са ДЦС-ом, односно да постоји неки проблем са интеракцијом. И каже да не може више да буде мајстор и даје оставку. Ова линија „деградирано ја“ говори управо то.
Ако погледамо догађаје који су претходили филеру, тамо можемо уочити управо разлоге који су представљали проблем за наставак рада мајстора.
Ако погледамо Патрони логове, видећемо да имамо много грешака и тајм-аута, тј. Патрони агент не може да ради са ДЦС-ом. У овом случају, ово је конзул агент, са којим се комуникација одвија на порту 8500.
Проблем је у томе што Patroni и база података раде на истом хосту. Консул сервери су такође радили на истом хосту. Оптерећењем сервера, створили смо проблеме за сервери Конзуле. Нису могли нормално да комуницирају.
Након неког времена, када се оптерећење спустило, наш Патрони је поново могао да комуницира са агентима. Нормалан рад је настављен. И исти Пгдб-2 сервер је поново постао господар. Односно, дошло је до малог превртања, због чега се чвор одрекао својих овлашћења као господара, а затим их поново преузео, односно све се вратило како је било.
И ово се може сматрати лажним позитивним, или се може сматрати да је Патрони урадио све како треба. Односно, схватио је да не може да одржи стање кластера и уклонио је свој ауторитет.
И овде је проблем настао због чињенице да се сервери Цонсул налазе на истој опреми као и базе података. Сходно томе, свако оптерећење: било да је то оптерећење дискова или процесора, такође утиче на интеракцију са Цонсул кластером.
И одлучили смо да ово не треба да живи заједно, издвојили смо засебан кластер за Конзула. А Патрони је већ радио са засебним конзулом, тј. постојао је посебан кластер Постгрес, посебан кластер конзула. Ово је основно упутство о томе како раздвојити и држати све ове ствари тако да не живе заједно.
Алтернативно, можете подесити параметре ттл, лооп_ваит, ретри_тимеоут, тј. покушати да преживите ове краткорочне врхове оптерећења повећањем ових параметара. Али ово није најпогоднија опција, јер ово оптерећење може бити дуготрајно. И једноставно ћемо прећи ове границе ових параметара. А то можда неће баш помоћи.
Први проблем, као што разумете, је једноставан. Узели смо ДЦС и спојили га са базом и добили смо проблем.
Други проблем је сличан првом. Слично је и по томе што поново имамо проблема у интеракцији са ДЦС системом.
Ако погледамо дневнике, видећемо да поново имамо грешку у комуникацији. А Патрони каже да не могу да комуницирам са ДЦС-ом, тако да тренутни мастер прелази у режим реплике.
Стари мајстор постаје реплика, овде Патрони ради како треба. Покреће пг_ревинд да премота евиденцију трансакција и затим се повеже са новим мастером, а затим ухвати корак са новим мастером. Овде Патрони ради како треба.
Овде морамо пронаћи место које је претходило филеру, односно оне грешке које су изазвале појаву филера. И у том погледу, Патрони дневники су прилично згодни за рад. У одређеним интервалима пише исте поруке. А ако почнемо брзо да скролујемо кроз ове дневнике, онда ћемо из дневника видети да су се логови променили, што значи да су почели неки проблеми. Брзо се враћамо на ово место и видимо шта се дешава.
А у нормалној ситуацији, дневници изгледају отприлике овако. Власник браве је проверен. А ако се власник, рецимо, промени, онда се могу десити неки догађаји на које Патрони мора да одговори. Али у овом случају сви смо у реду. Тражимо место где су грешке почеле.
И померајући се до тачке где су почеле да се појављују грешке, видимо да имамо аутоматско преокретање датотека. А пошто су наше грешке биле везане за интеракцију са ДЦС-ом и у нашем случају смо користили Цонсул, такође гледамо Цонсул логове да видимо шта се тамо догодило.
Приближно упоредивши време подносиоца и време у Конзулским дневникима, видимо да су наши суседи у Конзулском кластеру почели да сумњају у постојање других чланова Конзулског кластера.
А ако погледате логове других конзулских агената, такође можете видети да се тамо дешава нека врста колапса мреже. И сви чланови кластера Конзула сумњају једни у друге. И ово је био подстицај за филера.
Ако погледате шта се дешавало пре ових грешака, можете видети да постоје разне врсте грешака, на пример, рок, РПЦ је пао, односно очигледно постоји неки проблем у међусобној интеракцији чланова Конзул кластера.
Најједноставнији одговор је поправити мрежу. Али, стојећи на подијуму, лако ми је ово да кажем. Али околности су такве да купац не може увек да приушти поправку мреже. Можда живи у ДЦ-у и можда нема могућност да поправља мрежу или утиче на опрему. И стога су потребне неке друге опције.
Постоје опције:
- Најједноставнија опција, која је, по мом мишљењу, написана чак иу документацији, јесте да се онемогуће Цонсул провере, односно једноставно проследи празан низ. И ми кажемо конзулском агенту да не користи никакве чекове. Због ових провера, можемо да занемаримо ове мрежне олује и да не покренемо датотеку.
- Друга опција је да још једном проверите рафт_мултиплиер. Ово је параметар самог Цонсул сервера. Подразумевано је постављена на 5. Ова вредност се препоручује у складу са документацијом за окружења за постављање. У суштини, ово утиче на учесталост размене порука између чланова мреже Конзула. У суштини, овај параметар утиче на брзину званичне комуникације између чланова Конзул кластера. А за производњу се већ препоручује да се смањи како би чворови чешће размењивали поруке.
- Друга опција коју смо почели да користимо била је да повећамо приоритет процеса Цонсул међу осталим процесима за планер процеса оперативног система. Постоји такав параметар „лепо“, он само одређује приоритет процеса који ОС планер узима у обзир приликом планирања. Такође смо смањили лепу вредност за конзуларне агенте, тј. повећао приоритет тако да оперативни систем даје Цонсул процесима више времена за рад и извршавање свог кода. У нашем случају, ово је решило наш проблем.
- Друга опција је да не користите Цонсул. Имам пријатеља који је велики присталица Етцд-а. И он и ја се редовно расправљамо шта је боље, итд или Конзул. Али у погледу тога шта је боље, он и ја се генерално слажемо да Цонсул има агента који треба да ради на сваком чвору базе података. Односно, Патронијева интеракција са Конзул кластером се дешава преко овог агента. И овај агент постаје уско грло. Ако се нешто деси агенту, Патрони више не може да ради са Конзул кластером. И ово је проблем. У Етцд плану нема агента. Патрони може директно да ради са листом Етцд сервера и да већ комуницира са њима. У том погледу, ако користите Етцд у својој компанији, онда ће Етцд вероватно бити бољи избор од Цонсул-а. Али са нашим купцима, увек смо ограничени оним што је клијент изабрао и користи. И углавном сви наши клијенти имају Конзула.
- И последња тачка је да се преиспитају вредности параметара. Можемо подићи ове параметре више у нади да ће наши краткорочни мрежни проблеми бити кратки и да неће пасти у опсег ових параметара. На овај начин можемо смањити агресивност Патронија да изврши аутофилеовер ако се појаве било какви мрежни проблеми.
Мислим да су многи који користе Патрони упознати са овом командом.
Ова команда показује тренутно стање кластера. И на први поглед ова слика може изгледати нормално. Имамо мајстора, имамо реплику, нема кашњења у репликацији. Али ова слика је нормална док не знамо да овај кластер треба да има три чвора, а не два.
Сходно томе, дошло је до аутоматског пребацивања датотека. И након овог аутоматског преласка, наша реплика је нестала. Морамо открити зашто је нестала и вратити је, обновити. И поново идемо у евиденцију и погледамо зашто је дошло до аутоматског пребацивања датотека.
У овом случају, друга реплика је постала мајстор. Овде је све у реду.
И треба да погледамо реплику која је отпала и није у кластеру. Отварамо Патрони дневнике и видимо да смо имали проблем у фази пг_ревинд приликом повезивања на кластер. Да бисте се повезали са кластером, потребно је да премотате дневник трансакција, затражите потребну евиденцију трансакција од мастера и користите га да ухватите корак са мастером.
У овом случају, немамо евиденцију трансакција и реплика не може да се покрене. Сходно томе, заустављамо Постгрес са грешком. И зато није у кластеру.
Морамо да разумемо зашто није у кластеру и зашто није било дневника. Идемо до новог мајстора и погледамо шта има у својим логима. Испоставило се да када је пг_ревинд урађен, дошло је до контролне тачке. А неки од старих дневника трансакција су једноставно преименовани. Када је стари мастер покушао да се повеже са новим мастером и затражи ове евиденције, они су већ били преименовани, једноставно нису постојали.
Упоредио сам временске ознаке када су се ти догађаји десили. И ту је разлика буквално 150 милисекунди, односно за 369 милисекунди контролна тачка је завршена, ВАЛ сегменти су преименовани. И буквално на 517, 150 милисекунди касније, почело је премотавање на старој реплици. Односно, буквално 150 милисекунди нам је било довољно да спречимо да се реплика повеже и ради.
Које су опције?
У почетку смо користили слотове за репликацију. Мислили смо да је добро. Иако смо у првој фази рада онемогућили слотове. Чинило нам се да ако слотови нагомилају много ВАЛ сегмената, можемо испустити мастер. Он ће пасти. Патили смо неко време без слотова. И схватили смо да су нам слотови потребни, вратили смо слотове.
Али овде постоји проблем што када мастер пређе на реплику, он брише слотове и, заједно са слотовима, брише ВАЛ сегменте. И да бисмо елиминисали овај проблем, одлучили смо да подигнемо параметар вал_кееп_сегментс. Подразумевано је 8 сегмената. Подигли смо га на 1 и погледали колико слободног простора имамо. И донирали смо 000 гигабајта за вал_кееп_сегментс. То јест, приликом пребацивања увек имамо резерву од 16 гигабајта евиденције трансакција на свим чворовима.
И плус – ово је такође релевантно за дугорочне задатке одржавања. Рецимо да треба да ажурирамо једну од реплика. И желимо да га искључимо. Морамо да ажурирамо софтвер, можда оперативни систем, нешто друго. А када искључимо реплику, уклања се и слот за ту реплику. А ако користимо мале вал_кееп_сегментс, онда ако постоји дуго одсуство реплике, евиденција трансакција ће бити изгубљена. Покупићемо реплику, она ће захтевати те евиденције трансакција тамо где је стала, али они можда нису на мастеру. А реплика такође неће моћи да се повеже. Зато држимо велику залиху часописа.
Имамо производну базу. Тамо већ раде пројекти.
Дошло је до фајла. Ушли смо и погледали – све је у реду, реплике су на месту, нема застоја у репликацији. Ни у логовима нема грешака, све је у реду.
Тим производа каже да изгледа да би требало да постоје неки подаци, али ми их видимо из једног извора, али их не видимо у бази података. И треба да разумемо шта им се десило.
Јасно је да их је пг_ревинд избрисао. То смо одмах схватили, али смо отишли да видимо шта се дешава.
У евиденцији увек можемо да пронађемо када се појавио филер, ко је постао мастер, и можемо да утврдимо ко је био стари мастер и када је желео да постане реплика, тј. изгубљен.
Наш стари мајстор се поново покренуо. А Патрони је регистрован у аутостарту. Патрони је покренут. Затим је покренуо Постгрес. Тачније, пре покретања Постгреса и пре него што је направио реплику, Патрони је покренуо процес пг_ревинд. Сходно томе, он је обрисао неке од евиденције трансакција, преузео нове и повезао се. Овде је Патрони одлично одрадио посао, односно како и треба. Наш кластер је обновљен. Имали смо 3 чвора, након филера су била 3 чвора - све је било цоол.
Изгубили смо неке податке. И треба да схватимо колико смо изгубили. Тражимо тачно тренутак када смо имали премотавање. Ово можемо сазнати из ових дневничких записа. премотавање је почело, урадио нешто тамо и завршио.
Морамо да пронађемо позицију у евиденцији трансакција где је стари мастер стао. У овом случају, то је ова ознака. И потребна нам је друга ознака, односно раздаљина по којој се стари мајстор разликује од новог.
Узимамо уобичајени пг_вал_лсн_дифф и упоређујемо ове две ознаке. И у овом случају добијамо 17 мегабајта. Да ли је ово много или мало, свако одлучује за себе. Јер за неке 17 мегабајта није много, за друге је много и неприхватљиво. Овде свако одлучује за себе појединачно у складу са потребама пословања.
Али шта смо сами открили?
Прво, морамо сами да одлучимо - да ли нам је увек потребно Патрони аутостарт након поновног покретања система? Чешће се дешава да морамо да одемо код старог мајстора, да видимо докле је отишао. Можда прегледајте сегменте дневника трансакција, видите шта је тамо. И схватите да ли можемо да изгубимо ове податке или треба да покренемо стари мастер у самосталном режиму да бисмо преузели ове податке.
И тек након овога морамо одлучити да ли можемо да одбацимо ове податке или да их вратимо, да повежемо овај чвор као реплику са нашим кластером.
Поред тога, постоји параметар „макимум_лаг_он_фаиловер“. Подразумевано, ако ме меморија не вара, овај параметар има вредност од 1 мегабајт.
Како он ради? Ако наша реплика заостаје за 1 мегабајт података у кашњењу репликације, онда ова реплика не учествује на изборима. А ако се изненада појави филер, Патрони гледа које реплике заостају. Ако заостају за великим бројем евиденција трансакција, не могу постати господар. Ово је веома добра безбедносна функција која вас спречава да изгубите много података.
Али постоји проблем што се кашњење репликације у Патрони и ДЦС кластеру ажурира у одређеном интервалу. Мислим да је 30 секунди подразумевана вредност ттл.
Сходно томе, може доћи до ситуације у којој је кашњење у репликацији за реплике у ДЦС-у исто, али у ствари може постојати потпуно другачије кашњење или га уопште нема, тј. ова ствар није у реалном времену. И не одражава увек стварну слику. И не вреди правити фенси логику о томе.
А ризик од губитка увек остаје. И у најгорем случају постоји једна формула, ау просечном случају друга формула. Односно, када планирамо имплементацију Патронија и проценимо колико података можемо да изгубимо, морамо се ослонити на ове формуле и приближно замислити колико података можемо изгубити.
И има добрих вести. Када стари мајстор крене напред, може да настави због неких позадинских процеса. Односно, постојала је нека врста аутовакума, записао је податке и сачувао их у дневник трансакција. И лако можемо занемарити и изгубити ове податке. Нема проблема са овим.
А овако изгледају евиденције ако је подешен максимум_лаг_он_фаиловер и дође до преласка фајла, а ви морате да изаберете нови мастер. Реплика себе оцењује као неспособну за учешће на изборима. И одбија да учествује у трци за лидерство. И чека да се изабере нови мајстор, да би се онда могла повезати с њим. Ово је додатна мера против губитка података.
Овде је наш производни тим написао да њихов производ има проблема при раду са Постгрес-ом. Истовремено, не можете приступити самом мастеру, јер није доступан преко ССХ-а. А ни аутофилеовер се не дешава.
Овај домаћин је био приморан на поновно покретање. Због поновног покретања, дошло је до аутоматског пребацивања датотека, иако је било могуће урадити и ручно аутоматско преокретање датотека, како сада разумем. И после поновног покретања идемо да видимо шта смо имали са тренутним мастером.
У исто време, унапред смо знали да имамо проблема са дисковима, односно већ смо знали из праћења где да копамо и шта да тражимо.
Ушли смо у постгрес дневник и почели да гледамо шта се тамо дешава. Видели смо урезивања која су трајала једну, две или три секунде, што уопште није нормално. Видели смо да нашем аутовакуму треба веома дуго и чудно време да се покрене. И видели смо привремене датотеке на диску. Односно, све су то показатељи проблема са дисковима.
Погледали смо у системски дмесг (дневник нуклеарних порука). И видели смо да имамо проблема са једним од дискова. Дисковни подсистем је био софтверски Раид. Погледали смо /проц/мдстат и видели да нам недостаје један диск. То јест, постоји Раид од 8 дискова, један нам недостаје. Ако пажљиво погледате слајд, можете видети у излазу да тамо немамо сде. Наш диск је, релативно говорећи, испао. Ово је изазвало проблеме са диском, а апликације су такође имале проблеме при раду са Постгрес кластером.
А у овом случају, Патрони нам никако не би помогао, јер Патрони нема задатак да прати стање сервера, стање диска. И такве ситуације морамо пратити спољним надзором. Додали смо надгледање оперативног диска спољном надзору.
И постојала је ова мисао – да ли би нам софтвер за мачевање или чувар могао помоћи? Мислили смо да је мало вероватно да би нам он помогао у овом случају, јер је током проблема Патрони наставио да комуницира са ДЦС кластером и није видео никакав проблем. Односно, са становишта ДЦС-а и Патронија, све је било у реду са кластером, иако је у ствари било проблема са диском, било је проблема са доступношћу базе података.
По мом мишљењу, ово је један од најчуднијих проблема који сам истраживао веома дуго, поново читао много дневника, петљао по њему и назвао га симулатором кластера.
Проблем је био у томе што стари мајстор није могао да постане нормална реплика, односно Патрони га је покренуо, Патрони је показао да је овај чвор присутан као реплика, али у исто време није нормална реплика. Сада ћете видети зашто. Задржао сам ово од анализе тог проблема.
А где је све почело? Почело је, као иу претходном проблему, са диск кочницама. Имали смо урезивања једну по секунду, две по једну.
Дошло је до прекида везе, односно прекида везе са клијентима.
Било је блокада различите тежине.
И, сходно томе, подсистем диска не реагује много.
А најмистериозније за мене је захтев за моментално гашење који је стигао. Постгрес има три режима искључивања:
- Лепо је када чекамо да се сви клијенти сами прекину.
- Постоји брзо, када приморавамо клијенте да прекину везу јер ћемо се искључити.
- И одмах. У овом случају, инстант чак и не говори клијентима да се искључе, само се гаси без упозорења. А оперативни систем шаље РСТ поруку свим клијентима (ТЦП порука да је веза прекинута и да клијент нема више шта да ухвати).
Ко је послао овај сигнал? Позадина Постгрес процеси не шаљу такве сигнале једни другима, тј. ово је килл-9. Они ово не шаљу једни другима, они само реагују на ово, односно ово је хитно поновно покретање Постгреса. Не знам ко га је послао.
Погледао сам „последњу“ команду и видео сам једну особу која се такође пријавила на овај сервер са нама, али ми је било непријатно да поставим питање. Можда је било убиство -9. Видео бих да убије -9 у евиденцији, јер... Постгрес каже да је прихватио килл -9, али ја то нисам видео у евиденцији.
Гледајући даље, видео сам да Патрони није писао у дневник доста дуго - 54 секунде. А ако упоредите две временске ознаке, није било порука око 54 секунде.
И за то време дошло је до аутофилеовер-а. Патрони је овде поново радио одлично. Наш стари мајстор је био недоступан, нешто му се дешавало. И почео је избор новог господара. Овде је све добро испало. Наш пгскл01 је постао наш нови лидер.
Имамо реплику која је постала мајстор. А постоји и друга реплика. И било је проблема са другом примедбом. Покушала је да се поново конфигурише. Колико сам разумео, покушала је да промени рецовери.цонф, поново покрене Постгрес и повеже се са новим мастером. Сваких 10 секунди шаље поруке колико покушава, али не успева.
И током ових покушаја, до старог мајстора стиже сигнал за тренутно гашење. Мастер се поново покреће. И опоравак се зауставља јер стари мастер иде у поновно покретање. То јест, реплика не може да се повеже са њим јер је у режиму искључивања.
У неком тренутку је успело, али репликација није почела.
Једина хипотеза коју имам је да рецовери.цонф садржи адресу старог мајстора. А када се појавио нови мајстор, друга реплика је и даље покушавала да се повеже са старим мајстором.
Када је Патрони покренуо другу реплику, чвор је почео, али није могао да се повеже путем репликације. И формирао се кашњење у репликацији, које је изгледало отприлике овако. То јест, сва три чвора су била на месту, али је други чвор заостајао.
У исто време, ако погледате евиденције које су написане, можете видети да репликација не може да почне јер су евиденције трансакција различите. А евиденције трансакција које нуди чаробњак, које су наведене у рецовери.цонф, једноставно нису погодне за наш тренутни чвор.
И овде сам погрешио. Морао сам да дођем да видим шта има у рецовери.цонф-у да тестирам своју хипотезу да се повезујемо са погрешним мастером. Али ја сам тада тек сконтао и није ми пало на памет, или сам видео да реплика заостаје и да ће морати да се допуни, тј. некако сам је нехајно разрадио. Ово је био мој довратак.
После 30 минута је стигао админ, односно поново сам покренуо Патрони на реплици. Већ сам одустао од тога, мислио сам да ће морати да се напуни. И помислио сам, поново ћу покренути Патронија, можда ће нешто добро испасти. Почео је опоравак. А база се чак и отворила, била је спремна да прихвати везе.
Репликација је почела. Али минут касније се срушио са грешком да евиденције трансакција нису погодне за њега.
Мислио сам да поново покренем. Поново сам покренуо Патрони и нисам поново покренуо Постгрес, већ сам поново покренуо Патрони у нади да ће магично покренути базу података.
Репликација је поново почела, али белешке у дневнику трансакција су биле другачије, нису биле исте као оне које су биле у претходном покушају покретања. Репликација је поново заустављена. А порука је била мало другачија. И није ми било посебно информативно.
И онда ми падне на памет – шта ако поново покренем Постгрес, у овом тренутку направим контролну тачку на тренутном мастеру како бих померио тачку у евиденцији трансакција мало напред тако да опоравак почне од другог тренутка? Осим тога, још смо тамо имали резерве ВАЛ-а.
Рестартовао сам Патрони, направио пар контролних тачака на мастеру, пар тачака поновног покретања на реплици када се отворила. И помогло је. Дуго сам размишљао о томе зашто ми помаже и како функционише. И реплика је почела. И репликација више није успела.
Овај проблем је за мене један од мистериознијих, над којим се још увек мучим шта се тамо заправо догодило.
Који су закључци овде? Патрони може да ради како је предвиђено и без икаквих грешака. Али у исто време, ово није 100% гаранција да је код нас све у реду. Реплика може да почне, али може бити у полурадном стању, а апликација не може да ради са таквом репликом, јер ће тамо бити старих података.
А после преверавања фајлова увек треба да проверимо да ли је све у реду са кластером, односно да имамо потребан број реплика и да нема кашњења у репликацији.
И док будемо разматрали ове проблеме, ја ћу формулисати препоруке. Покушао сам да их спојим у два слајда. Вероватно су се све приче могле спојити у два слајда и само их испричати.
Када користите Патрони, морате имати надзор. Увек треба да знате када је дошло до аутоматског отварања датотека, јер ако не знате да сте имали аутофилеовер, немате контролу над кластером. И то је лоше.
После сваког филера, увек би требало да ручно проверимо кластер. Морамо се побринути да увек имамо ажуран број реплика, да нема кашњења у репликацији и да нема грешака у евиденцијама које се односе на репликацију стриминга, Патрони или ДЦС систем.
Аутоматизација може успешно да ради, Патрони је веома добар алат. Можда ради, али неће довести кластер у жељено стање. А ако не знамо за то, онда ћемо имати проблема.
А Патрони није сребрни метак. Још увек морамо да разумемо како Постгрес функционише, како функционише репликација и како Патрони ради са Постгресом и како се остварује комуникација између чворова. Ово је неопходно да бисте могли да решите проблеме својим рукама.
Како да приступим питању дијагнозе? Десило се да радимо са различитим клијентима и нико нема ЕЛК стек, а логове морамо да разумемо отварањем 6 конзола и 2 таба. На једној картици се налазе Патрони логови за сваки чвор, на другој картици се налазе Цонсул логови, или Постгрес логови ако је потребно. Веома је тешко поставити дијагнозу.
Које сам приступе развио? Прво, увек погледам када је филер стигао. А за мене је ово нека прекретница. Гледам шта се дешавало пре филера, током филера и после њега. Фајловер има две ознаке: ово је време почетка и завршетка.
Затим у евиденцији погледам догађаје пре филера, који су претходили филеру, односно тражим разлоге због којих је дошло до филера.
И ово даје слику разумевања шта се догодило и шта се може учинити у будућности да се такве околности спрече (и као резултат тога, не долази до преверавања датотека).
А где обично гледамо? Ја гледам:
- Прво у Патронијеве дневнике.
- Затим гледам Постгрес дневнике или ДЦС дневнике, у зависности од тога шта је пронађено у Патрони евиденцијама.
- А системски дневници такође понекад дају разумевање шта је изазвало датотеку.
Како се осећам према Патрони? Осећам се веома добро због Патронија. По мом мишљењу, ово је нешто најбоље што постоји данас. Знам многе друге производе. То су Столон, Репмгр, Пг_ауто_фаиловер, ПАФ. 4 алата. Све сам их пробао. Патрони ми се највише допао.
Ако ме питају: „Да ли препоручујем Патрони?“ Рећи ћу да, јер волим Патронија. И мислим да сам научио да га кувам.
Ако сте заинтересовани да видите још проблема са Патронијем, поред проблема које сам изнео, увек можете да одете на страницу на ГитХуб-у. Постоји много различитих прича и тамо се расправља о многим занимљивим проблемима. И као резултат тога, неке грешке су уведене и решене, односно ово је занимљиво читање.
Тамо постоје занимљиве приче о људима који су себи пуцали у ногу. Веома информативно. Читате и разумете да не морате ово да радите. Означио сам себе.
И желео бих да кажем велико хвала компанији Заландо за развој овог пројекта, односно Александру Кукушкину и Алексеју Кљукину. Алексеј Кљукин је један од коаутора, он више не ради у Заланду, али ово су двоје људи који су почели да раде са овим производом.
И мислим да је Патрони веома кул ствар. Драго ми је што постоји, занимљиво је бити са њом. И велико хвала свим сарадницима који пишу закрпе за Патрони. Надам се да ће Патрони са годинама постати зрелији, хладнији и способнији. Већ је ефикасан, али надам се да ће постати још бољи. Дакле, ако планирате да користите Патрони у свом дому, не бојте се. Ово је добро решење, може се имплементирати и користити.
То је све. Ако имате питања, питајте.
pitanja
Хвала на извештају! Ако након филера и даље морате пажљиво да погледате тамо, зашто нам је онда потребан аутоматски филер?
Зато што је то нова ствар. Са њом радимо само годину дана. Боље је играти на сигурно. Желимо да уђемо и видимо да је све заиста функционисало како треба. Ово је ниво неповерења одраслих - боље је још једном проверити и видети.
На пример, дошли смо јутрос и погледали, зар не?
Не ујутру, за аутофилеовер обично сазнамо скоро одмах. Добијамо обавештења, видимо да је дошло до аутоматског пребацивања датотека. Скоро одмах уђемо и погледамо. Али све ове провере морају бити доведене на ниво праћења. Ако приступите Патрони преко РЕСТ АПИ-ја, постоји историја. Користећи историју, можете погледати временске ознаке када је датотека преузета. На основу овога може се вршити мониторинг. Можете погледати историју да видите колико је догађаја било. Ако имамо више догађаја, то значи да је дошло до аутофилеовер-а. Можете отићи и погледати. Или је наша аутоматизација надгледања проверила да ли имамо све реплике на месту, да нема заостајања и да је све у реду.
Хвала!
Хвала вам пуно на сјајној причи! Ако смо ДЦС кластер померили негде далеко од Постгрес кластера, да ли и овај кластер треба периодично да се сервисира? Које су најбоље праксе у томе да неке делове ДЦС кластера треба искључити, нешто урадити са њима итд.? Како живи цела ова структура? И како да урадим ове ствари?
За једну компанију било је неопходно креирати матрицу проблема шта се дешава ако једна или више компоненти закаже. Користећи ову матрицу, узастопно пролазимо кроз све компоненте и градимо сценарије у случају квара ових компоненти. Сходно томе, за сваки сценарио неуспеха можете имати акциони план за опоравак. А у случају ДЦС-а, ово долази као део стандардне инфраструктуре. А администратор то администрира, а ми се већ ослањамо на администраторе који то администрирају и на његову способност да то поправи у случају катастрофе. Ако ДЦС уопште нема, онда га постављамо, али га посебно не пратимо, јер нисмо одговорни за инфраструктуру, али дајемо препоруке како и шта да пратимо.
То јест, да ли сам добро разумео да морам да онемогућим Патрони, онемогућим филер, онемогућим све пре него што урадим било шта са домаћинима?
Зависи од тога колико чворова имамо у ДЦС кластеру. Ако има много чворова и ако онемогућимо само један од чворова (реплику), онда се кворум одржава у кластеру. А Патрони остаје оперативан. И ништа се не покреће. Ако имамо неке сложене операције које утичу на више чворова, чије би одсуство могло да уништи кворум, онда да, можда има смисла паузирати Патрони. Има одговарајућу команду - патроництл паусе, патроництл ресуме. Једноставно га паузирамо, а аутофилеовер тренутно не ради. Одржавамо ДЦС кластер, затим уклањамо паузу и настављамо са животом.
Хвала вам пуно!
Хвала вам пуно на извештају! Како се тим производа осећа у вези са губитком података?
Тимове производа није брига, али вође тима су забринути.
Које гаранције постоје?
Са гаранцијама је веома тешко. Александар Кукушкин има извештај „Како израчунати РПО и РТО“, односно време опоравка и колико података можемо да изгубимо. Мислим да морамо пронаћи ове слајдове и проучити их. Колико се сећам, постоје конкретни кораци како да се израчунају ове ствари. Колико трансакција можемо изгубити, колико података можемо изгубити. Као опцију, можемо користити синхрону репликацију на Патрони нивоу, али ово је мач са две оштрице: или имамо поузданост података или губимо брзину. Постоји синхрона репликација, али она такође не гарантује 100% заштиту од губитка података.
Алексеј, хвала на дивном извештају! Има ли искуства у коришћењу Патронија за заштиту нултог нивоа? Односно, у комбинацији са синхроним стањем приправности? Ово је прво питање. И друго питање. Користили сте различита решења. Користили смо Репмгр, али без аутофилеовер-а и сада планирамо да повежемо аутофилеовер. А Патрони сматрамо алтернативним решењем. Које су предности у поређењу са Репмгр-ом?
Прво питање се односило на синхроне реплике. Нико овде не користи синхрону репликацију, јер су сви уплашени (неколико клијената је већ користи, уопште нису приметили проблеме са перформансама - Спеакер'с Ноте). Али ми смо за себе развили правило да у кластеру синхроне репликације морају бити најмање три чвора, јер ако имамо два чвора и ако мастер или реплика покваре, онда Патрони пребацује овај чвор у самостални режим како би апликација наставила да ради. рад. У овом случају постоји ризик од губитка података.
Што се тиче другог питања, користили смо Репмгр и још увек то радимо за неке клијенте из историјских разлога. шта можемо рећи? У Патрони, аутофилеовер долази из кутије у Репмгр, аутофилеовер долази као додатна функција коју треба омогућити. Морамо да покренемо Репмгр демон на сваком чвору и онда можемо да конфигуришемо аутофилеовер.
Репмгр проверава да ли су Постгрес чворови живи. Репмгр процеси проверавају постојање једни других, ово није баш ефикасан приступ јер Могу постојати сложени случајеви изолације мреже у којима се велики Репмгр кластер може разбити на неколико малих и наставити да ради. Нисам пратио Репмгр дуго времена, можда је ово поправљено... или можда не. Али преношење информација о стању кластера у ДЦС, као што то чине Столон и Патрони, је најизводљивија опција.
Алексеј, имам једно питање које је можда јадно. У једном од првих примера, преместили сте ДЦС са локалне машине на удаљени чвор. Разумемо да је мрежа ствар која има своје карактеристике; А шта се дешава ако из неког разлога ДЦС кластер постане недоступан? Нећу да говорим о разлозима, може их бити много: од кривих руку мрежара до стварних проблема.
Нисам то рекао наглас, али ДЦС кластер такође мора бити отпоран на грешке, што значи да има непаран број чворова да би се појавио кворум. Шта се дешава ако ДЦС кластер постане недоступан или се не може постићи кворум, тј. нека врста поделе мреже или квара чвора? У овом случају, Патрони кластер прелази у режим само за читање. Патрони кластер не може да одреди стање кластера и шта да ради. Не може да контактира ДЦС и да тамо сачува ново стање кластера, тако да цео кластер прелази у режим само за читање. И чека или на ручну интервенцију оператера или да се ДЦС врати.
Грубо речено, ДЦС постаје важан сервис за нас колико и сама база података?
Да да. У многим савременим компанијама, Сервице Дисцовери је саставни део инфраструктуре. Спроводи се и пре него што је у инфраструктури постојала и база података. Релативно говорећи, покренули смо инфраструктуру, распоредили је у ДЦ и одмах имамо Сервице Дисцовери. Ако је ово Конзул, онда се на њему може изградити ДНС. Ако је ово Етцд, онда можда постоји део из Кубернетес кластера у који ће све остало бити распоређено. Чини ми се да је Сервице Дисцовери већ саставни део савремених инфраструктура. И о томе размишљају много раније од база података.
Хвала!
Извор: ввв.хабр.цом
