هجرة ‏MySQL 8.0 إلى 8.4 LTS على خادم VPS: دليل شامل

لماذا تهاجر الآن: انتهاء الدعم والتعرض للثغرات

التغييرات الجذرية التي يجب معرفتها قبل الترقية

• تعطيل ‏mysql_native_password‏: مكوّن المصادقة هذا، المُهمل منذ ‏MySQL 8.0.34، لم يعد يُحمَّل افتراضيًا في ‏MySQL 8.4 (ويُحذف في 9.0). يمكن إعادة تفعيله مؤقتًا بـ‏mysql_native_password=ON‏ في قسم ‏[mysqld]‏ ريثما تُرحَّل الحسابات. أي حساب مستخدم يعتمد على هذا المكوّن سيفشل في الاتصال فوراً بعد الترقية. تطبيقات ‏PHP الأقدم من 7.4، و‏WordPress دون تهيئة ‏PDO صحيحة، وعملاء ‏JDBC القديمة هي الحالات الأكثر شيوعاً.
• تغيير المعامل ‏authentication_policy‏: المتغير ‏default_authentication_plugin‏، المُهمل منذ 8.0.27، محذوف في 8.4: أي سطر متبقٍّ منه في ‏my.cnf‏ يمنع الخادم من البدء. يحل محله ‏authentication_policy‏، وقيمته الافتراضية ‏*,,‏ تستخدم أصلًا ‏caching_sha2_password‏ للعامل الأول. يجب استبداله بـ‏authentication_policy‏.
• خيارات خادم محذوفة: ‏expire_logs_days‏ (يحل محله ‏binlog_expire_logs_seconds‏)، و‏--skip-host-cache‏ (يحل محله ‏host_cache_size = 0‏)، و‏--ssl‏ و‏--admin-ssl‏ (يحل محلهما ‏--tls-version‏ و‏--admin-tls-version‏)، و‏binlog_transaction_dependency_tracking‏ و‏avoid_temporal_upgrade‏ و‏show_old_temporals‏ لم تعد موجودة في 8.4: تعيينها أثناء التشغيل أو في ‏my.cnf‏ ينتج خطأ. تحقق من ملفات الإعداد والسكريبتات.
• أعمدة ‏JSON‏: كما في أي ترقية لإصدار رئيسي، يجب إعادة تشغيل الاستعلامات التي تعتمد على ‏JSON_TABLE()‏ و‏JSON_VALUE()‏ أو على مسارات ‏JSON‏ معقدة قبل التبديل. تحقق من الجداول التي تحتوي على أعمدة ‏JSON‏ كبيرة في بيئة اختبار أولاً.
• مجموعة الأحرف والترتيب: تبقى ‏utf8mb4‏ و‏utf8mb4_0900_ai_ci‏ افتراضيتين، أما مجموعة ‏utf8mb3‏ (و‏utf8‏ اسم مستعار لها) فهي مُهملة: تبقى مقبولة طوال سلسلة 8.4، لكن ‏Oracle تعلن حذفها في إصدار رئيسي مقبل. يُستحسن التخطيط للهجرة إلى ‏utf8mb4‏ لقواعد البيانات القديمة المنشأة تحت ‏MySQL 5.7.
• متغيرات النظام المُزالة أو المُعاد تسميتها: حُذفت في 8.4 عدة خيارات نسخ متطابق كانت مُهملة في 8.0 — خاصة ‏master_info_repository‏ و‏relay_log_info_repository‏ (لم تبقَ إلا جداول البيانات الوصفية المقاومة للأعطال)، و‏slave_rows_search_algorithms‏ و‏log_bin_use_v1_events‏؛ أما متغيرات ‏slave_*‏ المتبقية فمُهملة لصالح ‏replica_*‏، ومتغيرات ‏query_cache_*‏ اختفت منذ 8.0 مع ذاكرة الاستعلامات المؤقتة. تُنبّه أداة ‏Upgrade Checker‏ في ‏MySQL Shell‏ (‏util.checkForServerUpgrade()‏) إلى هذه النقاط قبل التبديل.
• النسخ المتطابق: أسماء المتغيرات المرتبطة بالنسخ المتطابق تحولت نهائياً إلى مصطلح ‏source‏/‏replica‏. التعليمات القديمة محذوفة في 8.4: أي سكريبت يستدعي ‏SHOW SLAVE STATUS‏ يجب تحديثه إلى ‏SHOW REPLICA STATUS‏، وكذلك ‏START SLAVE‏ ← ‏START REPLICA‏ و‏CHANGE MASTER TO‏ ← ‏CHANGE REPLICATION SOURCE TO‏ و‏SHOW MASTER STATUS‏ ← ‏SHOW BINARY LOG STATUS‏.

