11 "खाना पकाने के लिए व्यंजनों" MySQL Bitrix24 में

हमारे नए बड़े प्रोजेक्ट - बिट्रिक्स 24 को डिजाइन, डेवलप और लॉन्च करते समय , हम न केवल टीम के काम के लिए वास्तव में एक अच्छी सेवा बनाना चाहते थे (और 12 उपयोगकर्ताओं तक मुफ्त भी), लेकिन क्लाउड के संचालन में अनुभव को इकट्ठा करने और जमा करने के लिए भी। वेब सेवाएं, "लोड ओवर" करने के लिए अत्यधिक भरी हुई गलती-सहिष्णु परियोजनाओं के विकास में उनकी क्षमता और - सबसे महत्वपूर्ण बात - इस ज्ञान को हमारे भागीदारों और सभी वेब डेवलपर्स के साथ साझा करने के लिए जो "हाईलोड" के विषय के करीब हैं। :)

बेशक, एक लेख में (और एक में भी नहीं) एक सार्वभौमिक "नुस्खा" का वर्णन करना असंभव है जो बिल्कुल सभी परियोजनाओं के लिए उपयुक्त होगा: कुछ के लिए, उत्पादकता अधिक महत्वपूर्ण है (कभी-कभी - यहां तक ​​कि विश्वसनीयता की गिरावट), किसी के लिए - इसके विपरीत, गलती सहिष्णुता इन सबसे ऊपर, कहीं-कहीं कई छोटी-छोटी मेजें हैं, कहीं-कहीं बड़ी मात्रा में डेटा है ...

हमने उन "हाइलाइट्स" का वर्णन करने की कोशिश की जो एक से अधिक बार कुछ व्यावहारिक समस्याओं को हल करने में हमारे काम में मदद की हैं। हमें उम्मीद है कि आप उन्हें उपयोगी पाएंगे। :)

चलिए शुरू करते हैं।

हमने पहले ही एक से अधिक बार कहा और लिखा है कि Bitrix24 अमेज़न में तैनात है। और जब से हम प्यार करते हैं और सक्रिय रूप से विभिन्न क्लाउड सेवाओं का उपयोग करते हैं, तो पहला सवाल ...

1. आरडीएस का उपयोग क्यों नहीं?

Amazon Relational Database Service (Amazon RDS) एक क्लाउड-आधारित डेटाबेस है। एमएस एसक्यूएल, ओरेकल के लिए समर्थन है और - जो हमारे लिए दिलचस्प था - MySQL।

हमने लंबे समय तक करीब से देखा, इसे अपनी परियोजना में उपयोग करना चाहते थे ... नतीजतन, हमने इस विचार को छोड़ दिया। कुछ प्रमुख कारण:

• सबसे पहले, सिस्टम लचीला और पारदर्शी पर्याप्त नहीं है। उदाहरण के लिए, आपको डेटाबेस में पूर्ण रूट एक्सेस नहीं मिलता है। और इसका मतलब है कि कुछ विशिष्ट (विशेष रूप से आपकी परियोजना के लिए) सेटिंग्स बाहर काम नहीं कर सकती हैं।
• किसी भी दुर्घटना की स्थिति में एक लंबे डाउनटाइम का जोखिम होता है। और अभ्यास से पता चलता है कि यह जोखिम काफी वास्तविक है। हां, केवल एक ज़ोन में स्थित आधार अधिक बार प्रभावित होते हैं, और तथाकथित सह-AZ DB उदाहरणों का उपयोग दोष सहिष्णुता सुनिश्चित करने के लिए किया जा सकता है। लेकिन - उनके बारे में आगे ...
• जब एक डेटाबेस के लिए मल्टी-एज़ डीबी इंस्टेंस का उपयोग किया जाता है, तो एक स्टैंडबाय बैकअप लगातार दूसरे ऐज़ (उपलब्धता क्षेत्र) को लिखा जाता है, और पहले ज़ोन में दुर्घटना होने पर, यह स्वचालित रूप से दूसरे पर स्विच हो जाता है। लेकिन इस मामले में, आधार के साथ एक उदाहरण बिल्कुल दो गुना अधिक महंगा है। उसी समय, उपयोगकर्ता प्रभावी रूप से केवल एक मशीन (मास्टर-प्रतिकृति योजना के विपरीत, जिसे हमने हाल ही में लिखा था ) के संसाधनों का उपयोग करता है।

