Հոդվածի թարգմանությունը պատրաստվել է հատուկ դասընթացի ուսանողների համար «Տվյալների բազա». Հետաքրքրվա՞ծ եք այս ուղղությամբ զարգանալ: Մենք ձեզ հրավիրում ենք Բաց օր, որտեղ մենք մանրամասնորեն խոսում ենք ծրագրի, առցանց ձևաչափի առանձնահատկությունների, իրավասությունների և կարիերայի հեռանկարների մասին, որոնք սպասում են շրջանավարտներին վերապատրաստումից հետո:

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

Ինչո՞ւ է դա ինձ պետք:

Ինչպես կլաստերը պետք է վարվի, կախված է ձեր դիմումից: Վերցրեք, օրինակ, հաշիվների վճարման հավելվածը: Ձեզ անհրաժեշտ կլինի XNUMX% հետևողականություն ամբողջ կլաստերում, այնպես որ դուք պետք է միացնեք համաժամանակյա պարտավորությունները, որպեսզի ձեր տվյալների բազան սպասի բոլոր փոփոխությունների կատարմանը: Այնուամենայնիվ, եթե ձեր հավելվածը արագ զարգացող սոցիալական ցանց է, ապա դուք, հավանաբար, կնախընտրեք արագ արձագանքը, քան XNUMX% հետևողականությունը: Դրան հասնելու համար դուք կարող եք օգտագործել ասինխրոն հանձնառություններ ձեր կլաստերում:

Հանդիպեք փոխզիջման

Դուք պետք է փոխզիջումներ կատարեք տվյալների հետևողականության և կատարողականի միջև: PostgreSQL-ը հեռանում է հետևողականությունից, քանի որ կանխադրված կոնֆիգուրացիան այնուհետև կանխատեսելի է և առանց անսպասելի անակնկալների: Հիմա եկեք նայենք փոխզիջումներին:

Փոխանակում 1. կատարողականություն

Եթե ​​PostgreSQL կլաստերը չի պահանջում հետևողականություն, այն կարող է աշխատել ասինխրոն: Գրումը կատարվում է կլաստերի ղեկավարին, և թարմացումները կուղարկվեն նրա կրկնօրինակներին մի քանի միլիվայրկյան անց: Երբ PostgreSQL կլաստերը պահանջում է հետևողականություն, այն պետք է աշխատի համաժամանակյա: Գրումը կկատարվի կլաստերի ղեկավարին, որը թարմացում կուղարկի կրկնօրինակներին և կսպասի հաստատմանը, որ յուրաքանչյուրը գրել է նախքան գրելու նախաձեռնող հաճախորդին հաստատում ուղարկելը, որ այն հաջող է: Այս մոտեցումների գործնական տարբերությունն այն է, որ ասինխրոն մեթոդը պահանջում է ցանցի երկու հոփ, մինչդեռ համաժամանակյա մեթոդը պահանջում է չորս:

Փոխանակում 2. Հետևողականություն

Այս երկու մոտեցումներում առաջնորդի ձախողման դեպքում նույնպես արդյունքը տարբեր կլինի: Եթե ​​աշխատանքը կատարվում է ասինխրոն կերպով, ապա եթե նման սխալ տեղի ունենա, ոչ բոլոր գրառումները կկատարվեն կրկնօրինակների կողմից: Որքա՞ն կկորցվի: Կախված է բուն հավելվածից և կրկնօրինակման արդյունավետությունից: Կազմել կրկնօրինակումը թույլ չի տա, որ կրկնօրինակը դառնա առաջատար, եթե դրա մեջ եղած տեղեկատվության քանակը 1 ՄԲ-ով պակաս է, քան առաջատարում, այսինքն՝ մինչև 1 ՄԲ գրառումներ կարող են կորցնել ասինխրոն աշխատանքի ընթացքում:

Դա տեղի չի ունենում համաժամանակյա ռեժիմում: Եթե ​​առաջատարը ձախողվի, բոլոր կրկնօրինակները թարմացվում են, քանի որ առաջատարի վրա հաստատված ցանկացած գրություն պետք է հաստատվի կրկնօրինակների վրա: Սա հետևողականություն է:

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

