Patroni Failure Stories կամ Ինչպես խափանել ձեր PostgreSQL կլաստերը: Ալեքսեյ Լեսովսկի

Patroni-ի հիմնական նպատակը PostgreSQL-ի համար բարձր հասանելիություն ապահովելն է: Բայց Patroni-ն ընդամենը կաղապար է, ոչ թե պատրաստի գործիք (ինչը, ընդհանուր առմամբ, ասված է փաստաթղթում)։ Առաջին հայացքից, Patroni-ն թեստային լաբորատորիայում տեղադրելով, կարող եք տեսնել, թե ինչ հիանալի գործիք է դա և որքան հեշտությամբ է այն հաղթահարում կլաստերը կոտրելու մեր փորձերը: Այնուամենայնիվ, գործնականում, արտադրական միջավայրում, ամեն ինչ միշտ չէ, որ տեղի է ունենում այնքան գեղեցիկ և նրբագեղ, որքան թեստային լաբորատորիայում:

Ես ձեզ մի փոքր կպատմեմ իմ մասին: Ես սկսել եմ որպես համակարգի ադմինիստրատոր: Աշխատել է վեբ մշակման ոլորտում։ Data Egret-ում աշխատում եմ 2014 թվականից։ Ընկերությունը խորհրդատվությամբ է զբաղվում Postgres-ի ոլորտում։ Եվ մենք սպասարկում ենք հենց Postgres-ը, և մենք աշխատում ենք Postgres-ի հետ ամեն օր, ուստի ունենք տարբեր փորձաքննություն՝ կապված վիրահատության հետ:

Իսկ 2018-ի վերջում մենք կամաց-կամաց սկսեցինք օգտագործել Patroni-ն։ Եվ որոշակի փորձ կուտակվել է։ Մենք ինչ-որ կերպ ախտորոշեցինք, լարեցինք այն, հասանք մեր լավագույն փորձին: Եվ այս զեկույցում ես կխոսեմ դրանց մասին։

Բացի Postgres-ից, ես սիրում եմ Linux-ը: Ես սիրում եմ շրջել դրա մեջ և ուսումնասիրել, ես սիրում եմ միջուկներ հավաքել: Ես սիրում եմ վիրտուալացում, կոնտեյներներ, դոկեր, Kubernetes: Այս ամենն ինձ հետաքրքրում է, քանի որ ադմինի հին սովորությունները ազդում են։ Ես սիրում եմ զբաղվել մոնիտորինգով։ Եվ ես սիրում եմ ադմինիստրացիայի հետ կապված postgres-ի բաները, օրինակ՝ կրկնօրինակումը, կրկնօրինակումը: Իսկ ազատ ժամանակ գրում եմ Go-ում։ Ես ծրագրային ապահովման ինժեներ չեմ, ես պարզապես գրում եմ ինձ համար Go-ում: Եվ դա ինձ հաճույք է պատճառում:

• Կարծում եմ, որ ձեզանից շատերը գիտեն, որ Postgres-ը չունի HA (բարձր հասանելիություն): HA ստանալու համար պետք է ինչ-որ բան տեղադրել, կարգավորել, ջանք գործադրել և ստանալ այն:
• Կան մի քանի գործիքներ, և Patroni-ն դրանցից մեկն է, որը լուծում է HA-ն բավականին հիանալի և շատ լավ: Բայց դնելով այդ ամենը թեստային լաբորատորիայում և գործարկելով այն, մենք կարող ենք տեսնել, որ այդ ամենն աշխատում է, մենք կարող ենք վերարտադրել որոշ խնդիրներ, տեսնել, թե ինչպես է Պատրոնին սպասարկում դրանք: Եվ մենք կտեսնենք, որ ամեն ինչ հիանալի է ստացվում:
• Բայց գործնականում մենք բախվեցինք տարբեր խնդիրների։ Եվ ես կխոսեմ այս խնդիրների մասին։
• Ես ձեզ կասեմ, թե ինչպես ենք մենք դա ախտորոշել, ինչ ենք շտկել՝ արդյոք դա մեզ օգնեց, թե ոչ:

• Ես ձեզ չեմ ասի, թե ինչպես տեղադրել Patroni-ն, քանի որ դուք կարող եք google-ում գտնել ինտերնետում, կարող եք դիտել կոնֆիգուրացիայի ֆայլերը, որպեսզի հասկանաք, թե ինչպես է ամեն ինչ սկսվում, ինչպես է այն կազմաձևվում: Դուք կարող եք հասկանալ սխեմաները, ճարտարապետությունները, դրա մասին տեղեկատվություն գտնել ինտերնետում:
• Չեմ խոսի ուրիշի փորձի մասին։ Կխոսեմ միայն այն խնդիրների մասին, որոնց բախվել ենք։
• Եվ ես չեմ խոսի այն խնդիրների մասին, որոնք դուրս են Patroni-ից և PostgreSQL-ից: Եթե, օրինակ, հավասարակշռման հետ կապված խնդիրներ լինեն, երբ մեր կլաստերը փլուզվել է, ես դրա մասին չեմ խոսի։

Եվ մի փոքր հերքում՝ նախքան մեր զեկույցը սկսելը:

Այս բոլոր խնդիրները, որ մենք հանդիպել ենք, ունեցել ենք շահագործման առաջին 6-7-8 ամիսներին։ Ժամանակի ընթացքում մենք հասանք մեր ներքին լավագույն փորձին: Եվ մեր խնդիրները վերացել են: Հետևաբար, զեկույցը հայտարարվեց մոտ վեց ամիս առաջ, երբ այդ ամենը թարմ էր իմ գլխում, և ես հիանալի հիշում էի այդ ամենը։

Զեկույցը պատրաստելու ընթացքում ես արդեն բարձրացրել եմ հին դիահերձարաններ, նայեցի գերաններին։ Եվ որոշ մանրամասներ կարելի էր մոռանալ, կամ որոշ մանրամասներ չեն կարողացել ամբողջությամբ հետաքննել խնդիրների վերլուծության ժամանակ, ուստի որոշ կետերում կարող է թվալ, թե խնդիրները ամբողջությամբ չեն դիտարկվում, կամ տեղեկատվության պակաս կա: Եվ այսպես, ես խնդրում եմ ձեզ ներել ինձ այս պահի համար:

Ի՞նչ է Patroni-ն:

• Սա ՀԱ կառուցման կաղապար է: Դա այն է, ինչ ասվում է փաստաթղթերում: Եվ իմ տեսանկյունից սա շատ ճիշտ պարզաբանում է։ Պատրոնը արծաթյա փամփուշտ չէ, որը կլուծի ձեր բոլոր խնդիրները, այսինքն՝ պետք է ջանք գործադրել, որպեսզի այն աշխատի և օգուտներ բերի։
• Սա գործակալի ծառայություն է, որը տեղադրված է տվյալների բազայի յուրաքանչյուր ծառայության վրա և մի տեսակ սկզբնական համակարգ է ձեր Postgres-ի համար: Այն սկսում է Postgres-ը, դադարեցնում, վերագործարկում, վերակազմավորում և փոխում է ձեր կլաստերի տոպոլոգիան:
• Համապատասխանաբար, կլաստերի վիճակը պահպանելու համար, նրա ներկայիս ներկայացումը, ինչպես երևում է, անհրաժեշտ է ինչ-որ պահեստավորում: Եվ այս տեսակետից Պատրոնին բռնեց արտաքին համակարգում պետություն պահելու ուղին։ Դա բաշխված կոնֆիգուրացիայի պահպանման համակարգ է: Դա կարող է լինել Etcd, Consul, ZooKeeper կամ kubernetes Etcd, այսինքն՝ այս տարբերակներից մեկը:
• Իսկ Patroni-ի առանձնահատկություններից մեկն այն է, որ դուք ավտոմատ ֆայլերը դուրս եք բերում տուփից, միայն այն կարգավորելով: Եթե ​​համեմատության համար վերցնենք Repmgr-ը, ապա ֆայլերը ներառված է այնտեղ։ Repmgr-ի միջոցով մենք ստանում ենք անցում, բայց եթե ուզում ենք ավտոմատ ֆայլեր, ապա մենք պետք է այն լրացուցիչ կարգավորենք: Patroni-ն արդեն ունի ավտոմատ ֆայլեր:
• Եվ շատ այլ բաներ կան։ Օրինակ՝ կոնֆիգուրացիաների պահպանում, նոր կրկնօրինակների լցնում, կրկնօրինակում և այլն։ Բայց սա հաշվետվության շրջանակներից դուրս է, դրա մասին չեմ խոսի։

