सवाल MySQL: डेटाबेस छोड़ने में त्रुटि (त्रुटि 13; त्रुटि 17; errno 39)


मैं डेटाबेस छोड़ने में विफल रहा:

mysql> डेटाबेस mydb ड्रॉप;
त्रुटि 1010 (एचवाई 000): डेटाबेस छोड़ने में त्रुटि (rmdir './mydb' नहीं कर सकता, errno: 39)

निर्देशिका डीबी / mydb mysql पेड़ में मौजूद है लेकिन कोई तालिका नहीं है:

# एलएस -एल डीबी / mydb
-आरडब्ल्यू-आरडब्ल्यू ---- mysql mysql HIS_STAT.MYD
-आरडब्ल्यू-आरडब्ल्यू ---- mysql mysql HIS_STAT.MYI

मुझे क्या करना चाहिए?


44
2017-08-30 12:37


मूल


एक अनुमति मुद्दे की तरह लगता है। क्या आप एक पूर्ण पोस्ट कर सकते हैं ls -l उत्पादन? - Chris Henry
@ क्रिस हेनरी: मैंने # ls -l mydb के परिणाम के साथ प्रश्न अपडेट किया है - Philippe Blayo


जवाब:


Errno 13

MySQL में मूल निर्देशिका पर कोई लेखन अनुमति नहीं है जिसमें mydb फ़ोल्डर रहता है।

इसके साथ जांचें

ls -la /path/to/data/dir/         # see below on how to discover data dir
ls -la /path/to/data/dir/mydb   