Փոխանակում 3. Վթարներ

Շատ կարևոր է հասկանալ, թե ինչպես է կլաստերն իրեն պահում ձախողման ժամանակ: Մտածեք մի իրավիճակ, երբ մեկ կամ մի քանի կրկնօրինակներ ձախողվում են: Երբ պարտավորությունները մշակվում են ասինխրոն կերպով, առաջնորդը կշարունակի գործել, այսինքն՝ ընդունում և մշակում է գրությունները՝ չսպասելով բացակայող կրկնօրինակներին: Երբ կրկնօրինակները վերադառնում են կլաստեր, նրանք հասնում են առաջատարին: Սինքրոն կրկնօրինակման դեպքում, եթե կրկնօրինակները չեն արձագանքում, ապա առաջնորդը ընտրություն չի ունենա և կշարունակի սպասել կատարման հաստատմանը, մինչև որ կրկնօրինակը վերադառնա կլաստեր և կարողանա ընդունել և կատարել գրառումը:

Մեկ գործարքի համար մեկ կապ?

Յուրաքանչյուր հավելվածի կարիք ունի հետևողականության և կատարողականի տարբեր տեսակի համադրություն: Եթե, իհարկե, դա մեր հաշիվները վճարող հավելվածն է, որը մենք պատկերացնում ենք, որ լիովին հետևողական է, կամ մեր գրեթե անցողիկ սոցիալական ցանցային հավելվածը: Մնացած բոլոր դեպքերում կլինեն ժամանակներ, երբ որոշ գործողություններ պետք է լինեն համաժամանակյա, իսկ որոշները՝ ասինխրոն: Դուք կարող եք չցանկանալ, որ համակարգը սպասի մինչև չաթին ուղարկված հաղորդագրությունը հաստատվի, բայց եթե վճարումը մշակվի նույն հավելվածում, ապա դուք պետք է սպասեք:

Այս բոլոր որոշումները, իհարկե, կայացնում է հավելվածի մշակողը։ Յուրաքանչյուր մոտեցում օգտագործելու վերաբերյալ ճիշտ որոշումներ կայացնելը կօգնի ձեզ առավելագույն օգուտ քաղել ձեր կլաստերից: Կարևոր է, որ մշակողը կարողանա SQL մակարդակով անցնել դրանց միջև կապերի և գործարքների համար:

Գործնականում վերահսկողության ապահովում

Լռելյայնորեն, PostgreSQL-ն ապահովում է հետևողականություն: Սա վերահսկվում է սերվերի պարամետրով synchronous_commit. Լռելյայն դիրքում է on, բայց այն ունի երեք այլ տարբերակ. local, remote_write կամ off.

Պարամետրը դնելիս off բոլոր համաժամանակյա պարտավորությունները դադարեցված են, նույնիսկ տեղական համակարգում: Տեղական պարամետրը սահմանում է տեղական համակարգի համաժամանակյա ռեժիմը, սակայն կրկնօրինակների վրա գրությունները կատարվում են ասինխրոն: Remote_write ավելի հեռուն է գնում. կրկնօրինակների վրա գրությունները կատարվում են ասինխրոն, բայց վերադարձվում են, երբ կրկնօրինակն ընդունել է գրելը, բայց չի գրել այն սկավառակի վրա:

Հաշվի առնելով տարբերակների առկա շրջանակը՝ մենք ընտրում ենք վարքագիծ և, նկատի ունենալով, որ on – սինքրոն ձայնագրություններ են, մենք կընտրենք local ցանցի միջոցով ասինխրոն կատարումների համար, մինչդեռ տեղական պարտավորությունները թողնում են սինխրոն:

Այժմ մենք ձեզ կասենք, թե ինչպես կարելի է սա կարգավորել մի պահ, բայց պատկերացրեք, որ մենք կարգավորել ենք synchronous_commit в local սերվերի համար. Մենք հետաքրքրվեցինք, թե արդյոք հնարավոր է փոխել պարամետրը synchronous_commit թռիչքի ժամանակ, և պարզվեց, որ դա ոչ միայն հնարավոր է, այլև կա դա անելու երկու եղանակ: Առաջինը ձեր կապի նիստը սահմանելն է հետևյալ կերպ.

