MySQL स्टोरेज इंजन ऑप्टिमाइज़ेशन:उच्च प्रदर्शन के लिए InnoDB ऑप्टिमाइज़ेशन को कॉन्फ़िगर करना

InnoDB MySQL में सबसे व्यापक रूप से उपयोग किए जाने वाले स्टोरेज इंजनों में से एक है। इस स्टोरेज इंजन को उच्च-विश्वसनीयता और उच्च-प्रदर्शन स्टोरेज इंजन के रूप में जाना जाता है और इसके प्रमुख लाभों में पंक्ति-स्तरीय लॉकिंग, विदेशी कुंजी और एसीआईडी ​​​​मॉडल का पालन करना शामिल है। 2010 में जारी किए गए MySQL 5.5 के बाद से InnoDB MyISAM को डिफ़ॉल्ट स्टोरेज इंजन के रूप में बदल देता है।

यदि इसे ठीक से अनुकूलित किया जाए तो यह स्टोरेज इंजन अविश्वसनीय रूप से प्रदर्शनकारी और शक्तिशाली हो सकता है - आज हम उन चीजों पर एक नज़र डाल रहे हैं जो हम इसे अपनी क्षमता के अनुसार सबसे अच्छा प्रदर्शन करने के लिए कर सकते हैं, लेकिन इससे पहले कि हम गोता लगाएँ हालांकि, इनो डीबी में, हमें यह समझना चाहिए कि उपरोक्त एसीआईडी ​​मॉडल क्या है।

एसिड क्या है और यह क्यों महत्वपूर्ण है?

एसीआईडी ​​​​डेटाबेस लेनदेन के गुणों का एक समूह है। संक्षिप्त नाम चार शब्दों में अनुवाद करता है:परमाणुता, संगति, अलगाव और स्थायित्व। संक्षेप में, ये गुण सुनिश्चित करते हैं कि डेटाबेस लेनदेन विश्वसनीय रूप से संसाधित होते हैं और त्रुटियों, पावर आउटेज या ऐसे किसी भी मुद्दे के बावजूद डेटा वैधता की गारंटी देते हैं। एक डेटाबेस प्रबंधन प्रणाली जो इन सिद्धांतों का पालन करती है, उसे ACID-संगत DBMS कहा जाता है। यहां बताया गया है कि InnoDB में सब कुछ कैसे काम करता है:

• परमाणुता सुनिश्चित करती है कि लेन-देन में बयान एक अविभाज्य इकाई के रूप में काम करते हैं और उनके प्रभाव सामूहिक रूप से देखे जाते हैं या बिल्कुल नहीं;
• संगति को MySQL के लॉगिंग तंत्र द्वारा नियंत्रित किया जाता है जो डेटाबेस में सभी परिवर्तनों को रिकॉर्ड करता है;
• आइसोलेशन से तात्पर्य InnoDB के रो-लेवल लॉकिंग से है;
• स्थायित्व भी बनाए रखा जाता है क्योंकि InnoDB एक लॉग फ़ाइल रखता है जो सिस्टम में सभी परिवर्तनों को ट्रैक करती है।

InnoDB को समझना

अब जब हमने ACID को कवर कर लिया है, तो हमें शायद यह देखना चाहिए कि InnoDB हुड के नीचे कैसा दिखता है। यहां बताया गया है कि InnoDB अंदर से कैसा दिखता है (छवि पेरकोना के सौजन्य से):

उपरोक्त छवि से हम स्पष्ट रूप से देख सकते हैं कि InnoDB में कुछ इसके प्रदर्शन के लिए महत्वपूर्ण पैरामीटर और ये इस प्रकार हैं:

