Նվագավորող MySQL-ի համար. ինչու առանց դրա չես կարող ստեղծել անսարքությունների հանդուրժող նախագիծ

Ցանկացած մեծ նախագիծ սկսվում էր մի քանի սերվերով: Սկզբում կար մեկ DB սերվեր, այնուհետև դրան ավելացվեցին ստրուկներ՝ ընթերցումը մեծացնելու համար: Եվ հետո - կանգ! Մեկ տերը կա, բայց ստրուկները շատ են. եթե ստրուկներից մեկը հեռանա, ուրեմն ամեն ինչ լավ կլինի, բայց եթե վարպետը հեռանա, վատ կլինի՝ դաունթայմ, ադմինները փորձում են բարձրացնել սերվերը։ Ինչ անել? Վարպետի ամրագրում։ Այս մասին արդեն գրել է իմ գործընկեր Պավելը статью, չեմ կրկնի։ Փոխարենը, ես ձեզ կասեմ, թե ինչու ձեզ անպայման պետք է Orchestrator MySQL-ի համար:

Սկսենք հիմնական հարցից. «Ինչպե՞ս կփոխենք կոդը նոր մեքենայի, երբ վարպետը հեռանա»:

• Ինձ ամենաշատը դուր է գալիս VIP-ով (Վիրտուալ IP) սխեման, դրա մասին կխոսենք ստորև։ Դա ամենապարզն ու ակնհայտն է, թեև ունի ակնհայտ սահմանափակում՝ այն վարպետը, որը մենք կվերապահենք, պետք է լինի L2 հատվածում նոր մեքենայով, այսինքն՝ կարող ենք մոռանալ երկրորդ DC-ի մասին։ Եվ, բարեկամաբար, եթե հետևեք այն կանոնին, որ մեծ L2-ը չարիք է, քանի որ L2-ը միայն մեկ դարակ է, իսկ L3-ը գտնվում է դարակների միջև, և նման սխեման ավելի շատ սահմանափակումներ ունի:
• Դուք կարող եք գրել DNS անուն կոդում և լուծել այն /etc/hosts-ի միջոցով: Փաստորեն, ոչ մի բանաձեւ չի լինելու։ Սխեմայի առավելությունը. առաջին մեթոդին բնորոշ սահմանափակում չկա, այսինքն՝ հնարավոր է կազմակերպել խաչաձև DC: Բայց հետո ակնհայտ հարց է առաջանում. որքան արագ կարող ենք փոփոխությունը հասցնել /etc/hosts-ին Puppet-Ansible-ի միջոցով:
• Երկրորդ մեթոդը կարող եք մի փոքր փոխել՝ բոլոր վեբ սերվերների վրա տեղադրել քեշային DNS, որի միջոցով կոդը կգնա հիմնական տվյալների բազա։ DNS-ում այս մուտքի համար կարող եք սահմանել TTL 60: Թվում է, որ եթե ճիշտ իրականացվի, մեթոդը լավն է։
• Ծառայությունների հայտնաբերման սխեման, որը ենթադրում է հյուպատոսի օգտագործում և այլն:
• Հետաքրքիր տարբերակ է ProxySQL. Դուք պետք է ամբողջ տրաֆիկը տեղափոխեք դեպի MySQL ProxySQL-ի միջոցով: ProxySQL-ն ինքը կարող է որոշել, թե ով է վարպետը: Ի դեպ, այս ապրանքի օգտագործման տարբերակներից մեկի մասին կարող եք կարդալ իմ Հոդված.

Orchestrator-ի հեղինակը, աշխատելով Github-ում, նախ առաջին սխեման իրականացրեց VIP-ով, այնուհետև այն վերածեց հյուպատոսի հետ սխեմայի:

Տիպիկ ենթակառուցվածքի դասավորությունը.

Ես անմիջապես կնկարագրեմ ակնհայտ իրավիճակները, որոնք պետք է հաշվի առնել.

