תמיכת MySQL ב-Hyperdrive של Cloudflare זמינה לכלל הציבור לאחר תיקון 20 תקלות

Cloudflare הכריזה על זמינות כללית של תמיכת MySQL ב-Hyperdrive. Hyperdrive הוא מאגר חיבורים מבוזר עבור Workers. השירות תחילה תמך רק ב-Postas, וגרסת הבטא לפרוטוקול MySQL הוכרזה לאחרונה. לפי החברה, ההבדל בין בטא ל-GA היה תיקון של 20 תקלות.

תקלות קידוד שתוקנו בזמן הבטא

הבעיה הראשונה בבטא הייתה שאמוג'ים שנכתבו למסד הנתונים הוחזרו באופן שגוי. הסיבה התגלתה בקידוד של קבוצת תווים. Hyperdrive מתפעם על קידוד בעת פתיחת החיבור והשתמש ב-utf8, כינוי ישן ל-utf8mb3. קידוד זה תומך רק ב-1-3 בתים לנקודת קוד, ואילו UTF-8 מלא מגיע עד 4 בתים. הצוות החליף את היד ל-utf8mb4 ובעיית האמוג'ים נפתרה.

בעיית קידוד שנייה נחשפה אחרי ש-Hyperdrive הוסיף ניקוי חיבור עם COM_RESET_CONNECTION. זו פקודה קלה של MySQL שמנקה את מצב הסשן כדי שמצב הסשן לא ידלף בין אימוצים. הבעיה היא ש-COM_RESET_CONNECTION מחזיר את החיבור לקידוד ברירת המחדל של השרת במקום לקידוד שהוסכם בעת ההפעלה. עם ברירת המחדל latin1 בשרת MySQL, אחרי טעינה מחדש החיבור עבר ל-latin1. התיקון היה להריץ תמיד אחרי טעינה מחדש פקודה שמגדירה את הקידוד ל-utf8mb4.

תקלת מטמון נדירה

בזמן הבטא המשתמש העמוס ביותר עם MySQL ב-Hyperdrive דיווח על כמות קטנה אך יציבה של תשובות ריקות, בזמן שכל התשובות הצפויות לא היו ריקות. השגיאה קרה בכ-0,001% מהזמן, ולכן לכידת מעקב מקצה לקצה הייתה קשה. סימן אחד בלט: התקלה קרתה רק במופעים של Hyperdrive עם מטמון.

כל מופע של Hyperdrive הוא ארכיטקטורה מפוצלת של צמתים מסוג Client ו-Endpoint. Client נמצא על אותה מכונה של Worker ומעביר שאילתות בעת הצורך, ואילו Endpoint מחזיק מאגר חיבורים במרכז הקרוב ביותר למקור מסד הנתונים. שני הצמתים משתמשים במטמון המקומי של Cloudflare CDN במרכז שלהם, ולכן כשהם עובדים במרכז אחד הם משתפים מטמון משותף. לתפעול תקין יש צורך שאותה תשובה תקודד לאותם בתים במטמון, ללא קשר לכך איזה צומת אחסן אותה.

החיפוש הצביע לבסוף על משא ומתן אפשרויות בפרוטוקול של MySQL. Hyperdrive הוא לקוח מבחינת מקור מסד הנתונים, ושרת מבחינת Worker, ולצדים עשויות להיות אפשרויות שונות. לדוגמה, ספריית mysql2 של Node.js לא תומכת ב-CLIENT_DEPRECATE_EOF, שמשנה את סיומת סדרות התוצאות. לכן Hyperdrive מכתוב סדרות תוצאות, מוסיף חבילות EOF לפי הצורך ומתרגם חבילות OK ל-EOF כדי להתאים להמתנה של דרייבר ה-Worker.

הסיבה הייתה השערה שהועברה ממטמון Postgres: הבתים המדויקים שנכתבו עבור Worker עשויים להיכנס למטמון. עבור MySQL זה לא חל, כי Client כותב בתים מתורגמים לאפשרויות של Worker, ו-Endpoint עובד עם אפשרויות של Hyperdrive. במטמון משותף אחד צומט יכול היה לקרוא מה שצומט שני אחסן. במקרה אחד Endpoint אחסן במטמון את בתי התשובה, ו-Client מסר אותם ל-Worker ללא תרגום. במקרה שני Client אחסן במטמון בתים מתורגמים, Endpoint קרא אותם והעביר ללקוח אחר, ששוב ניסה לתרגם ונתקע בשליחת EOF שגויה או נתקע.

התיקון היה תמיד לכתוב למטמון את הגרסה הקנונית של בתי תוצאת השאילתה, מהודרת עם אפשרויות של Hyperdrive, ללא קשר לכך איזה צומת אחסן אותה. אחרי השינוי הבעיה של שורות ריקות נעלמה, ומדד ההצלחה של חיבורי Client הגיע ליעד הזמינות של 99,99%.

מקורות: Cloudflare