इसका मतलब यह नहीं है कि आरडीएस एक खराब सेवा है, और इसका उपयोग कभी नहीं किया जाना चाहिए। ऐसा नहीं है। वह हमारे लिए विशेष रूप से फिट नहीं थे। और, शायद, किसी के लिए अमेज़ॅन टूल के साथ स्केलिंग और गलती सहिष्णुता प्रदान करना बहुत आसान होगा।

2. मास्टर-गुलाम? नहीं, मास्टर-मास्टर!

MySQL में मानक मास्टर-स्लेव प्रतिकृति योजना लंबे समय से कई परियोजनाओं पर सफलतापूर्वक उपयोग की गई है और कई समस्याओं को हल करती है: लोड स्केलिंग (रीड-ओनली) - दासों के लिए प्रश्नों (चयन) का पुनर्वितरण, गलती सहिष्णुता।

लेकिन फैसला करता है - पूरी तरह से नहीं।

1. मैं स्केल और रिकॉर्ड करना चाहता हूं।
2. मैं एक विश्वसनीय विफलता चाहता हूं और किसी भी दुर्घटना के मामले में स्वचालित रूप से काम करना जारी रखूंगा (गुरु पर दुर्घटना के मामले में, आपको गुलामों में से एक को मैनुअल या अर्ध-स्वचालित मोड में मास्टर की भूमिका में बदलना होगा)।

इन समस्याओं को हल करने के लिए, हम "मास्टर-मास्टर" प्रतिकृति का उपयोग करते हैं। मैं अब खुद को नहीं दोहराऊंगा, हाल ही में एक अलग पोस्ट इस तकनीक के लिए समर्पित किया गया है।

3. MySQL? नहीं, Percona सर्वर!

पहले कुछ महीनों (प्रोटोटाइप पर, विकास प्रक्रिया में, सेवा के बंद बीटा परीक्षण की शुरुआत में), हमने मानक MySQL पर काम किया। और जितनी देर उन्होंने काम किया, उतने ही वे विभिन्न कांटों को देखते रहे। सबसे दिलचस्प, हमारी राय में, पेरकोना सर्वर और मारियाबीडी थे ।

अंत में, हमने एक समान "उल्टे" लोगो के कारण, पर्कन को चुना। ;)



... और कुछ विशेषताएं जो हमारे लिए बेहद महत्वपूर्ण थीं:

• Percona Server धीमी डिस्क के साथ काम करने के लिए अनुकूलित है। और यह "क्लाउड" के लिए बहुत सही है - "आयरन" सर्वर में नियमित ड्राइव की तुलना में ड्राइव हमेशा पारंपरिक रूप से धीमे (दुर्भाग्य से) होते हैं। सॉफ्टवेयर छापे का संगठन समस्या को अच्छी तरह हल करता है (हम RAID-10 का उपयोग करते हैं), लेकिन सर्वर-साइड अनुकूलन केवल एक प्लस है।
• एक डेटाबेस (डेटा की एक बड़ी राशि के साथ) को पुनः आरंभ करना एक महंगा लंबा ऑपरेशन है। Percon में कई विशेषताएं हैं जो आपको बहुत तेज़ी से पुनरारंभ करने की अनुमति देती हैं - फास्ट शट-डाउन, बफर पूल प्री-लोड। उत्तरार्द्ध आपको पुनरारंभ के दौरान बफर पूल की स्थिति को बचाने की अनुमति देता है और इस तरह शुरू होने के तुरंत बाद "वार्म अप" आधार प्राप्त करता है (और उस पर लंबे समय तक खर्च नहीं करता है)।
• बहुत सारे काउंटर और उन्नत रिपोर्ट (उपयोगकर्ताओं द्वारा, तालिकाओं द्वारा, SHOW Engine INNODB STATUS, इत्यादि का विस्तारित आउटपुट), जो खोजने में मदद करता है, उदाहरण के लिए, सिस्टम को लोड करने वाले सबसे "क्लाइंट"।
• XtraDB स्टोरेज इंजन - मानक InnoDB के साथ पिछड़े संगत, जबकि हाईलोड परियोजनाओं के लिए बेहतर अनुकूलित।

