الذكاء الاصطناعي

كلاودفلير تحلّ عطلاً نادراً في ذاكرة MySQL ضمن Hyperdrive

بعد فترة تجريبية طويلة، أصبحت ميزة دعم MySQL في Hyperdrive متاحة للجميع، عقب معالجة خلل دقيق في آلية تخزين نتائج الاستعلامات مؤقتاً.

رضوان عبدالهاديمحرر وكاتب تقني

نُشر: 14 أكتوبر 2026 · آخر تحديث: 14 أكتوبر 2026 · 4 دقائق قراءة

كلاودفلير تحلّ عطلاً نادراً في ذاكرة MySQL ضمن Hyperdrive — الصورة: Cloudflare Blog

الانتقال من التجريب إلى الإتاحة العامة

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

تحديات إدارة اتصالات قواعد البيانات

يعمل Hyperdrive كمدير اتصال موزع يربط تطبيقات Workers بقواعد البيانات SQL. بدلاً من إنشاء اتصال جديد لكل طلب، وهو أمر مكلف زمنياً وموارد، يحتفظ Hyperdrive باتصالات ساخنة مفتوحة على الشبكة العالمية ويشاركها بين العديد من الطلبات. كما يوفر النظام ميزة تخزين مؤقت (Caching) للاستعلامات الشائعة في شبكة CDN، مما يقلل زمن الاستجابة والضغط على قاعدة البيانات الأصلية. على الرغم من أن MySQL يستهلك موارد أقل من Postgres من حيث العمليات، إلا أن إدارة آلاف الاتصالات المفتوحة تتطلب معالجة دقيقة لتجنب استنفاد الموارد.

معالجة أخطاء ترميز الأحرف

من أبرز المشاكل التي واجهها الفريق خلال المرحلة التجريبية كانت عدم عودة الإيموجي بشكل صحيح عند قراءتها من قاعدة البيانات. تبيّن أن السبب يكمن في استخدام ترميز utf8، وهو مستعار قديم لـ utf8mb3 الذي يدعم فقط 1 إلى 3 بايت لكل رمز يونيكود، بينما يتطلب UTF-8 الكامل 4 بايت. تم حل المشكلة بتحديث عملية المصافحة الأولية للاتصال لاستخدام utf8mb4. واجه الفريق مشكلة مشابهة عند إضافة أمر COM_RESET_CONNECTION لتنظيف حالة الجلسة، حيث كان الأمر يعيد الترميز إلى الافتراضي (latin1) بدلاً من الترميز المتفق عليه، مما استدعى إضافة أمر صريح لضبط الترميز بعد كل إعادة تعيين.

تحقيق العطل النادر في الكاش

أبلغ أحد أكبر العملاء عن ظهور إجابات فارغة بشكل متكرر بنسبة 0.001% رغم توقع وجود بيانات. كان العطل يظهر فقط عند تفعيل ميزة الكاش، مما دفع الفريق للتركيز على آلية التخزين المؤقت. نظراً لصعوبة تتبع العطل بسبب ندرة حدوثه، قام الفريق بزيادة معدل التتبع (Tracing) وتحليل البيانات التلغرافية (Telemetry) دون العثور على أخطاء شبكة واضحة. كان التحدي الرئيسي هو فهم كيف يمكن أن تتداخل عمليات الكاش مع بروتوكول الاتصال نفسه، خاصة مع البنية المعمارية المعقدة التي تربط بين عقد العملاء ونقاط النهاية.

فهم بنية Hyperdrive وتفاعل الكاش

تعتمد Hyperdrive على بنية مقسمة إلى عقدة عميل (Client) وعقدة نقطة نهاية (Endpoint). تعمل عقدة العميل على نفس الجهاز الخاص بالمستخدم وتدير الكاش المحلي، بينما تحتفظ عقدة نقطة النهاية بحوض الاتصالات وتوضع في أقرب مركز بيانات لقاعدة البيانات الأصلية. عندما تعمل العقدةان في نفس المركز، يتشاركان ذاكرة CDN المحلية. يعتمد النظام على تجزئة (Hash) محتوى رسائل الاستعلام لتخزين النتائج، مما يسمح للعميل بتقديم الإجابة مباشرة من الكاش المشترك إذا كانت متاحة، شريطة أن تكون البايتات المخزنة مطابقة تماماً سواء تم تخزينها من قبل العميل أو نقطة النهاية.

تحليل بروتوكول MySQL

لإيجاد جذر المشكلة، تعمق الفريق في دراسة بروتوكول MySQL للعميل والخادم. يصف البروتوكول كيفية تواصل العميل مع الخادم، وهو أمر معقد في سياق تجميع الاتصالات حيث يتصرف مكوّنان كعملاء ومكوّنان كخوادم. يبدأ البروتوكول بمرحلة الاتصال (Connection Phase) للاتفاق على طرق المصادقة والقدرات، ثم ينتقل إلى مرحلة الأوامر (Command Phase) لإرسال أوامر SQL. يتم تبادل القدرات (Capabilities) لضمان التوافق مع الإصدارات السابقة، وأي عدم توافق في استخدام هذه الميزات قد يؤدي إلى انحراف في البروتوكول (Protocol Desync) وفشل في تفسير البيانات.