it-swarm.asia

لماذا تستغرق قاعدة بيانات DROP وقتًا طويلاً؟ (MySQL)

تركيب CentOS جديد.

كنت أقوم باستيراد قاعدة بيانات كبيرة (ملف سعة 2 جيجابايت) ولدي مشكلة. يبدو أن عميل SSH فقد الاتصال وبدا أن الاستيراد تجمد. لقد استخدمت نافذة أخرى لتسجيل الدخول إلى mysql وبدا أن الاستيراد قد مات ، عالقًا في جدول صف 3M معين.

لذا حاولت

DROP DATABASE huge_db;

بعد 15-20 دقيقة ، لا شيء. في نافذة أخرى ، فعلت:

/etc/init.d/mysqld restart

مراسلة DROP DB النافذة: SERVER SHUTDOWN. ثم قمت بالفعل بإعادة تشغيل الخادم الفعلي.

عند تسجيل الدخول مرة أخرى إلى mysql ، تم فحصه وظل الديسيبل موجودًا

DROP DATABASE huge_db;

مرة أخرى ، ومرة ​​أخرى أنتظر بالفعل حوالي 5 دقائق.

مرة أخرى ، إنه تثبيت جديد. ال huge_db هو db الوحيد (بخلاف dbs النظام). أقسم أنني أسقطت ديسيبل بهذا الحجم من قبل وبسرعة ، ولكن ربما أكون مخطئا.

لقد أسقطت قاعدة البيانات بنجاح. استغرق الأمر حوالي 30 دقيقة. لاحظ أيضًا أنني أعتقد أنني كنت مخطئًا عندما اعتقدت أن استيراد mysqldump قد مات. تم فقد الاتصال الطرفي ، ولكن أعتقد أن العملية لا تزال قيد التشغيل. أنا على الأرجح قتلت الجدول الأوسط للاستيراد (جدول الصف 3M) وربما 3/4 من خلال ديسيبل بأكمله. لقد كان من المضلل أن تظهر كلمة "أعلى" الخلية باستخدام 3٪ فقط من الذاكرة ، عندما يبدو أنها يجب أن تستخدم المزيد.

انتهى إسقاط قاعدة البيانات بأخذ 30 دقيقة ، لذلك ، مرة أخرى ، ربما لم أكن مضطرًا لإعادة تشغيل الخادم وربما كان من الممكن أن أنتظر للتو انتهاء DROP ، لكنني لا أعرف كيف سيتفاعل mysql للحصول على استعلام DROP لـ نفس الديسيبل الذي يستورده عبر mysqldump.

ومع ذلك ، يبقى السؤال ، لماذا يستغرق الأمر 30 دقيقة + لإسقاط قاعدة بيانات 2 غيغابايت في حين أن كل ما يجب أن تفعله هو حذف جميع ملفات db وإزالة جميع الإشارات إلى قاعدة البيانات من information_schema؟ ما هي الصفقة الكبيرة؟

49
Buttle Butkus

بدلاً من إنهاء العملية ، سيكون أكثر أمانًا إذا قمت بذلك ضمن MySQL:

$ mysqladmin processlist -u root -p
Enter password: 
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id  | User | Host      | db                | Command | Time | State | Info             |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example           | Sleep   | 297  |       |                  |
| 407 | root | localhost |                   | Query   | 0    |       | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+

الاستعلام ذو المعرف 174 هو الحذف الوحيد لقاعدة بيانات "المثال" ، لذا قبل أن تنهي أي عمليات ، دع MySQL يحاول إنهاء الاستعلام:

$ mysqladmin kill 174

قم بتشغيل الأمر processlist أعلاه مرة أخرى لتأكيد أنه قتل.

إذا لم يفلح ذلك ، فربما يمكنك النظر في إنهاء العملية الخاطئة ، ولكن قبل ذلك يمكنك محاولة إعادة تشغيل خادم MySQL.

