कुंजीकैच के साथ मरम्मत से कैसे बचें?

Question

मुझे my.cnf फ़ाइल को अनुकूलित करने के साथ कुछ अनुभव हुआ है लेकिन मेरे डेटाबेस में लगभग 4 मिलियन रिकॉर्ड (MyISAM) हैं। मैं एक mysqldump से पुनर्स्थापित करने की कोशिश कर रहा हूं लेकिन हर बार जब मैं करता हूं तो मुझे अंततः डरावनी "मरम्मत के साथ मरम्मत" मिलती है, जिसमें कुछ दिन लग सकते हैं। क्या इससे पहले कि इसे पाने के लिए कोई रास्ता है और इसे "सॉर्टिंग द्वारा मरम्मत" के रूप में रोल करने दें?

मेरे पास 2 जीबी रैम, ड्यूल कोर, अतिरिक्त हार्ड ड्राइव स्पेस है। my.cnf से बाहर

कटाव:

set-variable = max_connections=650 
set-variable = key_buffer=256M 
set-variable = myisam_sort_buffer_size=64M 
set-variable = join_buffer=1M 
set-variable = record_buffer=1M 
set-variable = sort_buffer_size=2M 
set-variable = read_buffer_size=2M 
set-variable = query_cache_size=32M 
set-variable = table_cache=1024 
set-variable = thread_cache_size=256 
set-variable = wait_timeout=7200 
set-variable = connect_timeout=10 
set-variable = max_allowed_packet=16M 
set-variable = max_connect_errors=10 
set-variable = thread_concurrency=8 

Answer 1

"छँटाई द्वारा मरम्मत" filesort दिनचर्या, जो बारी में अपने tmpdir में कई अस्थायी फ़ाइलें (आमतौर पर) बनाता है उपयोग करता है।

यदि आपके tmpdir के पास उनके लिए पर्याप्त जगह नहीं है, तो यह "कीकैच द्वारा मरम्मत" पर वापस आ जाएगी। यह बेहद खराब है क्योंकि यह बहुत धीमा है और कम इष्टतम इंडेक्स बनाता है।

कुछ अन्य स्थितियां हैं लेकिन मैंने उन्हें पहचाना नहीं है।

फाइलोर्ट() के लिए आपको आवश्यक tmpdir के आकार को काम करना अनिवार्य है; फाइल डेटा बफर में संग्रहीत डेटा डेटा MYD फ़ाइलों के समान नहीं है, यह आमतौर पर बहुत अधिक जगह का उपयोग करता है।

तो यदि आपका tmpdir एक छोटे/tmp (या tmpfs) पर इंगित करता है, तो हो सकता है कि आप इसे एक बड़े/var/tmp में बदलना चाहें - यदि यह मौजूद है।

Answer 2

धन्यवाद मार्क, हां यह वही है जो मैं कोशिश कर रहा हूं और लॉग से देख रहा हूं कि यही वजह है कि "कुंजीकैच के साथ मरम्मत" पर स्विच किया गया था, अंतरिक्ष त्रुटि से बाहर था।

यह वही है जो मैंने अपना समाधान प्राप्त करने के लिए किया था क्योंकि मैं इस तथ्य से नहीं जाऊंगा कि यह /tmp/mysqltmp/ पर इंगित कर रहा था, जिसमें केवल अधिकतम 2 एमबी था।

तो मैं इस किया था:

mkdir /home/mysqltmp 

chown mysql:mysql /home/mysqltmp 

tmpdir=/home/mysqltmp/

अब अगर मैं df -h /home/mysqltmp उपयोग करने के लिए बदल my.conf में मेरी tmp निर्देशिका, क्या मुझे लगता है कि dir 285 GB उपलब्ध है , ताकि वास्तव में देखने के लिए एक अच्छी दृष्टि थी, बहुत सारी खाली जगह थी, साथ ही मैं देख सकता था कि MySQL 20GB आसानी से चाहता था। तो अब मुझे 12 घंटे पहले क्या ले रहा था 20 मिनट में पूरा हो गया है, जो सूचकांक में 3 मिलियन से अधिक रिकॉर्ड सम्मिलित है।

Answer 3

MySQL MyISAM तालिकाओं के लिए कीकैच द्वारा मरम्मत का उपयोग करेगा जब भी तालिका इंडेक्स का अधिकतम संभव आकार परिवर्तनीय myisam_max_sort_file_size के मान से अधिक होता है।

आप सभी इंडेक्स में सभी चाबियों के लिए बाइट आकार मान जोड़कर और अपनी तालिका में पंक्तियों की संख्या से गुणा करके इंडेक्स के अधिकतम आकार की गणना कर सकते हैं।

myisam_max_sort_file_size बढ़ाएं और आपकी अनुक्रमणिका धीमी कीकैच विधि के बजाय डिस्क पर सॉर्टिंग का उपयोग करके पुनर्निर्मित की जाएगी।

Answer 4

मैंने गोपनीय रूप से एक नए डेटाबेस पर एक मरम्मत तालिका चलायी जो मैंने तेजी से reg के लिए स्थापित नहीं किया था। myisam_max_sort_file_size जो एमआईडी फ़ाइल की तुलना में बहुत छोटा था (जो 88279393280 बाईस बड़ा है, लगभग 88 जीबी)। डेटा फाइल 85 जीबी है। तालिका 1.2 बिलियन रिकॉर्ड्स है, जिसमें आईडी, दो तिथियां, एक टिनटेक्स्ट, कुछ बिगिनट्स और डबल शामिल हैं।मेरा सर्वर (विंडोज 7 के तहत एक बॉक्स में चल रहे 2 जीबी आभासी लिनक्स) केवल विंडोज सर्वर पर 4 का एक कोर है, लेकिन यह 3+ जीएचजेड चल रहा है। मैं इस बात से डर रहा था कि "कीकैच द्वारा मरम्मत" घटना हमेशा के लिए ले जाएगी - दूर छोटी टेबल के साथ डरावनी कहानियां दी गईं।

