WAL-G. նոր հնարավորություններ և համայնքի ընդլայնում: Գեորգի Ռիլով

Առաջարկում եմ կարդալ Գեորգի Ռիլովի 2020 թվականի սկզբի զեկույցի սղագրությունը «WAL-G. համայնքի նոր հնարավորություններ և ընդլայնում»

Բաց կոդով աշխատողները մեծանում են բազմաթիվ մարտահրավերների առաջ: Ինչպե՞ս գրել ավելի ու ավելի շատ պահանջվող գործառույթներ, շտկել ավելի ու ավելի շատ խնդիրներ և կարողանալ դիտել ավելի ու ավելի շատ պահանջներ: Օգտագործելով WAL-G-ը (պահուստային գործիք PostgreSQL-ի համար) որպես օրինակ՝ ես ձեզ կասեմ, թե ինչպես լուծեցինք այս խնդիրները՝ համալսարանում բաց կոդով զարգացման դասընթաց սկսելով, ինչի հասանք և ուր ենք շարժվելու հաջորդիվ:

Կրկին բարև բոլորին: Ես Յանդեքսի ծրագրավորող եմ Եկատերինբուրգից: Իսկ այսօր կխոսեմ WAL-G-ի մասին։

Զեկույցի վերնագրում չէր ասվում, որ խոսքը կրկնօրինակումների մասին է։ Որևէ մեկը գիտի՞, թե ինչ է WAL-G-ը: Թե՞ բոլորը գիտեն. Բարձրացրեք ձեր ձեռքը, եթե չգիտեք: Սրբուհի, դուք եկել եք զեկույցի և չգիտեք, թե ինչի մասին է խոսքը:

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

Նախորդ սերիաներում բազմաթիվ զեկույցներ կային Անդրեյ Բորոդինի և Վլադիմիր Լեսկովի կողմից։ Մենք շատ էինք։ Եվ մենք երկար տարիներ խոսում ենք WAL-G-ի մասին:

clck.ru/F8ioz — https://www.highload.ru/moscow/2018/abstracts/3964

clck.ru/Ln8Qw — https://www.highload.ru/moscow/2019/abstracts/5981

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

Մի քանի տարի առաջ WAL-G-ը բավականին փոքր նախագիծ էր, որը մենք ստացանք Citus Data-ից: Եվ մենք պարզապես վերցրեցինք այն: Եվ այն մշակվել է մեկ անձի կողմից:

Եվ միայն WAL-G-ն չուներ.

• Կրկնօրինակում կրկնօրինակից:
• Չկային լրացուցիչ կրկնօրինակումներ:
• WAL-Delta-ի կրկնօրինակներ չկային:
• Եվ դեռ շատ բան էր պակասում։

Այս մի քանի տարիների ընթացքում WAL-G-ն շատ է աճել:

Իսկ 2020 թվականին վերը նշված բոլորն արդեն ի հայտ են եկել։ Եվ սրան ավելացվեց այն, ինչ հիմա ունենք.

• Ավելի քան 1 աստղ GitHub-ում:
• 150 պատառաքաղ.
• Մոտ 15 բաց PR.
• Եվ շատ այլ ներդրողներ:
• Եվ անընդհատ բաց հարցեր: Եվ սա չնայած այն հանգամանքին, որ մենք գնում ենք այնտեղ բառացիորեն ամեն օր և ինչ-որ բան անում դրա դեմ:

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

Եվ ինչ-որ տեղ 2018 թվականի աշնանը մեր գլխում մի միտք ծագեց. Սովորաբար թիմն ունի մի քանի եղանակ՝ զարգացնելու որոշ առանձնահատկություններ կամ շտկելու սխալները, եթե դուք բավարար ձեռքեր չունեք: Օրինակ, դուք կարող եք վարձել մեկ այլ ծրագրավորող և նրան գումար վճարել: Կամ կարող եք որոշ ժամանակով պրակտիկանտ ընդունել և նրան նաև որոշակի աշխատավարձ վճարել: Բայց դեռ բավական մեծ խումբ կա մարդկանց մեջ, որոնցից ոմանք իսկապես գիտեն, թե ինչպես գրել կոդ: Դուք պարզապես միշտ չէ, որ գիտեք, թե ինչ որակի կոդը:

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

