MySQL: # 126 - तालिका के लिए गलत कुंजी फ़ाइल

Question

मुझे MySQL क्वेरी से निम्न त्रुटि मिली।

#126 - Incorrect key file for table

मैंने इस तालिका के लिए एक कुंजी भी घोषित नहीं की है, लेकिन मेरे पास सूचकांक हैं। क्या किसी को पता है कि समस्या क्या हो सकती है?

Comments

मैं इसे विचारों के साथ भी प्राप्त करता हूं

— एलोजो वलूगी

tmp फ़ोल्डर की सीमा आम तौर पर 2GB होती है, इसे देखने के लिए df -h का प्रयास करें

— Elzo Valugi

यदि आपने एक काम किया है REPAIR TABLEऔर अभी भी इसे प्राप्त कर रहा है, तो इसके अलावा भी जगह है /tmpतो आप सर्वर को रिबूट करने की कोशिश कर सकते हैं।

— icc97

Answer 1

हर बार ऐसा हुआ है, यह मेरे अनुभव में एक पूर्ण डिस्क है।

संपादित करें

यह भी ध्यान देने योग्य है कि यह एक पूर्ण रैमडिस्क के कारण हो सकता है जब एक बड़ी तालिका को बदलने जैसी चीजें करते हैं यदि आपके पास एक रैमडिस्क कॉन्फ़िगर है। आप अस्थायी रूप से इस तरह के ऑपरेशन की अनुमति देने के लिए रैमडिस्क लाइन पर टिप्पणी कर सकते हैं यदि आप इसका आकार नहीं बढ़ा सकते हैं।

Comments

इसके अलावा, मेरे पास लगभग 2Gb खाली स्थान है और यह त्रुटि मिलती है। लेकिन मेरे डेटाबेस के बारे में 1.7 जीबी और डेटाबेस में ~ 1.5M पंक्तियों के साथ एक तालिका है। क्लीनअप के बाद, जब 3.5-4Gb के बारे में खाली जगह होती है, तो त्रुटि गायब हो जाती है।

— सेर्गेई

मेरे सिस्टम पर (फेडोरा 18) /tmpएक छोटा tmpfs फाइलसिस्टम है और mysql अंतरिक्ष से बाहर एक टेम्प टेबल लिख कर भागा है। मुझे tmpdirकॉन्फ़िगर चर को mysql.com

— jcbwlkr

हालाँकि यह एक कारण हो सकता है, यह कभी भी मेरे लिए पूर्ण डिस्क के कारण नहीं है। मुझे यह त्रुटि 10GB के लिए आवंटित किए गए Amazon RDS उदाहरण पर मिल रही है जो केवल 1% पूर्ण है। कम मेमोरी भी एक कारण हो सकता है।

— सेरिन

आप tmpdir = / mysql_tmp या my.cnf में कुछ सेट कर सकते हैं और यह रूट फाइलसिस्टम पर होना चाहिए (हालाँकि यह बहुत बड़ा है)

— केविन पार्कर

हालांकि मुझे एक ही त्रुटि मिली, हालांकि मेरे पास डिस्क स्पेस है [रूट @ ADM-PROD-PERCONA-SL-RP-03 पर्कॉन्का] # df -h फाइलसिस्टम साइज यूज एवल यूज%% माउंटेड / देव / xvda2 7.8 जी 1.6G 6.1G 21% 21% / devtmpfs 61G 80K 61G 1% / dev tmpfs 61G 0 61G 0% / dev / shm / dev / md0 3.0T 1.8T 1.2T 61% / mnt

— आशीष करपे

Answer 2

सबसे पहले, आपको पता होना चाहिए कि चाबियाँ और सूचकांक MySQL में समानार्थक हैं। यदि आप क्रिएट टेबल सिंटैक्स के बारे में प्रलेखन को देखते हैं , तो आप पढ़ सकते हैं:

KEYसामान्य रूप से एक पर्यायवाची है INDEX। मुख्य विशेषता PRIMARY KEYको KEYकॉलम की परिभाषा में दिए गए अनुसार ही निर्दिष्ट किया जा सकता है । यह अन्य डेटाबेस सिस्टम के साथ संगतता के लिए लागू किया गया था।

---

अब, आपको जिस तरह की त्रुटि हो रही है, वह दो चीजों के कारण हो सकती है:

• MySQL सर्वर पर डिस्क समस्याएँ
• दूषित कुंजी / टेबल

पहले मामले में, आप देखेंगे कि आपकी क्वेरी में एक सीमा जोड़ने से समस्या अस्थायी रूप से हल हो सकती है। यदि वह आपके लिए ऐसा करता है, तो संभवतः आपके पास एक tmpफ़ोल्डर है जो आपके द्वारा किए जा रहे प्रश्नों के आकार के लिए बहुत छोटा है। तब आप निर्णय ले सकते हैं या tmpबड़ा कर सकते हैं , या अपने प्रश्नों को छोटा बना सकते हैं! ;)