يمكنك أيضًا تشغيل أوامر مثل 'SHOW FULL PROCESSLIST' و 'KILL 174' في MySQL Shell ، على سبيل المثال إذا كان لديك عميل MySQL مثبت فقط. النقطة الأساسية هي تجنب قتل العملية باستخدام "القتل" في شل ما لم يكن ذلك ضروريًا للغاية.

بشكل عام ، يمكنك استخدام mysql أو mysqladmin. لا تحتاج إلى تشغيل أوامر مثل هذا في كثير من الأحيان ؛ بمجرد أن تبدأ في قتل الاستعلامات بانتظام ، هناك خطأ ما بالتأكيد ، وسيكون من الأفضل لك إصلاح هذه المشكلة (قتل عملية الاستعلام هو مجرد معالجة الأعراض).

80
Stefan Magnuson

على الرغم من أنني اعتقدت أن عملية الاستيراد قد ماتت ، فمن المحتمل أنها لا تزال جارية.

ال DROP DATABASE ربما انتظر الأمر حتى تنتهي قاعدة البيانات من الاستيراد قبل تشغيلها.

لذا ، بدلاً من DROP DATABASE أخذ وقت طويل ، ربما كان مجرد الاستيراد.

إذا قرأ أي شخص آخر هذا ويحاول إلغاء استيراد قاعدة البيانات وإسقاط قاعدة البيانات ، أوصيك أولاً بالعثور على PID (معرف العملية) للاستيراد وتشغيل هذا من محطة طرفية مختلفة:

$ kill [PID]

... حيث يكون [PID] هو PID الفعلي للعملية.

يجب أن ترى توقف الاستيراد على الفور إذا كان الطرف الآخر لا يزال متصلاً.

يمكنك أيضًا تشغيل SHOW PROCESSLIST في علامة التبويب phpMyAdmin SQL. يوضح الجدول الناتج العمليات الجارية ، والنقر على "x" بجوار الصف الذي تريد قتله يجب أن يؤدي الحيلة.

ثم اركض

DROP DATABASE `database_name`;

ويجب أن يكون كل شيء نظيفًا.


إجابة أخرى تشير إلى أن قتل العملية داخل الخلية أفضل من القيام بها من الخارج. لم أختبر هذه الإجابة ، لكنها تبدو معقولة للغاية. لذا فقد قمت بوضع علامة عليها ك "إجابة مقبولة" بدلاً من هذه الإجابة.

11
Buttle Butkus

حاول اقتطاع أكبر الجداول في قاعدة بيانات youra قبل أن تسقطها. رأيت سلوكًا مشابهًا جدًا عند العمل مع أرشيف MySQL لحركة مرور جدار الحماية ، وقد ساعد ذلك كثيرًا.

3
Tim Brigham

أنا واجهت نفس المشكلة . ولكن هذه المرة راجعت عرض قائمة العمليات. قال التحقق من أذونات لوقت أطول. ثم اكتشفت أن mysqld_safe كان يعمل كجذر بينما كانت أذونات مستوى المجلد لمستخدم mysql فقط. ومن ثم قمت بقتل الاستعلام ، وبالطبع استغرق الأمر وقتًا طويلاً لقول أنه في حالة قتل ولكني انتظرته للرد ثم قتل الاستعلام وغيرت أذونات مستوى المجلد إلى الجذر أيضًا عن طريق إضافته إلى المجموعة و chmod إلى 770. ثم نفذت نفس قاعدة البيانات قطرة بلاه ؛ لقد عملت معي في ثانيتين لقاعدة بيانات 20 جيجابايت.

3
Mannoj

أول ما يتبادر إلى الذهن هو الوضع Checking Permissions...

عندما تصدر DROP DATABASE mydb; يتم فحص كل شيء داخل/var/lib/mysql/mydb لمعرفة ما إذا كانت أذونات نظام التشغيل موجودة في الحق في إسقاط كل ملف.

رأى البعض أن تقليل عدد مستخدمي الخلية قد يساعد

3
RolandoMySQLDBA