त्वरित सुधार
यदि आप डेटाबेस को छोड़ना चाहते हैं, चाहे कुछ भी हो (लेकिन कृपया पहले पूरी पोस्ट पढ़ें:त्रुटि किसी कारण से दी गई थी , और यह जानना महत्वपूर्ण हो सकता है कि इसका कारण क्या था!), आप यह कर सकते हैं:
- डेटादिर को कमांड के साथ ढूंढें
SHOW VARIABLES WHERE Variable_name LIKE '%datadir%'; - MySQL सर्वर को रोकें (जैसे
service mysql stopयाrcmysqld stopया लिनक्स पर समान,NET STOP <name of MYSQL service, often MYSQL57 or similar>याSERVICES.MSC. के माध्यम से विंडोज़ पर) - डेटादिर पर जाएं (यह वह जगह है जहां आपको जांच करनी चाहिए; नीचे देखें)
- डेटाबेस के समान नाम वाली निर्देशिका को हटा दें
- MySQL सर्वर को फिर से शुरू करें और उससे कनेक्ट करें
- एक ड्रॉप डेटाबेस निष्पादित करें
- बस!
इरनो 13 के कारण
MySQL के पास मूल निर्देशिका पर कोई लिखित अनुमति नहीं है जिसमें mydb फ़ोल्डर रहता है।
इसके साथ जांचें
ls -la /path/to/data/dir/ # see below on how to discover data dir
ls -la /path/to/data/dir/mydb
Linux पर, यह तब भी हो सकता है जब आप MySQL और AppArmor/SELinux संकुल को मिलाते हैं और मिलाते हैं। क्या होता है कि AppArmor mysqld से अपेक्षा करता है कि उसका डेटा /path/to/data/dir में होगा , और वहां पूर्ण R/W की अनुमति देता है, लेकिन MySQLd एक अलग वितरण या निर्माण से है, और यह वास्तव में अपना डेटा कहीं और संग्रहीत करता है (उदाहरण:/var/lib/mysql5/data/** /var/lib/mysql/** . के विपरीत ) तो आप जो देखते हैं वह यह है कि निर्देशिका में सही अनुमतियां और स्वामित्व हैं और फिर भी यह अभी भी Errno 13 देता है क्योंकि apparmor/selinux इसे एक्सेस करने की अनुमति नहीं देगा।
सत्यापित करने के लिए, सुरक्षा उल्लंघनों के लिए सिस्टम लॉग की जांच करें, मैन्युअल रूप से एपर्मर/सेलिनक्स कॉन्फ़िगरेशन का निरीक्षण करें, और/या MySQL उपयोगकर्ता का प्रतिरूपण करें और बेस var निर्देशिका में जाने का प्रयास करें, तब तक सीडी वृद्धिशील रूप से जब तक आप लक्ष्य निर्देशिका में न हों, और कुछ ऐसा चलाएं touch aardvark && rm aardvark . यदि अनुमतियाँ और स्वामित्व मेल खाते हैं, और फिर भी उपरोक्त एक पहुँच त्रुटि उत्पन्न करता है, तो संभावना है कि यह एक सुरक्षा ढांचे का मुद्दा है।
Errno 39 के कारण
इस कोड का अर्थ है "निर्देशिका खाली नहीं है"। निर्देशिका में कुछ छिपा हुआ . है फ़ाइलें MySQL के बारे में कुछ नहीं जानता है। गैर-छिपी हुई फाइलों के लिए, Errno 17 देखें। समाधान वही है।
इर्रनो 17 के कारण
इस कोड का अर्थ है "फ़ाइल मौजूद है"। निर्देशिका में कुछ MySQL फ़ाइल है जिसे MySQL हटाने के बारे में महसूस नहीं करता है। ऐसी फ़ाइलें एक SELECT ... INTO OUTFILE "filename"; . द्वारा बनाई जा सकती थीं कमांड जहां filename कोई रास्ता नहीं था। इस मामले में, MySQL प्रक्रिया उन्हें अपनी वर्तमान कार्यशील निर्देशिका में बनाती है, जो (MySQL 5.6 पर OpenSuSE 12.3 पर परीक्षण किया गया) डेटाबेस की डेटा निर्देशिका है। , जैसे /var/lib/mysql/data/nameofdatabase ।
पुनरुत्पादकता:
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 त्रुटि शोषण ध्वज के रूप में
यह एक लिनक्स सिस्टम पर हुआ जिसमें Wordpress स्थापित था। दुर्भाग्य से ग्राहक समय की कमी के तहत था और मैं न तो डिस्क की छवि बना सकता था और न ही वास्तविक फोरेंसिक राउंड कर सकता था - मैंने पूरी मशीन को फिर से स्थापित किया और वर्डप्रेस इस प्रक्रिया में अपडेट हो गया, इसलिए मैं केवल यह कह सकता हूं कि मैं लगभग लगभग निश्चित रूप से उन्होंने इसे इस प्लगइन के माध्यम से किया है। ।
लक्षण :mysql डेटा निर्देशिका में एक्सटेंशन PHP के साथ तीन फाइलें थीं। रुको, क्या?!? -- और फाइलों के अंदर बेस 64 कोड का एक बड़ा हिस्सा था जो base64_decode को पास किया गया था , gzuncompress और [eval()][2] . आह . बेशक ये केवल पहले प्रयास थे, असफल। साइट अच्छी और सही मायने में pwn3d थी।
इसलिए यदि आपको अपने mysql डेटा dir में कोई फ़ाइल मिलती है जिसके कारण 17 त्रुटि हो रही है, तो इसे file से जांचें उपयोगिता या इसे एंटीवायरस से स्कैन करें। या इसकी सामग्री का नेत्रहीन निरीक्षण करें। यह मत समझिए कि यह किसी अहानिकर गलती के लिए है।
(कहने की जरूरत नहीं है, फ़ाइल की दृष्टि से जांच करने के लिए, इसे कभी भी डबल क्लिक न करें )।
इस मामले में पीड़ित (उसके पास कोई दोस्त था "रखरखाव करता था") ने कभी भी अनुमान नहीं लगाया होगा कि जब तक रखरखाव/अद्यतन/जो भी स्क्रिप्ट DROP DATABASE चलाती है, तब तक उसे हैक कर लिया जाएगा। (मुझसे मत पूछो क्यों - मुझे यकीन नहीं है कि मैं जानना भी चाहता हूं ) और एक त्रुटि मिली। CPU लोड और syslog संदेशों से, मैं काफी सकारात्मक हूँ कि होस्ट एक स्पैम फ़ार्म बन गया था।
फिर भी एक और त्रुटि 17
अगर आप rsync या एक ही संस्करण के दो MySQL स्थापनाओं के बीच प्रतिलिपि बनाएँ लेकिन भिन्न प्लेटफ़ॉर्म या फ़ाइल सिस्टम जैसे कि लिनक्स या विंडोज (जो हतोत्साहित और जोखिम भरा है, लेकिन फिर भी कई लोग इसे करते हैं), और विशेष रूप से अलग केस सेंसिटिविटी
सेटिंग्स, आप गलती से दो संस्करणों के साथ समाप्त हो सकते हैं एक ही फ़ाइल (या तो डेटा, अनुक्रमणिका, या मेटाडेटा); कहें Customers.myi और Customer.MYI . MySQL उनमें से एक का उपयोग करता है और दूसरे के बारे में कुछ नहीं जानता (जो पुराना हो सकता है और एक विनाशकारी सिंक का कारण बन सकता है)। डेटाबेस को छोड़ते समय, जो कई mysqldump ... | ... mysql बैकअप योजनाएं, DROP विफल हो जाएगा क्योंकि वह अतिरिक्त फ़ाइल (या वे अतिरिक्त फ़ाइलें) मौजूद हैं। यदि ऐसा होता है, तो आप अप्रचलित फ़ाइल(फ़ाइलों) को पहचानने में सक्षम होना चाहिए जिन्हें फ़ाइल समय से मैन्युअल रूप से हटाने की आवश्यकता है, या इस तथ्य से कि उनकी केस योजना अन्य तालिकाओं के बहुमत से अलग है।
डेटा ढूँढना-dir
सामान्य तौर पर, आप 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)
