Պահուստային պատճեններ WAL-G-ից: Ի՞նչ կա 2019 թվականին: Անդրեյ Բորոդին

Առաջարկում եմ կարդալ Անդրեյ Բորոդինի 2019 թվականի սկզբի զեկույցի սղագրությունը «Պահուստավորումներ WAL-G-ով: Ի՞նչ կա 2019 թվականին»:

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

Գործերից մեկը, որի վրա ես աշխատում եմ, պահեստային համակարգն է: ՎԱԼ-Գ. Ընդհանրապես, Yandex-ում մենք շատ երկար ենք աշխատել PostgreSQL-ի պահեստային համակարգերի վրա։ Եվ դուք կարող եք ինտերնետում գտնել վեց զեկույցներից բաղկացած մի շարք այն մասին, թե ինչպես ենք մենք ստեղծում պահեստային համակարգեր: Եվ ամեն տարի նրանք մի փոքր զարգանում են, մի փոքր զարգանում և դառնում ավելի հուսալի:

Բայց այսօր զեկույցը ոչ միայն մեր արածի մասին է, այլև այն մասին, թե որքան պարզ է և ինչ կա։ Ձեզանից քանիսն է արդեն դիտել WAL-G-ի մասին իմ զեկույցները: Լավ է, որ բավականին քիչ մարդիկ չեն դիտել, քանի որ սկսեմ ամենապարզից.

Եթե ​​հանկարծ դուք ունեք PostgreSQL կլաստեր, և, կարծում եմ, բոլորն ունեն դրանցից մի քանիսը, և հանկարծ դեռ չկա պահեստային համակարգ, ապա դուք պետք է ստանաք ցանկացած S3 պահեստ կամ Google Cloud-ով համատեղելի պահեստ:

Օրինակ, դուք կարող եք գալ մեր ստենդ և վերցնել Yandex Object Storage-ի գովազդային ծածկագիրը, որը համատեղելի է S3-ի հետ:

Այնուհետև ստեղծեք դույլ: Դա պարզապես տեղեկատվության կոնտեյներ է:

Ստեղծեք ծառայության օգտվող:

Ստեղծեք մուտքի բանալի ծառայության օգտագործողի համար՝ aws-s3-key:

Ներբեռնեք WAL-G-ի վերջին կայուն թողարկումը:

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

WAL-G-ը ներբեռնելուց հետո կարող եք գործարկել պարզ «պահուստային ցուցակ» հրամանը՝ անցնելով շրջակա միջավայրի փոփոխականները: Եվ այն կմիանա Object Storage-ին և կպատմի, թե ինչ կրկնօրինակներ ունեք: Սկզբում, իհարկե, դուք չպետք է կրկնօրինակումներ ունենաք: Այս սլայդի նպատակն է ցույց տալ, որ ամեն ինչ բավականին պարզ է: Սա կոնսոլային հրաման է, որն ընդունում է շրջակա միջավայրի փոփոխականները և կատարում ենթահրամաններ:

Դրանից հետո դուք կարող եք կատարել ձեր առաջին կրկնօրինակը: WAL-G-ում ասեք «backup-push» և WAL-G-ում նշեք ձեր կլաստերի pgdata-ի գտնվելու վայրը: Եվ, ամենայն հավանականությամբ, PostgreSQL-ը ձեզ կասի, եթե դուք արդեն չունեք պահեստային համակարգ, որ պետք է միացնեք «archive-mode»-ը։

Սա նշանակում է, որ դուք պետք է գնաք կարգավորումներ և միացնեք «archive_mode = on» և ավելացնեք «archive_command», որը նույնպես ենթահանձնման է WAL-G-ում: Բայց ինչ-ինչ պատճառներով մարդիկ հաճախ օգտագործում են այս թեմայի գծագրերը և փաթաթում այն ​​WAL-G-ի շուրջ: Խնդրում եմ, մի արեք սա: Օգտագործեք WAL-G-ի ֆունկցիոնալությունը: Եթե ​​ինչ-որ բան բացակայում եք, գրեք GitHub. WAL-G-ը ենթադրում է, որ դա միակ ծրագիրն է, որն աշխատում է archive_command-ում:

Մենք օգտագործում ենք WAL-G-ը հիմնականում Yandex տվյալների բազայի կառավարման մեջ Բարձր հասանելիության կլաստեր ստեղծելու համար:

Եվ այն սովորաբար օգտագործվում է մեկ Master-ի և մի քանի կրկնությունների տոպոլոգիայում: Միևնույն ժամանակ, այն կրկնօրինակում է Yandex Object Storage-ում:

Ամենատարածված սցենարները կլաստերի պատճենների ստեղծումն են՝ օգտագործելով Point in time վերականգնումը: Բայց այս դեպքում մեզ համար պահեստային համակարգի կատարումն այնքան էլ կարևոր չէ։ Մենք պարզապես պետք է նոր կլաստեր վերբեռնենք պահուստից:

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

Եվ ևս մեկ նմանատիպ իրավիճակ. Սա հին Master-ը վերագործարկելու անհրաժեշտությունն է՝ Cluster Master-ը Տվյալների կենտրոնից միացնելուց հետո, որի հետ կապը կորել է:

• Արդյունքում պատճենահանման համակարգի պահանջները ձեւակերպելիս հասկացանք, որ pg_basebackup-ը մեզ հարմար չէ ամպում աշխատելիս։
• Մենք ցանկանում էինք, որ կարողանանք սեղմել մեր տվյալները: Բայց գրեթե ցանկացած պահուստային համակարգ, բացի այն, ինչ գալիս է տուփի մեջ, կտրամադրի տվյալների սեղմում:
• Մենք ուզում էինք ամեն ինչ զուգահեռացնել, քանի որ ամպի մեջ օգտագործողը մեծ քանակությամբ պրոցեսորային միջուկներ է գնում: Բայց եթե ինչ-որ գործողության մեջ չունենք զուգահեռություն, ապա մեծ թվով միջուկներ դառնում են անօգուտ։
• Մեզ անհրաժեշտ է գաղտնագրում, քանի որ հաճախ տվյալները մերը չեն և չեն կարող պահպանվել հստակ տեքստով: Ի դեպ, մեր ներդրումը WAL-G-ում սկսվեց գաղտնագրումից: Մենք ավարտեցինք գաղտնագրումը WAL-G-ում, որից հետո մեզ հարցրին. «Գուցե մեզանից մեկը մշակի նախագիծը»: Եվ դրանից հետո ես աշխատում եմ WAL-G-ի հետ մեկ տարուց ավելի։
• Մեզ նաև անհրաժեշտ էր ռեսուրսների խափանում, քանի որ ժամանակի ընթացքում ամպի միջոցով մենք պարզեցինք, որ երբեմն մարդիկ գիշերը կարևոր մթերային բեռ են ունենում, և այդ բեռը չի կարող խանգարվել: Այդ իսկ պատճառով մենք ավելացրել ենք ռեսուրսների կլանումը:
• Ինչպես նաև ցուցակագրում և կառավարում:
• Եվ ստուգում.

Մենք նայեցինք բազմաթիվ տարբեր գործիքների: Բարեբախտաբար, մենք ունենք հսկայական ընտրություն PostgreSQL-ում: Եվ ամենուր մեզ ինչ-որ բան էր պակասում, ինչ-որ մի փոքրիկ ֆունկցիա, ոմանց մի փոքր հատկանիշ:

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

Հիմնական գաղափարախոսությունը, որին մենք կառչում ենք, այն է, որ WAL-G-ն պետք է լինի բալալայկայի պես պարզ:

WAL-G-ն ունի 4 հրաման։ Սա.

WAL-PUSH – արխիվացնել լիսեռը:

WAL-FETCH – ստանալ լիսեռ:

BACKUP-PUSH – կրկնօրինակեք:

BACKUP-FETCH – ստացեք կրկնօրինակում պահուստային համակարգից:

Փաստորեն, WAL-G-ն ունի նաև այս պահուստավորման կառավարում, այսինքն՝ ցուցակագրում և ջնջում է պատմության մեջ առկա գրառումներն ու կրկնօրինակները, որոնք այս պահին այլևս կարիք չունեն:

Մեզ համար կարևոր գործառույթներից մեկը դելտա պատճենների ստեղծման գործառույթն է։

Delta պատճենները նշանակում են, որ մենք չենք ստեղծում ամբողջ կլաստերի ամբողջական կրկնօրինակում, այլ միայն կլաստերի փոխված ֆայլերի փոփոխված էջերը: Թվում է, թե ֆունկցիոնալ առումով սա շատ նման է WAL-ի միջոցով վերականգնելու ունակությանը: Բայց մենք կարող ենք զուգահեռաբար հավաքել WAL-ի մեկ թելերով դելտա կրկնօրինակը: Համապատասխանաբար, երբ մենք ունենք հիմնական կրկնօրինակում, որը կատարվում է շաբաթ օրը, դելտա կրկնօրինակում է ամեն օր, իսկ հինգշաբթի մենք ձախողում ենք, ապա մենք պետք է հավաքենք 4 դելտա կրկնօրինակում և 10 ժամ WAL: Մոտավորապես նույն ժամանակ կպահանջվի, քանի որ դելտայի կրկնօրինակները գլորվում են զուգահեռ:

LSN-ի վրա հիմնված դելտաներ - սա նշանակում է, որ կրկնօրինակում ստեղծելիս մենք պետք է միավորենք յուրաքանչյուր էջ և ստուգենք դրա LSN-ն նախորդ կրկնօրինակի LSN-ի հետ, որպեսզի հասկանանք, որ այն փոխվել է: Ցանկացած էջ, որը կարող է պոտենցիալ փոփոխված տվյալներ պարունակել, պետք է առկա լինի դելտա կրկնօրինակում:

Ինչպես ասացի, բավականին մեծ ուշադրություն է դարձվել զուգահեռությանը։