SET SESSION synchronous_commit TO ON;  
// Your writes go here

Սեսիայի բոլոր հետագա գրառումները կճանաչեն կրկնօրինակների գրությունները՝ նախքան միացված հաճախորդին դրական արդյունք վերադարձնելը: Եթե ​​իհարկե չփոխեք կարգավորումը synchronous_commit կրկին. Դուք կարող եք բաց թողնել մի մասը SESSION հրամանում, քանի որ այն կլինի լռելյայն արժեքով:

Երկրորդ մեթոդը լավ է, երբ դուք պարզապես ցանկանում եք համոզվել, որ դուք ստանում եք համաժամանակյա կրկնօրինակում մեկ գործարքի համար: NoSQL-ի ստեղծման շատ տվյալների բազաներում գործարքների հասկացությունը գոյություն չունի, բայց PostgreSQL-ում գոյություն ունի: Այս դեպքում դուք սկսում եք գործարք, ապա սահմանում synchronous_commit в on նախքան գործարքի համար մուտքագրումը կատարելը: COMMIT գործարքը կկատարի ցանկացած պարամետրի արժեքի միջոցով synchronous_commit, որը սահմանվել էր այն ժամանակ, թեև ավելի լավ է փոփոխականը նախապես սահմանել՝ համոզվելու համար, որ մյուս մշակողները հասկանում են, որ գրությունները ասինխրոն չեն:

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

Բոլոր գործարքների պարտավորություններն այժմ կհաստատվեն որպես գրված կրկնօրինակներին, նախքան տվյալների բազան միացված հաճախորդին դրական պատասխան կվերադարձնի:

PostgreSQL-ի կարգավորում

Մինչ այս մենք պատկերացնում էինք PostgreSQL համակարգը synchronous_commit, տեղադրված է local. Որպեսզի դա իրատեսական լինի սերվերի կողմից, դուք պետք է սահմանեք սերվերի կազմաձևման երկու տարբերակ: Եվս մեկ պարամետր synchronous_standby_names կհայտնվի իր մեջ, երբ synchronous_commit մեջ կլինի on. Այն որոշում է, թե որ կրկնօրինակներն են իրավասու համաժամանակյա պարտավորությունների համար, և մենք այն կսահմանենք *, ինչը կնշանակի, որ բոլոր կրկնօրինակները ներգրավված են: Այս արժեքները սովորաբար կազմաձևվում են կազմաձևման ֆայլ ավելացնելով.

synchronous_commit = local  
synchronous_standby_names='*'

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

Եթե ​​հետևել եք զարգացմանը Նահանգապետի նախագիծ, դուք կարող եք նկատել որոշ վերջին փոփոխություններ (1, 2), որը մարզպետի օգտատերերին թույլ տվեց ստուգել այս պարամետրերը և վերահսկել դրանց հետևողականությունը:

Եվս մի քանի բառ...

Ընդամենը մեկ շաբաթ առաջ ես ձեզ կասեի, որ անհնար է այդքան լավ կարգավորել PostgreSQL-ը: Հենց այդ ժամանակ էլ Կուրտը` Compose հարթակի թիմի անդամը, պնդեց, որ նման հնարավորություն կա: Նա հանգստացրեց իմ առարկությունները և գտավ PostgreSQL փաստաթղթերում հետևյալը:

Այս կարգավորումը կարող է փոխվել ցանկացած պահի: Ցանկացած գործարքի վարքագիծը որոշվում է կատարման պահին գործող կարգավորումներով: Հետևաբար, որոշ գործարքների համար հնարավոր և օգտակար է կատարել սինքրոն, իսկ մյուսների համար՝ ասինքրոն: Օրինակ՝ ստիպել մեկին multistatement գործարքը կատարել commits asynchronously, երբ լռելյայն արժեքը պարամետր հակառակ, set SET LOCAL synchronous_commit TO OFF գործարքի մեջ:

Կազմաձևման ֆայլի այս փոքր փոփոխությամբ մենք օգտատերերին վերահսկում ենք դրանց հետևողականությունը և կատարումը:

Source: www.habr.com