साल के सबसे बड़े ऑनलाइन-शॉपिंग दिन आने ही वाले हैं। क्या आपका डेटाबेस तैयार है? 20 प्रमुख मारियाडीबी सिस्टम वैरिएबल को ट्यून करके, आप अपने डेटाबेस के प्रदर्शन . को मजबूत करेंगे , मापनीयता और उपलब्धता , यह सुनिश्चित करना कि प्रत्येक संभावित ग्राहक के पास सहज उपयोगकर्ता अनुभव हो। एक इष्टतम मारियाडीबी सर्वर वातावरण को कॉन्फ़िगर करने में निम्नलिखित सिस्टम चर बार-बार आते हैं। सबसे बेहतर मूल्यों के लिए हमारी सिफारिशों को लागू करें, और इस साल के ब्लैक फ्राइडे-साइबर मंडे की अवधि को अपना सर्वश्रेष्ठ बनाएं।
कुछ महत्वपूर्ण नोट:
- इन सुझावों को आँख बंद करके स्वीकार न करें। प्रत्येक MariaDB वातावरण अद्वितीय है और कोई भी परिवर्तन करने से पहले अतिरिक्त विचार की आवश्यकता होती है। सबसे अधिक संभावना है कि आपको अपने विशिष्ट उपयोग के मामले और परिवेश के लिए इन सेटिंग्स को समायोजित करने की आवश्यकता होगी।
- MariaDB कॉन्फ़िगरेशन फ़ाइल /etc/my.cnf में स्थित है। हर बार जब आप इस फ़ाइल को संशोधित करते हैं तो आपको MySQL सेवा को पुनरारंभ करना होगा ताकि नए परिवर्तन प्रभावी हो सकें।
20 ब्लैक फ्राइडे और साइबर मंडे ट्यूनिंग अनुशंसाएं
1. InnoDB बफर पूल आकार
InnoDB बफ़र पूल आकार InnoDB का उपयोग करके किसी भी इंस्टॉलेशन को देखने के लिए यह #1 सेटिंग है। बफर पूल वह जगह है जहां डेटा और इंडेक्स कैश किए जाते हैं; जितना संभव हो उतना बड़ा होने से यह सुनिश्चित होगा कि आप मेमोरी का उपयोग करते हैं न कि अधिकांश रीड ऑपरेशंस के लिए डिस्क।
2. InnoDB लॉग फ़ाइल का आकार
innodb_log-file-size फिर से किए गए लॉग का आकार है, जिनका उपयोग यह सुनिश्चित करने के लिए किया जाता है कि लेखन तेज़ और टिकाऊ है। InnoDB लॉग फ़ाइल का आकार बदलने के लिए दो सामान्य सुझाव हैं:
- InnoDB लॉग फ़ाइलों का संयुक्त कुल आकार सेट करें जो InnoDB बफर पूल आकार के 25-50% से अधिक हो
या
- पीक लोड के दौरान एक घंटे की लॉग प्रविष्टियों के बराबर संयुक्त इनोडीबी लॉग फ़ाइल लॉग आकार सेट करें
सर्वर क्रैश होने की स्थिति में बड़ी लॉग फ़ाइलें धीमी गति से पुनर्प्राप्ति का कारण बन सकती हैं. हालांकि, वे आवश्यक चौकियों की संख्या को भी कम करते हैं और डिस्क I/O को कम करते हैं।
ऑपरेशनल लोड के तहत एक घंटे के बाइनरी लॉग के आकार का मूल्यांकन करें, फिर तय करें कि InnoDB लॉग फ़ाइलों का आकार बढ़ाया जाए या नहीं।
अच्छे सिस्टम प्रदर्शन को प्राप्त करने के लिए innodb लॉग फ़ाइल का आकार सही होना महत्वपूर्ण है। मारियाडीबी का इनोडीबी स्टोरेज इंजन एक निश्चित आकार (गोलाकार) रीडो लॉग स्पेस का उपयोग करता है। आकार को innodb_log_file_size और innodb_log_files_in_group (डिफ़ॉल्ट 2) द्वारा नियंत्रित किया जाता है। उपयोग के लिए उपलब्ध फिर से लॉग स्थान प्राप्त करने के लिए उन मानों को गुणा करें। जबकि तकनीकी रूप से इससे कोई फर्क नहीं पड़ता कि आप फिर से स्थान आकार को नियंत्रित करने के लिए innodb_log_file_size या innodb_log_files_in_group चर का उपयोग करते हैं, अधिकांश लोग केवल innodb_log_file_size के साथ काम करते हैं और innodb_log_files_in_group को अकेला छोड़ देते हैं।
InnoDB का रीडो स्पेस आकार लेखन-गहन कार्यभार के लिए सबसे महत्वपूर्ण कॉन्फ़िगरेशन विकल्पों में से एक है। हालाँकि, यह ट्रेड-ऑफ़ के साथ आता है। जितना अधिक रीडो स्पेस कॉन्फ़िगर किया जाएगा, उतना ही बेहतर InnoDB राइट I/O को ऑप्टिमाइज़ कर सकता है। हालांकि, रीडो स्पेस को बढ़ाने का मतलब यह भी है कि जब सिस्टम बिजली खो देता है या अन्य कारणों से क्रैश हो जाता है तो रिकवरी में अधिक समय लगता है।
3. InnoDB लॉग बफ़र आकार
एक बड़ा InnoDB लॉग बफर आकार का अर्थ है बड़े लेनदेन के लिए कम डिस्क I/O। सभी सर्वरों पर इसे 64M पर सेट करने का सुझाव दिया गया है।
4. InnoDB लॉग फ्लश अंतराल
innodb_flush_log_at_trx_commit चर नियंत्रित करता है जब लॉग बफर को डिस्क पर फ्लश किया जाता है। innodb_flush_log_at_trx_commit =1 (डिफ़ॉल्ट) प्रत्येक लेन-देन प्रतिबद्ध पर लॉग बफर को डिस्क पर फ्लश करता है। यह सबसे सुरक्षित लेकिन कम से कम प्रदर्शन करने वाला विकल्प भी है।
innodb_flush_log_at_trx_commit =0 लॉग बफर को हर सेकेंड में डिस्क पर फ्लश करता है, लेकिन लेन-देन प्रतिबद्ध पर कुछ भी नहीं। एक सेकंड तक (संभवतः प्रक्रिया शेड्यूलिंग के कारण अधिक) खो सकता है। यदि कोई दुर्घटना होती है, तो MySQL या सर्वर डेटा खो सकता है। यह सबसे तेज़ लेकिन कम से कम सुरक्षित विकल्प है।
innodb_flush_log_at_trx_commit =2 लॉग बफ़र को प्रत्येक कमिट पर फ़ाइल करने के लिए लिखता है लेकिन हर सेकंड डिस्क पर फ़्लश करता है। यदि डिस्क कैश में बैटरी बैकअप है (उदाहरण के लिए बैटरी समर्थित कैश रेड कंट्रोलर) तो यह आमतौर पर प्रदर्शन और सुरक्षा का सबसे अच्छा संतुलन है। MySQL के क्रैश होने से डेटा नहीं खोना चाहिए। एक सर्वर क्रैश या पावर आउटेज एक सेकंड तक खो सकता है (संभवतः प्रक्रिया शेड्यूलिंग के कारण अधिक)। बैटरी-समर्थित कैश इस संभावना को कम करता है।
हम सुरक्षा के लिए पहले विकल्प का उपयोग करने का सुझाव देते हैं।
5. InnoDB IO क्षमता
innodb_io_capacity को उस IOPS की अधिकतम संख्या पर सेट किया जाना चाहिए जिसे अंतर्निहित संग्रहण संभाल सकता है।
डिफ़ॉल्ट रूप से यह 1000 पर सेट होता है। हम यह निर्धारित करने के लिए भंडारण को बेंचमार्क करने की अनुशंसा करते हैं कि क्या आप इस मान को और बढ़ा सकते हैं।
<मजबूत>6. थ्रेड कैश आकार
Threads_created के मान की निगरानी करें। अगर यह कुछ थ्रेड प्रति मिनट से अधिक बढ़ता रहता है, तो thread_cache_size का मान बढ़ाएँ।
वर्तमान डिफ़ॉल्ट कॉन्फ़िगरेशन में थ्रेड कैश आकार 200 पर सेट है।
<मजबूत>7. टेबल कैश और टेबल डेफिनिशन कैश
table_open_cache और table_defintion_cache वैरिएबल सभी थ्रेड के लिए खुले रखने के लिए टेबल और परिभाषाओं की संख्या को नियंत्रित करते हैं।
सर्वोत्तम मान निर्धारित करने के लिए Open_tables, Open_table_definitions, Opened_tables, और Open_table_definitions की निगरानी करें। सामान्य सुझाव है कि Opened_tables (और Opened_table_definitions) स्थिति मान में वृद्धि की दर को कम करने के लिए केवल table_open_cache (और बाद में table_definition_cache) को इतना ऊंचा सेट किया जाए।
डिफ़ॉल्ट कॉन्फ़िगरेशन में दोनों table_open_cache और table_defintion_cache 2048 पर सेट हैं।
8. क्वेरी कैश
क्वेरी कैश एक प्रसिद्ध अड़चन है जिसे समवर्ती मध्यम होने पर भी देखा जा सकता है। सबसे अच्छा विकल्प यह है कि इसे पहले दिन से ही अक्षम कर दिया जाए query_cache_size =0 (MariaDB 10 में डिफ़ॉल्ट) और पढ़ने की क्वेरी को गति देने के लिए अन्य तरीकों का उपयोग करें:अच्छा अनुक्रमण होना, रीड लोड को फैलाने के लिए प्रतिकृतियां जोड़ना या बाहरी कैश का उपयोग करना ( memcache या redis, उदाहरण के लिए)। यदि आपने पहले से ही अपने मारियाडीबी एप्लिकेशन को क्वेरी कैश सक्षम के साथ बनाया है और कभी भी कोई समस्या नहीं देखी है, तो क्वेरी कैश आपके लिए फायदेमंद हो सकता है। उस स्थिति में, यदि आप इसे अक्षम करने का निर्णय लेते हैं तो सावधान रहें।
9. अस्थायी तालिकाएँ, tmp_table_size, और max_heap_table_size
MySQL मेमोरी में अस्थायी तालिकाओं के आकार को सीमित करने के लिए max_heap_table_size और tmp_table_size के निचले हिस्से का उपयोग करता है। ये प्रति ग्राहक चर हैं। जबकि यह मान बड़ा होने पर डिस्क पर बनाए गए अस्थायी तालिकाओं की संख्या को कम करने में मदद मिल सकती है, यह सर्वर की मेमोरी क्षमता तक पहुंचने का जोखिम भी बढ़ाता है क्योंकि यह प्रति क्लाइंट है। आम तौर पर 32M से 64M वेरिएबल और आवश्यकतानुसार ट्यून दोनों के लिए सुझाया गया मान होता है।
अस्थायी तालिकाओं का उपयोग अक्सर GROUP BY, ORDER BY, DISTINCT, UNION, उप क्वेरी आदि के लिए किया जाता है। आदर्श रूप से, MySQL को इन्हें मेमोरी में बनाना चाहिए, डिस्क पर जितना संभव हो सके उतना कम।
यह ध्यान रखना महत्वपूर्ण है कि जॉइन का उचित रूप से उपयोग न करने वाली क्वेरी और बड़ी अस्थायी तालिकाएँ बनाना डिस्क पर अधिक संख्या में अस्थायी तालिकाओं का एक कारण हो सकता है। दूसरा कारण यह है कि मेमोरी स्टोरेज इंजन निश्चित लंबाई के कॉलम का उपयोग करता है और सबसे खराब स्थिति को मानता है। यदि स्तंभों का आकार सही नहीं है (उदाहरण के लिए, एक छोटी स्ट्रिंग के लिए एक VARCHAR(255), तो यह स्मृति में तालिका के आकार को प्रभावित करता है और इसके कारण यह डिस्क पर जाने से पहले हो सकता है। साथ ही, ब्लॉब और टेक्स्ट कॉलम वाली अस्थायी टेबल तुरंत डिस्क पर चली जाएंगी, क्योंकि मेमोरी स्टोरेज इंजन उनका समर्थन नहीं करता है।
दोनों वर्तमान में डिफ़ॉल्ट रूप से 64M पर सेट हैं।
10. चेतावनी लॉग स्तर
हम चेतावनी लॉग स्तर को इसे log_warnings =2 पर सेट करने की अनुशंसा करते हैं। ऐसा करने से निरस्त कनेक्शन और एक्सेस-अस्वीकृत त्रुटियों के बारे में जानकारी लॉग हो जाती है।
<मजबूत>11. अधिकतम कनेक्शन
यदि आप अक्सर "बहुत अधिक कनेक्शन" त्रुटि का सामना कर रहे हैं, तो max_connections बहुत कम है। अक्सर, क्योंकि एप्लिकेशन डेटाबेस से कनेक्शन को सही ढंग से बंद नहीं करता है, आपको डिफ़ॉल्ट 151 कनेक्शन से कहीं अधिक की आवश्यकता होती है। max_connections (जैसे, 1,000 या अधिक) के लिए उच्च मूल्यों का मुख्य दोष यह है कि सर्वर अनुत्तरदायी हो जाएगा यदि उसे कई सक्रिय लेनदेन चलाना होगा। एप्लिकेशन स्तर पर कनेक्शन पूल या मारियाडीबी स्तर पर थ्रेड पूल का उपयोग करने से यहां मदद मिल सकती है।
12. लेन-देन अलगाव
उपलब्ध लेन-देन अलगाव स्तरों की जांच करें, और अपने सर्वर के उपयोग के मामले के लिए सर्वोत्तम लेनदेन अलगाव निर्धारित करें।
13. बाइनरी लॉग प्रारूप
हम मास्टर-मास्टर प्रतिकृति के लिए ROW बाइनरी लॉग प्रारूप का उपयोग करने की सलाह देते हैं।
<मजबूत>14. ऑटो-इन्क्रीमेंट ऑफ़सेट
एक साथ लिखे जा रहे दो मास्टर्स के बीच टकराव की संभावना को कम करने में सहायता के लिए, ऑटो इंक्रीमेंट और ऑटो इंक्रीमेंट ऑफ़सेट मानों को तदनुसार समायोजित करने की आवश्यकता है।
15. सिंक बिनलॉग
डिफ़ॉल्ट रूप से, OS बिनलॉग को डिस्क पर फ्लश करने का काम संभालता है। सर्वर क्रैश होने की स्थिति में, बाइनरी लॉग से लेन-देन खोना संभव है, जिससे प्रतिकृति सिंक से बाहर हो जाती है। सिंक_बिनलॉग =1 सेट करने से बिनलॉग फ़ाइल हर कमिट पर फ़्लश हो जाती है।
यह धीमा है, लेकिन सबसे सुरक्षित विकल्प है।
16. क्रैश सेफ(आर) गुलाम
स्लेव क्रैश के बाद प्रतिकृति त्रुटियों से बचने में मदद के लिए, रिले लॉग को पुनर्प्राप्त करने और रिले लॉग को सिंक करने और डिस्क पर लॉग जानकारी फ़ाइलों को रिले करने में सक्षम करें।
<मजबूत>17. लॉग स्लेव अपडेट
जंजीर प्रतिकृति (मास्टर -> दास -> दास) के लिए, log_slave_updates को सक्षम करने की आवश्यकता है। यह एक दास को अपने स्वयं के बाइनरी लॉग में दोहराए गए लेन-देन लिखने के लिए कहता है ताकि उन्हें इसके बाद के दासों को दोहराया जा सके।
<मजबूत>18. केवल पढ़ने के लिए गुलाम
दासों को गलती से डेटा लिखे जाने से बचने के लिए उन्हें केवल पढ़ने के लिए होना चाहिए।
नोट :सुपर विशेषाधिकार वाले उपयोगकर्ता तब भी लिख सकते हैं जब सर्वर केवल-पढ़ने के लिए हो।
19. स्लेव नेट टाइमआउट
स्लेव_नेट_टाइमआउट वैरिएबल सेकंड की वह संख्या है, जो दास फिर से कनेक्ट करने का प्रयास करने से पहले मास्टर से पैकेट की प्रतीक्षा करेगा। डिफ़ॉल्ट 3600 (1 घंटा) है। इसका मतलब है कि यदि लिंक नीचे चला जाता है और पता नहीं चलता है, तो दास के फिर से जुड़ने में एक घंटे तक का समय लग सकता है। इससे दास अचानक मालिक से एक घंटे तक पीछे रह सकता है।
हम अनुशंसा करते हैं कि गुलाम_नेट_टाइमआउट को 30 या 60 जैसे अधिक उचित मान पर सेट करें।
20. ब्लैक फ्राइडे और साइबर मंडे की तैयारी पर हमारा वेबिनार देखें
डेटाबेस की तैयारी के चार महत्वपूर्ण सिद्धांतों को जानने के लिए हमारा ऑन-डिमांड वेबिनार देखें - ब्लैक फ्राइडे और साइबर मंडे की तैयारी: सुरक्षा उपाय अपने डेटाबेस को दुर्भावनापूर्ण हमलों से बचाने के लिए, प्रदर्शन ट्यूनिंग यह सुनिश्चित करने के लिए कि आप एक सहज उपयोगकर्ता अनुभव प्रदान करते हैं, उच्च उपलब्धता रणनीतियाँ यह सुनिश्चित करने के लिए कि आप एक भी बिक्री और मापनीयता से न चूकें प्रत्याशित वृद्धि और अप्रत्याशित वृद्धि दोनों के लिए तैयार करने के लिए।