Բայց արխիվային API-ն PostgreSQL-ում համահունչ է: PostgreSQL-ը արխիվացնում է մեկ WAL ֆայլ և այն վերականգնելիս պահանջում է մեկ WAL ֆայլ: Բայց երբ տվյալների բազան պահանջում է մեկ WAL ֆայլ՝ օգտագործելով «WAL-FETCH» հրամանը, մենք կանչում ենք «WAL-PREFETCH» հրամանը, որը նախապատրաստում է հաջորդ 8 ֆայլերը՝ օբյեկտի պահեստից տվյալները զուգահեռաբար վերցնելու համար:

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

Իր մաքուր ձևով, LSN-ի վրա հիմնված WAL delta-ն պահանջում է կարդալ ցանկացած կլաստերային ֆայլ, որի ռեժիմի ժամանակը ֆայլային համակարգում փոխվել է նախորդ կրկնօրինակումից հետո: Սրանով ապրել ենք երկար, գրեթե մեկ տարի։ Եվ վերջում մենք եկանք այն եզրակացության, որ ունենք WAL դելտաներ։

Սա նշանակում է, որ ամեն անգամ, երբ մենք արխիվացնում ենք WAL-ը Master-ում, մենք ոչ միայն սեղմում ենք այն, գաղտնագրում և ուղարկում ցանց, այլև միաժամանակ կարդում ենք այն: Մենք վերլուծում և կարդում ենք դրանում առկա գրառումները։ Մենք հասկանում ենք, թե որ բլոկներն են փոխվել և հավաքում ենք դելտա ֆայլերը:

Դելտա ֆայլը նկարագրում է WAL ֆայլերի որոշակի տիրույթ, նկարագրում է տեղեկատվություն այն մասին, թե որ բլոկները փոխվել են WAL-ի այս տիրույթում: Եվ հետո այս դելտա ֆայլերը նույնպես արխիվացվում են:

Այստեղ մենք բախվում ենք այն փաստի հետ, որ մենք բավականին արագ զուգահեռեցինք ամեն ինչ, բայց չենք կարող զուգահեռաբար կարդալ հաջորդական պատմություն, քանի որ որոշակի հատվածում կարող ենք հանդիպել նախորդ WAL ռեկորդի ավարտին, որի հետ դեռ կապ չունենք, քանի որ. Զուգահեռ ընթերցումը հանգեցրեց նրան, որ մենք նախ վերլուծում ենք ապագան, որը դեռ անցյալ չունի։

Արդյունքում մենք ստիպված էինք անհասկանալի կտորներ դնել _delta_partial ֆայլերի մեջ: Արդյունքում, երբ վերադառնանք անցյալ, մենք կսոսնձենք WAL ռեկորդի կտորները մեկի մեջ, որից հետո կվերլուծենք այն և կհասկանանք, թե ինչ է փոխվել դրա մեջ։

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