Եվ փոքր արդյունքն այն է, որ Patroni-ի հիմնական խնդիրն է լավ և հուսալի կերպով կատարել ավտոմատ ֆայլ, որպեսզի մեր կլաստերը մնա գործառնական, և հավելվածը չնկատի փոփոխություններ կլաստերային տոպոլոգիայում:

Բայց երբ մենք սկսում ենք օգտագործել Patroni-ն, մեր համակարգը մի փոքր ավելի բարդանում է: Եթե ​​նախկինում մենք ունեինք Postgres, ապա Patroni-ն օգտագործելիս մենք ստանում ենք ինքը Patroni, մենք ստանում ենք DCS, որտեղ պահվում է վիճակը: Եվ ամեն ինչ ինչ-որ կերպ պետք է աշխատի: Այսպիսով, ի՞նչը կարող է սխալ լինել:

Մայիսյան ընդմիջում.

• Postgres-ը կարող է կոտրվել: Դա կարող է լինել վարպետ կամ կրկնօրինակ, դրանցից մեկը կարող է ձախողվել:
• Պատրոնն ինքնին կարող է կոտրվել:
• DCS-ը, որտեղ պահվում է վիճակը, կարող է կոտրվել:
• Եվ ցանցը կարող է կոտրվել:

Այս բոլոր կետերը ես կքննարկեմ զեկույցում:

Գործերը կդիտարկեմ այնքանով, որքանով դրանք բարդանան, ոչ թե այն տեսանկյունից, որ գործը շատ բաղադրիչներ է պարունակում։ Իսկ սուբյեկտիվ զգացմունքների տեսակետից, որ էս գործն ինձ համար դժվար էր, դժվար էր ապամոնտաժելը... և հակառակը, ինչ-որ պատյան թեթև էր ու հեշտ էր այն քանդելը։

Իսկ առաջին դեպքը ամենահեշտն է։ Սա այն դեպքն է, երբ մենք վերցրեցինք տվյալների բազայի կլաստերը և տեղադրեցինք մեր DCS պահեստը նույն կլաստերի վրա: Սա ամենատարածված սխալն է։ Սա սխալ է ճարտարապետության կառուցման մեջ, այսինքն՝ տարբեր բաղադրիչները մեկ վայրում համատեղելու մեջ:

Ուրեմն ֆայլեր կար, գնանք զբաղվենք կատարվածով։

Եվ այստեղ մեզ հետաքրքրում է, թե երբ է տեղի ունեցել ֆայլը։ Այսինքն՝ մեզ հետաքրքրում է ժամանակի այս պահը, երբ փոխվեց կլաստերային վիճակը։

Բայց ֆայլերը միշտ չէ, որ ակնթարթային է, այսինքն, այն չի պահանջում ժամանակի որևէ միավոր, այն կարող է հետաձգվել: Այն կարող է երկարատև լինել:

Հետևաբար, այն ունի մեկնարկի և ավարտի ժամանակ, այսինքն՝ շարունակական իրադարձություն է: Եվ մենք բոլոր իրադարձությունները բաժանում ենք երեք ինտերվալների՝ մենք ժամանակ ունենք ֆայլերից առաջ, ֆայլերի ընթացքում և ֆայլերից հետո։ Այսինքն՝ մենք բոլոր իրադարձությունները դիտարկում ենք այս ժամանակացույցում։

Եվ առաջինը, երբ ֆայլեր է տեղի ունեցել, մենք փնտրում ենք կատարվածի պատճառը, որն է եղել այն, ինչը հանգեցրել է ֆայլի:

Եթե ​​նայենք գերաններին, դրանք կլինեն դասական Պատրոնի գերաններ։ Նա մեզ ասում է դրանցում, որ սերվերը դարձել է վարպետ, և վարպետի դերն անցել է այս հանգույցին։ Այստեղ ընդգծված է.

Հաջորդը, մենք պետք է հասկանանք, թե ինչու է տեղի ունեցել ֆայլը, այսինքն՝ ինչ իրադարձություններ են տեղի ունեցել, որոնք պատճառ են դարձել, որ գլխավոր դերը տեղափոխվի մի հանգույցից մյուսը: Եվ այս դեպքում ամեն ինչ պարզ է. Մենք սխալ ունենք պահեստավորման համակարգի հետ փոխգործակցության մեջ: Վարպետը հասկացավ, որ չի կարող աշխատել DCS-ի հետ, այսինքն՝ փոխազդեցության հետ կապված ինչ-որ խնդիր կա։ Իսկ նա ասում է, որ այլեւս չի կարող վարպետ լինել ու հրաժարական է տալիս։ Այս «թուլացած ես» տողը հենց դա է ասում։

Եթե ​​նայենք այն իրադարձություններին, որոնք նախորդել են ֆայլերին, ապա այնտեղ կարող ենք տեսնել հենց այն պատճառները, որոնք պատճառ են դարձել, որ խնդիրը շարունակի կախարդը:

Եթե ​​նայենք Patroni-ի տեղեկամատյաններին, ապա կտեսնենք, որ մենք ունենք բազմաթիվ սխալներ, ժամանակի ընդհատումներ, այսինքն՝ Patroni գործակալը չի ​​կարող աշխատել DCS-ի հետ: Այս դեպքում սա Consul գործակալն է, որը հաղորդակցվում է 8500 նավահանգստի վրա:

Եվ այստեղ խնդիրն այն է, որ Patroni-ն և տվյալների բազան աշխատում են նույն հոսթի վրա: Իսկ Consul սերվերները գործարկվել են նույն հանգույցում։ Սերվերի վրա բեռ ստեղծելով մենք խնդիրներ ենք ստեղծել նաև Consul սերվերների համար։ Նրանք չէին կարողանում ինչպես հարկն է շփվել։

Որոշ ժամանակ անց, երբ բեռը թուլացավ, մեր Պատրոնին կրկին կարողացավ շփվել գործակալների հետ։ Նորմալ աշխատանքը վերսկսվել է. Եվ նույն Pgdb-2 սերվերը նորից դարձավ վարպետ։ Այսինքն՝ տեղի է ունեցել մի փոքրիկ շրջադարձ, որի պատճառով հանգույցը հրաժարվել է վարպետի լիազորություններից, իսկ հետո նորից վերցրել դրանք, այսինքն՝ ամեն ինչ վերադարձել է այնպես, ինչպես եղել է։

Եվ սա կարելի է համարել կեղծ ահազանգ, կամ կարելի է համարել, որ Պատրոնին ամեն ինչ ճիշտ է արել։ Այսինքն՝ նա հասկացավ, որ չի կարող պահպանել կլաստերի վիճակը և հանեց իր հեղինակությունը։

Եվ այստեղ խնդիրն առաջացել է այն պատճառով, որ Consul սերվերները գտնվում են նույն սարքավորման վրա, ինչ բազաները։ Համապատասխանաբար, ցանկացած բեռնվածություն՝ լինի դա սկավառակների կամ պրոցեսորների բեռը, այն նաև ազդում է հյուպատոսական կլաստերի հետ փոխգործակցության վրա:

Եվ մենք որոշեցինք, որ այն չպետք է միասին ապրի, առանձին կլաստեր ենք հատկացրել հյուպատոսի համար։ Իսկ Պատրոնին արդեն աշխատում էր առանձին Կոնսուլի հետ, այսինքն՝ կար առանձին Պոստգրես կլաստեր, առանձին Հյուպատոսական կլաստեր։ Սա հիմնական ցուցում է, թե ինչպես պետք է կրել և պահել այս ամենը, որպեսզի այն միասին չապրի:

Որպես տարբերակ, դուք կարող եք շրջել ttl, loop_wait, retry_timeout պարամետրերը, այսինքն՝ փորձել գոյատևել այս կարճաժամկետ ծանրաբեռնվածության գագաթնակետերը՝ ավելացնելով այս պարամետրերը: Բայց սա ամենահարմար տարբերակը չէ, քանի որ այս բեռը կարող է երկար ժամանակ տևել: Եվ մենք պարզապես դուրս կգանք այս պարամետրերի սահմաններից։ Եվ դա կարող է իսկապես չօգնել:

Առաջին խնդիրը, ինչպես հասկանում եք, պարզ է. Վերցրինք ու դրեցինք DCS-ը բազայի հետ, խնդիր ստացանք։

Երկրորդ խնդիրը նման է առաջինին. Դա նման է նրանով, որ մենք կրկին փոխգործունակության խնդիրներ ունենք DCS համակարգի հետ:

Եթե ​​նայենք տեղեկամատյաններին, ապա կտեսնենք, որ կրկին ունենք հաղորդակցման սխալ: Եվ Պատրոնին ասում է, որ ես չեմ կարող շփվել DCS-ի հետ, այնպես որ ներկայիս վարպետը անցնում է կրկնօրինակման ռեժիմի:

Հին վարպետը դառնում է կրկնօրինակ, այստեղ Պատրոնին աշխատում է այնպես, ինչպես պետք է լինի: Այն գործարկում է pg_rewind՝ գործարքների գրանցամատյանը ետ փաթաթելու և այնուհետև միանալու նոր վարպետին՝ նոր վարպետին հասնելու համար: Այստեղ Պատրոնին աշխատում է այնպես, ինչպես պետք է։

Այստեղ մենք պետք է գտնենք այն տեղը, որը նախորդել է ֆայլերին, այսինքն՝ այն սխալները, որոնց պատճառով մենք ունենք ֆայլեր: Եվ այս առումով Patroni տեղեկամատյանները բավականին հարմար են աշխատելու համար: Նա գրում է նույն հաղորդագրությունները որոշակի ընդմիջումով: Եվ եթե մենք սկսենք արագ պտտվել այս տեղեկամատյաններում, ապա տեղեկամատյաններից կտեսնենք, որ տեղեկամատյանները փոխվել են, ինչը նշանակում է, որ որոշ խնդիրներ են սկսվել։ Մենք արագ վերադառնում ենք այս վայր, տեսեք, թե ինչ է տեղի ունենում:

Իսկ նորմալ իրավիճակում գերաններն այսպիսի տեսք ունեն. Կողպեքի սեփականատերը ստուգված է. Եվ եթե սեփականատերը, օրինակ, փոխվել է, ապա կարող են տեղի ունենալ որոշ իրադարձություններ, որոնց Պատրոնը պետք է արձագանքի: Բայց այս դեպքում մենք լավ ենք։ Մենք փնտրում ենք այն տեղը, որտեղից սկսվել են սխալները։

Եվ ոլորելով դեպի այն կետը, որտեղ սխալները սկսեցին ի հայտ գալ, մենք տեսնում ենք, որ մենք ունեցել ենք ավտոմատ ֆայլերի վերափոխում: Եվ քանի որ մեր սխալները կապված էին DCS-ի հետ փոխազդեցության հետ, և մեր դեպքում մենք օգտագործում էինք Consul, մենք նաև նայում ենք հյուպատոսի տեղեկամատյաններին, թե ինչ է տեղի ունեցել այնտեղ:

Մոտավորապես համեմատելով հյուպատոսական տեղեկամատյանների ժամանակը և ժամանակը, մենք տեսնում ենք, որ հյուպատոսական կլաստերի մեր հարևանները սկսել են կասկածել հյուպատոսական կլաստերի այլ անդամների գոյությանը:

Եվ եթե նայեք այլ հյուպատոսական գործակալների տեղեկամատյաններին, կարող եք նաև տեսնել, որ այնտեղ ինչ-որ ցանցի փլուզում է տեղի ունենում: Իսկ Consul կլաստերի բոլոր անդամները կասկածում են միմյանց գոյությանը։ Եվ սա խթան հանդիսացավ ֆայլերի համար:

Եթե ​​նայեք, թե ինչ է տեղի ունեցել այս սխալներից առաջ, կարող եք տեսնել, որ կան բոլոր տեսակի սխալներ, օրինակ՝ վերջնաժամկետը, RPC-ն ընկել է, այսինքն՝ ակնհայտորեն ինչ-որ խնդիր կա հյուպատոսական կլաստերի անդամների միմյանց հետ փոխգործակցության մեջ։ .

Ամենապարզ պատասխանը ցանցի վերանորոգումն է: Բայց ինձ համար, ամբիոնին կանգնած, հեշտ է սա ասել. Բայց հանգամանքներն այնպիսին են, որ հաճախորդը միշտ չէ, որ կարող է իրեն թույլ տալ վերանորոգել ցանցը։ Նա կարող է ապրել DC-ում և չի կարող վերանորոգել ցանցը, ազդել սարքավորումների վրա: Եվ այսպես, որոշ այլ տարբերակներ են անհրաժեշտ:

Կան տարբերակներ.

• Ամենապարզ տարբերակը, որը գրված է, իմ կարծիքով, նույնիսկ փաստաթղթերում, անջատել Consul check-երը, այսինքն՝ ուղղակի դատարկ զանգված փոխանցել։ Իսկ հյուպատոսի գործակալին ասում ենք, որ չեկեր չօգտագործի։ Այս ստուգումների միջոցով մենք կարող ենք անտեսել այս ցանցային փոթորիկները և չսկսել ֆայլեր:
• Մեկ այլ տարբերակ է կրկնակի ստուգել raft_multiplier-ը: Սա ինքնին Consul սերվերի պարամետրն է: Լռելյայն սահմանվել է 5: Այս արժեքը առաջարկվում է բեմադրման միջավայրերի փաստաթղթերում: Փաստորեն, սա ազդում է հյուպատոսական ցանցի անդամների միջև հաղորդագրությունների հաճախականության վրա: Փաստորեն, այս պարամետրը ազդում է Consul կլաստերի անդամների միջև սպասարկման հաղորդակցության արագության վրա: Իսկ արտադրության համար արդեն խորհուրդ է տրվում կրճատել այն, որպեսզի հանգույցներն ավելի հաճախ փոխանակեն հաղորդագրությունները։
• Մեկ այլ տարբերակ, որին մենք եկել ենք, օպերացիոն համակարգի գործընթացների ժամանակացույցի համար այլ գործընթացների շարքում հյուպատոսական գործընթացների առաջնահերթությունը բարձրացնելն է: Կա այդպիսի «գեղեցիկ» պարամետր, այն պարզապես որոշում է գործընթացների առաջնահերթությունը, որը հաշվի է առնվում OS ժամանակացույցի կողմից ժամանակացույցի ժամանակ: Մենք նաև նվազեցրել ենք հաճելի արժեքը հյուպատոսական գործակալների համար, այսինքն. ավելացրել է առաջնահերթությունը, որպեսզի օպերացիոն համակարգը հյուպատոսի գործընթացներին ավելի շատ ժամանակ տրամադրի աշխատելու և իրենց ծածկագիրը գործարկելու համար: Մեր դեպքում սրանով մեր խնդիրը լուծվեց։
• Մեկ այլ տարբերակ է չօգտվել հյուպատոսից: Ես ունեմ ընկեր, որը Etcd-ի մեծ ջատագովն է: Եվ մենք պարբերաբար վիճում ենք նրա հետ, թե որն է ավելի լավ Etcd կամ Consul: Բայց այն առումով, թե որն է ավելի լավ, մենք սովորաբար համաձայն ենք նրա հետ, որ հյուպատոսն ունի գործակալ, որը պետք է աշխատի յուրաքանչյուր հանգույցի վրա տվյալների բազայով: Այսինքն՝ Պատրոնի փոխազդեցությունը հյուպատոսական կլաստերի հետ անցնում է այս գործակալի միջոցով։ Եվ այս գործակալը դառնում է խցան: Եթե ​​գործակալի հետ ինչ-որ բան պատահի, ապա Պատրոնին այլևս չի կարող աշխատել Consul կլաստերի հետ: Եվ սա է խնդիրը։ Etcd պլանում գործակալ չկա: Patroni-ն կարող է ուղղակիորեն աշխատել Etcd սերվերների ցանկի հետ և արդեն շփվել նրանց հետ: Այս առումով, եթե դուք օգտագործում եք Etcd ձեր ընկերությունում, ապա Etcd-ը հավանաբար ավելի լավ ընտրություն կլինի, քան Consul-ը: Բայց մենք մեր հաճախորդների հետ միշտ սահմանափակվում ենք նրանով, թե ինչ է ընտրել և օգտագործում հաճախորդը: Եվ մենք ունենք հյուպատոս մեծ մասամբ բոլոր հաճախորդների համար:
• Եվ վերջին կետը պարամետրերի արժեքների վերանայումն է: Մենք կարող ենք բարձրացնել այս պարամետրերը՝ հույս ունենալով, որ մեր կարճաժամկետ ցանցի խնդիրները կարճ կլինեն և դուրս չեն գա այս պարամետրերի շրջանակից: Այս կերպ մենք կարող ենք նվազեցնել Patroni-ի ագրեսիվությունը դեպի ավտոմատ ֆայլ, եթե ցանցի որոշ խնդիրներ առաջանան:

