خادم MySQL قد ذهب بعيدا
كان WordPress اتصال قاعدة بيانات العمل وفقدته في منتصف الطلب. نادرا ما يكون الاستعلام على خطأ ؛ الاتصال هو.
WordPress database error MySQL server has gone away for query …
ثلاثة أشياء تسقط اتصالًا مباشرًا: استعلام أكبر من max_allowed_packet ، فترة خمول أطول من wait_timeout ، أو إعادة تشغيل MySQL. تحقق مما إذا كان الخادم قد استمر لفترة أطول من الموقع ، لأن وقت التشغيل المنخفض يجيب على السؤال على الفور ولا يحتاج الآخران إلى اختبار.
الأسباب الأرجح أولًا.
افحص القائمة بالترتيب. يتيح لك كل فحص تأكيد السبب أو استبعاده قبل تغيير أي شيء، لأن الحلول تختلف والتخمين يكلّف أكثر من تنفيذ أمر للتحقق.
| السبب | كيفية التحقق | الإصلاح |
|---|---|---|
| استعلام أكبر من max_allowed_packet | الفشل يتبع استيراد كبير، وظيفة مع قيمة ميتا تسلسلية كبيرة جدا، أو استعادة النسخ الاحتياطي - وفشل في نفس النقطة في كل مرة بدلا من عشوائيا. | رفع max_allowed_packet على الخادم لتجاوز أكبر عبارة مفردة بشكل مريح. هذا سقف من جانب الخادم ، لذلك لا يقوم إعداد العميل بتحريكه. |
| تم تعطيل الاتصال في الماضي wait_timeout | تفشل عمليات المشرف الطويلة بالقرب من النهاية بينما لا يحدث تحميل الصفحات العادية أبدًا. تجاوزت الفجوة بين استعلامات اثنين المهلة وأغلقت MySQL المقبس. | رفع wait_timeout ، أو تقسيم العمل إلى دفعات أقصر حتى لا يوجد اتصال واحد يجلس خاملاً لفترة طويلة. الخلط هو أكثر دواما من الاثنين. |
| تم إعادة تشغيل MySQL أو قتل | وقت تشغيل الخادم أقصر من وقت تشغيل الموقع ، أو سجل الخطأ يسجل إيقاف التشغيل. عمليات القتل خارج الذاكرة هي السبب المعتاد على الأجهزة الصغيرة. | ابحث عن سبب توقفه قبل إعادة تشغيله. قاعدة البيانات التي قتلت مرة واحدة للذاكرة سيتم قتلها مرة أخرى تحت نفس الحمل. |
| قاعدة البيانات ترفض العمل الجديد | الأخطاء العنقودية تحت الحمل وواضحة عند انخفاض حركة المرور، وقائمة العملية قريبة من max_connections. | تقليل ما هو عقد اتصالات بدلا من رفع الحد. الاستعلامات طويلة الأمد تحتل فتحات هي السبب ؛ سقف أعلى فقط يؤخر نفس الفشل. |
الإصلاح خطوة بخطوة.
تفترض الأوامر توفر WP-CLI والوصول إلى سطر الأوامر. إن لم يتوفرا، تشرح كل خطوة الإجراء كي تنفذه من لوحة التحكم أو عبر SFTP.
اسأل عن المدة التي كان الخادم يعمل فيها
يعني وقت تشغيل أقصر من آخر مرة عمل فيها الموقع إعادة تشغيل قاعدة البيانات ، ولا يحتاج أي شيء آخر في هذه القائمة إلى التحقق.
mysqladmin status mysql -e "SHOW GLOBAL STATUS LIKE 'Uptime';"
اقرأ الحدين اللذين يهمان
حجم الحزمة وحساب المهلة الخمول لمعظم ما تبقى بمجرد استبعاد إعادة التشغيل.
mysql -e "SHOW VARIABLES WHERE Variable_name IN ('max_allowed_packet','wait_timeout','interactive_timeout');"رفع سقف الحزمة إذا فشل الاستيراد
قم بتعيينه في تكوين الخادم بدلاً من كل جلسة ، بحيث ترثه استعادة تديرها أي أداة.
[mysqld] max_allowed_packet = 256M wait_timeout = 300
تحقق مما إذا كان قد قتل للذاكرة
يقوم سجل kernel بتسمية العملية التي اختارها. هذا هو السبب الأكثر شيوعًا على خادم صغير يعمل MySQL بجوار PHP.
dmesg -T | grep -i -E 'out of memory|killed process' | tail -n 20
أعد العملية في قطع أصغر
إذا كان العمل هو استيراد، الخلط يبقي كل بيان جيدا تحت السقف وكل اتصال مشغول.
wp db import dump.sql wp db check
ما تتولاه المنصة عنك.
قاعدة البيانات تعمل في حاوية خاصة بها مع بدل الذاكرة التي تنتمي إليها وحدها، لذلك عملية فب أن المسامير لا يمكن الحصول على MySQL قتل من قبل النواة - وضع الفشل وراء معظم هذه الأخطاء على جهاز مشترك واحد. يتم حجم قيم الحزمة والوقت المستقطع مقابل هذا البدل بدلا من تركها عند التوزيع الافتراضي الذي تتجاوزه استعادة كبيرة على الفور.
الأسئلة الشائعة.
هل بياناتي تالفة؟
لماذا فقط خلال الواردات والنسخ الاحتياطي؟
هل يجب علي فقط ضبط wait_timeout عالية جدا؟
كيف يختلف هذا عن "خطأ إنشاء اتصال قاعدة بيانات"؟
إن لم يكن هذا هو السبب.
قد تبدو هذه الأخطاء متشابهة في المتصفح.