एक पूरी सूची पेरकोना सर्वर फ़ीचर तुलना अनुभाग में वेबसाइट पर देखी जा सकती है।

एक महत्वपूर्ण बिंदु - मानक MySQL से Percona सर्वर तक संक्रमण को किसी भी कोड या एप्लिकेशन लॉजिक के किसी भी संशोधन की आवश्यकता नहीं थी।

और, यहां, "चलती" की प्रक्रिया काफी दिलचस्प थी। और "मास्टर-मास्टर" प्रतिकृति के साथ योजना के उपयोग के लिए धन्यवाद, यह हमारे उपयोगकर्ताओं द्वारा पूरी तरह से ध्यान नहीं दिया गया। बस कोई डाउनटाइम नहीं था।

चलती योजना इस प्रकार थी:

• "शून्य" चरण - उन्होंने असली डेटा के साथ आधार के साथ अपनी स्नैपशॉट मशीन के लिए परीक्षण बेंच को उठाया। और यह स्थिर संचालन के लिए कॉन्फ़िगरेशन को डीबग करना शुरू कर दिया। और, निश्चित रूप से, कॉन्फ़िगरेशन फ़ाइल में पेरकोना-विशिष्ट विकल्प चुनें।
• एक स्थिर कॉन्फ़िगरेशन प्राप्त करने के बाद, हमने सभी ट्रैफ़िक को एक DC पर स्विच किया, और डेटाबेस को लोड के बिना प्रतिकृति से स्विच किया गया।
• इस आधार पर, हम पेरकोना सर्वर पर चले गए।
• आधार को प्रतिकृति में शामिल करें (मानक MySQL और Percona सर्वर संगत)।
• डेटा सिंक्रनाइज़ेशन के लिए प्रतीक्षा की जा रही है।
• उसके बाद उन्होंने दूसरे आधार के साथ भी यही प्रक्रिया की।

4. MyISAM? InnoDB?

यहां सब कुछ सरल है।

• MyISAM में लंबे प्रश्नों पर पूरी तालिका बंद है। InnoDB में, केवल वे लाइनें जिनके साथ हम काम करते हैं। तदनुसार, InnoDB में, लंबे अनुरोधों से अन्य अनुरोधों को प्रभावित करने की संभावना कम होती है और उपयोगकर्ता अनुभव को प्रभावित नहीं करते हैं।
• बड़ी मात्रा में डेटा और उच्च भार के तहत, MyISAM तालिकाओं को तोड़ते हैं। यह एक ज्ञात तथ्य है। यह हमारी सेवा में अस्वीकार्य है।
• खैर, चूंकि हमारे पास "सुधार" इनोबीडी - एक्स्ट्राबेड है, निश्चित रूप से, हम इस भंडारण इंजन का उपयोग करेंगे। :)

* * *

हम वास्तुशिल्प मुद्दों से अधिक व्यावहारिक लोगों को पास करते हैं। :)

5. क्या सभी डेटा को दोहराने की आवश्यकता है? नहीं, बिलकुल नहीं।

लगभग किसी भी परियोजना में नुकसान-महत्वपूर्ण या पुनर्प्राप्त करने योग्य डेटा है। सहित - और डेटाबेस में।