Կարծում եմ, շատերը, ովքեր օգտագործում են Patroni, ծանոթ են այս հրամանին:

Այս հրամանը ցույց է տալիս կլաստերի ներկայիս վիճակը: Եվ առաջին հայացքից այս պատկերը կարող է նորմալ թվալ։ Մենք ունենք վարպետ, մենք ունենք կրկնօրինակ, չկա կրկնօրինակման ուշացում: Բայց այս պատկերը ճիշտ է, քանի դեռ մենք չենք իմանա, որ այս կլաստերը պետք է ունենա երեք հանգույց, ոչ թե երկու:

Համապատասխանաբար, եղել է ավտոֆայլ: Եվ այս ավտոմատ ֆայլից հետո մեր կրկնօրինակն անհետացավ: Պետք է պարզել, թե ինչու է նա անհետացել և հետ բերել, վերականգնել։ Եվ մենք կրկին գնում ենք տեղեկամատյաններ և տեսնում ենք, թե ինչու ունեցանք ավտոմատ ֆայլերի վերափոխում:

Այս դեպքում երկրորդ կրկնօրինակը դարձավ վարպետ։ Այստեղ ամեն ինչ կարգին է:

Եվ մենք պետք է նայենք այն կրկնօրինակին, որն ընկել է և որը կլաստերի մեջ չէ: Մենք բացում ենք Patroni լոգերը և տեսնում ենք, որ pg_rewind փուլում կլաստերին միանալու գործընթացում խնդիր ենք ունեցել։ Կլաստերին միանալու համար դուք պետք է հետ շրջեք գործարքների գրանցամատյանը, պահանջեք պահանջվող գործարքների գրանցամատյանը Master-ից և օգտագործեք այն վարպետին հասնելու համար:

Այս դեպքում մենք գործարքների մատյան չունենք, և կրկնօրինակը չի կարող սկսվել: Համապատասխանաբար, մենք դադարեցնում ենք 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 գործընթացը։ Ըստ այդմ՝ նա ջնջել է գործարքների մատյանների մի մասը, ներբեռնել նորերը և միացել։ Այստեղ Պատրոնին խելացի աշխատեց, այսինքն՝ ինչպես սպասվում էր։ Կլաստերը վերականգնվել է։ Մենք ունեինք 3 հանգույց, ֆայլերից հետո 3 հանգույց - ամեն ինչ թույն է:

Մենք կորցրել ենք որոշ տվյալներ։ Եվ մենք պետք է հասկանանք, թե որքան ենք կորցրել։ Մենք փնտրում ենք հենց այն պահը, երբ հետադարձ կապ ունեցանք։ Մենք կարող ենք գտնել այն նման ամսագրի գրառումներում: Rewind-ը սկսեց, այնտեղ ինչ-որ բան արեց և ավարտվեց:

Գործարքների մատյանում մենք պետք է գտնենք այն դիրքը, որտեղից հեռացել է հին վարպետը: Այս դեպքում դա նշանն է: Եվ մեզ անհրաժեշտ է երկրորդ նշան, այն է՝ ինչ հեռավորությամբ է տարբերվում հին վարպետը նորից։

Մենք վերցնում ենք սովորական pg_wal_lsn_diff և համեմատում այս երկու նշանները: Եվ այս դեպքում մենք ստանում ենք 17 մեգաբայթ: Շատ թե քիչ, ամեն մեկն ինքն է որոշում։ Որովհետև ինչ-որ մեկի համար 17 մեգաբայթը շատ չէ, մեկի համար՝ շատ ու անընդունելի։ Այստեղ յուրաքանչյուրն անհատապես որոշում է իր համար՝ բիզնեսի կարիքներին համապատասխան։

Բայց ի՞նչ ենք պարզել ինքներս մեզ համար։

Նախ, մենք պետք է որոշենք ինքներս. արդյոք մեզ միշտ պետք է Patroni-ի ավտոմատ մեկնարկը համակարգի վերագործարկումից հետո: Հաճախ է պատահում, որ մենք պետք է գնանք հին վարպետի մոտ, տեսնենք, թե որքան հեռու է նա գնացել։ Միգուցե ստուգեք գործարքների գրանցամատյանի հատվածները, տեսեք, թե ինչ կա այնտեղ: Եվ հասկանալու համար, թե արդյոք մենք կարող ենք կորցնել այս տվյալները, թե արդյոք մեզ անհրաժեշտ է գործարկել հին վարպետը ինքնուրույն ռեժիմով, որպեսզի դուրս հանենք այս տվյալները:

Եվ միայն դրանից հետո մենք պետք է որոշենք՝ կարո՞ղ ենք հրաժարվել այս տվյալները, թե՞ կարող ենք վերականգնել այն, միացնել այս հանգույցը որպես կրկնօրինակ մեր կլաստերին։

Բացի այդ, կա «maximum_lag_on_failover» պարամետր: Լռելյայն, եթե իմ հիշողությունը ծառայում է ինձ, այս պարամետրը ունի 1 մեգաբայթ արժեք:

Ինչպե՞ս է նա աշխատում: Եթե ​​մեր կրկնօրինակը 1 մեգաբայթ տվյալների հետ է մնում կրկնօրինակման ուշացումով, ապա այս կրկնօրինակը չի մասնակցում ընտրություններին։ Եվ եթե հանկարծ ֆայլը վերափոխվի, Պատրոնին նայում է, թե որ կրկնօրինակները հետ են մնում: Եթե ​​նրանք հետ են մնում մեծ թվով գործարքների տեղեկամատյաններից, նրանք չեն կարող վարպետ դառնալ: Սա շատ լավ անվտանգության հատկանիշ է, որը թույլ չի տալիս ձեզ շատ տվյալներ կորցնել:

Բայց խնդիր կա նրանով, որ Patroni կլաստերում և DCS-ում կրկնօրինակման հետաձգումը թարմացվում է որոշակի ընդմիջումով: Կարծում եմ, 30 վայրկյանը լռելյայն ttl արժեքն է:

Համապատասխանաբար, կարող է լինել մի իրավիճակ, երբ կրկնօրինակների համար մեկ ուշացում կա DCS-ում, բայց իրականում կարող է լինել բոլորովին այլ ուշացում կամ ընդհանրապես ուշացում չկա, այսինքն՝ այս բանը իրական ժամանակում չէ: Եվ դա միշտ չէ, որ արտացոլում է իրական պատկերը: Եվ չարժե դրա վրա շքեղ տրամաբանություն անել։

Իսկ կորստի ռիսկը միշտ մնում է։ Իսկ վատագույն դեպքում՝ մի բանաձեւ, իսկ միջին դեպքում՝ մեկ այլ բանաձեւ։ Այսինքն, երբ մենք պլանավորում ենք Patroni-ի իրականացումը և գնահատում ենք, թե որքան տվյալներ կարող ենք կորցնել, մենք պետք է հիմնվենք այս բանաձևերի վրա և մոտավորապես պատկերացնենք, թե որքան տվյալներ կարող ենք կորցնել։

Եվ լավ նորություն կա. Երբ հին վարպետը առաջ է գնացել, նա կարող է առաջ գնալ որոշ ֆոնային գործընթացների պատճառով: Այսինքն՝ ինչ-որ ավտովակուում է եղել, նա գրել է տվյալները, պահել դրանք գործարքների մատյանում։ Եվ մենք հեշտությամբ կարող ենք անտեսել և կորցնել այս տվյալները: Սրա մեջ խնդիր չկա։

Եվ ահա թե ինչպես են տեղեկամատյանները նման, եթե առավելագույն_lag_on_failover-ը դրված է, և ֆայլեր է առաջացել, և դուք պետք է ընտրեք նոր վարպետ: Կրկնօրինակն իրեն գնահատում է որպես ընտրություններին մասնակցելու անկարող. Եվ նա հրաժարվում է մասնակցել առաջատարի համար պայքարին։ Եվ նա սպասում է նոր վարպետի ընտրությանը, որպեսզի հետո կարողանա միանալ դրան: Սա լրացուցիչ միջոց է տվյալների կորստի դեմ:

Այստեղ մենք ունենք ապրանքային թիմ, որը գրել է, որ իրենց արտադրանքը խնդիրներ ունի Postgres-ի հետ: Միևնույն ժամանակ, վարպետն ինքնին հնարավոր չէ մուտք գործել, քանի որ այն հասանելի չէ SSH-ի միջոցով: Իսկ ավտոֆայլն էլ չի լինում։

Այս հաղորդավարը ստիպված է եղել վերագործարկել: Վերագործարկման պատճառով տեղի ունեցավ ավտոմատ ֆայլ, թեև հնարավոր էր ձեռքով ավտոմատ ֆայլ անել, ինչպես հիմա հասկացա: Իսկ վերաբեռնումից հետո մենք արդեն պատրաստվում ենք տեսնել, թե ինչ ունեինք ներկայիս վարպետի հետ։

Միաժամանակ մենք նախապես գիտեինք, որ սկավառակների հետ կապված խնդիրներ ունենք, այսինքն՝ մոնիտորինգից արդեն գիտեինք՝ որտեղ փորել, ինչ փնտրել։

Մենք մտանք postgres log, սկսեցինք տեսնել, թե ինչ է կատարվում այնտեղ: Մենք տեսանք պարտավորություններ, որոնք տևում են մեկ, երկու, երեք վայրկյան, ինչը բոլորովին նորմալ չէ։ Մենք տեսանք, որ մեր ավտովակուումը միանում է շատ դանդաղ և տարօրինակ կերպով: Եվ մենք տեսանք ժամանակավոր ֆայլեր սկավառակի վրա: Այսինքն՝ սրանք բոլորը սկավառակների հետ կապված խնդիրների ցուցիչներ են։

Մենք նայեցինք համակարգի dmesg-ին (միջուկի մատյան): Եվ մենք տեսանք, որ մենք խնդիրներ ունենք սկավառակներից մեկի հետ։ Սկավառակի ենթահամակարգը ծրագրային Raid էր: Մենք նայեցինք /proc/mdstat-ը և տեսանք, որ մեզ բացակայում է մեկ դրայվ: Այսինքն՝ 8 սկավառակի Raid կա, մեզ պակասում է մեկը։ Եթե ​​ուշադիր նայեք սլայդին, ապա ելքում կարող եք տեսնել, որ մենք այնտեղ sde չունենք: Մեզ մոտ, պայմանականորեն ասած, սկավառակը դուրս է եկել։ Սա սկավառակի հետ կապված խնդիրներ առաջացրեց, և հավելվածները նույնպես խնդիրներ ունեցան Postgres կլաստերի հետ աշխատելիս:

Իսկ այս դեպքում Patroni-ն մեզ ոչ մի կերպ չէր օգնի, քանի որ Patroni-ն սերվերի վիճակը, սկավառակի վիճակը վերահսկելու խնդիր չունի։ Իսկ նման իրավիճակներին մենք պետք է վերահսկենք արտաքին մոնիտորինգով։ Մենք արագ ավելացրեցինք սկավառակի մոնիտորինգը արտաքին մոնիտորինգին:

Եվ այսպիսի միտք կար՝ ցանկապատումը կամ հսկիչ ծրագրերը կարո՞ղ են մեզ օգնել։ Մենք կարծում էինք, որ նա դժվար թե օգներ մեզ այս դեպքում, քանի որ խնդիրների ժամանակ Պատրոնին շարունակում էր շփվել DCS կլաստերի հետ և որևէ խնդիր չէր տեսնում։ Այսինքն՝ DCS-ի ու Patroni-ի տեսանկյունից կլաստերի հետ ամեն ինչ կարգին էր, չնայած իրականում սկավառակի հետ կապված խնդիրներ կային, տվյալների բազայի հասանելիության հետ կապված խնդիրներ կային։

Իմ կարծիքով սա ամենատարօրինակ խնդիրներից է, որը ես շատ երկար ուսումնասիրել եմ, շատ լոգեր եմ կարդացել, նորից ընտրել ու անվանել եմ կլաստերային սիմուլյատոր։

Խնդիրն այն էր, որ հին վարպետը չէր կարող սովորական կրկնօրինակ դառնալ, այսինքն՝ Պատրոնին սկսեց այն, Պատրոնին ցույց տվեց, որ այս հանգույցը առկա է որպես կրկնօրինակ, բայց միևնույն ժամանակ դա սովորական կրկնօրինակ չէ։ Այժմ դուք կտեսնեք, թե ինչու: Սա այն է, ինչ ես ետ եմ պահել այդ խնդրի վերլուծությունից։

Իսկ ինչպե՞ս սկսվեց ամեն ինչ։ Սկսվեց, ինչպես նախորդ խնդրի դեպքում, սկավառակային արգելակներով։ Մենք պարտավորություններ ունեինք մեկ վայրկյան, երկու:

Եղել են կապերի ընդմիջումներ, այսինքն՝ հաճախորդները պատռվել են:

Եղել են տարբեր ծանրության խցանումներ։

Եվ, համապատասխանաբար, սկավառակի ենթահամակարգը այնքան էլ արձագանքող չէ:

Եվ ինձ համար ամենաառեղծվածայինը անմիջապես ժամանած անջատման խնդրանքն է: Postgres-ն ունի երեք անջատման ռեժիմ.

• Հաճելի է, երբ մենք սպասում ենք, որ բոլոր հաճախորդներն ինքնուրույն անջատվեն:
• Արագ է, երբ մենք ստիպում ենք հաճախորդներին անջատել կապը, քանի որ մենք պատրաստվում ենք անջատել:
• Եվ անմիջապես: Այս դեպքում «immediate»-ը նույնիսկ չի ասում հաճախորդներին փակել, այն պարզապես անջատվում է առանց նախազգուշացման: Եվ բոլոր հաճախորդներին օպերացիոն համակարգն արդեն ուղարկում է RST հաղորդագրություն (TCP հաղորդագրություն, որ կապն ընդհատվել է, և հաճախորդն այլևս ոչինչ չունի բռնելու):

Ո՞վ է ուղարկել այս ազդանշանը: Postgres ֆոնային գործընթացները նման ազդանշաններ չեն ուղարկում միմյանց, այսինքն՝ սա kill-9 է: Նրանք միմյանց նման բաներ չեն ուղարկում, նրանք միայն արձագանքում են նման բաներին, այսինքն՝ սա Postgres-ի արտակարգ վերագործարկում է։ Ով է ուղարկել, չգիտեմ։

Ես նայեցի «վերջին» հրամանին և տեսա մեկ մարդու, ով նույնպես մուտք է գործել այս սերվերը մեզ հետ, բայց ես չափազանց ամաչեցի հարց տալ: Երևի սպանել -9 էր: Ես կտեսնեի սպանել -9 տեղեկամատյաններում, քանի որ Postgres-ն ասում է, որ սպանել է -9, բայց ես դա չտեսա տեղեկամատյաններում:

Հետագայում նայելով, տեսա, որ Պատրոնին բավականին երկար ժամանակ չէր գրում՝ 54 վայրկյան: Եվ եթե համեմատենք երկու ժամանակի դրոշմակնիք, ապա մոտ 54 վայրկյան հաղորդագրություններ չեն եղել։

Եվ այս ընթացքում եղել է ավտոֆայլ։ Պատրոնին կրկին մեծ աշխատանք կատարեց այստեղ: Մեր հին տերը անհասանելի էր, մի բան պատահեց նրան։ Եվ սկսվեց նոր վարպետի ընտրությունը։ Այստեղ ամեն ինչ լավ ստացվեց: Մեր pgsql01-ը դարձել է նոր առաջատարը:

Մենք ունենք կրկնօրինակ, որը դարձել է վարպետ: Եվ կա երկրորդ արձագանքը. Իսկ երկրորդ կրկնօրինակի հետ կապված խնդիրներ կային։ Նա փորձեց վերակազմավորել: Ինչպես հասկացա, նա փորձեց փոխել recovery.conf-ը, վերագործարկել Postgres-ը և միանալ նոր վարպետին: Նա 10 վայրկյանը մեկ հաղորդագրություն է գրում, որ փորձում է, բայց չի ստացվում։

