DROP DATABASE को इतना समय क्यों लग रहा है? (माई एसक्यूएल)


46

नई CentOS स्थापना।

मैं एक बड़े DB (2GB sql फ़ाइल) का आयात चला रहा था और एक समस्या थी। SSH क्लाइंट कनेक्शन खोता हुआ लग रहा था और आयात जमने लगा था। मैंने mysql में प्रवेश करने के लिए एक और विंडो का उपयोग किया और आयात मृत दिखाई दिया, एक विशेष 3M पंक्ति तालिका पर अटक गया।

इसलिए मैंने कोशिश की

DROP DATABASE huge_db;

15-20 मिनट बाद, कुछ नहीं। एक अन्य विंडो में, मैंने किया:

/etc/init.d/mysqld restart

DROP DB विंडो गड़बड़ हो गई: SERUT SHUTDOWN। तब मैंने वास्तव में भौतिक सर्वर को फिर से शुरू किया।

वापस mysql में लॉग इन किया, जाँच की और db अभी भी वहाँ था, भाग गया

DROP DATABASE huge_db;

फिर से, और फिर से मैं पहले से ही लगभग 5 मिनट इंतजार कर रहा हूँ।

एक बार फिर, यह ताजा स्थापना है। huge_dbकेवल डीबी (प्रणाली डीबीएस के अलावा अन्य) है। मैं कसम खाता हूँ कि मैंने db की इस बड़ी को पहले और जल्दी से गिरा दिया है, लेकिन शायद मैं गलत हूँ।

मैंने डेटाबेस को सफलतापूर्वक गिरा दिया है। इसमें 30 मिनट का समय लगा। यह भी ध्यान दें कि मुझे लगता है कि मुझसे गलती हुई जब मुझे लगा कि mysqldump आयात मर चुका है। टर्मिनल कनेक्शन खो गया था, लेकिन मुझे लगता है कि प्रक्रिया अभी भी चल रही थी। मैं सबसे अधिक संभावना है कि आयात मध्य-तालिका (3M पंक्ति तालिका) को मार डाला और शायद पूरे db के माध्यम से रास्ते का 3/4 हिस्सा। यह भ्रामक था कि "शीर्ष" ने केवल 3% मेमोरी का उपयोग करके mysql दिखाया, जब ऐसा लगा कि इसे अधिक उपयोग करना चाहिए।

DB को छोड़ने से 30 मिनट लगते हैं, इसलिए, फिर से, मुझे सर्वर को पुनरारंभ नहीं करना पड़ सकता है और संभवतः DROP के समाप्त होने का इंतजार किया जा सकता है, लेकिन मुझे नहीं पता कि mysql DROP क्वेरी प्राप्त करने के लिए कैसे प्रतिक्रिया देगा वही db जो यह mysqldump के माध्यम से आयात कर रहा है।

फिर भी, यह सवाल बना हुआ है कि 2GB डेटाबेस को 30min + से DROP तक क्यों ले जाता है, जब यह सब करना चाहिए कि सभी db फ़ाइलों को हटा दें और DB से सभी संदर्भों को information_schema से हटा दें? क्या बड़ी बात है?

जवाबों:


73

इस प्रक्रिया को मारने के बजाय, यह सुरक्षित होगा यदि आपने इसे 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 सर्वर को पुनरारंभ करने का प्रयास कर सकते हैं।

आप MySQL शेल में 'SHOW FULL PROCESSLIST' और 'KILL 174' जैसी कमांड भी चला सकते हैं, उदाहरण के लिए यदि आपके पास केवल MySQL क्लाइंट स्थापित है। मुख्य बिंदु शेल में 'किल' का उपयोग करके प्रक्रिया को मारने से बचने के लिए है जब तक कि बिल्कुल आवश्यक न हो।

आम तौर पर बोलना आप mysqlया तो उपयोग कर सकते हैं mysqladmin। आपको इस तरह से कमांड चलाने की आवश्यकता नहीं होनी चाहिए, हालांकि अक्सर; एक बार जब आप प्रश्नों को नियमित रूप से मारना शुरू कर देते हैं तो कुछ निश्चित रूप से गलत होता है और आप उस समस्या को ठीक करने से बेहतर होंगे (क्वेरी प्रक्रिया को मारना सिर्फ लक्षण का इलाज है)।