हमारे मामले में, इस तरह के डेटा सत्र थे। हर चीज की नकल करने में क्या गलत था?

• सत्र तालिकाओं में, चयनों के साथ, कई लेखन कार्य (INSERT, UPDATE, DELETE) हैं। इसका मतलब है कि हम दास आधार को अतिरिक्त भार देते हैं। वह भार जिसे टाला जा सकता है।
• इसके अलावा, query_cache_size के पर्याप्त रूप से बड़े मूल्य के साथ, हमें इस तथ्य का सामना करना पड़ता है कि इन तालिकाओं के साथ सक्रिय कार्य और प्रतिकृति में उनकी भागीदारी इस तथ्य की ओर ले जाती है कि कई थ्रेड्स "लटका" क्वेरी कैश लॉक " स्थिति " (SHOW PROCESSLIST में देखा गया)। इसके अलावा, यह सीपीयू पर बढ़ते भार और प्रदर्शन के सामान्य क्षरण से भरा हुआ है।

प्रतिकृति से इस डेटा को छोड़कर समस्या को पूरी तरह से हल किया।

बाहर कैसे करें? इसके अलग-अलग तरीके हैं।

1. आवेदन स्तर पर, उस कनेक्शन में जहां हम उन तालिकाओं के साथ काम कर रहे हैं जिन्हें हम प्रतिकृति से बाहर करना चाहते हैं, हम प्रदर्शन करते हैं:

SET sql_log_bin = 0; 

2. MySQL कॉन्फ़िगरेशन फ़ाइल में एक अपवाद निर्दिष्ट करने के लिए एक सरल और अधिक सहज तरीका है।

 replicate-wild-ignore-table = %.b_sec_session 

यह डिज़ाइन प्रतिकृति से सभी डेटाबेस में b_sec_session टेबल को बाहर करता है।

यदि आपको अधिक जटिल तर्क की आवश्यकता है तो सब कुछ थोड़ा अधिक जटिल है। उदाहरण के लिए, db डेटाबेस को छोड़कर सभी डेटाबेस में टेबल टेबल की प्रतिकृति न करें।

इस मामले में, आपको विकल्पों के सही संयोजन को बनाने के लिए MySQL द्वारा प्रदान किए गए विकल्पों की तरह थोड़े-थोड़े स्कीमैटिक्स आकर्षित करने होंगे - फिल्टर।

• डेटाबेस-स्तर प्रतिकृति और बाइनरी लॉगिंग विकल्प का मूल्यांकन
• तालिका-स्तरीय प्रतिकृति विकल्पों का मूल्यांकन

6. प्रतिकृति का प्रकार।

बहुत सारे विवाद यह सवाल उठाते हैं कि क्या STATEMENT- आधारित या ROW- आधारित प्रतिकृति का उपयोग करना है। दोनों कि, और अन्य विकल्प दोनों pluses, और minuses के पास है ।

डिफ़ॉल्ट रूप से, MySQL (Percona) 5.5 STATEMENT- आधारित प्रतिकृति का उपयोग करता है।

इस कॉन्फ़िगरेशन में हमारे आवेदन पर, हमने नियमित रूप से लॉग इन लाइनों में देखा: "स्टेटमेंट फॉर्मेट में लॉग इन करने के लिए स्टेटमेंट सुरक्षित नहीं हो सकता है" ।

इसके अलावा, मास्टर प्रतिकृति मास्टर में दो डेटाबेस की तुलना से पता चला है कि डेटा में विसंगतियां हो सकती हैं। यह, ज़ाहिर है, अस्वीकार्य था।

MySQL का एक दिलचस्प समाधान है जो पूरी तरह से हमें सूट करता है - MIXED binlog प्रारूप का उपयोग करें:

 binlog-format = mixed 

इस मामले में, डिफ़ॉल्ट रूप से, प्रतिकृति स्थिति मोड में है और ऐसे असुरक्षित संचालन के मामले में केवल ROW पर स्विच करता है।