सौभाग्य से यह मरम्मत तालिका त्वरित ऑपरेशन को पूरा करने के लिए "केवल" 1 दिन, 10 घंटे और 20.72 सेकंड ले लिया।

मुझे सबसे ज्यादा याद आती है कि यह जानने का कोई तरीका है कि mysql ऑपरेशन में कितना दूर है, और यह कितनी जल्दी समाप्त हो सकता है। यह अभी भी मेरे लिए अज्ञात है।

मैंने अब अपनी my.ini फ़ाइल बदल दी है और डीएफ के साथ दोबारा जांच की है कि मेरे पास उन बड़ी अस्थायी फ़ाइलों के लिए पर्याप्त डिस्क स्थान है।

वैसे भी .. मेरा मुख्य बिंदु, जो इस जाल में आने वाले अगले व्यक्ति को बहुत उपयोगी ज्ञान हो सकता है .. वास्तव में ... घबराओ मत! यह धीमा हो सकता है, लेकिन उप-पैरा हार्डवेयर पर एक या दो दिनों के भीतर 1+ बिलियन रिकॉर्ड्स निकालने के लिए यह संभव है। तीन इंडेक्स प्राप्त हुए, एक दिनांक फ़ील्ड पर, एक बड़ा क्षेत्र पर, और आईडी फ़ील्ड पर एक प्राथमिक।

मैं इसे समाधानों में से किसी एक टिप्पणी के रूप में पोस्ट कर दूंगा, लेकिन मुझे यह नहीं लगता कि यह कैसे करें, उपयोगकर्ता इंटरफ़ेस के साथ, इसलिए मैं इसे समाधान के रूप में छोड़ दूंगा। मुझे ऊपर मत बढ़ाओ, यह सिर्फ एक नोट है कि मुझे यहां होना पसंद होता, मैं लगभग "मेरे कुंजीपटल द्वारा क्रमबद्ध" थ्रेड मारने जा रहा था क्योंकि मैंने सोचा था कि इसमें एक हफ्ते या अधिक समय लग सकता है। 2 दिन प्रति अरब रिकॉर्ड प्रबंधनीय है ..

संपादित करें: और अब, एक ही डेटाबेस पर एक मरम्मत तालिका है, लेकिन एक बड़ी पर्याप्त mysiam_max_sort_file_size सेटिंग के साथ सॉर्टिंग द्वारा मरम्मत का उपयोग करके 10 घंटे, 20 मिनट लग गए। सबसे अधिक डिस्कस्पेस का उपयोग लगभग 250 जीबी था, लेकिन मैंने myisam_max_sort_file_size को बहुत अधिक सेट किया था, यह दर्शाता है कि सर्वर पर कितनी डिस्क स्पेस वास्तव में मुक्त है।

ट्रैकिंग प्रगति कठिन है। अलग-अलग इंडेक्स बनाए गए थे, जबकि डिस्क स्पेस ऊपर और नीचे चला गया था, लेकिन घंटे के लंबे विराम थे जहां कोई बदलाव नहीं किया गया था। डिस्क स्पेस उपयोग (जैसा कि डीएफ द्वारा रिपोर्ट किया गया है)। (http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_myisam_max_sort_file_size)

Answer 5

MySQL संदर्भ मैनुअल के अनुसार, डिस्क स्थान उपलब्ध होना चाहिए "फाइल सिस्टम में निर्देशिका जहां मूल इंडेक्स फ़ाइल स्थित है युक्त" - यह करने के लिए (कम से कम) v5.0 लागू होता है और ऊपर। यह उपर्युक्त उत्तरों में से कुछ का विरोध करता है, जो दावा करते हैं कि tmp निर्देशिका के लिए डिस्क स्थान बढ़ाना मदद करेगा।

मैं व्यवहार संदर्भ मैनुअल में वर्णित इस बात की पुष्टि कर सकते हैं: अस्थायी डिस्क स्थान tmpdir में जहां तालिका के डेटा (*.MYD) & सूचकांक फ़ाइलें (*.MYI) जमा हो जाती है प्रयोग किया जाता है, लेकिन नहीं।

Answer 6

यहां कोई भी समाधान मेरे लिए काम नहीं करता है: इससे कोई फर्क नहीं पड़ता कि मैंने myisam_sort_buffer_size वैरिएबल को कितना बढ़ाया है या जहां मैंने tmpdir परिवर्तनीय बिंदु बनाया है, तालिका हमेशा कुंजीकैच के साथ मरम्मत की जाती है। अंत में .MYI बिना,

• /path/to/table इसके विस्तार (ताकि बिना डेटाबेस फ़ाइल का मार्ग है:

  myisamchk --sort-recover --sort_buffer_size=14G /path/to/table 
  

  जहां:

  क्या काम किया कमांडलाइन उपयोगिता myisamchk का उपयोग किया गया)। यह डिफ़ॉल्ट रूप से /var/lib/mysql/your_database निर्देशिका में स्थित है।

• 14G से बफर आकार को आपके पास जो भी खाली स्थान उपलब्ध है, उसे बदलें।

एक अतिरिक्त बोनस के रूप में, यह चलती प्रगति को भी प्रदर्शित करता है क्योंकि यह डेटा को मंथन करता है।