المتطلبات الأساسية قبل البدء

• نسخة احتياطية كاملة ومُتحقق منها: نفّذ ‏mysqldump --all-databases --single-transaction --routines --events > backup_pre_migration.sql‏ وتحقق أن الملف قابل للقراءة. نسخة احتياطية غير مُتحقق منها ليست نسخة احتياطية.
• الإصدار الحالي ومحركات الجداول: نفّذ ‏SELECT VERSION();‏ وأدرج الجداول غير المستندة إلى ‏InnoDB‏ من ‏information_schema.tables‏. يجب تقييم أي جدول ‏MyISAM‏ أو ‏MEMORY‏ قبل الترقية.
• توافق التطبيق: حدّد مكوّن المصادقة لكل حساب بـ‏SELECT user, host, plugin FROM mysql.user;‏. أي مستخدم على ‏mysql_native_password‏ يجب ترحيله إلى ‏caching_sha2_password‏.
• المساحة المتاحة على القرص: تشغل النسخة الاحتياطية وترقية قاموس البيانات مساحة على قرص الخادم. تحقق من وجود 20% على الأقل من المساحة الحرة على قسم ‏/var‏.

إجراء هجرة ‏MySQL 8.0 → 8.4 LTS على خادم VPS

1. 01

   نسخة احتياطية كاملة مع التحقق

   نفّذ ‏mysqldump --all-databases --single-transaction --routines --events --triggers > /root/backup_mysql80_$(date +%Y%m%d).sql‏. تحقق من نهاية الملف بـ‏tail -5 /root/backup_mysql80_*.sql‏: يجب أن يكون آخر سطر ‏-- Dump completed on …‏. احفظ الملف خارج الخادم قبل المتابعة.

2. 02

   مراجعة الحسابات ومكوّنات المصادقة

   نفّذ ‏SELECT user, host, plugin FROM mysql.user ORDER BY plugin;‏. لكل مستخدم على ‏mysql_native_password‏، نفّذ ‏ALTER USER 'اسم'@'مضيف' IDENTIFIED WITH caching_sha2_password BY 'كلمة_مرور';‏. حدّث سلسلة الاتصال لكل تطبيق متأثر قبل الترقية.

3. 03

   التحقق من المتغيرات المُهملة في my.cnf

   افتح ‏/etc/mysql/mysql.conf.d/mysqld.cnf‏ وأزل أو استبدل: ‏default_authentication_plugin‏ بـ‏authentication_policy = caching_sha2_password‏، و‏expire_logs_days‏ بـ‏binlog_expire_logs_seconds‏، و‏skip-host-cache‏ بـ‏host_cache_size = 0‏، و‏slave_*‏ بـ‏replica_*‏، وأزل ‏master_info_repository‏ و‏relay_log_info_repository‏. أي متغير غير معروف يمنع تشغيل ‏MySQL 8.4.

4. 04

   إيقاف الخدمة وأخذ لقطة

   على خادم ‏Proxmox‏ أو ‏KVM‏، خذ لقطة قبل تعديل الحزم عبر لوحة التحكم أو ‏API‏ لمزود الاستضافة. ثم: ‏systemctl stop mysql‏ وتحقق من التوقف بـ‏systemctl status mysql‏.

5. 05

   إضافة مستودع MySQL 8.4 وتحديث الحزم

   على ‏Debian 12 / Ubuntu 22.04‏: نزّل حزمة إعداد مستودع ‏MySQL‏ من ‏dev.mysql.com/downloads/repo/apt/‏، ثبّتها بـ‏dpkg -i mysql-apt-config_*.deb‏، اختر ‏MySQL 8.4 LTS‏ من القائمة، ثم نفّذ ‏apt-get update && apt-get install mysql-server‏.

