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

Question

मैं एक डेटाबेस ड्रॉप करने में विफल रहा है:

 
mysql> drop database mydb; 
ERROR 1010 (HY000): Error dropping database (can't rmdir './mydb', errno: 39) 

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

 
# ls -l db/mydb 
-rw-rw---- mysql mysql HIS_STAT.MYD 
-rw-rw---- mysql mysql HIS_STAT.MYI 

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

Answer 1

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

सत्यापित करने के लिए, सुरक्षा उल्लंघनों के लिए सिस्टम लॉग की जांच करें, मैन्युअल रूप से एपर्मर/सेलिंक्स कॉन्फ़िगरेशन का निरीक्षण करें, और/या 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) 

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

इस Wordpress के साथ एक Linux सिस्टम स्थापित पर हुआ फायदा उठाने के रूप में त्रुटि 17: नीचे देखें ...

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

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

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

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

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

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

डेटा-निर्देशिका

सामान्य तौर पर, आप my.cnf फ़ाइल (my.ini Windows में MySQL प्रोग्राम फ़ाइलों निर्देशिका में /etc/my.cnf, /etc/sysconfig/my.cnf, /etc/mysql/my.cnf लिनक्स पर) का निरीक्षण करके डेटा निर्देशिका पा सकते हैं ढूँढना शीर्षक, datadir के रूप में।

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

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

Answer 2

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

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

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

Answer 3

, बस जाने के लिए/opt/lampp/var/mysql

वहाँ आप अपने datavase नाम पा सकते हैं। उस फ़ोल्डर को खोलें। अगर इसमें कोई भी फाइल

अब phpmyadmin पर आती है और उस डेटाबेस को छोड़ दें