Եվ այս փորձերի ժամանակ ծեր վարպետին անմիջապես անջատման ազդանշան է հասնում։ Վարպետը վերագործարկված է: Եվ նաև վերականգնումը դադարում է, քանի որ հին վարպետը անցնում է վերագործարկման: Այսինքն՝ ռեպլիկը չի կարող միանալ դրան, քանի որ անջատման ռեժիմում է։

Ինչ-որ պահի այն ստացվեց, բայց կրկնօրինակումը չսկսվեց:

Իմ միակ ենթադրությունն այն է, որ recovery.conf-ում եղել է հին հիմնական հասցե: Եվ երբ հայտնվեց նոր վարպետ, երկրորդ կրկնօրինակը դեռ փորձում էր կապվել հին վարպետի հետ:

Երբ Patroni-ն գործարկվեց երկրորդ կրկնօրինակով, հանգույցը գործարկվեց, բայց չկարողացավ կրկնօրինակել: Եվ ձևավորվեց կրկնօրինակման հետաձգում, որն այսպիսի տեսք ուներ. Այսինքն՝ երեք հանգույցներն էլ տեղում էին, բայց երկրորդ հանգույցը հետ մնաց։

Միևնույն ժամանակ, եթե նայեք գրված տեղեկամատյաններին, կարող եք տեսնել, որ կրկնօրինակումը չի կարող սկսվել, քանի որ գործարքների մատյանները տարբեր են: Եվ այն գործարքների գրանցամատյանները, որոնք առաջարկում է վարպետը, որոնք նշված են recovery.conf-ում, պարզապես չեն համապատասխանում մեր ընթացիկ հանգույցին:

Եվ այստեղ ես սխալվեցի. Ես պետք է գայի և տեսնեի, թե ինչ կա վերականգնման.conf-ում, որպեսզի փորձարկեի իմ վարկածը, որ մենք կապվում ենք սխալ վարպետի հետ: Բայց հետո ես պարզապես զբաղվում էի սրա հետ, և դա իմ մտքով չէր անցնում, կամ տեսա, որ կրկնօրինակը հետ է մնում և պետք է նորից լիցքավորվի, այսինքն՝ ես ինչ-որ կերպ անփույթ աշխատեցի: Սա իմ համատեղ էր:

30 րոպե անց ադմինն արդեն եկավ, այսինքն՝ ես վերագործարկեցի Patroni-ին ռեպլիկի վրա։ Արդեն վերջ տվեցի, մտածեցի, որ պետք է նորից լիցքավորվի։ Ու ես մտածեցի.-Պատրոնին կռեստարտեմ, միգուցե լավ բան ստացվի։ Վերականգնումը սկսվել է. Իսկ բազան նույնիսկ բացվեց, պատրաստ էր միացումներ ընդունել։

Կրկնօրինակումը սկսվել է: Բայց մեկ րոպե անց նա ընկավ սխալմամբ, որ գործարքների տեղեկամատյանները իրեն հարմար չեն:

Ես մտածեցի, որ նորից կվերագործարկեմ: Ես նորից վերագործարկեցի Patroni-ն, և ես չվերագործարկեցի Postgres-ը, այլ վերագործարկեցի Patroni-ն այն հույսով, որ այն կախարդական կերպով կսկսի տվյալների բազան:

Կրկնօրինակումը նորից սկսվեց, բայց գործարքների մատյանում նշանները տարբեր էին, դրանք նույնը չէին, ինչ նախորդ մեկնարկի փորձը: Կրկնօրինակումը կրկին դադարեց: Իսկ ուղերձն արդեն մի փոքր այլ էր։ Եվ դա ինձ համար այնքան էլ տեղեկատվական չէր։

Եվ հետո մտքովս անցնում է. իսկ եթե ես վերագործարկեմ Postgres-ը, այս պահին անցակետ կատարեմ ընթացիկ վարպետի վրա՝ գործարքների մատյանում կետը մի փոքր առաջ տեղափոխելու համար, որպեսզի վերականգնումը սկսվի մեկ այլ պահից: Բացի այդ, մենք դեռ ունեինք WAL-ի պաշարներ:

Վերագործարկեցի Patroni-ին, մի երկու հսկիչ կետ արեցի վարպետի վրա, մի երկու ռեստարտ կետ արեցի կրկնօրինակի վրա, երբ այն բացվեց: Եվ դա օգնեց: Ես երկար մտածեցի, թե ինչու դա օգնեց և ինչպես է այն աշխատում: Եվ սկսվեց կրկնօրինակը: Եվ կրկնօրինակումը այլևս պատռված չէր:

Նման խնդիրն ինձ համար առավել առեղծվածայիններից է, որի շուրջ դեռ տարակուսում եմ, թե իրականում ինչ է տեղի ունեցել այնտեղ։

Ի՞նչ հետևանքներ կան այստեղ: Patroni-ն կարող է աշխատել այնպես, ինչպես նախատեսված է և առանց որևէ սխալի: Բայց միևնույն ժամանակ սա 100% երաշխիք չէ, որ մեզ մոտ ամեն ինչ լավ է։ Կրկնօրինակը կարող է սկսվել, բայց այն կարող է լինել կիսաաշխատանքային վիճակում, և հավելվածը չի կարող աշխատել նման կրկնօրինակի հետ, քանի որ կլինեն հին տվյալներ։

Իսկ ֆայլերից հետո միշտ պետք է ստուգել, ​​որ կլաստերի հետ ամեն ինչ կարգին է, այսինքն՝ կան անհրաժեշտ թվով կրկնօրինակներ, կրկնօրինակման հետաձգում չկա։

Եվ երբ մենք անցնում ենք այս խնդիրների միջով, ես առաջարկություններ կանեմ: Ես փորձեցի դրանք համատեղել երկու սլայդների մեջ: Հավանաբար, բոլոր պատմությունները կարելի էր միավորել երկու սլայդի մեջ և միայն պատմել:

Երբ դուք օգտագործում եք Patroni, դուք պետք է ունենաք մոնիտորինգ: Դուք միշտ պետք է իմանաք, թե երբ է տեղի ունեցել ավտոմատ ֆայլերի վերափոխում, քանի որ եթե չգիտեք, որ ունեք ավտոմատ ֆայլեր, դուք վերահսկողություն չունեք կլաստերի վրա: Եվ դա վատ է:

Յուրաքանչյուր ֆայլերից հետո մենք միշտ պետք է ձեռքով ստուգենք կլաստերը: Մենք պետք է համոզվենք, որ մենք միշտ ունենանք կրկնօրինակների թարմացված քանակ, կրկնօրինակման հետաձգում չկա, հոսքային վերարտադրության հետ կապված գրանցամատյաններում սխալներ չկան, Patroni-ի հետ, DCS համակարգի հետ:

Ավտոմատացումը կարող է հաջողությամբ աշխատել, Patroni-ն շատ լավ գործիք է: Այն կարող է աշխատել, բայց դա կլաստերին չի բերի ցանկալի վիճակի: Եվ եթե մենք այդ մասին չպարզենք, մենք դժվարության մեջ կհայտնվենք:

Իսկ Պատրոնին արծաթե փամփուշտ չէ։ Մենք դեռ պետք է հասկանանք, թե ինչպես է աշխատում Postgres-ը, ինչպես է աշխատում կրկնօրինակումը և ինչպես է աշխատում Patroni-ն Postgres-ի հետ, և ինչպես է ապահովվում կապը հանգույցների միջև: Սա անհրաժեշտ է, որպեսզի կարողանաք լուծել ձեր ձեռքերի հետ կապված խնդիրները:

Ինչպե՞ս մոտենամ ախտորոշման հարցին: Այնպես ստացվեց, որ մենք աշխատում ենք տարբեր հաճախորդների հետ, և ոչ ոք չունի ELK stack, և մենք պետք է դասավորենք տեղեկամատյանները՝ բացելով 6 կոնսուլ և 2 ներդիր։ Մի ներդիրում սրանք Patroni տեղեկամատյաններն են յուրաքանչյուր հանգույցի համար, մյուս ներդիրում՝ սրանք Consul տեղեկամատյաններն են կամ անհրաժեշտության դեպքում Postgres: Շատ դժվար է սա ախտորոշել։

