لو عندك MySQL 8.0 في production الشهر ده، عندك أيام قليلة قبل ما الدعم الرسمي من Oracle يقف نهائيًا. المقال ده هيديك قرار واضح: إمتى تهاجر لـ 8.4 LTS، وإمتى توقف عند 8.0.46، وإمتى فعلاً تفكر في fork زي Percona أو MariaDB.

MySQL 8.0 EOL في أبريل 2026: قرارك قبل 8.0.46 النهائية

المشكلة باختصار

Oracle حدّدت إن MySQL 8.0 هيوصل End of Life في أبريل 2026 بإصدار 8.0.46 كآخر release رسمي. بعد التاريخ ده، مفيش security patches ولا bug fixes ولا دعم رسمي من Oracle. سواء شغّال على HeatWave أو On-Prem أو managed service زي RDS وCloud SQL، الضغط مش نظري. الترقية لـ 8.4 LTS لازم تكون على روديك Q2 2026.

الافتراض هنا إن عندك واحد أو أكثر من: تطبيق PHP/Node/Python بيكلّم MySQL 8.0 مباشرة، replication setup، أو managed DB على AWS/GCP/Azure.

ليه 8.4 LTS مش مجرد upgrade عادي

Oracle بتسوّق 8.4 كترقية سلسة. الكلام ده صحيح بنسبة 80% تقريبًا، لكن الـ 20% الباقية هي اللي بتكسر production في منتصف الليل.

أكبر نقطة كسر: الـ mysql_native_password plugin. في 8.0 كان shipped ومُفعّل افتراضيًا. في 8.4 بقى معطّل. أي connection جاي من client قديم مش بيدعم caching_sha2_password هيفشل برسالة "Authentication method unknown to the client" بدون ما يوضّح السبب الحقيقي.

نقاط كسر تانية بتظهر في production:

• SSL/TLS certificates موقّعة بـ SHA-1 مرفوضة — أي cert قديم لازم يتجدّد بـ SHA-256.
• group replication بياخد defaults مختلفة لـ group_replication_consistency (BEFORE_ON_PRIMARY_FAILOVER).
• أوامر mysql_upgrade القديمة اتشالت من 8.0.16 أصلاً، ولكن في 8.4 أي سكربت أتمتة لسه بيستدعيها هيفشل.
• partitioning على engines غير InnoDB (زي MyISAM partitioned tables) اتشال — الجدول بيرفض الإقلاع.
• الـ query cache (كان شبه ميت في 8.0) اختفى خالص، أي تطبيق لسه معتمد على SQL_CACHE hints هيلاقي errors.

شرح سريع قبل ما نكمل: إيه يعني caching_sha2_password؟

تخيل إنك ساكن في عمارة، والإدارة قرّرت تغيّر قفل البوابة من مفتاح عادي لبطاقة RFID. جيرانك اللي عندهم البطاقات بيدخلوا عادي. أي حد لسه ماسك مفتاح قديم بيقف قدام الباب مش فاهم السبب.

نفس الكلام في MySQL. الـ authentication plugin هو الطريقة اللي بيها الـ client بيثبت للـ server إنه هو فعلاً اليوزر اللي بيدّعيه. mysql_native_password هو الطريقة القديمة (مبنية على SHA-1)، وcaching_sha2_password هي الجديدة (مبنية على SHA-256 + caching). الجديدة أقوى أمنيًا وأسرع لأنها بتخزن الـ hash في memory بعد أول authentication ناجح.

تقنيًا: الـ server في 8.4 مش هيحاول يتفاهم مع client بيطلب الطريقة القديمة بشكل افتراضي. لازم كل الـ drivers (mysql-connector-python ≥ 8.0.11، mysql2 Node.js ≥ 2.0، JDBC ≥ 8.0.11) تكون مُحدَّثة، أو كل الـ users يتحوّلوا يدويًا للـ plugin الجديد.

روتين الترقية: خطوة بخطوة

الترتيب ده مش اختياري. كل خطوة بتحمي اللي بعدها.

1. audit الـ users — شوف مين لسه على الـ plugin القديم:
   SQLنسخ الكود

   SELECT user, host, plugin 
   FROM mysql.user 
   WHERE plugin = 'mysql_native_password';

   لو رجع أي صف، عندك شغل قبل الترقية.
2. migrate authentication — حوّل كل يوزر:
   SQLنسخ الكود

   ALTER USER 'app_user'@'%' 
   IDENTIFIED WITH caching_sha2_password 
   BY 'StrongNewPassword_2026!';

   مهم: حدّث كل application config (env vars، secrets manager) قبل ما تعمل reload.
3. check clients — كل driver بتستخدمه لازم يبقى ≥ النسخة اللي بتدعم الـ plugin الجديد. اللي بيتعرض كتير في الترقيات الفاشلة: legacy PHP apps على mysqli pre-7.2.
4. trial upgrade على staging — استخدم الأداة الرسمية:
   Bashنسخ الكود

   mysqlsh -- util check-for-server-upgrade \
     'root@localhost:3306' \
     --target-version=8.4.0 \
     --output-format=JSON > upgrade-report.json

   الأداة بتطلعلك list بكل incompatibility محتمل قبل ما تبدأ.
