دليل استكشاف الأخطاء وإصلاحها لحزمة ServBay MariaDB/MySQL

نظرة عامة

تُعد MariaDB وMySQL من أنظمة إدارة قواعد البيانات العلائقية المفتوحة المصدر الرائدة في الصناعة، وتستخدم على نطاق واسع في تطبيقات ويب وبيئات أعمال متنوعة. يدمج ServBay العديد من إصدارات حزم MariaDB/MySQL على macOS وWindows، ليمنح المطورين بيئة قواعد بيانات محلية سريعة وسهلة الاستخدام. رغم أن هذه الأنظمة مشهورة بالاستقرار، إلا أنه خلال التطوير والتشغيل قد تواجه مشاكل مثل عدم القدرة على البدء، فشل الاتصال، أو انخفاض الأداء.

يهدف هذا الدليل إلى مساعدة مستخدمي ServBay في تشخيص وحل المشكلات الشائعة لحزم MariaDB/MySQL. سنغطي المشاكل المعتادة، وخطوات التشخيص، والحلول المحددة، مع الإشارة بشكل خاص إلى المسارات والأوامر الخاصة ببيئة ServBay.

تنبيهات هامة:

• قبل إجراء أي عملية قد تُغيّر في البيانات أو الإعدادات، يجب نسخ قاعدة البيانات احتياطياً! يوفر ServBay ميزة النسخ الاحتياطي المدمجة ويُنصح بشدة باستخدامها بشكل دوري.
• أمثلة الأوامر والمسارات أدناه تستخدم أرقام إصدارات محددة (مثل 11.3 أو 11.5)؛ يرجى استبدالها برقم إصدار MariaDB/MySQL الفعلي المستخدم لديك في ServBay. يمكنك العثور على رقم الإصدار عبر واجهة التطبيق.
• في أمثلة الأوامر، العناصر مثل <username>، <database>، <your_backup.sql> هي رموز متغيرة؛ استبدلها بقيمك الفعلية.
• هذا الدليل يدعم أنظمة macOS وWindows، وستجد نماذج أوامر ومسارات مختصة بكل نظام في أماكنها الصحيحة.

خطوات التشخيص الأولية العامة

قبل الدخول في تفاصيل المشكلات، يوصى بالتحقق من النقاط التالية:

1. تحقق من حالة حزمة ServBay: افتح واجهة التطبيق الخاصة بـ ServBay وتأكد أن إصدار MariaDB/MySQL الذي تعمل عليه فعال ويظهر أنه "يعمل" حالياً. يمكنك أيضاً استخدام واجهة الأوامر:

   servbayctl status mariadb <version>
   # مثال للتحقق من حالة MariaDB 11.3:
   servbayctl status mariadb 11.3

2. راجع سجل تطبيق ServBay: في بعض الحالات يكتب ServBay أخطاء أثناء محاولة بدء أو إدارة الحزمة، تحقق من منطقة السجلات في التطبيق أو راجع ملف السجل الرئيسي لـ ServBay.

3. راجِع سجل أخطاء MariaDB/MySQL: خطوة أساسية لتحديد أسباب فشل البدء أو الأخطاء أثناء التنفيذ. غالباً ما تكون مسارات ملفات السجل كالتالي:

   macOS:

   /Applications/ServBay/logs/mariadb/<version>/<version>.err
   # مثال لعرض آخر 50 سطر من سجل أخطاء MariaDB 11.3:
   tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err

   Windows:

   C:\ServBay\logs\mariadb\<version>\<version>.err
   # مثال لعرض آخر 50 سطر من سجل الأخطاء:
   powershell "Get-Content -Path 'C:\ServBay\logs\mariadb\11.3\11.3.err' -Tail 50"

   اقرأ جيداً تفاصيل نهاية السجل، حيث غالباً تشير مباشرة إلى سبب المشكلة.

المشاكل الشائعة وحلولها

1. خطأ الاتصال: SQLSTATE[HY000] [2002] No such file or directory

يشير هذا الخطأ غالباً إلى أن العميل غير قادر على الاتصال بقاعدة بيانات MariaDB/MySQL عبر ملف Unix socket. في macOS، يُستخدم Unix socket للاتصالات المحلية وهو أسرع من TCP/IP. تظهر المشكلة عندما يحاول البرنامج أو أداة الأوامر استخدام المسار الخاطئ للـ socket أو عدم إيجاد الملف المطلوب.

الأسباب المحتملة والحلول:

• حزمة MariaDB/MySQL غير مُشغلة:
  • تحقق من الحالة عبر واجهة ServBay أو أمر servbayctl status mariadb <version>.
  • إذا كانت غير فعالة، حاول بدءها باستخدام: servbayctl start mariadb <version>، ثم راجع سجل الأخطاء (.err) لمعرفة التفاصيل.
• مسار ملف الـ socket غير صحيح (فقط في macOS/Linux):
  • تأكد أن الإعداد في ملف إعدادات السيرفر (my.cnf) يوافق مسار الـ socket المستخدم من قبل العميل.
  • macOS: تحقق من إعداد socket في /Applications/ServBay/etc/mariadb/<version>/my.cnf.
  • Windows: لا يستخدم الـ Unix socket وإنما منافذ TCP/IP أو الأنابيب المسماة.
  • macOS: تحقق من أن التطبيق أو الأداة تستخدم المسار الصحيح للـ socket. غالباً ما يكون مسار الـ socket الافتراضي في ServBay هو /Applications/ServBay/tmp/mysql.sock أو /tmp/mysql.sock حسب الإعداد والإصدار.
• مشكلة إعدادات ServBay الافتراضية:
  • انتقل إلى "الإعدادات" > "الخادم SQL الافتراضي" وتأكد من اختيار الإصدار الصحيح كإصدار افتراضي. بعض أدوات العميل (مثل أداة mysql بدون خيار -S أو -h) تحاول دائماً الاتصال بالإصدار الافتراضي.
• حاجز الصلاحيات:
  • macOS: يجب أن يملك مستخدم قاعدة البيانات صلاحية للكتابة على المسار الذي يوجد فيه ملف الـ socket. إذا عدلت صلاحيات الدليل /Applications/ServBay/tmp/ أو /tmp/ يدوياً قد يسبب ذلك المشكلة.
  • Windows: تأكد أن المستخدم الذي يشغل ServBay لديه صلاحية للاستماع على منافذ TCP/IP والأنابيب المسماة.

الحل البديل (التحويل لاتصال الشبكة):

• جرب الاتصال بـ IP المحلي 127.0.0.1 بدلاً من localhost، مما سيجبر العميل على استخدام TCP/IP:

  mysql -u <username> -p -h 127.0.0.1 -P 3306