Ի՞նչ մոտեցումներ եմ մշակել: Նախ, ես միշտ նայում եմ, երբ ֆայլերը հասել է: Իսկ ինձ համար սա ջրբաժան է։ Ես նայում եմ, թե ինչ է տեղի ունեցել ֆայլերից առաջ, ֆայլերի ժամանակ և ֆայլերից հետո: Filover-ն ունի երկու նշան. սա մեկնարկի և ավարտի ժամանակն է:

Հաջորդը, ես տեղեկամատյաններում փնտրում եմ այն ​​իրադարձությունները, որոնք նախորդել են ֆայլերին, այսինքն՝ փնտրում եմ այն ​​պատճառները, թե ինչու է տեղի ունեցել ֆայլը:

Եվ սա պատկերացում է տալիս հասկանալու, թե ինչ է տեղի ունեցել, և ինչ կարելի է անել հետագայում, որպեսզի նման հանգամանքներ չառաջանան (և արդյունքում ֆայլեր չկա):

Իսկ որտե՞ղ ենք մենք սովորաբար նայում: Ես նայում եմ:

• Նախ՝ դեպի Պատրոնի գերանները։
• Հաջորդը, ես նայում եմ Postgres-ի տեղեկամատյանները կամ DCS տեղեկամատյանները՝ կախված նրանից, թե ինչ է հայտնաբերվել Patroni-ի տեղեկամատյաններում:
• Եվ համակարգի տեղեկամատյանները նաև երբեմն հասկացնում են, թե ինչն է առաջացրել ֆայլը:

Ինչպե՞ս եմ ես վերաբերվում Patroni-ին: Պատրոնիի հետ շատ լավ հարաբերություններ ունեմ։ Իմ կարծիքով սա լավագույնն է, որ կա այսօր։ Ես գիտեմ շատ այլ ապրանքներ: Սրանք են Stolon, Repmgr, Pg_auto_failover, PAF: 4 գործիք. Ես փորձեցի բոլորին: Պատրոնն իմ սիրելին է:

Եթե ​​ինձ հարցնեն. «Պատրոնին խորհուրդ կտա՞մ»: Ես կասեմ՝ այո, քանի որ ինձ դուր է գալիս Պատրոնին։ Եվ կարծում եմ, որ սովորել եմ այն ​​պատրաստել:

Եթե ​​դուք հետաքրքրված եք տեսնել, թե ինչ այլ խնդիրներ կան Patroni-ի հետ, բացի իմ նշած խնդիրներից, միշտ կարող եք ստուգել էջը: հարցեր GitHub-ում: Շատ տարբեր պատմություններ կան ու շատ հետաքրքիր հարցեր են քննարկվում այնտեղ։ Եվ արդյունքում որոշ սխալներ ներկայացվեցին և լուծվեցին, այսինքն՝ սա հետաքրքիր ընթերցում է։

Հետաքրքիր պատմություններ կան այն մասին, որ մարդիկ կրակում են իրենց ոտքին: Շատ տեղեկատվական: Կարդում ես ու հասկանում, որ դա անել պետք չէ։ Ես ինքս ինձ նշան արեցի.

Եվ ես կցանկանայի մեծ շնորհակալություն հայտնել Զալանդոյին այս նախագիծը մշակելու համար, մասնավորապես Ալեքսանդր Կուկուշկինին և Ալեքսեյ Կլյուկինին։ Ալեքսեյ Կլյուկինը համահեղինակներից է, նա այլևս չի աշխատում Zalando-ում, բայց սրանք երկու մարդիկ են, ովքեր սկսել են աշխատել այս ապրանքի հետ։

Ու կարծում եմ, որ Պատրոնին շատ թույն բան է։ Ես ուրախ եմ, որ նա կա, նրա հետ հետաքրքիր է։ Եվ մեծ շնորհակալություն բոլոր այն մասնակիցներին, ովքեր պատիչներ են գրում Patroni-ին: Հուսով եմ, որ Պատրոնին տարիքի հետ ավելի հասուն, սառը և արդյունավետ կդառնա։ Այն արդեն ֆունկցիոնալ է, բայց հուսով եմ, որ ավելի լավ կլինի: Հետևաբար, եթե նախատեսում եք օգտագործել Patroni, ապա մի վախեցեք: Սա լավ լուծում է, այն կարելի է իրականացնել և օգտագործել։

Այսքանը: Եթե ​​հարցեր ունեք, հարցրեք:

Հարցեր

Շնորհակալություն զեկույցի համար: Եթե ​​ֆայլերից հետո դուք դեռ պետք է շատ ուշադիր նայեք այնտեղ, ապա ինչո՞ւ է մեզ անհրաժեշտ ավտոմատ ֆայլեր:

Քանի որ դա նոր բան է: Մենք նրա հետ ենք ընդամենը մեկ տարի: Ավելի լավ է ապահով լինել: Մենք ուզում ենք մտնել և տեսնել, որ ամեն ինչ իսկապես ստացվել է այնպես, ինչպես պետք է: Սա մեծահասակների անվստահության մակարդակն է՝ ավելի լավ է կրկնակի ստուգել և տեսնել:

Օրինակ՝ առավոտ գնացինք ու նայեցինք, հա՞։

Առավոտյան չէ, մենք սովորաբար իմանում ենք ավտոմատ ֆայլի մասին գրեթե անմիջապես: Մենք ծանուցումներ ենք ստանում, տեսնում ենք, որ ավտոմատ ֆայլ է առաջացել։ Մենք գրեթե անմիջապես գնում և նայում ենք։ Բայց այս բոլոր ստուգումները պետք է հասցնել մոնիտորինգի մակարդակի։ Եթե ​​մուտք եք գործում Patroni REST API-ի միջոցով, կա պատմություն: Պատմության համաձայն՝ դուք կարող եք տեսնել ժամանակային դրոշմանիշները, երբ ֆայլը տեղի է ունեցել: Դրա հիման վրա կարելի է մոնիտորինգ անել։ Դուք կարող եք տեսնել պատմությունը, թե քանի իրադարձություն է եղել այնտեղ։ Եթե ​​մենք ունենք ավելի շատ իրադարձություններ, ապա տեղի է ունեցել ավտոմատ ֆայլ: Դուք կարող եք գնալ և տեսնել: Կամ մեր մոնիտորինգի ավտոմատացումը ստուգեց, որ մենք ունենք բոլոր կրկնօրինակները տեղում, ուշացում չկա, և ամեն ինչ լավ է:

Thank you!

Շատ շնորհակալ եմ հիանալի պատմության համար: Եթե ​​մենք տեղափոխել ենք DCS կլաստերը Postgres կլաստերից ինչ-որ տեղ հեռու, ապա այս կլաստերը նույնպես պետք է պարբերաբար սպասարկվի: Որո՞նք են լավագույն փորձը, որ DCS կլաստերի որոշ մասեր պետք է անջատվեն, ինչ-որ բան անել դրանց հետ և այլն: Ինչպե՞ս է գոյատևում այս ամբողջ կառույցը: Եվ ինչպես եք դուք անում այս բաները:

Մի ընկերության համար անհրաժեշտ էր կազմել խնդիրների մատրիցա, թե ինչ է տեղի ունենում, եթե բաղադրիչներից մեկը կամ մի քանի բաղադրիչները ձախողվեն։ Ըստ այս մատրիցայի, մենք հաջորդաբար անցնում ենք բոլոր բաղադրիչները և կառուցում սցենարներ այս բաղադրիչների ձախողման դեպքում։ Համապատասխանաբար, յուրաքանչյուր ձախողման սցենարի համար դուք կարող եք ունենալ վերականգնման գործողությունների ծրագիր: Իսկ DCS-ի դեպքում դա գալիս է որպես ստանդարտ ենթակառուցվածքի մաս: Եվ ադմինը կառավարում է այն, և մենք արդեն ապավինում ենք այն կառավարող ադմիններին և վթարների դեպքում այն ​​ուղղելու նրանց կարողությանը: Եթե ​​ընդհանրապես DCS չկա, ապա մենք այն տեղակայում ենք, բայց միևնույն ժամանակ առանձնապես չենք վերահսկում, քանի որ մենք պատասխանատվություն չենք կրում ենթակառուցվածքի համար, այլ տալիս ենք առաջարկություններ, թե ինչպես և ինչ վերահսկել:

Այսինքն՝ ես ճի՞շտ հասկացա, որ հոսթների հետ որևէ բան անելուց առաջ պետք է անջատել Patroni-ն, անջատել ֆայլերը, անջատել ամեն ինչ։

