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