Ի՞նչ պայմաններով է ընդունվում ուսանողական PR-ը:

• Նրանցից պահանջվում է ծածկել իրենց ծածկագիրը թեստերով: Ամեն ինչ պետք է տեղի ունենա CI-ում:
• Եվ մենք նաև անցնում ենք 2 վերանայում: Մեկը՝ Անդրեյ Բորոդինի, մեկը՝ իմ։
• Եվ լրացուցիչ, ստուգելու համար, որ դա որևէ բան չի կոտրի մեր ծառայության մեջ, ես առանձին վերբեռնում եմ ժողովը այս commit-ով: Եվ մենք ստուգում ենք վերջնական թեստերում, որ ոչինչ չի հաջողվում:

Հատուկ դասընթաց բաց կոդով

Մի փոքր այն մասին, թե ինչու է դա անհրաժեշտ և ինչու սա, ինձ թվում է, հիանալի գաղափար է:

Մեզ համար շահույթն ակնհայտ է.

• Մենք ստանում ենք լրացուցիչ ձեռքեր:
• Եվ մենք թիմի համար թեկնածուներ ենք փնտրում խելացի ուսանողների շրջանում, ովքեր գրում են խելացի կոդ:

Ո՞րն է օգուտը ուսանողների համար:

Նրանք կարող են ավելի քիչ ակնհայտ լինել, քանի որ ուսանողները, նվազագույնը, գումար չեն ստանում իրենց գրած ծածկագրի համար, այլ միայն գնահատականներ են ստանում իրենց ուսանողական գրառումների համար:

Ես նրանց հարցրի այս մասին։ Եվ նրանց խոսքերով.

• Աջակցողի փորձ բաց կոդով:
• Ստացեք տող ձեր CV-ում:
• Ապացուցեք ինքներդ ձեզ և անցեք հարցազրույց Yandex-ում:
• Դարձեք GSoC անդամ:
• +1 հատուկ դասընթաց կոդ գրել ցանկացողների համար։

Չեմ խոսի այն մասին, թե ինչպես է դասընթացը կազմակերպվել: Պարզապես ասեմ, որ WAL-G-ն հիմնական նախագիծն էր։ Այս դասընթացում մենք ներառել ենք նաև այնպիսի նախագծեր, ինչպիսիք են Odyssey, PostgreSQL և ClickHouse:

Եվ խնդիրներ են տվել ոչ միայն այս կուրսում, այլեւ տվել են դիպլոմներ, կուրսային աշխատանքներ։

Ինչ վերաբերում է օգտատերերի օգուտին:

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

Եվ թույլ տվեք պատմել ձեզ այն բաների մասին, որոնք վաղուց էիք ցանկանում, և որոնք իրականացվել են։

Սեղանի տարածքների աջակցություն: WAL-G-ում աղյուսակային տարածքներ սպասվում էին, հավանաբար, WAL-G-ի թողարկումից հետո, քանի որ WAL-G-ը WAL-E-ի մեկ այլ պահեստային գործիքի իրավահաջորդն է, որտեղ աջակցվում էին տվյալների բազայի կրկնօրինակումները սեղանի տարածքներով:

Թույլ տվեք հակիրճ հիշեցնել ձեզ, թե ինչ է դա և ինչու է դա անհրաժեշտ: Սովորաբար, ձեր բոլոր Postgres տվյալները զբաղեցնում են մեկ գրացուցակ ֆայլային համակարգում, որը կոչվում է բազա: Եվ այս գրացուցակը արդեն պարունակում է Postgres-ի կողմից պահանջվող բոլոր ֆայլերն ու ենթագրանցերը։

Սեղանի տարածքները դիրեկտորիաներ են, որոնք պարունակում են Postgres-ի տվյալներ, բայց դրանք տեղակայված չեն բազային գրացուցակից դուրս: Սլայդը ցույց է տալիս, որ սեղանի տարածքները գտնվում են բազային գրացուցակից դուրս:

Ի՞նչ տեսք ունի սա հենց Պոստգրեսի համար: Բազային գրացուցակում կա pg_tblspc առանձին ենթացուցակ: Եվ այն պարունակում է սիմվոլներ դեպի դիրեկտորիաներ, որոնք իրականում պարունակում են Postgres-ի տվյալներ բազային գրացուցակից դուրս:

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

Մենք այս ամենը չենք օգտագործում մեր թիմում, բայց այն օգտագործվել է WAL-E-ի շատ այլ օգտատերերի կողմից, ովքեր գրել են մեզ, որ ցանկանում են տեղափոխվել WAL-G, բայց դա խանգարում է նրանց: Սա այժմ աջակցվում է:

Մեկ այլ առանձնահատկություն, որը մեզ բերեց մեր հատուկ դասընթացը, catchup-ն է: Մարդիկ, ովքեր հավանաբար ավելի շատ են աշխատել Oracle-ի, քան Postgres-ի հետ, գիտեն catchup-ի մասին:

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

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

Իսկ ամենահեշտ ճանապարհը կրկնօրինակը հեռացնելն ու նորից վերբեռնելն է, քանի որ այն երբեք չի հասնի, և խնդիրը պետք է լուծել: Բայց սա բավականին երկար ժամանակ է, քանի որ ամբողջ 10 ՏԲ տվյալների բազայի կրկնօրինակը վերականգնելը շատ, շատ երկար ժամանակ է: Եվ մենք ցանկանում ենք այս ամենն անել հնարավորինս արագ, եթե նման խնդիրներ առաջանան։ Եվ հենց դրա համար է catchup-ը:

Catchup-ը թույլ է տալիս օգտագործել դելտա կրկնօրինակները, որոնք այս կերպ պահվում են ամպում։ Դուք ասում եք, թե որ LSN-ի վրա է գտնվում ուշացած կրկնօրինակը և նշեք այն catchup հրամանում, որպեսզի ստեղծեք դելտա կրկնօրինակում այդ LSN-ի և LSN-ի միջև, որի վրա ներկայումս գտնվում է ձեր կլաստերը: Եվ դրանից հետո դուք վերականգնում եք այս կրկնօրինակը, որը հետ էր մնում:

Այլ հիմքեր

Ուսանողներն էլ մեզ միանգամից բազմաթիվ առանձնահատկություններ բերեցին։ Քանի որ Yandex-ում մենք պատրաստում ենք ոչ միայն Postgres, մենք ունենք նաև MySQL, MongoDB, Redis, ClickHouse, ինչ-որ պահի մեզ անհրաժեշտ էր, որ կարողանայինք կրկնօրինակումներ անել MySQL-ի համար ժամանակի վերականգնմամբ, և որպեսզի հնարավորություն լիներ վերբեռնել: դրանք դեպի ամպ:

Եվ մենք ուզում էինք դա անել այնպես, ինչպես անում է WAL-G-ը: Եվ մենք որոշեցինք փորձարկել և տեսնել, թե ինչ տեսք կունենա այդ ամենը:

Եվ սկզբում, առանց որևէ կերպ կիսելու այս տրամաբանությունը, ծածկագիրը գրեցին պատառաքաղում։ Նրանք տեսան, որ մենք ունենք ինչ-որ աշխատող մոդել և այն կարող է թռչել։ Հետո մտածեցինք, որ մեր հիմնական համայնքը պոստգրեսիստներն են, նրանք օգտագործում են WAL-G: Եվ հետևաբար, մենք պետք է ինչ-որ կերպ առանձնացնենք այս մասերը: Այսինքն, երբ մենք խմբագրում ենք կոդը Postgres-ի համար, մենք չենք կոտրում MySQL-ը, երբ խմբագրում ենք MySQL-ը, մենք չենք խախտում Postgres-ը:

Առաջին գաղափարը, թե ինչպես կարելի է դա առանձնացնել, նույն մոտեցումն օգտագործելու գաղափարն էր, որն օգտագործվում է PostgreSQL ընդարձակման մեջ: Եվ, փաստորեն, MySQL-ի կրկնօրինակում ստեղծելու համար հարկավոր էր տեղադրել ինչ-որ դինամիկ գրադարան:

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

Տարբեր կառուցումներ Postgres-ի, MySQL-ի, MongoDB-ի, Redis-ի համար