7. प्रतिकृति टूटी हुई है। क्या करें?

प्रतिकृति कभी-कभी टूट जाती है। विशेष रूप से डरावना (पहले :)) यह "मास्टर मास्टर" के साथ काम करते समय लगता है।

वास्तव में, चिंता की कोई बात नहीं है। सच तो यह है। :)

सबसे पहले, याद रखें कि वर्णित मास्टर-मास्टर प्रतिकृति योजना वास्तव में केवल दो सामान्य मास्टर-दास प्रतिकृति हैं। हां, कुछ बारीकियों के साथ, लेकिन मानक योजना में उपयोग की जाने वाली अधिकांश प्रथाएं यहां काम करती हैं।

सबसे सरल (और सबसे अधिक बार होने वाली) समस्या "1062 त्रुटि 'डुप्लिकेट प्रविष्टि' के रूप में एक त्रुटि है। "

कारण अलग हो सकते हैं। उदाहरण के लिए, आधार के साथ किसी भी दुर्घटना के मामले में, हम ट्रैफ़िक को किसी अन्य डीसी पर स्विच करते हैं। यदि अनुरोध पहले से ही डीसी 1 में निष्पादित किया गया है, लेकिन डीसी 2 में दोहराया जाने का प्रबंधन नहीं किया गया था और वहां फिर से निष्पादित किया गया था - हां, हमें बिल्कुल यह त्रुटि मिलेगी।

यह दास पर इन आदेशों को निष्पादित करके व्यवहार किया जाता है:

 STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; 

इस प्रकार, हम अतिरिक्त अनुरोध को छोड़ देते हैं। अगला, प्रतिकृति स्थिति देखें:

 SHOW SLAVE STATUS\G 

यदि आवश्यक हो, तो प्रक्रिया को दोहराएं।

* * *

हां, अब हम विस्तार से सबसे सरल विकल्प पर विचार कर रहे हैं। सब कुछ बहुत बुरा होता है - फ़ाइल सिस्टम टूट जाता है, फ़ाइल को हरा देता है, आदि।

कोई सार्वभौमिक नुस्खा नहीं है "सब कुछ कैसे ठीक करें"। लेकिन निम्नलिखित को याद रखना हमेशा महत्वपूर्ण होता है:

• घबराओ मत।
• SHOW SLAVE STATUS \ G का उपयोग करके दास की स्थिति देखें ।
• जादूगर की स्थिति का उपयोग करते हुए विज़ार्ड की स्थिति देखें ।
• हमेशा एक लॉग ( लॉग-एरर = /var/log/mysqld.log ) रखें - इसमें बहुत सारी उपयोगी जानकारी होती है। उदाहरण के लिए, गुलाम ने मास्टर बिनलॉग को किस स्थिति में पढ़ा, इस पर डेटा। यह दुर्घटनाओं के मामले में मदद करता है।
• यदि सब कुछ पूरी तरह से टूट गया है - बैकअप से उठो।

8. बैकअप मास्टर से प्रतिकृति मास्टर में से एक सर्वर कैसे बढ़ाएं?

दो-मास्टर योजना में कुछ गलत होने पर क्या करना है (उदाहरण के लिए, कुछ दिनों पहले अमेज़न में एक दुर्घटना के दौरान, कई सर्वरों पर फ़ाइल सिस्टम अपरिवर्तनीय रूप से क्षतिग्रस्त हो गए थे)?

"माथे पर" समाधान - एक सर्वर से दूसरे में डेटा स्थानांतरित करने और खरोंच से प्रतिकृति शुरू करने के लिए - बहुत लंबा।

अमेज़ॅन में, हम संपूर्ण मशीनों के लिए डिस्क स्नैपशॉट और इमेजिंग (एएमआई) तंत्र का उपयोग करते हैं । यह आपको वांछित सर्वर की पूरी प्रतिलिपि को जल्दी से तैनात करने की अनुमति देता है - उदाहरण के लिए, कुछ घंटों पहले।

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