5. replication-first — لو عندك replica، رقّيها الأول وخليها تشتغل يومين. replication من 8.0 primary لـ 8.4 replica مدعوم رسميًا، العكس لا.
6. snapshot + rollback plan — قبل ما تترقّي الـ primary، خُد snapshot للـ data directory:
   Bashنسخ الكود

   systemctl stop mysql
   tar -czf /backup/mysql-8.0.46-$(date +%F).tar.gz /var/lib/mysql
   systemctl start mysql

   MySQL ما بيدعمش downgrade من 8.4 لـ 8.0. الـ snapshot ده هو خطة الرجوع الوحيدة.
7. smoke test بعد الترقية — شغّل أهم 10 queries عندك وقس الزمن. لو في أي query بقى أبطأ من قبل بنسبة > 20%، EXPLAIN ANALYZE قبل ما تفتح traffic.

trade-offs: ليه مش الكل لازم يهاجر الأسبوع ده

الترقية ليها تكلفة حقيقية. لو شغّال على workload بسيط (≤ 50K queries/day) والـ server وراء VPC داخلية، الـ risk من تأخير شهرين محدود. المقابل: downtime window لازم تحجزه مع الـ product team، regression testing على الـ queries المعقدة، وتحديث كل client libraries في الـ services الـ microservices.

المكسب من 8.4 ملموس: تحسينات InnoDB بحوالي 10–15% على workloads read/write المكثفة، دعم Premier حتى 2029 وExtended حتى 2032، وsecurity patches مستمرة. لو التطبيق تحت compliance زي PCI-DSS أو HIPAA، غياب الـ security patches بعد أبريل 2026 مش bug — ده violation.

رقم بيفرق في الحسبة: حسب إحصائيات Percona لعملائها، حوالي 60% من الإنستنسز لسه على 8.0.x في مارس 2026. لو موقعك بين الـ 40% المتأخرين بعد يوليو، صيد الـ attackers ليك بيبقى أسهل لأن الـ known CVEs مش هتتقفل.

متى لا تستخدم هذه الطريقة

في ثلاث حالات، الهجرة لـ 8.4 مش الخيار الأذكى:

• عندك تطبيق legacy على PHP 5.6 أو Python 2.7 ومش هتقدر تحدّث الـ driver — الـ caching_sha2_password مش مدعوم ومفيش workaround آمن.
• بتستخدم MyISAM partitioned tables كـ core feature ومش عندك وقت لتحويلهم لـ InnoDB قبل أبريل.
• managed DB على cloud provider لسه ما طرحش 8.4 بشكل GA (AWS RDS دخلها في Q1 2026، Azure Database for MySQL Flexible Server لسه في preview وقت كتابة المقال).

في الحالات دي، الحل البراغماتي: Percona Server for MySQL 8.0 (دعم مدفوع مستمر لـ 3 سنين إضافية) أو MariaDB 11.x كـ fallback. بس احسب ساعات الهجرة لأي fork مقابل ساعات الترقية المباشرة لـ 8.4.

البدائل المدعومة: Percona, MariaDB, Aurora

Percona Server for MySQL 8.0 بيستمر بدعم مدفوع لمدة 3 سنين إضافية. الميزة: drop-in replacement، صفر تغيير في الـ application. العيب: subscription ecosystem مختلف عن Oracle الرسمي.

MariaDB bifurcated عن MySQL من 5.5، والتوافق مش 100%. بعض الـ JSON functions بتتصرف مختلف، والـ INVISIBLE columns بتسبّب سلوك غير متوقع في ORMs زي Prisma وDrizzle. لو تطبيقك معتمد على MySQL-specific features (مثل JSON_TABLE أو CHECK TABLE الحديث)، الهجرة لـ MariaDB ممكن تاخد أسابيع.

Amazon Aurora MySQL 3 (متوافق مع 8.0) لسه مدعوم من AWS حتى أواخر 2027، والـ migration path لـ Aurora 4 (متوافق مع 8.4) موثّق رسميًا. لو أنت على Aurora، الضغط الزمني عليك أقل، بس مش معناه تأجّل بدون تخطيط.

الخطوة التالية

افتح terminal دلوقتي وشغّل الـ audit query اللي فوق. لو رجع صف واحد أو أكتر، افتح Jira ticket اسمه "MySQL 8.4 migration — auth plugin" قبل ما تقفل اللابتوب النهارده. لو صفر صفوف، جدوَل trial upgrade على staging في آخر الأسبوع ده، لأن 30 أبريل أقرب مما يبدو.

المصادر

• Oracle Blog — End-Of-Life of HeatWave MySQL 8.0 version
• endoflife.date — MySQL lifecycle timeline
• Percona — MySQL 8.0 End of Life Date: What Happens Next?
• The Register — The clock's ticking for MySQL 8.0
• MySQL 8.0 Official Release Notes
• MySQL Product Support EOL Announcements