دعم MySQL في Hyperdrive من Cloudflare متاح للجميع بعد إصلاح 20 خطأ

أعلنت Cloudflare عن التوفر العام لدعم MySQL في Hyperdrive. Hyperdrive هي تجمع اتصالات قاعدة بيانات موزعة لـ Workers. كانت الخدمة تدعم Postgres في البداية فقط، بينما تم الإعلان عن الإصدار التجريبي لبروتوكول MySQL الأسبوع الماضي. وبحسب الشركة، كان الفرق بين البيتا والإصدار العام هو إصلاح 20 خطأ.

أخطاء الترميز التي تم إصلاحها خلال فترة البيتا

كانت أول مشكلة في البيتا هي أن الرموز التعبيرية المخزنة في قاعدة البيانات كانت تُرجع بشكل غير صحيح. وكان السبب هو ترميز مجموعة الأحرف. عند بدء الاتصال، كان Hyperdrive يتفاوض على الترميز ويستخدم utf8، وهو اسم مستعار قديم لـ utf8mb3. هذا الترميز يدعم فقط من 1 إلى 3 بايتات لنقطة الترميز، بينما UTF-8 الكامل يصل إلى 4 بايتات. قام الفريق بتغيير الإعداد اليدوي إلى utf8mb4 وحل مشكلة الرموز التعبيرية.

ظهرت مشكلة الترميز الثانية بعد أن أضاف Hyperdrive تنظيف الاتصال باستخدام COM_RESET_CONNECTION. هذا أمر خفيف في MySQL ينظف حالة الجلسة حتى لا تنتقل حالة الجلسة بين عمليات الجلب. المشكلة هي أن COM_RESET_CONNECTION يعيد الاتصال إلى الترميز الافتراضي للخادم بدلاً من المتفق عليه عند بدء التشغيل. بعد إعادة تحميل خادم MySQL الذي لديه latin1 افتراضيًا، كان الاتصال ينتقل إلى 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 إلى EOFs لتتوافق مع مهلة برنامج تشغيل Worker.

كان السبب افتراضًا مستوردًا من تخزين Postgres المؤقت: البايتات الدقيقة المكتوبة لـ Worker قد يتم تخزينها مؤقتًا. هذا لا ينطبق على MySQL لأن Client يكتب بايتات مترجمة لقدرات Worker، بينما Endpoint يعمل بقدرات Hyperdrive. مع ذاكرة التخزين المؤقت المشتركة، يمكن لأحدهما قراءة ما خزنه الآخر. في حالة واحدة، خزن Endpoint بايتات الرد في ذاكرة التخزين المؤقت، وقام Client بتوصيلها إلى Worker بدون ترجمة. في الحالة الأخرى، خزن Client البايتات المترجمة في ذاكرة التخزين المؤقت، وقراها Endpoint ومررتها إلى Client آخر، الذي حاول ترجمتها مرة أخرى وإما أرسل EOF زائدًا أو علق.

كان الإصلاح هو تخزين الإصدار القانوني لبايتات نتيجة الاستعلام دائمًا في ذاكرة التخزين المؤقت، مشفرًا بقدرات Hyperdrive، بغض النظر عن العقدة التي خزنته. بعد التغيير، اختفت مشكلة الصفوف الفارغة وبلغ معدل نجاح اتصالات Client هدف التوفر بنسبة 99.99%.

المصادر: Cloudflare