2. خطأ الاتصال: مشاكل اتصال الشبكة (Connection refused, Can't connect to MySQL server)

هذه الأخطاء تدل عادة على فشل العميل في الاتصال بقاعدة البيانات عبر TCP/IP.

الأسباب والحلول المحتملة:

• حزمة MariaDB/MySQL غير مُشغلة: (تحقق مثل السابق ثم راجع سجل الأخطاء)

• احتلال المنفذ المطلوب:

  • تأكد أن المنفذ (عادة 3306) غير مشغول من برنامج آخر.

  macOS:

  lsof -i :3306
  # أو
  netstat -anv | grep LISTEN | grep 3306

  Windows:

  netstat -an | findstr :3306
  # أو بالبوارشيل
  Get-NetTCPConnection -LocalPort 3306

  إذا كان المنفذ مشغولاً، قم بإيقاف البرنامج الذي يشغله أو غير المنفذ في إعدادات MariaDB/MySQL ثم أعد تشغيل الحزمة.

  • macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
  • Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

• جدار الحماية يمنع الاتصال:

  macOS:

  • تحقق من إعدادات جدار الحماية في النظام.
  • يمكنك السماح مؤقتاً لعملية mysqld بالاتصال عبر جدار الحماية:

    # مثال، اضبط المسار حسب الحاجة
    sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/mariadb/<version>/bin/mysqld
    sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/mariadb/<version>/bin/mysqld

  Windows:

  • تحقق من إعدادات جدار حماية Windows Defender أو أي برامج جدار حماية أخرى.
  • أضف قاعدة لإتاحة المنفذ أو البرنامج:

    netsh advfirewall firewall add rule name="ServBay MariaDB" dir=in action=allow program="C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe"

• مشكلة إعدادات bind-address:

  • تحقق من قيمة bind-address في ملف my.cnf. إذا كانت 127.0.0.1 أو localhost فسيسمح فقط بالاتصالات المحلية. لتفعيل اتصالات من أجهزة أخرى، يجب تعيينها على 0.0.0.0 أو على عنوان IP آخر مع السماح من جدار الحماية.

• مشاكل تكوين الشبكة (localhost):

  • تحقق أن localhost يوجه فعلياً إلى 127.0.0.1 (IPv4) أو ::1 (IPv6).

  macOS:

  ping localhost
  cat /etc/hosts

  Windows:

  ping localhost
  type C:\Windows\System32\drivers\etc\hosts

  تأكد أن ملف hosts يضم تدوين localhost الصحيح. أوقف أي برامج بروكسي قد تعيق الاتصالات المحلية.

3. فشل بدء تشغيل حزمة MariaDB/MySQL

الأسباب والحلول المحتملة:

1. راجِع سجل الأخطاء (الأهم!): كما سبق، تحقق من السجل لمعرفة سبب الفشل.

   • macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
   • Windows: C:\ServBay\logs\mariadb\<version>\<version>.err

2. خطأ في ملف الإعدادات: قد يحتوي الملف على أخطاء صياغة أو مسارات غير صحيحة أو معاملات غير مقبولة.

   مسار ملف الإعدادات:

   • macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
   • Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

   تحقق من صحة الإعدادات:

   # macOS
   /Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config
   
   # Windows
   C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf --validate-config

3. المنفذ مشغول: (مثل السابق، استعمل lsof -i :<port> أو netstat)

4. انخفاض مساحة القرص: قد يكون دليل البيانات أو السجلات على قرص ممتلئ. تحتاج قواعد البيانات لمساحة كافية لتخزين البيانات والسجلات والملفات المؤقتة.

   المسارات:

   • macOS: دليل البيانات /Applications/ServBay/db/mariadb/<version>/، سجل الأخطاء /Applications/ServBay/logs/mariadb/<version>/
   • Windows: دليل البيانات C:\ServBay\db\mariadb\<version>\، سجل الأخطاء C:\ServBay\logs\mariadb\<version>\

5. صلاحيات التشغيل: قد لا يكون للمستخدم صلاحية لقراءة ملف الإعدادات أو الوصول إلى دليل البيانات أو السجلات. خدمات ServBay مُعدة بشكل مناسب، لكن التعديلات اليدوية قد تفسد ذلك.

   تحقق من صلاحيات macOS:

   ls -ld /Applications/ServBay/db/mariadb/<version>
   ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
   ls -ld /Applications/ServBay/logs/mariadb/<version>

   تأكد أن المستخدم النصيب (مثلاً _mysql) له صلاحية كافية.

   Windows: تحقق من خصائص الدليل والملفات عبر نظام التشغيل وكن واثقاً أن حساب ServBay لديه صلاحية القراءة/الكتابة.

6. تلف في ملفات البيانات: (راجع قسم "انهيار القاعدة أو تلف البيانات" أدناه) في حال كان هناك توقف غير طبيعي أو مشاكل سابقة.

بعد الحل:

• حاول إعادة تشغيل الحزمة: servbayctl restart mariadb <version>

4. مشاكل صلاحية المستخدم أو المصادقة

بعد الاتصال بالخادم، قد تواجه أخطاء المرتبطة بالمصادقة أو الصلاحيات، مثل Access denied.

الأسباب والحلول:

• اسم المستخدم أو كلمة المرور خطأ: تحقق من أنك تستخدم بيانات الدخول الصحيحة. يسمح ServBay بسهولة إعادة تعيين كلمة مرور root.
• حديد الموقع المسموح: قد يكون المستخدم محدد فقط للاتصال من localhost أو عنوان IP معين مثل 127.0.0.1. الإذن من '%' يسمح بالاتصال من أي مكان.
• نقص في الصلاحيات: قد لا يملك المستخدم صلاحية الدخول إلى قاعدة البيانات المطلوبة أو أداء العمليات (مثل SELECT, INSERT, UPDATE, DELETE, CREATE, DROP إلخ).
• فحص صلاحيات المستخدم:
  • سجل دخول بحساب ذي صلاحية (مثلاً root):

    mysql -u root -p

  • استخدم SQL لفحص صلاحيات المستخدم:

    SHOW GRANTS FOR '<username>'@'<hostname>';
    -- مثال لمستخدم webapp على localhost:
    SHOW GRANTS FOR 'webapp'@'localhost';
    -- لمستخدم admin من أي موقع:
    SHOW GRANTS FOR 'admin'@'%';

  • استخدم أوامر GRANT وREVOKE لتعديل الصلاحيات أو إنشاء مستخدم جديد مع صلاحيات لازمة.

5. مشاكل الأداء

ضعف أداء قاعدة البيانات يؤثر على سرعة التطبيق بالكامل.

الأسباب والحلول:

1. استعلامات بطيئة: قد يكون الاستعلام غير فعال أو يفتقد الفهارس أو خطة التنفيذ سيئة.

   • تفعيل سجل الاستعلامات البطيئة: في ملف my.cnf، فعل slow_query_log = 1 و long_query_time = 1 وحدد مسار الملف بـ slow_query_log_file.
   • استخدم EXPLAIN: ضع الكلمة EXPLAIN قبل الاستعلام لرؤية خطة التنفيذ:

     EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';

   • حسن الاستعلامات: حسب نتائج EXPLAIN، أعد كتابة الاستعلامات وتأكد من أن WHERE وJOIN يستخدمان الفهارس بشكل كفء.

2. نقص أو سوء تصميم الفهارس: قد تفتقد الأعمدة المهمة للفهارس.

   CREATE INDEX idx_column_name ON your_table_name(column_name);

   انتبه أن الفهارس تزيد من تكلفة الكتابة وحجم القرص.

3. إعدادات الكاش غير مناسبة: مثل innodb_buffer_pool_size، key_buffer_size إلخ في my.cnf.

   • عدل الإعدادات: حسب حجم ذاكرة الجهاز ووظيفة الخادم. ينصح لـ InnoDB ضبط innodb_buffer_pool_size على 50%-70% من الذاكرة.

     [mysqld]
     innodb_buffer_pool_size = 2G
     # إذا كان لديك جداول MyISAM كثيرة:
     # key_buffer_size = 256M

4. عنق الزجاجة في الموارد: مراقب استخدام CPU، الذاكرة أو القرص عبر أدوات النظام أو أوامر مثل top, htop.

6. انهيار قاعدة البيانات أو تلف البيانات

إذا لم تستطع بدء القاعدة أو إذا كانت تتوقف بشكل متكرر، فهذا غالباً بفعل تلف ملفات البيانات.

الأسباب والحلول:

1. سجل الأخطاء: الخطوة الأولى دائماً.
   • macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
   • Windows: C:\ServBay\logs\mariadb\<version>\<version>.err
2. خلل في العتاد: كفشل القرص أو أخطاء الذاكرة.
3. تعارض برمجي أو أخطاء في نظام MariaDB/MySQL نفسه.
4. إعدادات خاطئة في my.cnf.
5. إيقاف الخدمة قسرياً أو غير نظامي.

الحلول:

• جرب إعادة تشغيل آمن: عبر واجهة ServBay أو الأمر:

  servbayctl restart mariadb <version>

• استخدم mysqlcheck لفحص وإصلاح الجداول: مفيد لجداول MyISAM.

  mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
  # لجداول MyISAM فقط:
  # mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases

  تنبيه: الخيار الأخير يصلح فقط لـ MyISAM، أما InnoDB قد تحتاج إجراءات أكثر تقدماً.

• الاستعادة القسرية لـ InnoDB (innodb_force_recovery):

  1. نسخ دليل البيانات احتياطياً أولاً.
  2. عدل ملف إعدادات النسخة المتضررة وأضف innodb_force_recovery = N تحت قسم [mysqld]، وابدأ برقم 1 وصاعداً حتى 6.
  3. حاول تشغيل الحزمة.
  4. إذا اشتغلت حتى لو بالوضعية المحدودة، فوراً قم بتصدير كافة البيانات باستخدام mysqldump:

     mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql

     تحقق من نجاح وكفاية حجم ملف النسخة الاحتياطية.
  5. بعد النسخ، أوقف الخدمة ثم احذف أو علق سطر innodb_force_recovery=N.
  6. لإنشاء قاعدة جديدة واستعادة البيانات، قد تحتاج لحذف أو إعادة تسمية دليل البيانات القديم واستيراد الـ dump الجديد.

• استعادة من نسخة احتياطية: إذا تعذر الإصلاح، استخدم النسخة الاحتياطية الموجودة في /Applications/ServBay/backup/mariadb/<version>/.

  • مثال للاستعادة (يفترض إنشاء قاعدة البيانات مسبقاً):

    # إنشاء قاعدة بيانات الهدف
    # mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"
    
    # استيراد النسخة الاحتياطية
    mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

    ملاحظة: استبدل <version> وبيانات الاسم بما يناسب بيئتك.

7. مشاكل النسخ الاحتياطي والاستعادة

خلال استخدام ميزة النسخ الاحتياطية في ServBay أو عن طريق mysqldump يدوياً، قد تواجه بعض التحديات.

الأسباب والحلول:

• ملفات النسخ الاحتياطي تالفة أو ناقصة:

  • تحقق من حجم الملف (ls -lh /path/to/your_backup.sql) وتأكد من توافقه مع توقعاتك.
  • افتح الملف بالنص أو استخدم less لمراجعة المحتوى.
  • راجع سجل الأوامر أو سجل ServBay لأي أخطاء إذا ظهرت.

• خطأ في أمر الاستعادة:

  • قد يكون هناك خطأ في اسم المستخدم أو كلمة المرور أو اسم قاعدة البيانات.
  • المستخدم قد يفتقر للصلاحية اللازمة.
  • أخطاء في التوافق بين إصدارات MariaDB/MySQL أو اختلافات في صيغة SQL.

• مشاكل القيود الخارجية (foreign keys):

  • قبل الاستيراد يمكن تعطيل فحص القيود مؤقتاً ثم تفعيله بعد الانتهاء:

    -- قبل الاستيراد
    SET foreign_key_checks = 0;
    -- نفذ الاستيراد
    source /path/to/your_backup.sql;
    -- أو عبر الأوامر: mysql ... < /path/to/your_backup.sql
    
    -- بعد الاستيراد
    SET foreign_key_checks = 1;

    تنبيه: هذا فقط أثناء الاستيراد، احذر من احتمالية فقدان الاتساق.

• مشاكل في الترميز أو ترتيب الحروف: تأكد من توافق نوع الترميز بين ملف النسخ الاحتياطي وقاعدة البيانات المدخلة (مثلاً utf8mb4).

استعادة صحيحة عبر سطر الأوامر:

macOS:

# يفترض أن النسخة الاحتياطية تخص قاعدة بيانات معينة
# أنشئ قاعدة البيانات أولاً
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# الاستعادة
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

# إذا كانت النسخة لكل القواعد (--all-databases)
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Windows:

REM النسخة الاحتياطية تخص قاعدة بيانات
REM أنشئ قاعدة البيانات أولاً
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

REM الاستعادة
C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p <target_database_name> < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>

REM إذا كانت لكل القواعد
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>

ملاحظة: لا تنسَ تبديل رموز <version> وما يلزم حسب بيئتك. ميزة النسخ الاحتياطية في ServBay توفر ملفات يسهل استعادتها وخيارات مناسبة لذلك.

8. خطأ محدد: فشل بدء تشغيل InnoDB في MariaDB 11.5.1 (ib_logfile0 was not found أو Missing FILE_CHECKPOINT)

هذا خطأ معروف في إصدار MariaDB 11.5.1، يؤدي أحياناً إلى عدم قدرة محرك InnoDB على البدء أو الاسترجاع من ملفات السجل، وبالتالي فشل تشغيل القاعدة.

مظاهر الخطأ في سجل الأخطاء:

macOS (/Applications/ServBay/logs/mariadb/11.5/11.5.err):

[ERROR] InnoDB: File /Applications/ServBay/db/mariadb/11.5/ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

Windows (C:\ServBay\logs\mariadb\11.5\11.5.err):

[ERROR] InnoDB: File C:\ServBay\db\mariadb\11.5\ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

أو:

[ERROR] InnoDB: Missing FILE_CHECKPOINT(xxxxx) at xxxxx
[ERROR] InnoDB: Log scan aborted at LSN xxxxx
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

كل ذلك يدل أن InnoDB غير قادر على استخدام ملفات السجل وبالتالي فشل المحرك.

الحل (يشمل نقل البيانات؛ أجرِ نسخ احتياطية دائماً):

الحل الأكثر أماناً هو محاولة التشغيل القسري فقط لتصدير البيانات ثم نقلها لإصدار أكثر استقراراً.

1. جرب الاستعادة القسرية (إجراء خطير!):

   تعديل ملف الإعدادات:

   • macOS: /Applications/ServBay/etc/mariadb/11.5/my.cnf
   • Windows: C:\ServBay\etc\mariadb\11.5\my.cnf

   أضف تحت القسم [mysqld]: innodb_force_recovery = 6

   جرّب بدء الخدمة:

   servbayctl start mariadb 11.5

   إذا نجحت، فوراً صدّر البيانات:

   macOS:

   mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/11.5/my.cnf -u root -p --all-databases --routines --triggers --events > /Applications/ServBay/backup/mariadb/11.5/mariadb_11.5_emergency_backup.sql

   Windows:

   C:\ServBay\bin\mariadb\11.5\bin\mysqldump.exe --defaults-file=C:\ServBay\etc\mariadb\11.5\my.cnf -u root -p --all-databases --routines --triggers --events > C:\ServBay\backup\mariadb\11.5\mariadb_11.5_emergency_backup.sql

   تحقق أن حجم الملف وكفايته مناسب.

2. أوقف الخدمة وتعامل مع دليل البيانات المتعطل:

   • أوقف MariaDB 11.5: servbayctl stop mariadb 11.5
   • عدل ملف my.cnf واحذف أو علق سطر `innodb_force_recovery