1
@BugsBuggy एक सामान्य तरीका है जिसमें यह हो सकता है यदि कोई अन्य प्रक्रिया (जैसे एक वेब सर्वर, या इस मामले में एक आयात प्रक्रिया) चल रही है और डेटाबेस से जुड़ी है। जब आप DROP DATABASEआदेश जारी करते हैं तो सर्वर तब तक आगे नहीं बढ़ेगा जब तक सभी कनेक्शन बंद नहीं हो जाते।
स्टेफन मैग्नसन

11

हालांकि मुझे लगा था कि आयात प्रक्रिया मर गई थी, यह शायद अभी भी चल रहा था।

DROP DATABASEआदेश शायद आयात करने से पहले यह भाग गया समाप्त करने के लिए डेटाबेस के लिए इंतजार कर रहे थे।

इसलिए, DROP DATABASEएक लंबा समय लेने के बजाय , यह शायद सिर्फ आयात था।

अगर कोई और इसे पढ़ता है और डेटाबेस आयात को रद्द करने और डेटाबेस को छोड़ने की कोशिश कर रहा है, तो मैं आपको पहले आयात के लिए पीआईडी ​​(प्रक्रिया आईडी) खोजने और इसे एक अलग टर्मिनल से चलाने की सलाह देता हूं:

$ kill [PID]

... जहां [PID] प्रक्रिया के लिए वास्तविक PID होगा।

यदि अन्य टर्मिनल अभी भी जुड़ा हुआ है, तो आपको तुरंत आयात रुक जाना चाहिए।

आप SHOW PROCESSLISTphpMyAdmin SQL टैब में भी चल सकते हैं । परिणामी तालिका चल रही प्रक्रियाओं को दिखाती है, और जिस पंक्ति को आप मारना चाहते हैं उसके बगल में स्थित 'x' पर क्लिक करके चाल चलनी चाहिए।

तो भागो

DROP DATABASE `database_name`;

और सब कुछ साफ होना चाहिए।


एक अन्य उत्तर ने सुझाव दिया कि mysql के भीतर प्रक्रिया को मारना बाहर से करने से बेहतर है। मैंने उस उत्तर का परीक्षण नहीं किया है, लेकिन यह बहुत प्रशंसनीय लगता है। इसलिए मैंने इसे एक के बजाय "स्वीकृत उत्तर" के रूप में चिह्नित किया है।


3

इससे पहले कि आप इसे ड्रॉप करें, आप डेटाबेस में सबसे बड़ी तालिकाओं को अलग करने का प्रयास करें। फ़ायरवॉल ट्रैफ़िक के MySQL अभिलेखागार के साथ काम करते समय मैंने बहुत समान व्यवहार देखा और इससे काफी मदद मिली।


MySQL डॉक्स के अनुसार, "ट्रंककेट ऑपरेशंस ड्रॉप करें और टेबल को फिर से बनाएं, जो एक-एक करके पंक्तियों को हटाने की तुलना में बहुत तेज है", इसलिए ड्रॉप करने के लिए ट्रंक
ejoubaud

3

पहली बात जो मन में आती है वह है स्थिति Checking Permissions...

जब आप DROP DATABASE mydb;अंदर / var / lib / mysql / mydb सब कुछ जारी करते हैं, तो यह देखने के लिए जाँच की जाती है कि क्या OS आपकी फ़ाइल को छोड़ने के अधिकार के लिए मौजूद है।

कुछ ने महसूस किया है कि mysql उपयोगकर्ताओं की संख्या कम करने से मदद मिल सकती है


3

मैंने उसी समस्या का सामना किया। लेकिन इस बार मैंने शो प्रक्रिया सूची की जाँच की; यह अधिक समय के लिए अनुमति के लिए जाँच कहा। तब मैंने पाया कि mysqld_safe रूट के रूप में चल रहा था जबकि फ़ोल्डर स्तर अनुमतियाँ केवल mysql उपयोगकर्ता के लिए थी। इसलिए मैंने क्वेरी को मार दिया, यह लंबे समय तक यह कहते हुए मार दिया कि इसकी हत्या की स्थिति में है, लेकिन मैंने इसके लिए प्रतिक्रिया की प्रतीक्षा की तो इसने क्वेरी को मार दिया और फ़ोल्डर स्तर की अनुमतियों को रूट में बदलकर इसे समूह और chmod में जोड़कर 770 कर दिया। फिर मैंने निष्पादित किया एक ही ड्रॉप डेटाबेस ब्लाह; इसने 20GB डेटाबेस के लिए 2 सेकेंड में मेरे लिए काम किया।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.