हम यह करते हैं:

1. सभी ट्रैफ़िक "लाइव" डीसी पर जाता है। सर्वर पर कोई लोड नहीं है जिसे हम पुनर्स्थापित कर रहे हैं।
2. बैकअप से उठाए गए सर्वर पर, हम तुरंत mysqld को रोकते हैं और इसे कॉन्फ़िगरेशन में दर्ज करते हैं:

 skip-slave-start replicate-same-server-id #log-slave-updates = 1 ; ! 

3. mysqld शुरू करें और प्रतिकृति शुरू करें।
4. डेटा समन्‍वयित होने के बाद, हम कॉन्‍फ़िगरेशन को उसकी मूल स्थिति में लौटाते हैं:

 #skip-slave-start #replicate-same-server-id log-slave-updates = 1 

5. चूंकि हमारे पास एक "मास्टर मास्टर" है, इसलिए हमें विपरीत दिशा में प्रतिकृति शुरू करने की आवश्यकता है। हम उस सर्वर पर प्रतिकृति को रोकते हैं जिसे हमने बहाल किया था, और करते हैं:

 SHOW MASTER STATUS; 

यदि हम प्रतिकृति को बंद नहीं करते हैं, तो डेटा बदल जाएगा।
6. हम वांछित स्थिति से पहले (लाइव) सर्वर पर प्रतिकृति शुरू करते हैं:

 STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS = ...; START SLAVE; 

हम पैराग्राफ 5 में प्राप्त डेटा दर्ज करते हैं।
7. हम दूसरे सर्वर पर प्रतिकृति शुरू करते हैं।

9. प्रतिकृति के प्रदर्शन और विश्वसनीयता के बीच संतुलन क्या है?

MySQL / Percona में कई विकल्प हैं जो नाटकीय रूप से डेटा की विश्वसनीयता और सुरक्षा में सुधार कर सकते हैं, उदाहरण के लिए, अचानक विद्रोह। उनमें से लगभग सभी नाटकीय रूप से सिस्टम की गति को कम करते हैं।

हमने विकल्पों के इस संयोजन में अपने लिए एक संतुलन पाया:

 sync_binlog = 1 sync_master_info = 0 sync_relay_log = 0 sync_relay_log_info = 0 innodb-flush-log-at-trx-commit = 2 

बिनलॉग हमारे लिए महत्वपूर्ण है, इसलिए Sync_binlog = 1 । लेकिन एक ही समय में, बिनलॉग सिस्टम में एक अलग डिस्क पर संग्रहीत होते हैं, इसलिए इस डिस्क पर लिखने से सिस्टम के प्रदर्शन को समग्र रूप से कम नहीं किया जाता है।

10. मैं सिस्टम प्रदर्शन का मूल्यांकन कैसे करूँ?

यदि हमारे पास बड़े "भारी" अनुरोध हैं, तो निश्चित रूप से, हम उनके निष्पादन के समय पर तुच्छ रूप से उन्मुख हैं।

अधिक बार नहीं (और हमारे मामले में - वह तरीका है) सिस्टम कई, कई छोटे अनुरोधों को संसाधित करता है।

बेशक, आप सिस्टम प्रदर्शन का मूल्यांकन करने के लिए विभिन्न सिंथेटिक परीक्षणों का उपयोग कर सकते हैं। और वे कुछ प्रशंसा करेंगे। लेकिन आप वास्तव में कुछ वास्तविक संकेतक (अधिमानतः संख्याओं में) चाहते हैं कि "युद्ध में" का उपयोग किया जा सके।

