MySQL 8.0 EOL في أبريل 2026: روتين الترقية لـ 8.4 LTS بدون downtime

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

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

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