• Innodb_data_file_path पैरामीटर सिस्टम टेबलस्पेस का वर्णन करता है (सिस्टम टेबलस्पेस InnoDB डेटा डिक्शनरी के लिए स्टोरेज एरिया है, डबल राइट और चेंज बफ़र्स और अनडू लॉग्स)। पैरामीटर उस फ़ाइल को दर्शाता है जहां InnoDB तालिकाओं से प्राप्त डेटा संग्रहीत किया जाएगा;
• Innodb_buffer_pool_size पैरामीटर एक मेमोरी बफर है जिसका उपयोग InnoDB अपने टेबल के डेटा और इंडेक्स को कैश करने के लिए करता है;
• innodb_log_file_size पैरामीटर InnoDB लॉग फ़ाइलों के आकार को दर्शाता है;
• innodb_log_buffer_size पैरामीटर का उपयोग डिस्क पर लॉग फ़ाइलों को लिखने के लिए किया जाता है;
• innodb_flush_log_at_trx_commit पैरामीटर सख्त ACID अनुपालन और उच्च प्रदर्शन के बीच संतुलन को नियंत्रित करता है;
• innodb_lock_wait_timeout पैरामीटर सेकंड में समय की लंबाई है, एक InnoDB लेनदेन हार मानने से पहले एक पंक्ति लॉक की प्रतीक्षा करता है;
• innodb_flush_method पैरामीटर डेटा को InnoDB डेटा फ़ाइलों और लॉग फ़ाइलों में फ़्लश करने के लिए उपयोग की जाने वाली विधि को परिभाषित करता है जो I/O थ्रूपुट को प्रभावित कर सकता है।

InnoDB भी ibdata1 नामक फ़ाइल में अपनी टेबल से डेटा संग्रहीत करता है - लॉग हालांकि ib_logfile0 और ib_logfile1 नामक दो अलग-अलग फ़ाइलों में संग्रहीत होते हैं:उन सभी तीन फ़ाइलें /var/lib/mysql में रहती हैं निर्देशिका।

InnoDB को जितना संभव हो उतना बेहतर बनाने के लिए, हमें अपने उपलब्ध हार्डवेयर संसाधनों को देखकर इन मापदंडों को ठीक करना चाहिए और जितना हो सके उन्हें अनुकूलित करना चाहिए।

उच्च प्रदर्शन के लिए InnoDB ट्यूनिंग

अपने हार्डवेयर पर InnoDB के प्रदर्शन को समायोजित करने के लिए, इन चरणों का पालन करें:

• Innodb_data_file_path को स्वचालित रूप से विस्तारित करने के लिए, सेटिंग में autoextend विशेषता निर्दिष्ट करें और सर्वर को पुनरारंभ करें। उदाहरण के लिए:

innodb_data_file_path=ibdata1:10M:autoextend

जब ऑटोएक्सटेंड पैरामीटर का उपयोग किया जाता है, तो डेटा फ़ाइल स्वचालित रूप से आकार में 8MB की वृद्धि के साथ हर बार स्थान की आवश्यकता होती है। एक नई ऑटो-विस्तारित डेटा फ़ाइल को भी इस तरह निर्दिष्ट किया जा सकता है (इस मामले में, नई डेटा फ़ाइल को ibdata2 कहा जाता है):

innodb_data_file_path=ibdata1:10M;ibdata2:10M:autoextend

• InnoDB का उपयोग करते समय, उपयोग किया जाने वाला मुख्य तंत्र बफर पूल है। InnoDB बफ़र पूल पर बहुत अधिक निर्भर करता है और सामान्य तौर पर, innodb_buffer_pool_size पैरामीटर सर्वर पर उपलब्ध कुल RAM का लगभग 60% से 80% होना चाहिए। ध्यान रखें कि OS में चल रही प्रक्रियाओं के लिए भी आपको कुछ RAM छोड़ देनी चाहिए;

• InnoDB का innodb_log_file_size जितना संभव हो उतना बड़ा सेट किया जाना चाहिए, लेकिन आवश्यकता से बड़ा नहीं। इस मामले में, ध्यान रखें कि एक बड़ा लॉग फ़ाइल आकार प्रदर्शन के लिए बेहतर है, लेकिन यह जितना बड़ा होगा, क्रैश के बाद उतना ही अधिक पुनर्प्राप्ति समय की आवश्यकता होगी। जैसे, कोई "एक आकार सभी फिट बैठता है" समाधान नहीं है, लेकिन ऐसा कहा जाता है कि लॉग फ़ाइलों का संयुक्त आकार काफी बड़ा होना चाहिए। यह MySQL सर्वर को नियमित रूप से चेकपॉइंटिंग और डिस्क फ्लशिंग गतिविधि पर काम करने में मदद करता है। यह बहुत अधिक CPU और डिस्क IO बचाता है और अपने चरम समय या उच्च कार्यभार गतिविधि के दौरान आसानी से चल सकता है। हालांकि अनुशंसित तरीका यह है कि आप स्वयं इसका परीक्षण और प्रयोग करें और स्वयं इष्टतम मूल्य पाएं;