पर्कोना सर्वर में एक महान उपकरण है:

 SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME; 

 +----------------+-------+----------------+ | time | count | total | +----------------+-------+----------------+ | 0.000001 | 0 | 0.000000 | | 0.000010 | 6555 | 0.024024 | | 0.000100 | 56132 | 2.326873 | | 0.001000 | 23165 | 6.686421 | | 0.010000 | 9755 | 39.737027 | | 0.100000 | 1437 | 40.831493 | | 1.000000 | 141 | 31.785571 | | 10.000000 | 9 | 17.891514 | | 100.000000 | 0 | 0.000000 | | 1000.000000 | 0 | 0.000000 | | 10000.000000 | 0 | 0.000000 | | 100000.000000 | 0 | 0.000000 | | 1000000.000000 | 0 | 0.000000 | | TOO LONG | 0 | TOO LONG | +----------------+-------+----------------+ 14 rows in set (0.00 sec) 

क्वेरी निष्पादन समय के वितरण का ऐसा हिस्टोग्राम सिस्टम की सामान्य स्थिति का मूल्यांकन करने में बहुत मदद करता है।

उदाहरण के लिए, हमने अपने लिए एक निश्चित महत्वपूर्ण सीमा निर्धारित की - 0.01 सेकंड से अधिक के रन समय के साथ अनुरोधों (कुल का 5%) से अधिक नहीं।

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

11. स्मृति संतुलन।

MySQL सेटिंग्स ऐसी होनी चाहिए कि मेमोरी की खपत संतुलित हो!

यह एक सरल और समझ में आने वाला नियम है, लेकिन इसे अक्सर भुला दिया जाता है। मैं स्वीकार करता हूं, कुछ समय (शुरुआत में, प्रोटोटाइप पर) :) हमें OOM (मेमोरी से बाहर) प्राप्त हुआ और, परिणामस्वरूप, mysqld प्रक्रिया ऑपरेटिंग सिस्टम द्वारा "मार" गई।

आदर्श रूप से, mysqld प्रक्रिया को इस तरह से काम करना चाहिए जैसे कि पूरी तरह से रैम में फिट होना चाहिए और स्वैप पर काम नहीं करना चाहिए।

अनिवार्य - सभी सिस्टम प्रक्रियाओं को मेमोरी + स्वैप में रखा जाना चाहिए।

अक्सर, कितनी स्मृति mysqld उपभोग कर सकते हैं की गणना कई के लिए स्पष्ट नहीं हैं।

सूत्र कुछ इस प्रकार है:

• वैश्विक बफर आकार: key_buffer_size + tmp_table_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size
• एक कनेक्शन के लिए बफ़र आकार: read_buffer_size + read_rnd_buffer_size + Sort_buffer_size + thread_stack + join_buffer_size
• अधिकतम स्मृति उपयोग: वैश्विक बफ़र्स + कनेक्शन बफ़र्स * अधिकतम कनेक्शन की संख्या

यदि आप वास्तव में विचार नहीं करना चाहते हैं :), आप mysqltuner.pl स्क्रिप्ट का उपयोग कर सकते हैं, जो इस जानकारी के अलावा सिस्टम, सुरक्षा, प्रदर्शन, आदि पर बहुत अधिक डेटा दिखाएगा।

 # wget mysqltuner.pl # perl mysqltuner.pl 

* * *

इस जगह को पढ़ने के लिए धन्यवाद! :)



हमने केवल कुछ व्यावहारिक मुद्दों और तकनीकों पर विचार किया जो हम Bitrix24 के काम में उपयोग करते हैं । उनके लिए धन्यवाद सहित, सेवा बढ़ रही है और विकसित हो रही है।

हमें उम्मीद है कि हमारा अनुभव आपको अपनी परियोजनाओं के निर्माण और विकास में मदद करेगा।

और अब यह स्पष्ट है कि एक लेख की मात्रा पूरी तरह से अपर्याप्त है। निकट भविष्य में हम बड़ी परियोजनाओं में MySQL का उपयोग करने के विषय को जारी रखने की कोशिश करेंगे, नए व्यंजनों को साझा करेंगे और सबसे दिलचस्प और प्रासंगिक विषयों का अधिक विस्तार से वर्णन करेंगे।