Բայց սա մեզ թույլ տվեց, մեզ թվում է, ճիշտ որոշման գալ՝ տարբեր հենակետերի համար տարբեր հավաքներ հատկացնել։ Սա հնարավորություն տվեց մեկուսացնել տրամաբանությունը, որը կապված է տարբեր տվյալների բազաների կրկնօրինակների հետ, որոնք հասանելի կլինեն WAL-G-ի կիրառած ընդհանուր API-ին:

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

Դրանից հետո մենք խնդիրներ տվեցինք։ Դրանք անմիջապես ապամոնտաժվել են։ Ուսանողներից պահանջվում էր աջակցել երեք բազայի:

Սա MySQL-ն է, որը մենք կրկնօրինակում ենք WAL-G-ի միջոցով այս եղանակով ավելի քան մեկ տարի:

Եվ հիմա MongoDB-ն մոտենում է արտադրությանը, որտեղ այն ավարտում են ֆայլով։ Փաստորեն, մենք գրել ենք այս ամենի շրջանակը։ Այնուհետև ուսանողները գրեցին մի քանի գործունակ բաներ։ Եվ հետո դրանք բերում ենք մի վիճակի, որը կարող ենք ընդունել արտադրության մեջ։

Այս խնդիրները նման չէին ուսանողներին այս տվյալների բազաներից յուրաքանչյուրի համար ամբողջական պահեստային գործիքներ գրելու կարիք: Մենք նման խնդիր չենք ունեցել։ Մեր խնդիրն այն էր, որ մենք ցանկանում էինք ժամանակի վերականգնում և ցանկանում էինք կրկնօրինակել ամպի վրա: Եվ նրանք խնդրեցին ուսանողներին գրել ինչ-որ ծածկագիր, որը կլուծեր դա: Ուսանողները օգտագործեցին արդեն գոյություն ունեցող պահեստային գործիքները, որոնք ինչ-որ կերպ պահուստավորումներ են վերցնում, և այնուհետև այն սոսնձեցին WAL-G-ի հետ, որն այդ ամենը փոխանցեց ամպին: Եվ սրան ավելացրին նաև ժամանակի վերականգնումը:

Էլ ի՞նչ են բերել ուսանողները։ Նրանք բերեցին Libsodium գաղտնագրման աջակցություն WAL-G-ին:

Մենք նաև ունենք պահեստային պահպանման քաղաքականություն: Այժմ կրկնօրինակները կարող են նշվել որպես մշտական: Եվ ինչ-որ կերպ ձեր ծառայության համար ավելի հարմար է ավտոմատացնել դրանք պահելու գործընթացը:

Ո՞րն էր այս փորձի արդյունքը:

Դասընթացին սկզբում գրանցվել է ավելի քան 100 մարդ: Սկզբում ես չէի ասում, որ Եկատերինբուրգի համալսարանը Ուրալի դաշնային համալսարանն է։ Այնտեղ մենք ամեն ինչ հայտարարել ենք։ Գրանցվել է 100 մարդ։ Իրականում շատ ավելի քիչ մարդիկ սկսեցին ինչ-որ բան անել՝ մոտ 30 հոգի։

Դասընթացը ավարտեցին նույնիսկ ավելի քիչ մարդիկ, քանի որ անհրաժեշտ էր թեստեր գրել արդեն գոյություն ունեցող ծածկագրերի համար։ Եվ նաև շտկել որոշ սխալներ կամ ստեղծել որոշ գործառույթներ: Եվ որոշ ուսանողներ դեռ փակել են դասընթացը:

Ներկայումս այս դասընթացի ընթացքում ուսանողները ուղղել են մոտ 14 խնդիր և կազմել տարբեր չափերի 10 հատկանիշ։ Եվ, ինձ թվում է, սա մեկ կամ երկու մշակողների լիարժեք փոխարինում է։

Ի թիվս այլ բաների, մենք տվել ենք դիպլոմներ և դասընթաց: Իսկ 12-ը ստացել են դիպլոմներ։ Նրանցից 6-ն արդեն պաշտպանվել են «5»-ում։ Մնացածները դեռ պաշտպանություն չունեին, բայց կարծում եմ, որ նրանց համար էլ ամեն ինչ լավ կլինի։