• innodb_log_buffer_size मान कम से कम 16M पर सेट होना चाहिए। एक बड़ा लॉग बफर बड़े लेन-देन को डिस्क पर लॉग लिखने की आवश्यकता के बिना चलाने की अनुमति देता है, इससे पहले कि लेनदेन कुछ डिस्क I/O को सहेजता है;

• innodb_flush_log_at_trx_commit ट्यूनिंग करते समय, ध्यान रखें कि यह पैरामीटर तीन मानों - 0, 1 और 2 को स्वीकार करता है। 1 के मान के साथ आपको ACID अनुपालन मिलता है। और 0 या 2 के मान के साथ आपको अधिक प्रदर्शन मिलता है, लेकिन कम विश्वसनीयता क्योंकि उस स्थिति में लेन-देन जिसके लिए लॉग अभी तक डिस्क पर फ़्लश नहीं किए गए हैं, क्रैश में खो सकते हैं;

• innodb_lock_wait_timeout को उचित मान पर सेट करने के लिए, ध्यान रखें कि यह पैरामीटर सेकंड में समय को परिभाषित करता है (डिफ़ॉल्ट मान 50 है) इससे पहले निम्नलिखित त्रुटि जारी करना और वर्तमान विवरण को वापस लाना:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

• InnoDB में, कई फ्लश विधियाँ उपलब्ध हैं। डिफ़ॉल्ट रूप से यह सेटिंग विंडोज़ मशीनों पर "async_unbuffered" पर सेट होती है यदि मान NULL और Linux मशीनों में "fsync" पर सेट है। यहां बताया गया है कि तरीके क्या हैं और वे क्या करते हैं:

• आपको innodb_file_per_table सेटिंग को सक्षम करने पर भी विचार करना चाहिए। यह पैरामीटर MySQL 5.6 और उच्चतर में डिफ़ॉल्ट रूप से चालू है। यह पैरामीटर आपको InnoDB तालिकाओं से संबंधित प्रबंधन समस्याओं से छुटकारा दिलाता है, उन्हें अलग-अलग फ़ाइलों में संग्रहीत करता है और फूला हुआ मुख्य शब्दकोशों और सिस्टम तालिकाओं से बचता है। इस चर को सक्षम करने से एक निश्चित तालिका के दूषित होने पर डेटा पुनर्प्राप्ति जटिलता का सामना करने से भी बचा जाता है
• अब जब आपने ऊपर बताए गए निर्देशों के अनुसार इन सेटिंग्स को संशोधित कर दिया है, तो आप जाने के लिए लगभग तैयार हो जाएंगे! हालांकि इससे पहले कि आप मैदान में उतरें, आपको संभवतः संपूर्ण InnoDB अवसंरचना - ibdata1 की सबसे व्यस्त फ़ाइल पर नज़र रखनी चाहिए।

ibdata1 से निपटना

जानकारी के कई वर्ग हैं जो ibdata1 में संग्रहीत हैं:

1. InnoDB तालिकाओं का डेटा;
2. InnoDB तालिकाओं की अनुक्रमणिका;
3. InnoDB तालिका मेटाडेटा;
4. मल्टीवर्सन कंसुरेंसी कंट्रोल (एमवीसीसी) डेटा;
5. डबलराइट बफ़र - ऐसा बफ़र InnoDB को आधे-अधूरे पृष्ठों से पुनर्प्राप्त करने में सक्षम बनाता है। ऐसे बफर का उद्देश्य डेटा भ्रष्टाचार को रोकना है;
6. इन्सर्ट बफ़र - इस तरह के बफर का उपयोग InnoDB द्वारा एक ही पेज पर अपडेट को बफर करने के लिए किया जाता है ताकि उन्हें एक के बाद एक किया जा सके और एक के बाद एक नहीं किया जा सके।