• VIP հասցեն չպետք է գրանցվի սերվերներից որևէ մեկի կոնֆիգուրայում: Եկեք պատկերացնենք մի իրավիճակ. վարպետը վերագործարկեց, և մինչ այն բեռնվում էր, Orchestrator-ը անցավ failover ռեժիմի և ստրուկներից մեկին վարպետ դարձրեց; հետո հին վարպետը բարձրացավ, իսկ հիմա VIP-ն երկու մեքենայի վրա է: Սա վատ է:
• Նվագախմբի համար ձեզ հարկավոր է սցենար գրել հին վարպետին և նոր վարպետին կանչելու համար: Հին վարպետի վրա պետք է գործարկել ifdown-ը, իսկ նոր վարպետի վրա՝ ifup vip: Հաճելի կլինի նաև այս սցենարում ներառել, որ ձախողման դեպքում հին վարպետի անջատիչի պորտը պարզապես անջատված է, որպեսզի խուսափի որևէ ճեղքվածքից:
• Այն բանից հետո, երբ Orchestrator-ը զանգահարում է ձեր սցենարը՝ նախ հեռացնելու VIP-ը և/կամ անջատելու պորտը, ապա մի մոռացեք օգտագործել arping հրամանը՝ բոլորին ասելու, որ նոր VIP-ն այժմ է: այստեղ.
• Բոլոր ստրուկները պետք է ունենան read_only=1, և հենց որ դուք բարձրացնեք ստրուկին տիրոջ մոտ, այն պետք է ունենա read_only=0:
• Մի մոռացեք, որ ցանկացած ստրուկ, որին մենք ընտրել ենք դրա համար, կարող է դառնալ տեր (Նվագախումբն ունի նախապատվության մի ամբողջ մեխանիզմ, որի համար ստրուկը պետք է համարի որպես նոր տիրոջ թեկնածու առաջին հերթին, որը երկրորդ տեղում և որ ստրուկը պետք է. ոչ մի դեպքում չընտրվի վարպետ): Եթե ​​ստրուկը տեր դառնա, ուրեմն ստրուկի բեռը կմնա վրան ու տիրոջ բեռը կավելացվի, սա պետք է հաշվի առնել։

Ինչու՞ է ձեզ պետք նվագախումբը, եթե չունեք:

• Orchestrator-ն ունի շատ հարմար գրաֆիկական ինտերֆեյս, որը ցուցադրում է ամբողջ տոպոլոգիան (տես ստորև ներկայացված սքրինշոթը):
• Նվագախումբը կարող է հետևել, թե որ ստրուկներն են ետ մնում, և որտեղ է վերարտադրումը հիմնականում խափանվել (մենք ունենք Orchestrator-ին կցված սցենարներ SMS ուղարկելու համար):
• Նվագախումբը պատմում է ձեզ, թե որ ստրուկներն ունեն GTID սխալ:

Նվագախմբի ինտերֆեյս.

Ի՞նչ է GTID սխալը:

Նվագախմբի աշխատանքի համար երկու հիմնական պահանջ կա.

• Անհրաժեշտ է, որ կեղծ GTID-ը միացված լինի MySQL կլաստերի բոլոր մեքենաների վրա, մենք միացված ենք GTID-ին:
• Անհրաժեշտ է, որ ամենուր լինի մեկ տեսակի բինլոգ, կարող եք օգտագործել քաղվածք: Մենք ունեինք կոնֆիգուրացիա, որտեղ վարպետը և ստրուկների մեծ մասը ունեին Row, և երկուսը պատմականորեն մնացին Mixed ռեժիմում: Արդյունքում, Orchestrator-ը պարզապես չցանկացավ կապել այս ստրուկներին նոր վարպետի հետ:

Հիշեք, որ արտադրության ստրուկի մեջ ամենակարևորը նրա հետևողականությունն է վարպետի հետ: Եթե ​​դուք միացված եք Գլոբալ գործարքի ID-ն (GTID) և՛ ձեր վարպետի, և՛ ստրուկի վրա, ապա կարող եք օգտագործել gtid_subset ֆունկցիան՝ պարզելու, թե արդյոք տվյալների փոփոխության նույն հարցումները իրականում կատարվել են այս մեքենաներում: Այս մասին կարող եք կարդալ ավելին այստեղ.

Այսպիսով, Orchestrator-ը ձեզ ցույց է տալիս GTID սխալի միջոցով, որ ստրուկի վրա կան գործարքներ, որոնք վարպետի վրա չեն: Ինչու է դա տեղի ունենում:

• Read_only=1-ը միացված չէ ստրուկում, ինչ-որ մեկը միացել և լրացրել է տվյալները փոխելու հարցումը:
• Super_read_only=1-ը միացված չէ ստրուկի վրա, այնուհետև ադմինը, շփոթեցնելով սերվերը, մտավ և այնտեղ կատարեց հարցումը:
• Եթե ​​հաշվի առնեք նախորդ երկու կետերը, ապա կա ևս մեկ հնարք. MySQL-ում բինլոգները flush-ի հարցումը նույնպես գնում է բինլոգ, այնպես որ առաջին flush-ի ժամանակ վարպետի և բոլոր ստրուկների վրա կհայտնվի GTID սխալ: Ինչպե՞ս խուսափել սրանից: Perona-5.7.25-28-ը ներկայացրեց binlog_skip_flush_commands=1 պարամետրը, որն արգելում է բինլոգներում flush գրել: Կա հաստատված մեկը mysql.com կայքում bug.

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

Ակնհայտ հարցն է՝ «Ինչպե՞ս պետք է աշխատի նվագախումբը»: Նա պետք է ընտրի նոր վարպետ ընթացիկ ստրուկներից, այնուհետև նորից միացնի բոլոր ստրուկները դրան (սա այն է, ինչի համար անհրաժեշտ է GTID-ը. եթե դուք օգտագործում եք հին մեխանիզմը binlog_name-ի և binlog_pos-ի հետ, ապա ստրուկը ներկայիս վարպետից նորին փոխեք: պարզապես անհնար է!): Նախքան նվագախումբ ունենալը, ես մի անգամ ստիպված էի այս ամենը ձեռքով անել: Հին վարպետը կախված էր խելագարված Adaptec վերահսկիչի պատճառով, այն ուներ մոտ 10 ստրուկ: Ինձ անհրաժեշտ էր փոխանցել VIP-ը վարպետից ստրուկներից մեկին և նորից միացնել մյուս բոլոր ստրուկներին: Քանի՞ կոնսուլ պետք է բացեի, քանի՞ միաժամանակյա հրամաններ մտցրի... Ստիպված էի սպասել մինչև գիշերվա ժամը 3-ը, հանել բեռը բոլոր ստրուկներից, բացի երկուսից, առաջին մեքենան պատրաստել երկու վարպետից, անմիջապես միացնել երկրորդ մեքենան։ դրան, այնպես որ բոլոր մյուս ստրուկները միացրեք նոր տիրոջը և վերադարձրեք բեռը: Ընդհանուր առմամբ, սարսափելի ...

Ինչպե՞ս է Orchestrator-ն աշխատում, երբ այն անցնում է ձախողման ռեժիմի: Սա ամենահեշտ կերպով երևում է մի իրավիճակի օրինակով, երբ մենք ցանկանում ենք վարպետին դարձնել ավելի հզոր, ավելի ժամանակակից մեքենա, քան հիմա ունենք:

Նկարը ցույց է տալիս գործընթացի կեսը: Ի՞նչ է արդեն արվել մինչ այս պահը։ Մենք ասացինք, որ ուզում ենք ինչ-որ ստրուկի դարձնել նոր վարպետ, նվագախումբը սկսեց պարզապես վերամիացնել բոլոր մյուս ստրուկներին, նոր վարպետը հանդես գալով որպես տարանցիկ մեքենա: Այս սխեմայով սխալներ չեն լինում, բոլոր ստրուկները աշխատում են, Orchestrator-ը հեռացնում է VIP-ին հին վարպետից, փոխանցում այն ​​նորին, դարձնում read_only=0 և մոռանում հին վարպետի մասին: Բոլորը! Մեր ծառայության պարապուրդը VIP փոխանցման ժամանակն է, որը 2-3 վայրկյան է:

Այսօրվա համար այսքանը, շնորհակալություն բոլորիդ: Շուտով կլինի երկրորդ հոդվածը նվագախմբի մասին: Խորհրդային հայտնի «Գարաժ» ֆիլմում մի կերպար ասաց. «Ես նրա հետ հետախուզության չէի գնա»։ Այսպիսով, նվագախումբ, ես ձեզ հետ կգնայի հետախուզության:

Source: www.habr.com