نهاية الدعم القياسي لـ MySQL 8.0: ما الذي تغيّر في 1 أغسطس 2026؟
في 31 يوليو 2026 وصلت النسخة الرئيسية MySQL 8.0 على خدمة Amazon RDS إلى نهاية الدعم القياسي (End of Standard Support). ومنذ 1 أغسطس 2026، تُسجّل AWS تلقائيًا كل قاعدة بيانات ما زالت تعمل على هذه النسخة في برنامج «الدعم الممتد» (RDS Extended Support) المدفوع، دون أي إجراء من العميل ودون موافقة صريحة منه. وتبدأ التكلفة الإضافية في اليوم التالي لتاريخ انتهاء الدعم القياسي، وتستمر ما دامت القاعدة تعمل على نسخة متجاوزة للدعم.
والدعم الممتد ليس تكلفة إضافية عبثية، بل شبكة أمان: تواصل AWS خلاله توفير تصحيحات الأمان الحرجة وإصلاحات الأخطاء لنسخة لم تعد مدعومة من المجتمع. لكنه محدود المدة؛ فهو يمتد حتى ثلاث سنوات كحدٍّ أقصى بعد نهاية الدعم القياسي، أي حتى 31 يوليو 2029 بالنسبة لـ MySQL 8.0، وبعدها لا يبقى خيار سوى الترقية.
أما آلية الحساب فهي مصدر المفاجأة: التكلفة الإضافية تُحسب لكل vCPU في الساعة، لا كنسبة من تكلفة المثيل. في منطقة us-east-1 تبلغ 0.100 دولار لكل vCPU في الساعة خلال السنتين الأولى والثانية، ثم تتضاعف إلى 0.200 دولار في السنة الثالثة ابتداءً من 1 أغسطس 2028. والأهم أنها تُطبَّق كذلك على المثيل الاحتياطي (Standby) في نشر Multi-AZ، أي تتضاعف فعليًا.
حالة عملية من فاتورة حقيقية: ارتفاع 353% في أحد عشر يومًا
لتوضيح حجم الأثر، هذه أرقام فاتورة حقيقية لبيئة صغيرة: بلغت تكلفة RDS في يوليو 2026 نحو 14.96 دولارًا. وفي الأيام الأحد عشر الأولى من أغسطس وحدها وصلت إلى 67.86 دولارًا، أي بزيادة 52.90 دولارًا وبنسبة 353.7%. وبمعدل الإنفاق اليومي نفسه، يتجه الشهر إلى نحو 169 دولارًا.
وتفصيل الفاتورة بحسب نوع الاستخدام يكشف السبب بلا لبس: بند «Extended Support: MySQL 8.0 (Year 1–2)» استهلك 54.72 دولارًا أي 80.6% من الإجمالي، مقابل 12.28 دولارًا للمثيل المحجوز db.t4g.micro (18.1%)، و0.85 دولارًا لتخزين gp3، وأقل من سنتَين للنسخ الاحتياطي. بعبارة أخرى: التكلفة الإضافية للدعم الممتد وحدها تجاوزت تكلفة الخادم نفسه بأكثر من ثلاثة عشر ضعفًا.
وبحساب المعدل اليومي (نحو 5.47 دولارًا) على مثيل بـ vCPU اثنين يعمل 24 ساعة، يكون السعر الفعلي نحو 0.114 دولارًا لكل vCPU في الساعة — أعلى قليلًا من سعر us-east-1، وهو تذكير بأن التكلفة الإضافية تختلف من منطقة إلى أخرى، ويجب التحقق من صفحة تسعير RDS للمنطقة التي تعمل فيها.
كيف توقف التكلفة الإضافية؟ ثلاثة مسارات وتحذير مهم
المسار الأول والموصى به هو الترقية إلى نسخة رئيسية مدعومة، وأقربها MySQL 8.4. والخبر الجيد أن التكلفة الإضافية تتوقف تلقائيًا يوم اكتمال الترقية، وتُحاسَب بالتناسب على الأيام التي عملت فيها القاعدة على النسخة القديمة فقط؛ فكل يوم تأخير مال يُدفع بلا مقابل. لكن انتبه: 8.4 نسخة رئيسية جديدة لا تحديث ثانوي، وتتطلب اختبار توافق جديًا. وتوصي AWS بتشغيل فحوص ما قبل الترقية (prechecks)، واستخدام نشر Blue/Green لتقليل زمن التوقف، وإعداد خطة تراجع (rollback) قبل البدء.
المسار الثاني هو حذف القاعدة إن لم تكن مطلوبة أصلًا، وهو الحل الأمثل للبيئات المنسية بعد أخذ لقطة نهائية والتحقق منها. أما المسار الثالث فهو تعطيل التسجيل عبر المعامل EngineLifecycleSupport بالقيمة open-source-rds-extended-support-disabled من واجهة الأوامر أو الـ API. وهنا التحذير الأهم: هذا الخيار ليس طريقًا للحصول على نسخة قديمة مجانًا؛ فإذا كانت القاعدة قد تجاوزت تاريخ نهاية الدعم القياسي، فإن تعطيل التسجيل يؤدي إلى ترقيتها تلقائيًا إلى النسخة الرئيسية المدعومة التالية. استخدمه فقط وأنت مدرك أن الترقية ستحدث دون جدولة منك.
وأخيرًا، ضع هذا الدرس في خطة أطول أمدًا: التكلفة الإضافية تعود إذا دخلت نسختك الجديدة الدعم الممتد لاحقًا، وهو ما يجعل متابعة تقويم إصدارات RDS جزءًا من انضباط FinOps لا مهمة موسمية. والأمر لا يخص MySQL وحده؛ فالدعم الممتد لـ Aurora MySQL النسخة 2 — التي انتهى دعمها القياسي في 31 أكتوبر 2024 — ينتهي في فبراير 2027. ضع تواريخ نهاية الدعم في تقويم الفريق، واربطها بتنبيه في AWS Budgets، حتى لا تكون الفاتورة هي من يبلّغك بالخبر.
كيف تتأكد أن فاتورتك متأثرة؟ خطوات سريعة
لا تحتاج إلى أدوات خاصة لتعرف إن كنت تدفع هذه التكلفة أم لا. افتح Cost Explorer في حسابك، واختر خدمة Amazon RDS، ثم اعرض البيانات بحسب «نوع الاستخدام» (Usage Type) بتفصيل يومي لآخر عشرة أيام. إن ظهر بند يبدأ بعبارة Extended Support فأنت مسجَّل في البرنامج، وسيظهر أمامك مقدار ما تدفعه يوميًا بوضوح.
ونصيحة أخيرة قد توفّر عليك الكثير: افحص جميع مناطق حسابك، لا المنطقة التي تعمل فيها عادة. أكثر الحالات تكلفةً هي قواعد بيانات قديمة تُركت تعمل في منطقة لا يزورها أحد، فتستمر في تحصيل التكلفة شهرًا بعد شهر دون أن يلاحظها أحد. وبعد أن تحدّد القواعد المتأثرة، ابدأ بترقية الأكثر تكلفة أولًا.