बड़े डेटा सेट के साथ काम करते समय, ibdata1 फ़ाइल बहुत बड़ी हो सकती है और यह एक बहुत ही निराशाजनक समस्या का मूल हो सकता है - फ़ाइल केवल बढ़ सकती है और डिफ़ॉल्ट रूप से, यह सिकुड़ नहीं सकती है। आप MySQL को बंद कर सकते हैं और इस फ़ाइल को हटा सकते हैं लेकिन यह तब तक अनुशंसित नहीं है जब तक आप यह नहीं जानते कि आप क्या कर रहे हैं। हटाए जाने पर, MySQL ठीक से काम नहीं करेगा क्योंकि डिक्शनरी और सिस्टम टेबल चले गए हैं, इस प्रकार मुख्य सिस्टम टेबल दूषित है।

ibdata1 को हमेशा के लिए सिकोड़ने के लिए, इन चरणों का पालन करें:

1. InnoDB डेटाबेस से सभी डेटा डंप करें। आप इस क्रिया के लिए mysqldump या mysqlpump का उपयोग कर सकते हैं;
2. mysql, performance_schema और info_schema डेटाबेस को छोड़कर सभी डेटाबेस को छोड़ दें;
3. MySQL बंद करें;
4. अपनी my.cnf फ़ाइल में निम्नलिखित जोड़ें:

   [mysqld]
   innodb_file_per_table = 1
   innodb_flush_method = O_DIRECT
   innodb_log_file_size = 25% of innodb_buffer_pool_size
   innodb_buffer_pool_size = up to 60-80% of available RAM.

5. ibdata1 और ib_logfile* फ़ाइलें हटाएं (ये MySQL के अगले पुनरारंभ होने पर फिर से बनाई जाएंगी);
6. MySQL प्रारंभ करें और आपके द्वारा पहले लिए गए डंप से डेटा को पुनर्स्थापित करें। ऊपर बताए गए चरणों को करने के बाद, ibdata1 फ़ाइल अभी भी बढ़ेगी, लेकिन इसमें अब InnoDB तालिकाओं का डेटा नहीं होगा - फ़ाइल में केवल मेटाडेटा होगा और प्रत्येक InnoDB तालिका ibdata1 के बाहर मौजूद होगी। अब, यदि आप /var/lib/mysql निर्देशिका में जाते हैं, तो आप दो फाइलें देखेंगे जो आपके पास InnoDB इंजन के साथ प्रत्येक तालिका का प्रतिनिधित्व करती हैं। फाइलें इस तरह दिखेगी:
   1. demotable.frm
   2. demotable.ibd

.frm फ़ाइल में स्टोरेज इंजन हेडर होता है और .ibd फ़ाइल में आपकी टेबल का टेबल डेटा और इंडेक्स होता है।

हालांकि परिवर्तनों को लागू करने से पहले, अपने बुनियादी ढांचे के अनुसार मापदंडों को ठीक करना सुनिश्चित करें। ये पैरामीटर InnoDB प्रदर्शन को बना या बिगाड़ सकते हैं इसलिए हर समय उन पर नज़र रखना सुनिश्चित करें। अब आपको जाना अच्छा होगा!

सारांश

संक्षेप में, InnoDB के प्रदर्शन को अनुकूलित करना एक बड़ा लाभ हो सकता है यदि आप एक ही समय में डेटा अखंडता और उच्च प्रदर्शन की आवश्यकता वाले एप्लिकेशन विकसित करते हैं - InnoDB आपको यह बदलने की अनुमति देता है कि इंजन को कितनी मेमोरी की अनुमति है उपभोग, लॉग फ़ाइल का आकार बदलने के लिए, इंजन द्वारा उपयोग की जाने वाली फ्लश विधि और इसी तरह - ये परिवर्तन InnoDB को बहुत अच्छा प्रदर्शन कर सकते हैं यदि उन्हें ठीक से ट्यून किया गया हो। हालांकि, कोई भी एन्हांसमेंट करने से पहले, अपने सर्वर और MySQL दोनों पर अपने कार्यों के परिणामों से सावधान रहें।

हमेशा की तरह, प्रदर्शन के लिए कुछ भी अनुकूलित करने से पहले हमेशा बैकअप लें (और परीक्षण करें!) ताकि यदि आवश्यक हो तो आप अपने डेटा को पुनर्स्थापित कर सकें और उत्पादन में परिवर्तन करने से पहले हमेशा स्थानीय सर्वर पर किसी भी बदलाव का परीक्षण कर सकें।