Իր ելույթում Անդրեյ Բորոդինը ձեզ կպատմի, թե ինչպես են նրանք հաշվի առել PgBouncer-ի մասշտաբի փորձը կապի ավազան նախագծելիս: , թե ինչպես են այն գլորել արտադրության մեջ։ Բացի այդ, մենք կքննարկենք pooler-ի ինչ գործառույթներ մենք կցանկանայինք տեսնել նոր տարբերակներում. մեզ համար կարևոր է ոչ միայն ծածկել մեր կարիքները, այլև զարգացնել օգտվողների համայնքը: .
Video:
Բարեւ բոլորին! Իմ անունը Էնդրյու է:
Yandex-ում ես բաց կոդով տվյալների բազաներ եմ մշակում: Եվ այսօր մենք մի թեմա ունենք միացումների միացությունների մասին:
Եթե գիտեք, թե ինչպես կարելի է ռուսերեն զանգահարել կապի պուլեր, ապա ասեք ինձ: Ես շատ եմ ուզում գտնել լավ տեխնիկական տերմին, որը պետք է հաստատվի տեխնիկական գրականության մեջ։
Թեման բավականին բարդ է, քանի որ շատ տվյալների բազաներում կապի միավորը ներկառուցված է, և դուք նույնիսկ կարիք չունեք դրա մասին իմանալու: Որոշ կարգավորումներ, իհարկե, ամենուր են, բայց Postgres-ում դա չի աշխատում: Եվ դրան զուգահեռ (HighLoad++ 2019-ին) կա Նիկոլայ Սամոխվալովի զեկույցը Postgres-ում հարցումներ տեղադրելու մասին։ Եվ ես հասկանում եմ, որ մարդիկ եկել են այստեղ, ովքեր արդեն կատարելապես կարգավորել են հարցումները, և սրանք մարդիկ են, ովքեր բախվում են ցանցի, ռեսուրսների օգտագործման հետ կապված ավելի հազվադեպ համակարգի խնդիրների հետ: Իսկ տեղ-տեղ կարող է բավականին բարդ լինել այն առումով, որ խնդիրներն ակնհայտ չեն։
Yandex-ն ունի Postgres: Yandex-ի շատ ծառայություններ ապրում են Yandex.Cloud-ում: Եվ մենք ունենք մի քանի փետաբայթ տվյալներ, որոնք ստեղծում են վայրկյանում առնվազն մեկ միլիոն հարցում Postgres-ում:
Եվ մենք տրամադրում ենք բավականին բնորոշ կլաստեր բոլոր ծառայությունների համար. սա հանգույցի հիմնական առաջնային հանգույցն է, սովորական երկու կրկնօրինակները (սինխրոն և ասինխրոն), կրկնօրինակի վրա ընթերցման հարցումների կրկնօրինակում, մասշտաբավորում:
Յուրաքանչյուր կլաստերային հանգույց Postgres-ն է, որի վրա, բացի Postgres-ից և մոնիտորինգի համակարգերից, տեղադրված է նաև կապի պուլեր։ Միացման լողավազանն օգտագործվում է ցանկապատերի և իր հիմնական նպատակի համար:
Ո՞րն է կապի լողավազանի հիմնական նպատակը:
Postgres-ը ընդունում է տվյալների բազայի հետ աշխատելու գործընթացի մոդել: Սա նշանակում է, որ մեկ կապը մեկ գործընթաց է, մեկ Postgres backend: Եվ այս հետնամասում կան բազմաթիվ տարբեր քեշեր, որոնք բավականին թանկ են տարբեր կապերի համար տարբեր դարձնելու համար:
Բացի այդ, Postgres կոդի մեջ կա մի զանգված, որը կոչվում է procArray: Այն պարունակում է հիմնական տվյալներ ցանցային կապերի մասին: Եվ գրեթե բոլոր procArray մշակման ալգորիթմներն ունեն գծային բարդություն, դրանք անցնում են ցանցային միացումների ողջ զանգվածով։ Դա բավականին արագ ցիկլ է, բայց ավելի շատ մուտքային ցանցային կապերի դեպքում ամեն ինչ մի փոքր ավելի թանկ է դառնում: Եվ երբ ամեն ինչ մի փոքր թանկանում է, դուք ի վերջո շատ բարձր գին եք վճարում մեծ թվով ցանցային միացումների համար:
Գոյություն ունի 3 հնարավոր մոտեցում.
- Դիմումի կողմում.
- Տվյալների բազայի կողմում:
- Իսկ արանքում, այսինքն՝ բոլոր հնարավոր համակցությունները։
Ցավոք, ներկառուցված լողավազանը ներկայումս մշակման փուլում է: PostgreSQL Professional-ի ընկերները հիմնականում դա անում են: Թե երբ կհայտնվի, դժվար է կանխատեսել։ Եվ իրականում ճարտարապետի ընտրության երկու լուծում ունենք. Սրանք դիմումի կողմնակի լողավազան և վստահված անձի լողավազան են:
Կիրառման կողմնակի լողավազանն ամենահեշտ ճանապարհն է: Եվ գրեթե բոլոր հաճախորդի դրայվերները ձեզ հնարավորություն են տալիս. ներկայացնել ձեր միլիոնավոր կապերը կոդում որպես տվյալների բազայի մի քանի տասնյակ կապեր:
Խնդիր կա այն փաստի հետ, որ որոշակի կետում դուք ցանկանում եք մասշտաբավորել հետնամասը, ցանկանում եք այն տեղակայել բազմաթիվ վիրտուալ մեքենաների վրա:
Հետո դու դեռ հասկանում ես, որ ունես ևս մի քանի հասանելիության գոտիներ, մի քանի տվյալների կենտրոններ։ Իսկ հաճախորդի կողմից միավորման մոտեցումը հանգեցնում է մեծ թվերի: Խոշորները կազմում են մոտ 10 կապ: Սա եզր է, որը կարող է լավ աշխատել:
Եթե խոսենք պրոքսի պուլերների մասին, ապա կան երկու պուլերներ, որոնք կարող են շատ բաներ անել: Նրանք միայն լողավազաններ չեն։ Նրանք poolers + ավելի լավ ֆունկցիոնալ. Սա и .
Բայց, ցավոք, ոչ բոլորին է պետք այս լրացուցիչ ֆունկցիոնալությունը: Եվ դա հանգեցնում է նրան, որ poolers-ն աջակցում է միայն նիստերի միավորմանը, այսինքն՝ մեկ մուտքային հաճախորդ, մեկ ելքային հաճախորդ դեպի տվյալների բազա:
Սա այնքան էլ հարմար չէ մեր առաջադրանքների համար, ուստի մենք օգտագործում ենք PgBouncer-ը, որն իրականացնում է գործարքների միավորում, այսինքն՝ սերվերի միացումները քարտեզագրվում են հաճախորդների միացումներին միայն գործարքի տևողության համար:
Եվ մեր բեռի վրա, դա ճիշտ է: Բայց կան մի քանի խնդիրներ.
Խնդիրները սկսվում են, երբ ցանկանում եք ախտորոշել նիստը, քանի որ բոլոր մուտքային կապերը տեղական են: Բոլորը եկել են loopback-ով և ինչ-որ կերպ դժվարանում է հետևել նիստին:
Իհարկե, դուք կարող եք օգտագործել application_name_add_host: Սա Bouncer-ի կողային եղանակն է՝ IP հասցե ավելացնելու application_name-ին: Բայց application_name-ը սահմանվում է լրացուցիչ կապով:
Այս գծապատկերում, որտեղ դեղին գիծը իրական հարցումներն են, իսկ կապույտ գիծը՝ հարցումները, որոնք թռչում են տվյալների բազա: Եվ այս տարբերությունը հենց application_name-ի կարգավորումն է, որն անհրաժեշտ է միայն հետագծելու համար, բայց այն ամենևին էլ անվճար չէ։
Բացի այդ, Bouncer-ը չի կարող սահմանափակել մեկ լողավազան, այսինքն՝ տվյալների բազայի միացումների քանակը մեկ օգտագործողի համար, յուրաքանչյուր տվյալների բազայում:
Սա ինչի՞ է հանգեցնում։ Դուք ունեք բեռնված սերվիս, որը գրված է C ++-ով և ինչ-որ տեղ մոտակայքում մի փոքրիկ ծառայություն մի հանգույցի վրա, որը ոչ մի վատ բան չի անում բազայի հետ, բայց դրա վարորդը խելագարվում է: Այն բացում է 20 կապ, իսկ մնացած ամեն ինչ կսպասի: Նույնիսկ ձեր կոդը ճիշտ է:
Իհարկե, մենք Bouncer-ի համար գրել ենք փոքրիկ կարկատել, որն ավելացրել է այս պարամետրը, այսինքն՝ սահմանափակելով հաճախորդներին լողավազանում:
Դա հնարավոր կլիներ անել Postgres-ի կողմից, այսինքն՝ սահմանափակել դերերը տվյալների բազայում կապերի քանակով:
Բայց հետո դուք կորցնում եք հասկանալու ունակությունը, թե ինչու կապեր չունեք սերվերի հետ: PgBouncer-ը կապի սխալ չի տալիս, այն միշտ վերադարձնում է նույն տեղեկատվությունը: Եվ դուք չեք կարող հասկանալ. գուցե ձեր գաղտնաբառը փոխվել է, գուցե տվյալների բազան պարզապես իջել է, գուցե ինչ-որ բան այն չէ: Բայց ախտորոշում չկա։ Եթե նիստը չի կարող հաստատվել, դուք չեք իմանա, թե ինչու դա չի կարող արվել:
Ինչ-որ պահի նայում ես հավելվածի գրաֆիկներին ու տեսնում, որ հավելվածը չի աշխատում։
Նայեք վերևին և տեսեք, որ Bouncer-ը մեկ թելերով է: Սա շրջադարձային է ծառայության կյանքում։ Դուք հասկանում եք, որ պատրաստվում էիք մեկուկես տարում ընդլայնել տվյալների բազան, և դուք պետք է մեծացնեք ավելին:
Մենք եկել ենք այն եզրակացության, որ մեզ անհրաժեշտ են ավելի շատ PgBouncers:
Bouncer-ը մի փոքր կարկատվել է:
Եվ նրանք այնպես արեցին, որ մի քանի Bouncer-ներ կարող են բարձրացվել TCP պորտի վերաօգտագործմամբ: Եվ արդեն օպերացիոն համակարգը ավտոմատ կերպով փոխանցում է մուտքային TCP կապերը նրանց միջև round-robin'om-ով:
Սա թափանցիկ է հաճախորդների համար, այսինքն՝ թվում է, թե դուք ունեք մեկ Bouncer, բայց դուք ունեք անգործուն կապերի մասնատվածություն գործարկվող Bouncers-ի միջև:
Եվ ինչ-որ պահի, դուք կարող եք նկատել, որ այս 3 Bouncer-ներից յուրաքանչյուրը 100%-ով ուտում է իր միջուկը: Ձեզ անհրաժեշտ են բավականին մի քանի Bouncers: Ինչո՞ւ։
Քանի որ դուք ունեք TLS: Դուք գաղտնագրված կապ ունեք: Եվ եթե դուք փորձարկեք Postgres-ը TLS-ով և առանց TLS-ի, ապա կտեսնեք, որ հաստատված կապերի թիվը կնվազի գրեթե երկու կարգով, քանի որ գաղտնագրումը միացված է, քանի որ TLS ձեռքսեղմումը սպառում է պրոցեսորի ռեսուրսները:
Եվ վերևում դուք կարող եք տեսնել բավականին գաղտնագրային գործառույթներ, որոնք իրականացվում են մուտքային կապերի ալիքի ընթացքում: Քանի որ մեր հիմնականը կարող է անցնել հասանելիության գոտիների միջև, մուտքային կապերի ալիքը բավականին բնորոշ իրավիճակ է: Այսինքն, ինչ-ինչ պատճառներով, հին առաջնայինն անհասանելի էր, ամբողջ բեռը ուղարկվեց մեկ այլ տվյալների կենտրոն: Նրանք բոլորը կգան ողջունելու TLS-ին միաժամանակ:
Եվ մեծ թվով TLS ձեռքսեղմումներ կարող են արդեն ոչ թե ողջունել Բաունսերին, այլ սեղմել նրա կոկորդը: Մուտքային կապերի ալիքը կարող է չխաթարվել ժամանակի դադարի պատճառով: Եթե դուք նորից փորձեք դեպի բազա՝ առանց էքսպոնենցիալ հետընթացի, դրանք նորից ու նորից չեն վերադառնա համահունչ ալիքով:
Ահա 16 PgBouncer-ի օրինակ, որոնք բեռնում են 16 միջուկներ 100%-ով:
Մենք հասել ենք կասկադային PgBouncer-ին: Սա լավագույն կոնֆիգուրացիան է, որին մենք կարող ենք հասնել մեր Bouncer բեռի վրա: Մեր արտաքին Bouncer-ները ծառայում են TCP ձեռքսեղմման համար, իսկ ներքին Bouncer-ները ծառայում են իրական միավորման համար, որպեսզի մեծապես չկոտրվեն արտաքին կապերը:
Այս կազմաձևում հնարավոր է փափուկ վերագործարկում: Դուք կարող եք վերագործարկել բոլոր այս 18 Bouncers-ը մեկ առ մեկ: Բայց նման կոնֆիգուրացիայի պահպանումը բավականին դժվար է: Համակարգի ադմինիստրատորները, DevOps-ը և այն մարդիկ, ովքեր իսկապես պատասխանատու են այս սերվերի համար, այնքան էլ գոհ չեն լինի այս սխեմայից:
Թվում է, թե մեր բոլոր բարելավումները կարող են խթանվել բաց կոդով, բայց Bouncer-ը այնքան էլ լավ չի աջակցում: Օրինակ, նույն նավահանգստում մի քանի PgBouncer-ներ գործարկելու հնարավորությունը կատարվել է մեկ ամիս առաջ: Այս հատկանիշով ձգման հարցումը եղել է մի քանի տարի առաջ:
Կամ ևս մեկ օրինակ. Postgres-ում դուք կարող եք չեղարկել գործող հարցումը՝ ուղարկելով գաղտնիքը մեկ այլ կապի առանց լրացուցիչ նույնականացման: Բայց որոշ հաճախորդներ պարզապես ուղարկում են TCP-վերականգնում, այսինքն՝ նրանք խախտում են ցանցային կապը: Ի՞նչ կանի Բաունսերը սրա հետ: Նա ոչինչ չի անի։ Այն կշարունակի կատարել հարցումը: Եթե դուք ստացել եք հսկայական թվով կապեր, որոնք հիմք են դրել փոքր հարցումներով, ապա պարզապես կապը Bouncer-ից անջատելը բավարար չի լինի, դուք նույնպես պետք է լրացնեք այն հարցումները, որոնք գործում են տվյալների բազայում:
Սա կարկատվել է, և խնդիրը դեռևս չի միացվել Bouncer-ի վերին հոսանքին:
Եվ այսպես, մենք եկանք այն եզրակացության, որ մեզ անհրաժեշտ է մեր սեփական կապի լողավազան, որը կմշակվի, կկարկատվի, որի մեջ հնարավոր կլինի արագ շտկել խնդիրները և որը, իհարկե, պետք է լինի բազմաթելային։
Մենք որպես հիմնական խնդիր դրեցինք բազմաթելային աշխատանքը: Մենք պետք է կարողանանք լավ կառավարել մուտքային TLS կապերի ալիքը:
Դա անելու համար մենք պետք է մշակեինք առանձին գրադարան, որը կոչվում է Machinarium, որը նախատեսված է ցանցային կապի մեքենայական վիճակները որպես սերիական կոդ նկարագրելու համար: Եթե նայեք libpq աղբյուրի կոդը, կտեսնեք բավականին բարդ զանգեր, որոնք կարող են ձեզ վերադարձնել արդյունքը և ասել. «Զանգիր ինձ մի փոքր ուշ: Հենց հիմա ես IO ունեմ առայժմ, բայց երբ IO-ն անցնում է, պրոցեսորի վրա ծանրաբեռնվածություն ունեմ: Եվ սա բազմամակարդակ սխեմա է: Ցանցի փոխազդեցությունը սովորաբար նկարագրվում է պետական մեքենայի կողմից: Շատ կանոններ, ինչպիսիք են «Եթե ես նախկինում ստացել էի N չափի փաթեթի վերնագիր, ապա հիմա սպասում եմ N բայթ», «Եթե ես ուղարկել եմ SYNC փաթեթ, ապա այժմ սպասում եմ արդյունքի մետատվյալներով փաթեթի»: Ստացվում է բավականին բարդ հակաինտուիտիվ ծածկագիր, կարծես լաբիրինթոսը վերածվել է գծային սկանավորման: Մենք այնպես արեցինք, որ պետական մեքենայի փոխարեն ծրագրավորողը նկարագրում է փոխազդեցության հիմնական ուղին սովորական իմպերատիվ կոդի տեսքով։ Պարզապես այս հրամայական կոդում դուք պետք է տեղադրեք այն վայրերը, որտեղ կատարման հաջորդականությունը պետք է ընդհատվի՝ սպասելով տվյալներին ցանցից՝ փոխանցելով կատարման համատեքստը մեկ այլ կորուտինի (կանաչ թեմա): Այս մոտեցումը նման է նրան, որ մենք անընդմեջ գրում ենք լաբիրինթոսում ամենասպասված ճանապարհը, իսկ հետո դրան ճյուղեր ավելացնում։
Արդյունքում, մենք ունենք մեկ շղթա, որը ստիպում է TCP-ին ընդունել և շրջանաձև ռեժիմով փոխանցել TPC կապը շատ աշխատողների:
Այս դեպքում յուրաքանչյուր հաճախորդի կապ միշտ աշխատում է մեկ պրոցեսորի վրա: Եվ սա թույլ է տալիս այն դարձնել քեշի համար հարմար:
Եվ բացի այդ, մենք փոքր-ինչ բարելավել ենք փոքր փաթեթների հավաքածուն մեկ մեծ փաթեթի մեջ, որպեսզի բեռնաթափենք համակարգի TCP փաթեթը:
Բացի այդ, մենք կատարելագործել ենք գործարքների միավորումն այն առումով, որ Odyssey-ը, երբ կազմաձևված է, կարող է ուղարկել CANCEL և ROLLBACK ցանցային կապի խափանման դեպքում, այսինքն, եթե ոչ ոք չի սպասում խնդրանքին, Odyssey-ը կասի տվյալների բազան չփորձի կատարել: խնդրանքը, որը կարող է վատնել թանկարժեք ռեսուրսները:
Եվ հնարավորության դեպքում մենք կապեր ենք պահպանում նույն հաճախորդի հետ: Սա թույլ չի տալիս վերատեղադրել application_name_add_host-ը: Հնարավորության դեպքում մենք չունենք ախտորոշման համար անհրաժեշտ պարամետրերի լրացուցիչ վերականգնում:
Մենք աշխատում ենք Yandex.Cloud-ի շահերից ելնելով: Եվ եթե դուք օգտագործում եք կառավարվող PostgreSQL և ունեք տեղադրված կապի միավոր, կարող եք տրամաբանական վերարտադրություն ստեղծել դեպի դուրս, այսինքն՝ թողնել մեզ, եթե ցանկանում եք՝ օգտագործելով տրամաբանական վերարտադրությունը: Տրամաբանական կրկնօրինակման հոսքից դուրս պարծենկոտը չի տա:
Սա տրամաբանական կրկնօրինակման ստեղծման օրինակ է:
Բացի այդ, մենք աջակցություն ունենք ֆիզիկական վերարտադրության համար: Cloud-ում, իհարկե, դա անհնար է, քանի որ այդ դեպքում կլաստերը ձեզ չափազանց շատ տեղեկատվություն կտա իր մասին։ Բայց ձեր տեղադրություններում, եթե ձեզ անհրաժեշտ է ֆիզիկական կրկնօրինակում Odyssey-ում միացման պոուլերի միջոցով, դա հնարավոր է:
Odyssey-ն ունի լիովին համատեղելի մոնիտորինգ PgBouncer-ի հետ: Մենք ունենք նույն վահանակը, որը կատարում է գրեթե բոլոր նույն հրամանները: Եթե ինչ-որ բան բացակայում է, ուղարկեք ձգման հարցում կամ գոնե խնդիր GitHub-ում, մենք կկատարենք անհրաժեշտ հրամանները: Բայց մենք արդեն ունենք PgBouncer վահանակի հիմնական ֆունկցիոնալությունը:
Եվ, իհարկե, մենք ունենք փոխանցման սխալ: Մենք կվերադարձնենք բազայի հաղորդած սխալը։ Դուք տեղեկատվություն կստանաք, թե ինչու չեք գտնվում բազայում, ոչ միայն այն մասին, որ դուք դրա մեջ չեք:
Այս ֆունկցիան անջատված է, եթե Ձեզ անհրաժեշտ է 100% համատեղելիություն PgBouncer-ի հետ: Մենք կարող ենք վարվել ինչպես պարծենկոտ, ամեն դեպքում:
Զարգացում
Մի քանի խոսք Odyssey սկզբնական կոդի մասին։
Օրինակ, կան «Դադար / Վերսկսել» հրամանները: Դրանք սովորաբար օգտագործվում են տվյալների բազան թարմացնելու համար: Եթե Ձեզ անհրաժեշտ է արդիականացնել Postgres-ը, կարող եք դադարեցնել այն կապի միավորում, կատարել pg_upgrade, ապա վերսկսել: Եվ հաճախորդի կողմից, կարծես տվյալների բազան պարզապես դանդաղում էր: Այս ֆունկցիոնալությունը մեզ բերեցին համայնքի մարդիկ: Նա դեռ չի մահացել, բայց շուտով ամեն ինչ կլինի: (արդեն մահացած)
- արդեն մահացած
Բացի այդ, PgBouncer-ի նոր հնարավորություններից է SCRAM Authentication-ի աջակցությունը, որը մեզ է բերել նաև Yandex.Cloud-ում չաշխատող անձը: Երկուսն էլ բարդ ֆունկցիոնալ են և կարևոր:
Ուստի ես կցանկանայի ձեզ ասել, թե ինչից է ստեղծված Odyssey-ը, եթե դուք նույնպես ցանկանում եք հիմա ինչ-որ կոդ գրել։
Դուք ունեք օրիգինալ Odyssey բազան, որը հիմնված է երկու հիմնական գրադարանների վրա: Կիվի գրադարանը Postgres հաղորդագրության արձանագրության իրականացումն է: Այսինքն, Postgres-ի մայրենի պրոտո 3-ը ստանդարտ հաղորդագրություններ են, որոնք կարող են փոխանակել ճակատներն ու հետնամասերը: Դրանք իրականացվում են կիվի գրադարանում։
Machinarium գրադարանը թելերի իրականացման գրադարան է: Այս Machinarium-ի մի փոքրիկ հատված գրված է assembler-ում: Բայց մի անհանգստացեք, կա ընդամենը 15 տող:
Ոդիսական ճարտարապետություն. Գոյություն ունի հիմնական մեքենա, որն աշխատում է կորուտիններով: Այս մեքենան իրականացնում է մուտքային TCP կապերի ընդունում և բաշխում աշխատողների միջև:
Մեկ աշխատողի ներսում կարող է աշխատել մի քանի հաճախորդների համար աշխատող: Եվ նաև հիմնական թեմայում պտտվում է վահանակը և քրոնի առաջադրանքների մշակումը, որպեսզի հեռացնեն կապերը, որոնք այլևս անհրաժեշտ չեն լողավազանում:
Odyssey-ը փորձարկվում է ստանդարտ Postgres թեստային փաթեթի միջոցով: Մենք պարզապես կատարում ենք install-check-ը Bouncer-ի միջոցով և Odyssey-ի միջոցով՝ մենք ստանում ենք null div: Կան մի քանի թեստեր, որոնք կապված են ամսաթվի ձևաչափման հետ, որոնք նույն կերպ ձախողվում են Bouncer-ում և Odyssey-ում:
Բացի այդ, կան բազմաթիվ վարորդներ, որոնք ունեն իրենց փորձարկումը: Եվ մենք օգտագործում ենք նրանց թեստերը Ոդիսականը փորձարկելու համար:
Բացի այդ, շնորհիվ մեր կասկադային կոնֆիգուրացիայի, մենք պետք է փորձարկենք տարբեր փաթեթներ՝ Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, որպեսզի համոզվենք, որ եթե Odyssey-ը կա կասկադի որևէ մասում է, այն նույնպես աշխատում է այնպես, ինչպես սպասվում էր: .
Rake
Արտադրության մեջ մենք օգտագործում ենք Odyssey-ը: Եվ արդար չի լինի, եթե ասեմ, որ ամեն ինչ ուղղակի աշխատում է։ Ոչ, այսինքն՝ այո, բայց ոչ միշտ։ Օրինակ, արտադրության մեջ ամեն ինչ պարզապես աշխատում էր, հետո մեր ընկերները PostgreSQL Professional-ից եկան և ասացին, որ հիշողության արտահոսք ունենք: Իրոք եղել են, ուղղել ենք։ Բայց դա պարզ էր.
Այնուհետև մենք հայտնաբերեցինք, որ կապի միավորիչն ունի մուտքային TLS և ելքային TLS կապեր: Իսկ կապերին անհրաժեշտ են հաճախորդի վկայագրեր և սերվերի վկայագրեր:
Bouncer և Odyssey սերվերի վկայագրերը վերընթերցվում են pcache-ով, սակայն հաճախորդի վկայագրերը կարիք չունեն վերընթերցվելու pcache-ից, քանի որ մեր մասշտաբային Odyssey-ն ի վերջո հիմնված է այս վկայագրի ընթերցման համակարգի աշխատանքի վրա: Սա մեզ համար անակնկալ էր, քանի որ նա անմիջապես չհանգստացավ։ Սկզբում այն գծային մասշտաբով է ծավալվել, և 20 մուտքային միաժամանակյա միացումներից հետո այս խնդիրն իրեն դրսևորել է։
Pluggable Authentication Method-ը ներկառուցված lunux գործիքներով նույնականացման հնարավորությունն է: PgBouncer-ում այն իրականացվում է այնպես, որ կա առանձին թեմա, որը սպասում է PAM-ի պատասխանին, և կա հիմնական PgBouncer թեմա, որը սպասարկում է ընթացիկ կապը և կարող է խնդրել նրանց ապրել PAM թեմայում:
Մենք սա չենք իրականացրել մի պարզ պատճառով. Մենք շատ հոսքեր ունենք։ Ինչո՞ւ է դա մեզ պետք:
Արդյունքում, դա կարող է խնդիրներ առաջացնել այն առումով, որ եթե դուք ունեք PAM-ի իսկությունը և ոչ PAM-ի նույնականացումը, ապա PAM-ի նույնականացման մեծ ալիքը կարող է զգալիորեն հետաձգել ոչ PAM-ի նույնականացումը: Դա այն բաներից է, որը մենք չենք շտկել: Բայց եթե ցանկանում եք շտկել այն, կարող եք դա անել:
Մեկ այլ ռեյկ այն էր, որ մենք ունենք մեկ շարանը, որն ընդունում է բոլոր մուտքային կապերը: Եվ հետո նրանց տեղափոխում են աշխատողների լողավազան, որտեղ տեղի կունենա TLS ձեռքսեղմումը։
Արդյունքում, եթե դուք ունեք 20 ցանցային կապերի համահունչ ալիք, դրանք բոլորը կընդունվեն: Իսկ հաճախորդի կողմից, libpq-ը կսկսի հաղորդել ժամանակի դադարների մասին: Լռելյայնորեն, այնտեղ նման է 000 վայրկյան:
Եթե նրանք բոլորը չեն կարող միաժամանակ մտնել բազա, ապա չեն կարող մտնել բազա, քանի որ այս ամենը կարող է ծածկվել ոչ էքսպոնենցիոնալ կրկնակի փորձով։
Մենք վերջացրինք այստեղ պատճենելով PgBouncer սխեման, որպեսզի մենք ունենանք մեր կողմից ընդունված TCP կապերի քանակի կրճատում:
Եթե տեսնում ենք, որ միացումներ ենք ընդունում, բայց վերջում ձեռքսեղմման ժամանակ չեն ունենում, հերթ ենք դնում, որ պրոցեսորի ռեսուրսները չսպառեն։ Սա հանգեցնում է նրան, որ միաժամանակյա ձեռքսեղմում չի կարող իրականացվել ժամանած բոլոր կապերի համար: Բայց գոնե ինչ-որ մեկը կմտնի տվյալների բազա, նույնիսկ եթե բեռը բավականաչափ ուժեղ է:
Ճանապարհային քարտեզը
Ի՞նչ կցանկանայիք տեսնել ապագայում Odyssey-ում: Ի՞նչ ենք մենք պատրաստ զարգացնել ինքներս մեզ և ի՞նչ ենք ակնկալում համայնքից։
2019 թվականի օգոստոսի համար.
Ահա թե ինչպիսի տեսք ուներ Օդիսական ճանապարհային քարտեզը օգոստոսին.
- Մենք ուզում էինք SCRAM և PAM նույնականացում:
- Մենք ուզում էինք ընթերցման հարցումները փոխանցել սպասման ռեժիմին:
- Ես կցանկանայի առցանց-վերագործարկել:
- Եվ սերվերի վրա դադարեցնելու հնարավորությունը:
Այս ճանապարհային քարտեզի կեսն արված է, և ոչ մեր կողմից։ Եվ սա լավ է: Այսպիսով, եկեք քննարկենք, թե ինչ է մնացել և ավելացնենք ավելին:
? Մենք ունենք կրկնօրինակներ, որոնք, առանց խնդրանքների կատարման, ուղղակի տաքացնելու են օդը։ Մեզ անհրաժեշտ է, որ նրանք ապահովեն ձախողում և անցում: Տվյալների կենտրոններից մեկում խնդիրների դեպքում ես կցանկանայի դրանք զբաղեցնել որոշ օգտակար աշխատանքով։ Քանի որ մենք չենք կարող կարգավորել նույն կենտրոնական պրոցեսորները, նույն հիշողությունը այլ կերպ, քանի որ կրկնօրինակումը այլ կերպ չի աշխատի:
Սկզբունքորեն, Postgres-ում, սկսած 10-ից, կարելի է միանալիս նշել session_attrs։ Դուք կարող եք թվարկել տվյալների բազայի բոլոր հոսթները կապի մեջ և ասել, թե ինչու եք գնում տվյալների բազա՝ գրել կամ կարդալ միայն: Իսկ վարորդն ինքը կընտրի ցուցակի առաջին հոսթին, որն իրեն ավելի շատ է դուր գալիս, որը բավարարում է session_attrs-ի պահանջները։
Բայց այս մոտեցման խնդիրն այն է, որ այն չի վերահսկում կրկնօրինակման հետաձգումը: Դուք կարող եք ունենալ ինչ-որ կրկնօրինակ, որը հետ է մնում ձեր ծառայության համար անընդունելի ժամանակից: Որպեսզի կրկնօրինակի վրա ընթերցման հարցումները լիարժեք կատարենք, իրականում մենք պետք է աջակցենք Odyssey-ում չաշխատելու ունակությանը, երբ անհնար է կարդալ:
Odyssey-ը պետք է ժամանակ առ ժամանակ գնա տվյալների բազա և խնդրի առաջնայինից կրկնօրինակման հեռավորությունը: Եվ եթե այն հասել է սահմանաչափին, մի թողեք նոր հարցումներ տվյալների բազա, ասեք հաճախորդին, որ դուք պետք է նորից գործարկեք կապերը և, հնարավոր է, ընտրեք այլ հոսթ՝ հարցումները կատարելու համար: Սա թույլ կտա տվյալների բազան արագ վերականգնել կրկնօրինակման հետաձգումը և նորից վերադառնալ՝ պատասխանելու հարցումով:
Իրականացման ժամկետները դժվար է նշել, քանի որ այն բաց կոդով է։ Բայց, հուսով եմ, ոչ 2,5 տարի PgBouncer-ի գործընկերների նման: Սա այն հատկանիշն է, որը ես կցանկանայի տեսնել «Ոդիսականում»:
. Այժմ դուք կարող եք պատրաստել պատրաստված հայտարարություն երկու եղանակով. Նախ, դուք կարող եք կատարել SQL հրամանը, մասնավորապես «պատրաստված»: Այս SQL հրամանը հասկանալու համար մենք պետք է սովորենք, թե ինչպես հասկանալ SQL-ը Bouncer-ի կողմից: Սա չափազանց մեծ կլինի, քանի որ դա չափազանց է, քանի որ մեզ անհրաժեշտ է ամբողջ վերլուծիչը: Մենք չենք կարող վերլուծել յուրաքանչյուր SQL հրաման:
Բայց proto3-ի վրա հաղորդագրության արձանագրության մակարդակով պատրաստված հայտարարություն կա: Եվ սա այն վայրն է, երբ տեղեկատվությունը, որ պատրաստված հայտարարությունը ստեղծվում է, գալիս է կառուցվածքային: Եվ մենք կարող էինք աջակցել այն ըմբռնմանը, որ որոշ սերվերային կապի դեպքում հաճախորդը խնդրել է պատրաստել պատրաստված հայտարարություններ: Եվ նույնիսկ եթե գործարքը փակված է, մենք դեռ պետք է սերվերը և հաճախորդը միացված լինեն:
Բայց այստեղ երկխոսության մեջ անհամապատասխանություն է առաջանում, քանի որ ինչ-որ մեկն ասում է, որ դուք պետք է հասկանաք, թե որ պատրաստված հայտարարությունները ստեղծել է հաճախորդը և տարածել սերվերի կապը բոլոր հաճախորդների միջև, որոնք ստեղծել են այս սերվերի կապը, այսինքն, ով է ստեղծել նման պատրաստված հայտարարություն:
Անդրես Ֆրեյունդն ասաց, որ եթե ձեզ մոտ է եկել հաճախորդ, ով արդեն ստեղծել է նման պատրաստված հայտարարություն այլ սերվերի միացումում, ապա ստեղծեք այն նրա համար: Բայց թվում է, թե հաճախորդի փոխարեն տվյալների բազայում հարցումներ կատարելը մի փոքր սխալ է, բայց ծրագրավորողի տեսանկյունից, ով գրում է տվյալների բազայի հետ փոխազդելու արձանագրություն, հարմար կլիներ, եթե նրան ուղղակի ցանցային միացում տրվեր: որ ունի այսպիսի պատրաստված խնդրանք։
Եվ ևս մեկ առանձնահատկություն, որը մենք պետք է իրականացնենք. Այժմ մենք ունենք մոնիտորինգ, որը համատեղելի է PgBouncer-ի հետ: Մենք կարող ենք վերադարձնել հարցման կատարման միջին ժամանակը: Բայց միջին ժամանակը հիվանդանոցում միջին ջերմաստիճանն է. ինչ-որ մեկը ցուրտ է, ինչ-որ մեկը տաք է. միջինում բոլորն առողջ են: Դա ճիշտ չէ։
Մենք պետք է իրականացնենք աջակցություն տոկոսների համար, ինչը ցույց կտա, որ կան դանդաղ պահանջներ, որոնք սպառում են ռեսուրսները և մոնիտորինգն ավելի ընդունելի կդարձնեն:
Ամենակարևորն այն է, որ ես ուզում եմ 1.0 տարբերակ (1.1 տարբերակն արդեն թողարկվել է): Փաստն այն է, որ այժմ Odyssey-ը գտնվում է 1.0rc տարբերակում, այսինքն՝ թողարկման թեկնածու: Եվ ամբողջ ռեյկը, որ թվարկեցի, ֆիքսվել է հենց նույն տարբերակով, բացառությամբ հիշողության արտահոսքի։
Ի՞նչ նշանակություն կունենա մեզ համար 1.0 տարբերակը: Մենք ոդիսականը տարածում ենք դեպի մեր հիմքերը: Այն արդեն աշխատում է մեր տվյալների շտեմարաններում, բայց երբ այն հասնում է վայրկյանում 1 հարցումների կետին, ապա կարող ենք ասել, որ սա թողարկման տարբերակ է, և սա այն տարբերակն է, որը կարելի է անվանել 000:
Համայնքի մի քանի հոգի խնդրել են ավելի շատ դադար և SCRAM 1.0 տարբերակում: Բայց դա կնշանակի, որ մենք պետք է հաջորդ տարբերակը թողարկենք արտադրության, քանի որ ոչ SCRAM-ը, ոչ էլ դադարը դեռ չեն միացվել: Բայց, ամենայն հավանականությամբ, այս հարցը բավականին արագ կլուծվի։
Ես սպասում եմ ձեր ձգման խնդրանքին: Եվ ես նույնպես կցանկանայի լսել, թե ինչ խնդիրներ ունեք դուք Bouncer-ի հետ: Եկեք քննարկենք դրանք: Միգուցե մենք կարողանանք իրականացնել ձեզ անհրաժեշտ որոշ գործառույթներ:
Սա ավարտում է իմ մասը, ես կցանկանայի լսել ձեզնից: Շնորհակալություն!
Հարցեր
Եթե ես դնեմ իմ սեփական application_name-ը, արդյո՞ք այն ճիշտ կուղարկվի, այդ թվում՝ Odyssey-ում գործարքների միավորման ժամանակ:
Odyssey, թե Bouncer.
Ոդիսականում. The Bouncer-ը նետվում է:
Մենք կպատրաստենք հավաքածու:
Իսկ եթե իմ իրական կապը թռչի այլ կապերի վրա, այն կփոխանցվի՞:
Մենք կկազմենք թվարկված բոլոր պարամետրերի հավաքածու: Ես չեմ կարող ասել, արդյոք application_name-ն այս ցանկում է: Կարծես թե նա տեսավ նրան այնտեղ։ Մենք սահմանելու ենք բոլոր նույն պարամետրերը: Մեկ խնդրանքով հավաքածուն կանի այն ամենը, ինչ տեղադրվել է հաճախորդի կողմից գործարկման ընթացքում:
Շնորհակալություն Անդրեյին զեկույցի համար: Լավ հաշվետվություն! Ուրախ եմ, որ Odyssey-ն ամեն րոպե ավելի ու ավելի արագ է զարգանում։ Ես կուզենայի նույնը շարունակել։ Մենք արդեն խնդրել ենք ձեզ ունենալ տվյալների աղբյուրների բազմաբնույթ կապ, որպեսզի Odyssey-ը կարողանա միաժամանակ միանալ տարբեր տվյալների բազաներին, այսինքն՝ ստրուկ վարպետին, այնուհետև ավտոմատ կերպով միանալ նոր վարպետին՝ ձախողումից հետո:
Այո, ես կարծես հիշում եմ այդ քննարկումը։ Այժմ կան մի քանի պահեստներ։ Բայց նրանց միջև անցում չկա: Մեր կողմից, մենք պետք է հարցնենք սերվերին, որ այն դեռ կենդանի է և հասկանանք, որ ձախողում է տեղի ունեցել, ով կկանչի pg_recovery: Ես ստանդարտ ձև ունեմ հասկանալու, որ մենք վարպետի մոտ չենք եկել։ Իսկ սխալներից ինչ-որ կերպ պետք է հասկանանք, թե ինչպե՞ս։ Այսինքն՝ գաղափարը հետաքրքիր է, քննարկվում է։ Գրեք ավելի շատ մեկնաբանություններ: Եթե դուք ունեք աշխատող ձեռքեր, որոնք գիտեն C-ն, ապա սա ընդհանուր առմամբ հրաշալի է:
Կրկնօրինակների մասշտաբի հարցը նույնպես մեզ հետաքրքրում է, քանի որ մենք ցանկանում ենք հնարավորինս պարզ դարձնել կրկնօրինակվող կլաստերների ընդունումը հավելված մշակողների համար: Բայց այստեղ ես կցանկանայի ավելի շատ մեկնաբանություններ, այսինքն, թե ինչպես դա անել, ինչպես դա անել լավ:
Հարցը վերաբերում է նաև կրկնօրինակներին։ Ստացվում է, որ դուք ունեք վարպետ և մի քանի կրկնօրինակներ: Եվ պարզ է, որ նրանք ավելի քիչ են գնում ռեպլիկի, քան վարպետի մոտ միացումների համար, քանի որ դրանք կարող են տարբերություն ունենալ։ Դուք ասացիք, որ տվյալների տարբերությունը կարող է այնպիսին լինել, որ ձեր բիզնեսը չբավարարվի, և դուք չեք գնա այնտեղ, մինչև այն կրկնօրինակվի: Միևնույն ժամանակ, եթե երկար ժամանակ չեք գնացել այնտեղ, այնուհետև սկսել եք գնալ, ապա ձեզ անհրաժեշտ տվյալները անմիջապես հասանելի չեն լինի: Այսինքն, եթե մենք անընդհատ գնում ենք վարպետի մոտ, ապա քեշը տաքացվում է այնտեղ, իսկ քեշը մի փոքր հետ է մնում կրկնօրինակից։
Այո, դա ճիշտ է. Ձեր ուզած pcache-ում տվյալների բլոկներ չեն լինի, իրական քեշում չեն լինի ձեր ուզած աղյուսակների մասին տեղեկատվություն, պլաններում վերլուծված հարցումներ չեն լինի, ընդհանրապես ոչինչ:
Եվ երբ դուք ունեք մի տեսակ կլաստեր, և այնտեղ ավելացնում եք նոր կրկնօրինակ, ապա մինչ այն սկսվում է, ամեն ինչ վատ է դրանում, այսինքն՝ այն մեծացնում է իր քեշը:
Ես հասկացա. Ճիշտ մոտեցումը կլինի նախ կրկնօրինակի վրա հարցումների փոքր տոկոս գործարկելը, որը կջերմացներ քեշը: Կոպիտ ասած՝ պայման ունենք, որ վարպետից 10 վայրկյանից ոչ ավել պետք է հետ մնանք։ Եվ այս պայմանը չպետք է ներառվի մեկ ալիքի մեջ, այլ սահուն որոշ հաճախորդների համար:
Այո, ավելացրեք քաշը:
Սա լավ գաղափար է: Բայց նախ դուք պետք է իրականացնեք այս անջատումը: Նախ պետք է անջատել, իսկ հետո կմտածենք, թե ինչպես միացնել։ Սա հիանալի հատկություն է սահուն միացնելու համար:
nginx-ն ունի այս տարբերակը slowly start սերվերի համար նախատեսված կլաստերում: Եվ նա աստիճանաբար մեծացնում է բեռը:
Այո, հիանալի գաղափար է, մենք կփորձենք այն, երբ հասնենք դրան:
Source: www.habr.com