Պլանները ապագայի համար

Ի՞նչ ծրագրեր ունենք ապագայի համար։

Առնվազն այն գործառույթների հարցումները, որոնք մենք արդեն լսել ենք օգտատերերից և ցանկանում ենք անել: Սա.

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

Դուք կարող եք դրանք կիսել այստեղ

Ինչի՞ համար էր այս զեկույցը: Ավելին, այժմ, բացի 4 հոգուց, ովքեր աջակցում են այս նախագծին, մենք ունենք լրացուցիչ ձեռքեր, որոնք բավականին շատ են։ Հատկապես եթե նրանց գրեք անձնական հաղորդագրությամբ։ Եվ եթե դուք կրկնօրինակում եք ձեր տվյալները և դա անում եք WAL-G-ի միջոցով կամ ցանկանում եք տեղափոխվել WAL-G, ապա մենք կարող ենք բավականին հեշտությամբ կատարել ձեր ցանկությունները:

Սա QR կոդ է և հղում: Դուք կարող եք անցնել դրանց միջով և գրել ձեր բոլոր ցանկությունները: Օրինակ, մենք չենք շտկում որոշ սխալներ: Կամ դուք իսկապես ուզում եք ինչ-որ հատկանիշ, բայց ինչ-ինչ պատճառներով այն դեռ որևէ պահուստավորման մեջ չէ, ներառյալ մերը: Անպայման գրեք այս մասին։

Հարցեր

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Հարց WAL-G-ի մասին, բայց ոչ Postgres-ի մասին։ WAL-G-ը կրկնօրինակում է MySQL-ը և կանչում լրացուցիչ կրկնօրինակում: Եթե ​​մենք վերցնենք ժամանակակից տեղադրումներ CentOS-ում, և եթե դուք տեղադրեք MySQL, ապա MariDB-ն կտեղադրվի: 10.3 տարբերակից լրացուցիչ կրկնօրինակում չի աջակցվում, MariDB-ի կրկնօրինակումն ապահովվում է: Ինչպե՞ս ես դա անում:

Այս պահին մենք չենք փորձել կրկնօրինակել MariDB-ն: Ունեցել ենք FoundationDB-ի աջակցության հարցումներ, բայց ընդհանուր առմամբ, եթե նման խնդրանք լինի, ապա կարող ենք գտնել մարդկանց, ովքեր կանեն դա։ Դա այնքան էլ երկար կամ դժվար չէ, որքան կարծում եմ:

Բարի օր Շնորհակալություն զեկույցի համար: Հարց պոտենցիալ նոր հնարավորությունների մասին: Պատրա՞ստ եք այնպես անել, որ WAL-G-ն աշխատի ժապավեններով, որպեսզի կարողանաք կրկնօրինակել ժապավենները:

Կրկնօրինակում ժապավենի պահեստում, ըստ երևույթին, նշանակում է.

Այո:

Կա Անդրեյ Բորոդին, ով կարող է ինձնից լավ պատասխանել այս հարցին։

(Անդրեյ) Այո, շնորհակալություն հարցի համար: Մենք խնդրանք ունեինք ամպային պահեստից կրկնօրինակը ժապավենին փոխանցելու համար: Եվ սրա համար սղոցում փոխանցում ամպերի միջև. Քանի որ ամպից ամպ փոխանցումը ժապավենի փոխանցման ընդհանրացված տարբերակ է: Բացի այդ, մենք ունենք ընդարձակելի ճարտարապետություն Պահեստների առումով: Ի դեպ, բազմաթիվ Ստորոգներ գրել են ուսանողները։ Եվ եթե դուք գրում եք Storage ժապավենի համար, ապա այն, իհարկե, կաջակցվի: Մենք պատրաստ ենք դիտարկել ձգման հարցումները: Այնտեղ պետք է ֆայլ գրել, ֆայլ կարդալ։ Եթե ​​դուք անում եք այս բաները Go-ում, սովորաբար հայտնվում եք 50 տող կոդով: Եվ հետո ժապավենը կաջակցվի WAL-G-ում:

Շնորհակալություն զեկույցի համար: Հետաքրքիր զարգացման գործընթաց. Կրկնօրինակումը ֆունկցիոնալության լուրջ մասն է, որը պետք է լավ ծածկված լինի թեստերով: Երբ դուք ֆունկցիոնալություն էիք իրականացնում նոր շտեմարանների համար, ուսանողները նո՞ւյնպես գրում էին թեստերը, թե՞ ինքներդ եք գրում, իսկ հետո կատարումը տալիս ուսանողներին:

Ուսանողները նաև թեստեր են գրել: Բայց ուսանողներն ավելին գրեցին այնպիսի հնարավորությունների համար, ինչպիսիք են տվյալների բազաները: Նրանք գրել են ինտեգրացիոն թեստեր: Եվ նրանք գրեցին միավորի թեստեր: Եթե ​​ինտեգրումն անցնի, այսինքն՝ տվյալ պահին, սա սկրիպտ է, որը դուք կատարում եք ձեռքով, կամ, օրինակ, դուք ունեք cron դա անում։ Այսինքն՝ այնտեղ սցենարը շատ պարզ է։

Ուսանողները մեծ փորձ չունեն։ Արդյո՞ք վերանայումը շատ ժամանակ է պահանջում:

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

Շնորհակալություն զեկույցի համար: Նախկինում Անդրեյ Բորոդինը հայտարարել էր, որ archive_command-ը WAL-G-ում պետք է ուղղակիորեն կանչվի: Բայց ինչ-որ կլաստերային քարթրիջների դեպքում մեզ լրացուցիչ տրամաբանություն է պետք՝ որոշելու այն հանգույցը, որտեղից պետք է ուղարկվեն լիսեռները: Ինչպե՞ս եք ինքներդ լուծում այս խնդիրը:

Ի՞նչ խնդիր ունեք այստեղ։ Ենթադրենք, դուք ունեք համաժամանակյա կրկնօրինակ, որի հետ դուք կրկնօրինակում եք: Կամ ինչ.

(Անդրեյ) Փաստն այն է, որ իսկապես WAL-G-ը նախատեսված է օգտագործել առանց կեղևի սկրիպտների: Եթե ​​ինչ-որ բան պակասում է, ապա ավելացնենք այն տրամաբանությունը, որը պետք է լինի WAL-G-ի ներսում։ Իսկ թե որտեղից պետք է գա արխիվացումը, մենք կարծում ենք, որ արխիվացումը պետք է լինի կլաստերի ներկայիս վարպետից: Կրկնօրինակից արխիվացնելը վատ գաղափար է: Խնդիրների հետ կապված տարբեր հնարավոր սցենարներ կան։ Մասնավորապես, ժամանակացույցերի արխիվացման և ցանկացած լրացուցիչ տեղեկատվության հետ կապված խնդիրներ: Շնորհակալություն հարցի համար։

(Պարզաբանում. Մենք ազատվեցինք shell-ի սցենարներից այս հարցում)

Բարի երեկո! Շնորհակալություն զեկույցի համար: Ինձ հետաքրքրում է catchup ֆունկցիան, որի մասին խոսեցիր: Մենք բախվեցինք մի իրավիճակի, երբ կրկնօրինակը ետևում էր և չէր կարողանում հասնել: Իսկ WAL-G փաստաթղթերում այս հատկանիշի նկարագրությունը չգտա:

Catchup-ը հայտնվել է բառացիորեն 20 թվականի հունվարի 2020-ին։ Փաստաթղթերը կարող են լրացուցիչ աշխատանք պահանջել: Մենք ինքներս ենք դա գրում և լավ չենք գրում: Եվ միգուցե մենք պետք է սկսենք ուսանողներից պահանջել գրել այն:

Այն արդեն թողարկվե՞լ է:

Ձգման հարցումն արդեն մեռած է, այսինքն՝ ես ստուգեցի այն: Ես փորձեցի սա փորձարկման կլաստերի վրա: Մինչ այժմ մենք չենք ունեցել այնպիսի իրավիճակ, որ կարողանայինք սա փորձարկել մարտական ​​օրինակով։

Ե՞րբ սպասել:

չգիտեմ։ Սպասեք մեկ ամիս, մենք անպայման կստուգենք:

Source: www.habr.com