कभी-कभी, tmpकाफी बड़ा होता है, लेकिन फिर भी पूर्ण हो जाता है, आपको इन स्थितियों में कुछ मैनुअल सफाई करने की आवश्यकता होगी।

दूसरे मामले में, MySQL के डेटा के साथ वास्तविक समस्याएं हैं। यदि आप डेटा को आसानी से पुन: सम्मिलित कर सकते हैं, तो मैं केवल तालिका को फिर से बनाने / फिर से बनाने और डेटा को पुन: सम्मिलित करने की सलाह दूंगा। यदि आप नहीं कर सकते हैं तो आप REPAIR तालिका के साथ तालिका की मरम्मत करने का प्रयास कर सकते हैं । यह आम तौर पर लंबी प्रक्रिया है जो बहुत अच्छी तरह से विफल हो सकती है।

---

देखो पूर्ण त्रुटि संदेश आपको मिलता है:

'FILEPATH.MYI' तालिका के लिए गलत कुंजी फ़ाइल; इसे सुधारने का प्रयास करें

यह संदेश में उल्लेख करता है कि आप इसे सुधारने का प्रयास कर सकते हैं। इसके अलावा, यदि आप वास्तविक FILEPATH को देखते हैं, तो आप और अधिक जानकारी प्राप्त कर सकते हैं:

• अगर यह कुछ ऐसा है /tmp/#sql_ab34_23fतो इसका मतलब है कि क्वेरी आकार के कारण MySQL को एक अस्थायी तालिका बनाने की आवश्यकता है। यह इसे / tmp में संग्रहीत करता है, और उस अस्थायी तालिका के लिए आपके / tmp में पर्याप्त स्थान नहीं है।

• यदि इसमें इसके बजाय एक वास्तविक तालिका का नाम शामिल है, तो इसका मतलब है कि यह तालिका बहुत भ्रष्ट है और आपको इसकी मरम्मत करनी चाहिए।

---

यदि आप यह पहचानते हैं कि आपका मुद्दा / tmp के आकार के साथ है, तो ठीक के लिए इसी तरह के प्रश्न का उत्तर पढ़ें: MySQL, त्रुटि 126: तालिका के लिए गलत कुंजी फ़ाइल ।

Answer 3

इन निर्देशों का पालन करने से मुझे अपनी tmp निर्देशिका को पुनः बनाने और समस्या को हल करने की अनुमति मिली:

सभी फ़ाइल सिस्टम और उनके डिस्क उपयोग को मानव पठनीय रूप में प्रदर्शित करें:

df -h

उन प्रक्रियाओं को खोजें जिसमें फ़ाइलें खुली हों /tmp

sudo lsof /tmp/**/*

फिर umount /tmpऔर /var/tmp:

umount -l /tmp
umount -l /var/tmp

फिर भ्रष्ट विभाजन फ़ाइल को हटा दें:

rm -fv /usr/tmpDSK

फिर एक अच्छा नया बनाएं:

/scripts/securetmp

ध्यान दें कि safetmp पर्ल स्क्रिप्ट को संपादित करके आप मैन्युअल रूप से tmp निर्देशिका का आकार स्वयं निर्धारित कर सकते हैं, हालाँकि अभी स्क्रिप्ट चलाने से हमारे सर्वर पर tmp निर्देशिका का आकार लगभग 450MB से 4.0GB तक बढ़ गया है।

Answer 4

त्रुटि # 126 आमतौर पर तब होती है जब आपको एक भ्रष्ट तालिका मिली थी। इसे हल करने का सबसे अच्छा तरीका मरम्मत करना है। यह लेख मदद कर सकता है:

http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

Comments

मैंने अपनी सभी कुंजियों को हटा दिया और अनुकूलित किया। यदि मेरी क्वेरी बहुत धीमी है तो क्या मुझे यह त्रुटि मिल सकती है?

— ब्रायन

मुझे यकीन नहीं है लेकिन मेरी समझ के आधार पर, यह त्रुटि क्वेरी के कारण नहीं है। क्या आपने अभी तक मरम्मत की कोशिश की है?

— जून

Answer 5

मुझे यह त्रुटि तब मिली जब मैंने सेट ft_min_word_len = 2किया my.cnf, जो 4 के डिफ़ॉल्ट से पूर्ण पाठ सूचकांक में न्यूनतम शब्द लंबाई 2 तक कम करता है।

टेबल की मरम्मत करने से समस्या ठीक हो गई।

Comments

क्या आप जानते हैं कि यह केवल तब होता है जब आप पहली बार सेटिंग बदलते हैं, या यह ऐसा कुछ है जो हो सकता है क्योंकि न्यूनतम शब्द की लंबाई बहुत छोटी है?