लिनक्स पर, यह भी हो सकता है यदि आप MySQL और AppArmor / SELinux संकुल को मिलाकर मेल खाते हैं। क्या होता है कि AppArmor MySQL के पास अपना डेटा रखने की अपेक्षा करता है /path/to/data/dir, और वहां पूर्ण आर / डब्ल्यू की अनुमति देता है, लेकिन MySQLd एक अलग वितरण या निर्माण से है, और यह वास्तव में अपने डेटा को संग्रहीत करता है अन्यत्र (उदा .: /var/lib/mysql5/data/** विरोध के रूप में /var/lib/mysql/**)। तो आप क्या देखते हैं कि निर्देशिका है सही अनुमतियां और स्वामित्व और फिर भी यह अभी भी Errno 13 देता है क्योंकि apparmor / selinux इसे एक्सेस करने की अनुमति नहीं देगा।

सत्यापित करने के लिए, सुरक्षा उल्लंघनों के लिए सिस्टम लॉग की जांच करें, मैन्युअल रूप से एपर्मर / सेलिंक्स कॉन्फ़िगरेशन का निरीक्षण करें, और / या mysql उपयोगकर्ता का प्रतिरूपण करें और बेस var निर्देशिका पर जाने का प्रयास करें, फिर सीडी वृद्धिशील रूप से जब तक कि आप लक्ष्य निर्देशिका में न हों, और कुछ ऐसा चलें touch aardvark && rm aardvark। यदि अनुमतियां और स्वामित्व मिलान है, और फिर भी उपर्युक्त पहुंच त्रुटि उत्पन्न करता है, तो संभावना है कि यह एक सुरक्षा ढांचा समस्या है।

Errno 39

इस कोड का अर्थ है "निर्देशिका खाली नहीं है"। निर्देशिका में कुछ शामिल हैं छिपा हुआ फ़ाइलें MySQL के बारे में कुछ भी नहीं जानता है। गैर-छिपी हुई फ़ाइलों के लिए, इरनो 17 देखें। समाधान वही है।

Errno 17

इस कोड का अर्थ है "फ़ाइल मौजूद है"। निर्देशिका में कुछ MySQL फ़ाइल है जो MySQL को हटाने के बारे में महसूस नहीं करता है। ऐसी फाइलें एक द्वारा बनाई गई थीं SELECT ... INTO OUTFILE "filename"; आदेश कहाँ है filename कोई रास्ता नहीं था। इस मामले में, MySQL प्रक्रिया उन्हें अपनी वर्तमान कार्यशील निर्देशिका में बनाती है, जो (ओपनएसयूएसई 12.3 पर MySQL 5.6 पर परीक्षण) है डेटाबेस की डेटा निर्देशिका, उदा। /var/lib/mysql/data/nameofdatabase

reproducibility:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1676
Server version: 5.6.12-log openSUSE package
[ snip ]    

mysql> CREATE DATABASE pippo;
Query OK, 1 row affected (0.00 sec)

mysql> USE pippo;
Database changed
mysql> SELECT version() INTO OUTFILE 'test';
Query OK, 1 row affected (0.00 sec)

mysql> DROP DATABASE pippo;
ERROR 1010 (HY000): Error dropping database (can't rmdir './pippo/', errno: 17)

-- now from another console I delete the "test" file, without closing this connection
-- and just retry. Now it works.

mysql> DROP DATABASE pippo;
Query OK, 0 rows affected (0.00 sec)

फ़ाइल को बाहर ले जाएं (या यदि आवश्यक नहीं है तो हटाएं) और पुनः प्रयास करें। साथ ही, यह निर्धारित करें कि वे पहले स्थान पर क्यों बनाए गए थे - यह कुछ एप्लिकेशन में एक बग को इंगित कर सकता है। या बदतर: नीचे देखें ...

अद्यतन: झंडा का शोषण के रूप में त्रुटि 17

यह वर्डप्रेस स्थापित के साथ एक लिनक्स सिस्टम पर हुआ। दुर्भाग्य से ग्राहक समय की बाधाओं के अधीन था और मैं न तो डिस्क को चित्रित कर सकता था या असली फोरेंसिक दौर कर सकता था - मैंने पूरी मशीन को पुनर्स्थापित किया और वर्डप्रेस को प्रक्रिया में अपडेट किया गया, इसलिए मैं केवल इतना कह सकता हूं कि मैं हूं लगभग निश्चित रूप से उन्होंने इसे किया यह प्लगइन

लक्षण: द mysql डेटा निर्देशिका में एक्सटेंशन PHP के साथ तीन फाइलें थीं। रुको क्या?!? - और फाइलों के अंदर बेस 64 कोड का एक बड़ा हिस्सा था जिसे पारित किया गया था base64_decode, gzuncompress तथा [eval()][2]अहा। बेशक ये केवल पहले प्रयास थे, असफल लोग। साइट अच्छी तरह से और वास्तव में pwn3d किया गया था।

तो अगर आपको अपने mysql डेटा dir में कोई फ़ाइल मिलती है जो त्रुटि 17 उत्पन्न कर रही है, इसे जांचें file उपयोगिता या एंटीवायरस के साथ स्कैन करें। या इसकी सामग्री का निरीक्षण करें। मान लीजिए कि यह कुछ निर्दोष गलती के लिए है।

इस मामले में पीड़ित (उसके पास कुछ दोस्त "रखरखाव करते थे") कभी अनुमान लगाया नहीं था कि वह एक रखरखाव / अद्यतन / जो कुछ भी स्क्रिप्ट चलाता है, तब तक हैक किया गया था DROP DATABASE (मुझसे मत पूछो क्यों - मुझे यकीन नहीं है कि मैं भी जानना चाहता हूं) और एक त्रुटि मिली। सीपीयू लोड और syslog संदेशों से, मैं काफी सकारात्मक हूं कि मेजबान स्पैम फार्म बन गया था।

फिर भी एक और त्रुटि 17

अगर तुम rsync या एक ही संस्करण के दो MySQL प्रतिष्ठानों के बीच प्रतिलिपि बनाएँ लेकिन विभिन्न मंच या फाइल सिस्टम जैसे कि लिनक्स या विंडोज (जो निराश है, और जोखिम भरा है, लेकिन कई लोग इसे फिर भी करते हैं), और विशेष रूप से अलग-अलग हैं मामले की संवेदनशीलता सेटिंग्स, आप गलती से खत्म कर सकते हैं दो संस्करण एक ही फ़ाइल (या तो डेटा, सूचकांक, या मेटाडाटा); कहना Customers.myi तथा Customer.MYI। MySQL उनमें से एक का उपयोग करता है और दूसरे के बारे में कुछ नहीं जानता (जो कि पुराना हो सकता है और एक विनाशकारी सिंक का कारण बन सकता है)। डेटाबेस छोड़ते समय, जो कई में भी होता है mysqldump ... | ... mysql बैकअप योजनाएं, द DROP असफल हो जाएगा क्योंकि उस अतिरिक्त फ़ाइल (या उन अतिरिक्त फाइलें) मौजूद हैं। यदि ऐसा होता है, तो आपको अप्रचलित फ़ाइल (ओं) को पहचानने में सक्षम होना चाहिए, जिन्हें फ़ाइल समय से मैन्युअल हटाने की आवश्यकता है, या इस तथ्य से कि उनकी केस योजना अन्य तालिकाओं के बहुमत से अलग है।

डेटा-डीआईआर ढूँढना

आम तौर पर, आप निरीक्षण करके डेटा निर्देशिका पा सकते हैं my.cnf फ़ाइल (/etc/my.cnf, /etc/sysconfig/my.cnf, /etc/mysql/my.cnf लिनक्स पर; my.ini विंडोज़ में MySQL प्रोग्राम फाइल निर्देशिका में) के तहत [mysqld] शीर्षक, के रूप में datadir

वैकल्पिक रूप से आप इसे MySQL से ही पूछ सकते हैं:

mysql> SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)

87
2017-08-30 13:06



हेड-अप के लिए धन्यवाद @ xk0der (लेकिन मुझे विश्वास है कि वास्तव में एक होना चाहिए था टिप्पणी)। के बारे में सुझाव my.cnf उत्तर में जोड़ा गया। त्रुटि 13 समस्याएं यहां आने वाले लोगों के लिए उपयोगी साबित हो सकती हैं, इसलिए मैंने इसे रखने का फैसला किया है। - LSerni
मेरे मामले में, मैं OUTFILE का उपयोग कर तालिका का डंप लेने की कोशिश कर रहा था और वह फ़ाइल डेटाबेस नाम के तहत डेटा डीआईआर में सहेजी गई थी। उस फ़ाइल को हटाकर इसे हल करें। - Taranjeet


मेरे मामले में यह 'lower_case_table_names' पैरामीटर के कारण था।

जब मैंने डेटाबेस को ड्रॉप करने का प्रयास किया तो त्रुटि संख्या 39 फेंक दिया गया जिसमें निम्न_case_table_names पैरामीटर के साथ ऊपरी केस तालिका नाम सक्षम हैं।

यह पिछले स्थिति में निचले केस पैरामीटर परिवर्तन को वापस लौटकर तय किया गया है।


23
2018-03-10 12:59



सच। यह उस सेटिंग के कारण हो सकता है। बॉट, उस सेटिंग को वापस करना सही समाधान नहीं है लेकिन समझौता IMHO है। - Vikas B
यह मेरी समस्या हल हो गई। आप इसे वापस कर सकते हैं, अपने डेटाबेस हटा सकते हैं और इसे वापस कर सकते हैं ... - c4k
हाँ, यह मेरे साथ भी कारण था - Ashish Ratan
मेरी समस्या हल हो गई - Charles-Antoine Fournel
इससे मुझे मेरी समस्या हल करने में मदद मिली - hemantgp


बस / opt / lampp / var / mysql पर जाएं

वहां आप अपना डाटाबेस नाम पा सकते हैं। उस फ़ोल्डर को खोलें। अगर इसमें कोई फाइल निकालें

अब phpmyadmin पर आओ और डेटाबेस को छोड़ दें


4
2017-11-09 17:21





से संबंधित ERRORCODE 39, आप डिस्क पर भौतिक तालिका फ़ाइलों को निश्चित रूप से हटा सकते हैं। स्थान आपके ओएस वितरण और सेटअप पर निर्भर करता है। डेबियन पर इसके आम तौर पर / var / lib / mysql /डेटाबेस नाम/ तो एक करें:

rm -f /var/lib/mysql/<database_name>/

और फिर डेटाबेस को अपनी पसंद के टूल से या कमांड का उपयोग करके ड्रॉप करें:

DROP DATABASE <database_name>

2
2018-05-03 07:50



यह मेरे लिए काम करता है। फ़ाइलों को हटाने से पहले, पहले MySQL सर्वर (सेवा mysql स्टॉप) को रोकें, फिर फ़ाइलों को हटाएं और फिर से शुरू करें। अंत में mysql और डीआरओपी डीबी में लॉगिन करें। - bakalov
बहुत बहुत धन्यवाद, बहुत उपयोगी, मुझे बचाओ, सरल और सीधा। - Ariane Martins Gomes Do Rego


लिनक्स में, बस "/ var / lib / mysql" पर जाएं राइट क्लिक करें और (adminstrator के रूप में खोलें), mysql फ़ोल्डर के अंदर अपने डेटाबेस नाम से संबंधित फ़ोल्डर ढूंढें और इसे हटाएं। बस। डेटाबेस गिरा दिया गया है।


-2
2017-07-13 08:00