6. 06

   ترقية جداول النظام

   عند أول تشغيل لـ‏MySQL 8.4‏، يُحدّث المحرك جداول النظام تلقائياً. تحقق من السجلات: ‏journalctl -u mysql -n 50 | grep -i 'upgrade\|error'‏. إذا لم تتم الترقية التلقائية، فلا تبحث عن ‏mysql_upgrade‏: الأداة محذوفة في 8.4. أعد تشغيل الخادم مرة واحدة بالخيار ‏--upgrade=FORCE‏ (مثلًا ‏upgrade = FORCE‏ في قسم ‏[mysqld]‏، ثم احذفه بعد ذلك)‏.

7. 07

   التحقق بعد الترقية

   اتصل وتحقق من الإصدار: ‏SELECT VERSION();‏ يجب أن يُرجع ‏8.4.x‏. ثم نفّذ ‏mysqlcheck --all-databases --auto-repair --user=root --password‏ للكشف عن أي تلف في الجداول. راجع سجل الأخطاء ‏/var/log/mysql/error.log‏.

8. 08

   اختبار وظيفي للتطبيق

   أعد تشغيل التطبيق وتحقق من النقاط الحساسة: الاتصال بقاعدة البيانات، مصادقة المستخدمين، استعلامات أعمدة ‏JSON‏، الإجراءات المخزنة. الحساب الذي بقي على ‏mysql_native_password‏ دون ترحيل يفشل بالخطأ ‏ERROR 1045 (28000): Access denied‏ ويترك أثرًا في سجل الخادم؛ أما الخطأ ‏The server requested authentication method unknown to the client‏ فيدل على عميل أقدم من أن يدعم ‏caching_sha2_password‏ (‏PHP‏ أقدم من 7.4 مثلًا).

9. 09

   التنظيف وتفعيل المراقبة

   احذف ملف النسخة الاحتياطية المحلية بعد تأكيد النسخة الخارجية. تحقق من أداة المراقبة: بعض أسماء المقاييس تغيرت بين 8.0 و8.4. جدوِل فحص سجل الأخطاء بعد 24 و72 ساعة من الهجرة.

MariaDB 11.x: متى تُفضّل هذا البديل

MySQL 8.0 مقابل MySQL 8.4 LTS مقابل MariaDB 11.x

مرّر الجدول أفقيًا

استكشاف الأخطاء: الأخطاء الشائعة بعد الهجرة

• ERROR 1045 (28000): Access denied‏ بعد الترقية: تحقق من مكوّن المصادقة بـ‏SELECT plugin FROM mysql.user WHERE user='اسم';‏. إذا كان لا يزال ‏mysql_native_password‏، فهذا الحساب لم يُرحَّل (الترقية لا تغيّر مكوّن أي حساب)، نفّذ ‏ALTER USER … IDENTIFIED WITH caching_sha2_password BY '…';‏.
• Unknown system variable 'default_authentication_plugin'‏: هذا المتغير لم يعد مُعترفاً به في 8.4. أزله من ‏my.cnf‏ واستبدله بـ‏authentication_policy = caching_sha2_password‏.
• ‏MySQL لا يبدأ بعد الترقية: راجع ‏/var/log/mysql/error.log‏. الأكثر شيوعاً هو متغير نظام غير معروف في ‏my.cnf‏. علّق المتغيرات واحداً تلو الآخر حتى تحدد المصدر.
• تدهور الأداء في استعلامات الفرز: قد يختار مُحسِّن الاستعلامات في ‏MySQL 8.4 خطط تنفيذ مختلفة عن 8.0 في بعض الاستعلامات. نفّذ ‏EXPLAIN‏ على الاستعلامات البطيئة. ‏ANALYZE TABLE اسم_الجدول;‏ يُجبر على تحديث الإحصائيات.
• سكريبتات مراقبة تفشل بعد الترقية: العدادات ‏Com_slave_*‏ و‏Com_show_master_status‏ محذوفة في 8.4 لصالح ‏Com_replica_*‏ و‏Com_show_binary_log_status‏، وتعليمات ‏SLAVE‏/‏MASTER‏ لم تعد موجودة. حدّث استعلامات المراقبة وفق الأسماء الموثّقة في ‏dev.mysql.com/doc/refman/8.4/en/performance-schema.html‏.

الانتقال إلى MySQL 8.4 LTS: ما يجب تذكره