Cloudflare-ի Hyperdrive-ում MySQL-ի սպասարկումը հասանելի է հանրայնորեն 20 սխալի շտկումից հետո

Cloudflare-ը հայտարարել է Hyperdrive-ում MySQL-ի սպասարկման հանրայն հասանելիության մասին։ Hyperdrive-ը Workers-ի բաշխված բազայի կապերի պուլեր է։ Ծառայությունը սկզբնապես սպասարկում էր միայն Postgres-ին, MySQL-ի պրոտոկոլի բետան հետո հայտարարվել է։ Ընկերության հասկացմամբ, բետայի և GA-ի միջև տարբերությունը եղել է 20 սխալի շտկումը։

Բետայի ընթացքում շտկված կոդավորման սխալները

Բետայում առաջին խնդիրը նրանում էր, որ բազայում գրված էմոջիները սխալ էին վերադառնում։ Պատճառը սիմվոլների հավաքածուի կոդավորումն էր։ Hyperdrive-ը կապը սկսելիս պայմանավորվում է կոդավորման մասին և օգտագործում է utf8-ն՝ utf8mb3-ի հնացած այլանունը։ Այս կոդավորումն աջակցում է կոդային կետի համար միայն 1-ից 3 բայթ, մինչդեռ լրիվ UTF-8-ը՝ մինչև 4 բայթ։ Թիմը ձեռքով անցնել է utf8mb4-ի և էմոջիների խնդիրը լուծվել է։

Երկրորդ կոդավորման խնդիրը հայտնվել է հետո, երբ Hyperdrive-ը ավելացրել է կապի մաքրումը COM_RESET_CONNECTION-ով։ Սա MySQL-ի թեթև հրաման է, որը մաքրում է սեսիայի վիճակը, որպեսզի սեսիայի վիճակը չթափանցի բեռնման միջև։ Խնդիրը նրանում է, որ COM_RESET_CONNECTION-ը կապը գործարկելիս համաձայնեցվածի փոխարեն վերադարձնում է սերվերի լռելյայն կոդավորումը։ latin1-ի լռելյայն MySQL սերվերում վերաբեռնելուց հետո կապը անցել է latin1-ի։ Շտկումը եղել է վերաբեռնելուց հետո կոդավորումը utf8mb4-ի սահմանող հրամանի միշտ կատարումը։

Հազվադեպ քեշավորման սխալը

Բետայի ընթացքում Hyperdrive-ի ամենաբեռնված MySQL օգտատերը հաղորդել է դատարկ պատասխանների փոքր, բայց կայուն քանակի մասին, երբ միշտ դատարկ պատասխանը ակնկալելի էր։ Սխալը տեղի է ունենում մոտավորապես 0,001% դրույթով, ուստի հետևելը սկզբից մինչև վերջ դժվար էր։ Մեկ նշան առանձնանում էր․ սխալը տեղի է ունենում միայն քեշավորված Hyperdrive-ի նմուշներում։

Hyperdrive-ի յուրաքանչյուր նմուշ բաժանված ճարտարապետություն է Client-ի և Endpoint-ի հանգույցներով։ Client-ը Worker-ի նույն մեքենայի վրա է և կարիքի դեպքում հարցումներ է ուղարկում, Endpoint-ը կապերի պուլը պահում է աղբյուր բազային ամենամոտ կենտրոնում։ Երկու հանգույցներն էլ օգտագործում են իրենց կենտրոնի տեղական Cloudflare CDN քեշը, ուստի մեկ կենտրոնում աշխատելիս նրանք կիսվում են ընդհանուր քեշով։ Նորմալ աշխատանքի համար հարկավոր է, որ մեկ նույն պատասխանի համար մեկ նույն բայթերը քեշավորվեն, անկախ նրանից, թե որ հանգույցն է պահել։

Հետաքննությունն ի վերջո ցույց տվել է MySQL-ի պրոտոկոլում հնարավորությունների պայմանավորմանը։ Hyperdrive-ը աղբյուր բազայի համար կլիենտ է, Worker-ի համար՝ սերվեր, և կողմերը կարող են ունենալ տարբեր հնարավորություններ։ Օրինակ, Node.js-ի mysql2 գրադարանը չի աջակցում CLIENT_DEPRECATE_EOF-ը, որը փոխում է արդյունքների հավաքածուների ավարտը։ Ուստի Hyperdrive-ը վերագրում է արդյունքների հավաքածուները, ըստ կարիքի ավելացնում EOF փաթեթներ և թարգմանում OK փաթեթները EOF-ների, որպեսզի համապատասխանի Worker-ի դրայվերի սպասմանը։

Պատճառը Postgres-ի քեշավորումից ներմուծված ենթադրույթն էր․ Worker-ի համար գրված ճշգրիտ բայթերը կարող էին քեշավորվել։ MySQL-ի համար սա գործելիք չունի, քանի որ Client-ը գրում է Worker-ի հնարավորություններով թարգմանված բայթեր, Endpoint-ը դե Hyperdrive-ի հնարավորություններով է աշխատում։ Ընդհանուր քեշի դեպքում մեկը կարող էր կարդալ նրան, ինչ մյուսը էր պահել։ Մեկ դեպքում Endpoint-ը պատասխանի բայթերը պահել էր քեշում, Client-ը դրանք առանց թարգմանության էր հասցրել Worker-ին։ Մյուսում Client-ը թարգմանված բայթերը պահել էր քեշում, Endpoint-ը կարդացել և հանձնել էր մեկ այլ Client-ի, որը նորից փորձել էր թարգմանել և ուղարկել էր անժամանակ EOF կամ կոտրվել էր։

Շտկումը եղել է հարցման արդյունքի բայթերի կանոնական տարբերակի միշտ գրանցումը, գաղտնագրված Hyperdrive-ի հնարավորություններով, անկախ նրանից, թե որ հանգույցն է պահել։ Փոփոխությունից հետո դատարկ տողերի խնդիրը վերացել է, և Client-ի կապերի հաջողության ցուցիչը հասել է 99,99%-անոց հասանելիության նպատակին։

Հղումներ: Cloudflare