Դա կախված է նրանից, թե քանի հանգույց ունենք DCS կլաստերում: Եթե ​​կան շատ հանգույցներ, և եթե անջատենք հանգույցներից միայն մեկը (կրկնօրինակը), ապա կլաստերը պահպանում է քվորում: Իսկ Պատրոնը շարունակում է գործել: Եվ ոչինչ չի հրահրվում: Եթե ​​մենք ունենք որոշ բարդ գործողություններ, որոնք ազդում են ավելի շատ հանգույցների վրա, որոնց բացակայությունը կարող է փչացնել քվորումը, ապա, այո, կարող է իմաստ ունենալ Patroni-ին դադարի մեջ դնել: Ունի համապատասխան հրաման՝ patronictl pause, patronictl resume։ Մենք պարզապես դադար ենք տալիս, և ավտոմատ ֆայլերը այդ պահին չի աշխատում: Մենք կատարում ենք սպասարկում DCS կլաստերի վրա, այնուհետև հանում ենք դադարը և շարունակում ենք ապրել:

Thank you very much!

Շատ շնորհակալ եմ ձեր զեկույցի համար: Ինչպե՞ս է արտադրանքի թիմը զգում տվյալների կորստի մասին:

Ապրանքների թիմերը հոգ չեն տանում, իսկ թիմի առաջատարներն անհանգստացած են:

Ի՞նչ երաշխիքներ կան։

Երաշխիքները շատ դժվար են։ Ալեքսանդր Կուկուշկինը զեկույց ունի «Ինչպես հաշվարկել RPO-ն և RTO-ն», այսինքն՝ վերականգնման ժամանակը և որքան տվյալներ կարող ենք կորցնել: Կարծում եմ՝ պետք է գտնել այս սլայդները և ուսումնասիրել դրանք: Որքան հիշում եմ, կան կոնկրետ քայլեր, թե ինչպես կարելի է հաշվարկել այս բաները: Քանի՞ գործարք կարող ենք կորցնել, որքան տվյալներ կարող ենք կորցնել: Որպես տարբերակ, մենք կարող ենք օգտագործել համաժամանակյա կրկնօրինակումը Patroni մակարդակում, բայց սա երկսայրի սուր է. մենք կամ ունենք տվյալների հուսալիություն, կամ կորցնում ենք արագությունը: Կա համաժամանակյա կրկնօրինակում, բայց այն նաև չի երաշխավորում տվյալների կորստի դեմ 100% պաշտպանություն:

Ալեքսեյ, շնորհակալություն հիանալի զեկույցի համար: Զրոյական մակարդակի պաշտպանության համար Patroni-ի օգտագործման փորձ կա՞: Այսինքն՝ համաժամանակյա սպասման հետ կապված։ Սա առաջին հարցն է։ Եվ երկրորդ հարցը. Դուք օգտագործել եք տարբեր լուծումներ։ Մենք օգտագործել ենք Repmgr-ը, բայց առանց autofiler-ի, և այժմ մենք նախատեսում ենք ներառել autofiler: Իսկ Patroni-ին մենք դիտարկում ենք որպես այլընտրանքային լուծում։ Ի՞նչ կարող եք ասել որպես առավելություններ Repmgr-ի համեմատ:

Առաջին հարցը վերաբերում էր սինխրոն կրկնօրինակներին: Այստեղ ոչ ոք չի օգտագործում համաժամանակյա կրկնօրինակում, քանի որ բոլորը վախենում են (մի քանի հաճախորդներ արդեն օգտագործում են այն, սկզբունքորեն, նրանք չեն նկատել կատարման խնդիրներ. Բանախոսի գրառումը) Բայց մենք ինքներս մեզ համար մշակել ենք կանոն, որ համաժամանակյա վերարտադրության կլաստերում պետք է լինի առնվազն երեք հանգույց, քանի որ եթե մենք ունենք երկու հանգույց, և եթե հիմնականը կամ կրկնօրինակը ձախողվում է, ապա Patroni-ն այս հանգույցը փոխում է ինքնուրույն ռեժիմի, որպեսզի հավելվածը շարունակի գործել: աշխատանքը։ Այս դեպքում տվյալների կորստի վտանգ կա:

Երկրորդ հարցի վերաբերյալ մենք օգտագործել ենք Repmgr և դեռ օգտագործում ենք որոշ հաճախորդների հետ պատմական պատճառներով: Ի՞նչ կարելի է ասել։ Patroni-ն գալիս է արկղից դուրս գտնվող ավտոմատ զտիչով, Repmgr-ը գալիս է ավտոմատ զտիչով, որպես լրացուցիչ գործառույթ, որը պետք է միացնել: Մենք պետք է գործարկենք Repmgr daemon-ը յուրաքանչյուր հանգույցի վրա, այնուհետև մենք կարող ենք կարգավորել ավտոմատ ֆայլը:

Repmgr-ը ստուգում է՝ արդյոք Postgres հանգույցները կենդանի են: Repmgr գործընթացները ստուգում են միմյանց գոյությունը, սա այնքան էլ արդյունավետ մոտեցում չէ: կարող են լինել ցանցի մեկուսացման բարդ դեպքեր, երբ մեծ Repmgr կլաստերը կարող է բաժանվել մի քանի փոքրերի և շարունակել աշխատել: Ես երկար ժամանակ չէի հետևում Repmgr-ին, միգուցե այն շտկվել է ... կամ գուցե ոչ: Սակայն DCS-ում կլաստերի վիճակի մասին տեղեկատվության հեռացումը, ինչպես անում է Ստոլոնը, Պատրոնին, ամենակենսունակ տարբերակն է:

Ալեքսեյ, ես մի հարց ունեմ, միգուցե ավելի կաղ. Առաջին օրինակներից մեկում դուք DCS-ը տեղական մեքենայից տեղափոխեցիք հեռավոր հոսթ: Մենք հասկանում ենք, որ ցանցը մի բան է, որն ունի իր առանձնահատկությունները, այն ապրում է ինքնուրույն։ Իսկ ի՞նչ տեղի կունենա, եթե ինչ-ինչ պատճառներով DCS կլաստերն անհասանելի դառնա: Պատճառները չեմ ասի, դրանք կարող են շատ լինել՝ ցանցագործների ծուռ ձեռքերից մինչև իրական խնդիրներ։

Ես դա բարձրաձայն չասացի, բայց DCS կլաստերը նույնպես պետք է ձախողվի, այսինքն՝ այն կենտ թվով հանգույցներ է, որպեսզի քվորում ապահովվի: Ի՞նչ է պատահում, եթե DCS կլաստերը դառնում է անհասանելի, կամ քվորումը չի կարող բավարարվել, այսինքն՝ ինչ-որ ցանցի պառակտում կամ հանգույցի ձախողում: Այս դեպքում Patroni կլաստերը անցնում է միայն կարդալու ռեժիմ: Patroni կլաստերը չի կարող որոշել կլաստերի վիճակը և ինչ անել: Այն չի կարող կապ հաստատել DCS-ի հետ և այնտեղ պահել նոր կլաստերի վիճակը, ուստի ամբողջ կլաստերը անցնում է միայն կարդալու: Եվ սպասում է կամ օպերատորի ձեռքով միջամտությանը կամ DCS-ի վերականգնմանը:

Կոպիտ ասած, DCS-ը մեզ համար դառնում է նույնքան կարևոր ծառայություն, որքան բուն բազան։

Այո այո. Շատ ժամանակակից ընկերություններում Service Discovery-ը ենթակառուցվածքի անբաժանելի մասն է: Այն իրականացվում է նույնիսկ ավելի վաղ ենթակառուցվածքում տվյալների բազայի առկայությունից առաջ։ Համեմատաբար, ենթակառուցվածքը գործարկվեց, տեղակայվեց DC-ում, և մենք անմիջապես ունենք Service Discovery: Եթե ​​դա Consul է, ապա դրա վրա կարելի է կառուցել DNS: Եթե ​​սա Etcd-ն է, ապա կարող է լինել մի հատված Kubernetes կլաստերից, որտեղ կտեղակայվի մնացած ամեն ինչ: Ինձ թվում է, որ Service Discovery-ն արդեն ժամանակակից ենթակառուցվածքների անբաժանելի մասն է։ Եվ նրանք այդ մասին շատ ավելի վաղ են մտածում, քան տվյալների բազաների մասին։

Thank you!

Source: www.habr.com