— Y0lk

Answer 6

अपनी क्वेरी में सीमा का उपयोग करने का प्रयास करें। यह पूर्ण डिस्क के कारण @Monsters X द्वारा कहा गया है।

मैंने इस समस्या का भी सामना किया है और क्वेरी में सीमा से हल किया है, क्योंकि हजारों रिकॉर्ड थे। अब अच्छा काम कर रहे हैं :)

Answer 7

मुझे पता है कि यह एक पुराना विषय है, लेकिन मेरे द्वारा काम किए गए किसी भी समाधान का उल्लेख नहीं किया गया है। मैंने कुछ और काम किया है:

आपको:

1. MySQL सेवा बंद करें:
2. Mysql \ data खोलें
3. Ib_logfile0 और ib_logfile1 दोनों निकालें।
4. सेवा को पुनरारंभ करें

Answer 8

repair table myschema.mytable;

Answer 9

मैंने इस समस्या को ठीक किया:

ALTER TABLE table ENGINE MyISAM;
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
ALTER TABLE table ENGINE InnoDB;

मदद कर सकता है

• Refs: MySQL: पहले से अधिक टेबल "अखंडता बाधा का उल्लंघन" देता है

Comments

मैं सिर्फ एक कदम का उपयोग करके एक समान समस्या को हल करने में सक्षम था, आप अपने वर्तमान टेबल इंजन का उपयोग करके अपनी तालिका का पुनर्निर्माण कर सकते हैं। Ie, यदि आप myisam का उपयोग कर रहे हैं: पहले से तय table इंजन = MyISAM;

— सीनडाउन डे 10'14

Answer 10

पर जाएं /etc/my.cnfऔर टिप्पणी करेंtmpfs

#tmpdir=/var/tmpfs

यह समस्या को ठीक करता है।

मैंने एक अन्य उत्तर में सुझाए गए कमांड को चलाया और जबकि निर्देशिका छोटी है, यह खाली था, इसलिए स्थान मुद्दा नहीं था।

/var/tmp$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs
/var/tmpfs$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs

Answer 11

क्वेरी में शामिल तालिकाओं में से प्रत्येक के लिए एक मरम्मत कमांड चलाने का प्रयास करें।

MySQL व्यवस्थापक का उपयोग करें, कैटलॉग पर जाएं -> अपनी कैटलॉग चुनें -> एक तालिका चुनें -> रखरखाव बटन पर क्लिक करें -> मरम्मत -> FRM का उपयोग करें।

Answer 12

अब दूसरे जवाबों ने इसे मेरे लिए हल कर दिया। यह बताता है कि एक कॉलम और एक ही क्वेरी में एक इंडेक्स का नाम बदलने से त्रुटि हुई।

काम नहीं कर रहा:

-- rename column and rename index
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

काम करता है (2 कथन):

-- rename column
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
-- rename index
ALTER TABLE `client_types`
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

यह MariaDB 10.0.20 पर था। MySQL 5.5.48 पर समान क्वेरी के साथ कोई त्रुटि नहीं थी।

Answer 13

mysql> set global sql_slave_skip_counter=1; start slave; show slave status\G

फिर त्रुटि मिली:

 Error 'Table './openx/f_scraper_banner_details' is marked as crashed and should be repaired' on query. Default database: 'openx'. Query: 'INSERT INTO f_scraper_banner_details(job_details_id, ad_id, client_id, zone_id, affiliateid, comments, pct_to_report, publisher_currency, sanity_check_enabled, status, error_code, report_date) VALUES (10274859, 321264, 0, 31926, 0, '', -1, 'USD', 1, 'FAILURE', 'INACTIVE_BANNER', '2016-06-28 04:00:00')'

mysql> मरम्मत तालिका f_scraper_banner_details;

इसने मेरे लिए काम किया

Answer 14

मेरा मुद्दा खराब क्वेरी से आया है। मैंने FROM में सेलेक्ट में रेफर नहीं किया गया था।

उदाहरण:

   SELECT t.*,s.ticket_status as `ticket_status`
   FROM tickets_new t, ticket_status s, users u

, users uमेरे लिए समस्या का कारण था। उस समस्या को हल करना।

संदर्भ के लिए यह एक CodeIgniter देव वातावरण में था।

Answer 15

Ft_min_word_len (पूर्ण पाठ न्यूनतम शब्द लंबाई) को कम करने के बाद एक मेज पर लिखते समय मुझे यह संदेश मिला । इसे हल करने के लिए, तालिका की मरम्मत करके सूचकांक को फिर से बनाएं।

Answer 16

mysqlcheck -r -f -uroot -p --use_frm db_name

सामान्य रूप से चाल चलेगा