Արդյունքում, մեր ամբողջ տառապանքը հանգեցրեց նրան, որ մենք բաց կոդով օգտագործեցինք WAL-G վերլուծական գրադարանը: Ինչքան գիտեմ, դեռ ոչ ոք չի օգտվում, բայց եթե ինչ-որ մեկն ուզում է, գրի ու օգտագործի, հանրային տիրույթում է։ (Թարմացված հղում https://github.com/wal-g/wal-g/tree/master/internal/walparser)

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

Գրաֆիկների վրա ամեն ինչ շատ ավելի պարզ է թվում: Սա ներբեռնում է մեր իրական կլաստերներից մեկից: Մենք ունենք LSN-ի վրա հիմնված՝ պատրաստված մեկ օրում: Եվ մենք տեսնում ենք, որ LSN-ի վրա հիմնված դելտա կրկնօրինակումն աշխատում էր առավոտյան երեքից մինչև առավոտյան հինգը: Սա պրոցեսորային միջուկների քանակի ծանրաբեռնվածությունն է: WAL-delta-ն մեզ այստեղ խլեց մոտ 20 րոպե, այսինքն՝ այն զգալիորեն արագացավ, բայց միևնույն ժամանակ ցանցով ավելի ինտենսիվ փոխանակում կար:

Քանի որ մենք ունենք տեղեկատվություն այն մասին, թե որ բլոկները փոխվել են և որ ժամանակում են տվյալների բազայի պատմության մեջ, մենք ավելի հեռուն գնացինք և որոշեցինք ինտեգրել ֆունկցիոնալությունը՝ PostgreSQL ընդլայնում, որը կոչվում է «pg_prefaulter»:

Սա նշանակում է, որ երբ սպասման բազան կատարում է վերականգնման հրամանը, այն ասում է WAL-G-ին բեռնել հաջորդ WAL ֆայլը: Մոտավորապես մենք հասկանում ենք, թե մոտ ապագայում WAL-ի վերականգնման գործընթացի տվյալների որ բլոկները հասանելի կլինեն և կսկսեն կարդալ այս բլոկների գործողությունը: Դա արվել է SSD կարգավորիչների աշխատանքը բարձրացնելու համար: Քանի որ WAL roll-ը կհասնի այն էջին, որը պետք է փոխվի: Այս էջը սկավառակի վրա է և էջերի քեշում չէ: Եվ նա սինխրոն կսպասի այս էջին: Բայց մոտակայքում WAL-G-ն է, որը գիտի, որ WAL-ի հաջորդ մի քանի հարյուր մեգաբայթում մեզ անհրաժեշտ կլինեն որոշակի էջեր և միևնույն ժամանակ սկսում է դրանք տաքացնել: Սկսում է սկավառակի բազմաթիվ մուտքեր, որպեսզի դրանք կատարվեն զուգահեռ: Սա լավ է աշխատում SSD կրիչներում, բայց, ցավոք, այն բացարձակապես կիրառելի չէ կոշտ սկավառակի համար, քանի որ մենք դրան խանգարում ենք միայն մեր հուշումներով:

Սա այն է, ինչ հիմա կոդում է:

Կան առանձնահատկություններ, որոնք մենք կցանկանայինք ավելացնել:

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

Բանն այն է, որ երբ մենք վերականգնում ենք կլաստերը, մենք կրճատում ենք պատմությունների քանակը, որոնք մենք պետք է հաջորդաբար գլորենք: Այսինքն՝ WAL-ի քանակը, որը գլորում է PostgreSQL-ը, պետք է կրճատվի, քանի որ դա զգալի ժամանակ է պահանջում։

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

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

Բայց սա դեռ մի գաղափար է, որը ակտիվորեն քննարկվում է մեր ներսում, բայց դեռ չի հասել օրենսգրքին։

Մենք ցանկանում ենք ևս մեկ առանձնահատկություն ստեղծել WAL-G-ում: Մենք ցանկանում ենք այն ընդարձակել, քանի որ մենք պետք է աջակցենք տարբեր տվյալների բազաներին և կցանկանայինք նույն կերպ մոտենալ պահեստային կառավարմանը: Բայց խնդիրն այն է, որ MySQL API-ները արմատապես տարբեր են: MySQL-ում PITR-ը հիմնված է ոչ թե ֆիզիկական WAL մատյանի, այլ բինլոգի վրա: Եվ մենք չունենք արխիվացման համակարգ MySQL-ում, որը կհայտնի որոշ արտաքին համակարգի, որ այս բինլոգն ավարտված է և պետք է արխիվացվի: Մենք պետք է ինչ-որ տեղ կանգնենք տվյալների բազայի հետ և ստուգենք, արդյոք ինչ-որ բան պատրաստ է:

Եվ նույն կերպ, MySQL-ի վերականգնման ժամանակ չկա վերականգնման հրաման, որը կարող է համակարգին ասել, որ ինձ պետք են այսինչ ֆայլերը: Նախքան ձեր կլաստերի վերակառուցումը սկսելը, դուք պետք է իմանաք, թե ինչ ֆայլեր են ձեզ անհրաժեշտ: Դուք ինքներդ պետք է գուշակեք, թե ինչ ֆայլեր ձեզ անհրաժեշտ կլինեն: Բայց այս խնդիրները հնարավոր է ինչ-որ կերպ շրջանցել: (Պարզաբանում. MySQL-ն արդեն աջակցվում է)

Զեկույցում ես ուզում էի խոսել նաև այն դեպքերի մասին, երբ WAL-G-ը ձեզ հարմար չէ։

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

Ես հաճախ եմ տեսնում մարդկանց, ովքեր փորձում են միաժամանակ վազել և՛ WAL-G, և՛ WAL-E: Մենք աջակցում ենք հետընթաց համատեղելիությանը այն իմաստով, որ WAL-G-ը կարող է վերականգնել ֆայլը WAL-E-ից և կարող է վերականգնել WAL-E-ում ստեղծված կրկնօրինակը: Բայց քանի որ այս երկու համակարգերն էլ օգտագործում են զուգահեռ wal-push, նրանք սկսում են միմյանցից ֆայլեր գողանալ: Եթե ​​մենք այն ուղղենք WAL-G-ում, այն դեռ կմնա WAL-E-ում: WAL-E-ում այն ​​նայում է արխիվի կարգավիճակին, տեսնում է պատրաստի ֆայլերը և արխիվացնում դրանք, մինչդեռ մյուս համակարգերը պարզապես չեն իմանա, որ այս WAL ֆայլը գոյություն է ունեցել, քանի որ PostgreSQL-ը չի փորձի այն երկրորդ անգամ արխիվացնել:

Ի՞նչ ենք մենք ուղղելու այստեղ WAL-G-ի կողմից: Մենք PostgreSQL-ին չենք տեղեկացնի, որ այս ֆայլը փոխանցվել է զուգահեռ, և երբ PostgreSQL-ը մեզ խնդրի արխիվացնել այն, մենք արդեն կիմանանք, որ այս ռեժիմով և այս md5-ով նման ֆայլ արդեն արխիվացված է, և մենք պարզապես կասենք PostgreSQL. Լավ, ամեն ինչ պատրաստ է, ըստ էության, ոչինչ չանելով:

Բայց այս խնդիրը հազիվ թե շտկվի WAL-E կողմում, ուստի ներկայումս անհնար է ստեղծել արխիվի հրաման, որը արխիվացնի ֆայլը և՛ WAL-G, և՛ WAL-E:

Բացի այդ, կան դեպքեր, երբ WAL-G-ն այժմ ձեզ հարմար չէ, բայց մենք այն անպայման կուղղենք։

Նախ, մենք ներկայումս չունենք ներկառուցված պահուստային ստուգում: Մենք ստուգում չունենք ոչ պահուստավորման, ոչ էլ վերականգնման ժամանակ։ Իհարկե, սա իրականացվում է ամպի մեջ: Բայց դա իրականացվում է պարզապես նախնական ստուգմամբ, պարզապես կլաստերի վերականգնմամբ։ Ես կցանկանայի այս գործառույթը տրամադրել օգտվողներին: Բայց ստուգման միջոցով ես ենթադրում եմ, որ WAL-G-ում հնարավոր կլինի վերականգնել կլաստերը և գործարկել այն և գործարկել ծխի թեստեր՝ pg_dumpall դեպի /dev/null և amcheck index verification։

Ներկայումս WAL-G-ում WAL-ից մեկ պահուստավորումը հետաձգելու հնարավորություն չկա: Այսինքն՝ մենք աջակցում ենք ինչ-որ պատուհանի։ Օրինակ՝ վերջին յոթ օրերի պահպանում, վերջին տասը կրկնօրինակների պահպանում, վերջին երեք ամբողջական կրկնօրինակների պահպանում։ Շատ հաճախ մարդիկ գալիս են և ասում. «Մեզ պետք է կրկնօրինակում այն, ինչ տեղի է ունեցել Ամանորին, և մենք ցանկանում ենք այն հավերժ պահել»: WAL-G-ը դեռ չի կարող դա անել: (Ծանոթագրություն - Սա արդեն ուղղվել է: Կարդալ ավելին - Backup-mark option in https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

Եվ մենք չունենք էջի ստուգման գումարներ և ամբողջականության ստուգումներ լիսեռի բոլոր հատվածների համար PITR-ի վավերացման ժամանակ:

Այս ամենից ես հավաքեցի նախագիծ Google Summer of Code-ի համար: Եթե ​​գիտեք խելացի ուսանողների, ովքեր կցանկանան ինչ-որ բան գրել Go-ում և մի ընկերությունից ստանալ մի քանի հազար դոլար «G» ​​տառով, ապա նրանց խորհուրդ տվեք մեր նախագիծը: Ես հանդես կգամ որպես մենթոր այս նախագծի համար, նրանք կարող են դա անել: Եթե ​​ուսանողներ չլինեն, ուրեմն կվերցնեմ ու ինքս ամռանը կանեմ։

Եվ շատ այլ մանր խնդիրներ ունենք, որոնց վրա աստիճանաբար աշխատում ենք։ Եվ բավականին տարօրինակ բաներ են տեղի ունենում:

Օրինակ, եթե WAL-G-ին դատարկ կրկնօրինակեք, այն պարզապես կընկնի: Օրինակ, եթե նրան ասեք, որ նա պետք է կրկնօրինակի դատարկ թղթապանակը: pg_control ֆայլը այնտեղ չի լինի: Եվ նա կմտածի, որ ինչ-որ բան չի հասկանում։ Տեսականորեն, այս դեպքում պետք է սովորական հաղորդագրություն գրել օգտատիրոջը՝ բացատրելու նրան, թե ինչպես օգտագործել գործիքը։ Բայց սա նույնիսկ ծրագրավորման հատկանիշ չէ, այլ լավ, հասկանալի լեզվի հատկանիշ։

Մենք չգիտենք, թե ինչպես անել անցանց կրկնօրինակում: Եթե ​​տվյալների բազան ստում է, մենք չենք կարող կրկնօրինակել այն: Բայց այստեղ ամեն ինչ շատ պարզ է. Մենք կանչում ենք կրկնօրինակումներ LSN-ով, երբ այն սկսվեց: Հիմնական բազայի LSN-ը պետք է ընթերցվի կառավարման ֆայլից: Եվ սա այնքան չիրացված հատկանիշ է։ Պահուստային շատ համակարգեր կարող են կրկնօրինակել հիմքում ընկած տվյալների բազան: Եվ դա հարմար է:

Ներկայումս մենք չենք կարող պատշաճ կերպով կարգավորել պահեստային տարածքի բացակայությունը: Քանի որ մենք տանը սովորաբար աշխատում ենք մեծ կրկնօրինակներով: Եվ նրանք չհասան դրան: Բայց եթե ինչ-որ մեկը ցանկանում է ծրագրավորել Go-ում հենց հիմա, ավելացրեք բեռնաթափման սխալների կառավարումը դույլում: Ես անպայման կանդրադառնամ ձգման խնդրանքին:

Եվ գլխավորը, որ անհանգստացնում է մեզ, այն է, որ մենք ցանկանում ենք որքան հնարավոր է շատ docker ինտեգրման թեստեր, որոնք ստուգում են տարբեր սցենարներ: Հենց հիմա մենք փորձարկում ենք միայն հիմնական սցենարները: Յուրաքանչյուր commit-ի դեպքում մենք ցանկանում ենք ստուգել commit-by-commit բոլոր գործառույթները, որոնք մենք աջակցում ենք: Մասնավորապես, օրինակ, մենք կունենանք բավականաչափ աջակցություն PostgreSQL 9.4-9.5-ի համար։ Մենք աջակցում ենք նրանց, քանի որ համայնքն աջակցում է PostgreSQL-ին, բայց մենք չենք ստուգում commit-by-commit՝ համոզվելու համար, որ ամեն ինչ կոտրված չէ: Եվ ինձ թվում է, որ դա բավականին լուրջ ռիսկ է։

Մենք ունենք WAL-G, որն աշխատում է ավելի քան հազար կլաստերների վրա Yandex Database-ի կառավարման մեջ: Եվ այն ամեն օր պահուստավորում է մի քանի հարյուր տերաբայթ տվյալներ:

Մենք ունենք շատ TODO մեր կոդում: Եթե ​​ուզում եք ծրագրավորել, եկեք, մենք սպասում ենք ձգման հարցումների, սպասում ենք հարցերի։

Հարցեր

Բարի երեկո! Շնորհակալություն! Իմ ենթադրությունն այն է, որ եթե դուք օգտագործում եք WAL-delta-ն, հավանաբար մեծապես ապավինում եք ամբողջ էջով գրելուն: Եվ եթե այո, ապա դուք թեստեր եք անցկացրել: Գեղեցիկ գրաֆիկ ես ցույց տվել։ Որքան ավելի գեղեցիկ է դառնում, եթե FPW-ն անջատված է:

Ամբողջաէջ գրելը մեզ համար միացված է, մենք չենք փորձել անջատել այն։ Այսինքն՝ ես՝ որպես ծրագրավորող, չեմ փորձել անջատել։ Համակարգի ադմինիստրատորները, ովքեր ուսումնասիրել են, հավանաբար ուսումնասիրել են այս հարցը: Բայց մեզ պետք է FPW: Գրեթե ոչ ոք այն չի անջատում, քանի որ հակառակ դեպքում անհնար է կրկնօրինակից կրկնօրինակում վերցնել։

Շնորհակալություն զեկույցի համար: Երկու հարց ունեմ. Առաջին հարցն այն է, թե ինչ կլինի սեղանի տարածքների հետ:

Մենք սպասում ենք ձգման խնդրանքի: Մեր տվյալների շտեմարաններն ապրում են SSD և NMVE սկավառակների վրա, և մենք իրականում այս հատկության կարիքը չունենք: Ես պատրաստ չեմ այս պահին լուրջ ժամանակ ծախսել դա լավ անելու վրա: Ես ամբողջ սրտով պաշտպանում եմ, որ մենք սատարում ենք դրան: Մարդիկ կան, որ սատարել են, բայց իրենց հարմար ձեւով աջակցել են։ Պատառաքաղ են սարքել, բայց քաշքշուկի պահանջները չեն անում։ (Ավելացված է 0.2.13 տարբերակում)

Եվ երկրորդ հարցը. Դուք հենց սկզբում ասացիք, որ WAL-G-ն ենթադրում է, որ այն աշխատում է միայնակ, և փաթաթաններ պետք չեն: Ես ինքս օգտագործում եմ փաթաթաններ: Ինչո՞ւ դրանք չպետք է օգտագործվեն։

Մենք ցանկանում ենք, որ այն լինի նույնքան պարզ, որքան բալալայկան: Սա նշանակում է, որ ձեզ ընդհանրապես ոչինչ պետք չէ, բացի բալալայկայից: Մենք ցանկանում ենք, որ համակարգը պարզ լինի: Եթե ​​դուք ունեք ֆունկցիոնալություն, որը դուք պետք է կատարեք սցենարում, ապա եկեք և ասեք մեզ. մենք դա կանենք Go-ում:

Բարի երեկո! Շնորհակալություն զեկույցի համար: Մենք չկարողացանք WAL-G-ին աշխատել GPG ապակոդավորման հետ: Այն սովորաբար կոդավորում է, բայց չի ցանկանում վերծանել: Արդյո՞ք դա մեզ մոտ չստացվեց: Իրավիճակը ճնշող է.

Ստեղծեք խնդիր GitHub-ում և եկեք պարզենք այն:

Այսինքն՝ դուք սրան չե՞ք հանդիպել։

Սխալի հաշվետվության մի առանձնահատկություն կա, երբ WAL-G-ը չի հասկանում, թե ինչ տեսակի ֆայլ է, հարցնում է. «Գուցե այն կոդավորված է»: Թերևս խնդիրն ամենևին էլ կոդավորումը չէ։ Ես ուզում եմ բարելավել այս թեմայի գրանցումը: Նա պետք է վերծանի այն: Մենք ներկայումս աշխատում ենք այս թեմայի վրա այն առումով, որ մեզ այնքան էլ դուր չի գալիս, թե ինչպես է կազմակերպվում հանրային և մասնավոր բանալիներ ստանալու համակարգը։ Որովհետև մենք անվանում ենք արտաքին GPG, որպեսզի այն մեզ տա իր բանալիները։ Եվ հետո մենք վերցնում ենք այս բանալիները և փոխանցում դրանք ներքին GPG-ին, որը բաց PGP-ն է, որը մեզ համար կազմված է WAL-G-ի ներսում, և այնտեղ մենք անվանում ենք գաղտնագրում։ Այս առումով մենք ցանկանում ենք բարելավել համակարգը և ցանկանում ենք աջակցել Libsodium կոդավորմանը (Ավելացված է 0.2.15 տարբերակում): Իհարկե, ապակոդավորումը պետք է աշխատի, եկեք պարզենք, ձեզ ավելի շատ ախտանիշ է պետք, քան մի քանի բառ: Դուք կարող եք երբևէ հավաքվել խոսնակի սենյակում և նայել համակարգին: (PGP գաղտնագրում առանց արտաքին GPG - v0.2.9)

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Երկու հարց ունեմ. Ես տարօրինակ ցանկություն ունեմ անել pg_basebackup և WAL մուտք գործել երկու պրովայդեր, այսինքն՝ ես ուզում եմ անել մեկ ամպ, մյուսը: Կա՞ դա անելու որևէ միջոց:

Սա հիմա չկա, բայց հետաքրքիր գաղափար է:

Ես պարզապես չեմ վստահում մի մատակարարի, ես ուզում եմ նույնը ունենալ մյուսում, ամեն դեպքում:

Գաղափարը հետաքրքիր է. Տեխնիկապես դա ամենևին էլ դժվար չէ իրականացնել։ Որպեսզի գաղափարը չկորցնի, կարո՞ղ եմ խնդրել ձեզ խնդիր առաջացնել GitHub-ում:

Այո, իհարկե.

Եվ հետո, երբ ուսանողները գան Google Summer of Code, մենք նրանց կավելացնենք նախագծին, որպեսզի ավելի շատ աշխատանք լինի նրանցից ավելին ստանալու համար:

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

Խնդիրն այն է, որ ինչ-ինչ պատճառներով պահեստը (CEPH) վերակայում է կապը, երբ մենք հասնում ենք դրան բարձր զուգահեռականությամբ: Ի՞նչ կարելի է անել այս մասին: Կրկնելու տրամաբանությունն այսպիսի տեսք ունի. Մենք նորից փորձում ենք ներբեռնել ֆայլը: Մեկ անցումով ունեինք մի շարք չներբեռնված ֆայլեր, կպատրաստենք երկրորդը բոլոր նրանց համար, ովքեր մուտք չեն գործել։ Եվ քանի դեռ առնվազն մեկ ֆայլ բեռնված է յուրաքանչյուր կրկնության համար, մենք կրկնում ենք և կրկնում և կրկնում ենք: Մենք բարելավեցինք կրկնակի փորձի տրամաբանությունը՝ էքսպոնենտալ հետքայլ: Բայց լիովին պարզ չէ, թե ինչ անել այն փաստի հետ, որ կապը պարզապես խզվում է պահեստավորման համակարգի կողմից: Այսինքն, երբ մենք վերբեռնում ենք մեկ հոսք, այն չի խզում այս կապերը։ Ի՞նչ կարող ենք բարելավել այստեղ: Մենք ունենք ցանցի խափանում, մենք կարող ենք սահմանափակել յուրաքանչյուր կապը ուղարկվող բայթերի քանակով: Հակառակ դեպքում, ես չգիտեմ, թե ինչպես վարվել այն փաստի հետ, որ օբյեկտների պահպանումը թույլ չի տալիս մեզ զուգահեռաբար ներբեռնել կամ ներբեռնել դրանից:

SLA չկա՞ Նրանց համար գրված չէ՞, թե ինչպես են թույլ տալիս, որ իրենց տանջեն։

Բանն այն է, որ մարդիկ, ովքեր նման հարց են տալիս, սովորաբար ունենում են իրենց պահոցը: Այսինքն, ոչ ոք չի գալիս Amazon-ից կամ Google Cloud-ից կամ Yandex Object Storage-ից:

Գուցե հարցն այլևս ձեզ համար չէ՞։

Հարցն այստեղ այս դեպքում նշանակություն չունի, թե ում համար։ Եթե ​​կան գաղափարներ, թե ինչպես վարվել սրա հետ, եկեք դա անենք WAL-G-ում: Բայց մինչ այժմ ես լավ գաղափարներ չունեմ, թե ինչպես վարվել սրա հետ: Կան որոշ օբյեկտների պահեստավորում, որոնք տարբեր կերպ են աջակցում ցուցակագրման կրկնօրինակումներին: Դուք նրանց խնդրում եք ցուցակագրել օբյեկտները, և նրանք այնտեղ թղթապանակ են ավելացնում: WAL-G-ը վախենում է դրանից. այստեղ ինչ-որ բան կա, որը ֆայլ չէ, ես չեմ կարող վերականգնել այն, ինչը նշանակում է, որ կրկնօրինակը չի վերականգնվել: Այսինքն, իրականում դուք ունեք ամբողջությամբ վերականգնված կլաստեր, բայց այն ձեզ վերադարձնում է սխալ կարգավիճակ, քանի որ Object Storage-ը վերադարձրեց մի քանի տարօրինակ տեղեկատվություն, որը նա լիովին չի հասկացել:

Սա մի բան է, որը տեղի է ունենում Mail ամպի մեջ:

Եթե ​​դուք կարող եք վերարտադրել...

Հետևողականորեն վերարտադրվում է...

Եթե ​​կա վերարտադրում, ապա ես կարծում եմ, որ մենք կփորձարկենք կրկնակի փորձարկման ռազմավարություններ և կպարզենք, թե ինչպես կարելի է նորից փորձել և հասկանալ, թե ինչ է պահանջում ամպը մեզանից: Միգուցե այն մեզ համար կայուն լինի երեք միացումների վրա ու չխզվի կապը, հետո զգուշորեն հասնենք երեքին։ Որովհետև հիմա մենք շատ արագ հեռացնում ենք կապը, այսինքն՝ եթե վերականգնում ենք սկսել 16 թելերով, ապա առաջին անգամից հետո կլինի 8 թել, 4 թել, 2 թել և մեկ։ Եվ այնուհետև այն կքաշի ֆայլը մեկ հոսքի մեջ: Եթե ​​կան որոշ կախարդական արժեքներ, ինչպիսիք են 7,5 թելերը պոմպելու համար լավագույնը, ապա մենք կանդրադառնանք դրանց վրա և կփորձենք ստեղծել ևս 7,5 թել: Ահա մի միտք.

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

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

Այսինքն, ամեն անգամ, երբ մենք գործարկում ենք WAL-G-ը, այն փորձում է ամբողջական կրկնօրինակե՞լ:

Ոչ, մենք գործարկում ենք WAL-G-ը, և այն փորձում է դելտա ստեղծել, եթե ձեր քաղաքականությունը դա թույլ է տալիս:

Կոպիտ ասած, եթե ամեն անգամ գործարկես զրոյով, այն իրեն pg_basebackup պես կպահի:

Ոչ, այն դեռ ավելի արագ կաշխատի, քանի որ օգտագործում է սեղմում և զուգահեռություն: Pg_basebackup-ը ձեր կողքին կդնի լիսեռը: WAL-G-ը ենթադրում է, որ դուք կարգավորել եք արխիվացումը: Եվ այն նախազգուշացում կտա, եթե այն կազմաձևված չէ:

Pg_basebackup-ը կարող է գործարկվել առանց լիսեռների:

Այո, հետո նրանք իրենց գրեթե նույն կերպ կպահեն։ Pg_basebackup-ը պատճենում է ֆայլային համակարգին: Ի դեպ, մենք ունենք նոր առանձնահատկություն, որը մոռացա նշել. Այժմ մենք կարող ենք պատճենել ֆայլային համակարգին pg_basebackup-ից: Ես չգիտեմ, թե ինչու է դա անհրաժեշտ, բայց կա:

Օրինակ, CephFS-ում: Ոչ բոլորն են ցանկանում կարգավորել Object Storage-ը:

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

Շնորհակալություն զեկույցի համար: Ուղղակի հարց կա ֆայլային համակարգում պատճենելու մասին։ Արդյո՞ք դուք այժմ աջակցում եք պատճենումը հեռավոր պահեստում, օրինակ, եթե տվյալների կենտրոնում ինչ-որ դարակ կա կամ այլ բան:

Այս ձեւակերպման մեջ սա բարդ հարց է։ Այո, մենք աջակցում ենք, բայց այս գործառույթը դեռ ներառված չէ որևէ թողարկման մեջ: Այսինքն՝ բոլոր նախնական թողարկումներն աջակցում են դրան, իսկ թողարկման տարբերակները՝ ոչ։ Այս գործառույթն ավելացվել է 0.2 տարբերակում: Այն անպայման շուտով կթողարկվի, հենց որ շտկենք բոլոր հայտնի սխալները։ Բայց այս պահին դա կարելի է անել միայն նախնական թողարկման ժամանակ: Նախնական թողարկումում երկու սխալ կա: WAL-E վերականգնման խնդիր, մենք այն չենք շտկել: Իսկ վերջին նախնական թողարկումում ավելացվել է դելտա-պահուստավորման մասին սխալ: Ուստի խորհուրդ ենք տալիս բոլորին օգտագործել թողարկման տարբերակները: Հենց որ նախնական թողարկումում այլևս սխալներ չկան, կարող ենք ասել, որ մենք աջակցում ենք Google Cloud-ին, S3-ի հետ համատեղելի բաներին և ֆայլերի պահպանմանը։

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

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

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

P.S Թողարկվել է նոր տարբերակ 0.2.15, որում կարող եք օգտագործել .walg.json կազմաձևման ֆայլը, որը լռելյայնորեն գտնվում է postgres-ի գլխավոր գրացուցակում։ Դուք կարող եք հրաժարվել bash սցենարներից: Օրինակ .walg.json-ն այս հարցում է https://github.com/wal-g/wal-g/issues/545

Video:

Source: www.habr.com