MySQL tmpfs के लिए

मैं MySQL का उपयोग मेमोरी में डेटा स्टोर करने के साथ अपने अनुभव को साझा करना चाहूंगा, डिस्क पर नहीं। इसने हमें सर्वर के लोड औसत को कम करने की अनुमति दी, जो डिस्क संचालन के कारण तेजी से बढ़ने लगा।











एक परियोजना में, हम डेबियन लेन के तहत MyISAM इंजन के साथ MySQL का उपयोग करते हैं। सामान्य डेटा को C ++ में डेमॉन की रैम में लोड किया जाता है, और उपयोगकर्ता डेटा को एक बार लॉगिन और समय-समय पर उपयोगकर्ता के काम के दौरान सहेजा जाता है। लॉगआउट (या टाइमआउट) के साथ भी सहेजा गया है। वर्णित योजना के मद्देनजर, चयन अपडेट की तुलना में बहुत छोटे हैं (चुनें: 24%, हटाएं: 4%, अपडेट: 61%, सम्मिलित करें: 11%)।



सिद्धांत रूप में, यह समस्या एक व्यवस्थापक समस्या नहीं है, लेकिन उपकरण के एक नहीं-तो-अच्छे विकल्प के कारण होती है। सबसे अधिक संभावना है कि, इनसोबीडी हमारे लिए उपयुक्त होगी, जो माईसम की तरह टेबल-लेवल लॉकिंग (लिखने के दौरान पूरी मेज को लॉक करने) के बजाय रो-लेवल लॉकिंग (रिकॉर्ड-आधारित लॉकिंग) का उपयोग करती है। यद्यपि डिस्क पर लिखे गए डेटा की मात्रा कम होने की संभावना नहीं है। दूसरी ओर, हमें वास्तव में एसक्यूएल की आवश्यकता नहीं है और हम इस परियोजना को NoSQL में पोर्ट करने के लिए इच्छुक हैं (हम कुछ प्रतिनिधियों को लंबे समय से देख रहे हैं (assandra), और हम सक्रिय रूप से कुछ (tokyo tantant, बर्कले DB) का उपयोग उपयोगकर्ता लॉगिंग के लिए कर रहे हैं)। लेकिन डेटा वेयरहाउस को किसी अन्य इंजन / डेटाबेस में स्थानांतरित करने का समय नहीं था, इसलिए हमने व्यवस्थापक का उपयोग करने का निर्णय लिया। संसाधन।



उपयोगकर्ताओं की संख्या में वृद्धि और नई सामग्री की शुरूआत के साथ, हमें डेटाबेस सर्वर पर लोड औसत में वृद्धि की समस्या का सामना करना पड़ा (8-कोर सर्वर पर 2-3 ला प्रति सेकंड केवल 400 अनुरोधों पर देखा गया था)। इसके अलावा, मेमोरी को अंडरलोड किया गया था, जैसा कि प्रोसेसर था। समस्या बड़ी, बड़ी मात्रा में डेटा डिस्क (इओविट में वृद्धि) के लिए लिखी जा रही थी। कुछ बिंदुओं पर, सिस्टम हकलाना शुरू कर दिया और कुछ आदिम प्रश्नों को 2 सेकंड, या इससे भी अधिक समय लगा। सामान्य मोड में, ऐसे अनुरोधों को मिलीसेकंड में निष्पादित किया जाता है।



हमने MySQL को थोड़ा अनुकूलित किया (ऑटोमैटिक स्क्रिप्ट्स जैसे mysqltuner और मैनुअल ट्यूनिंग का उपयोग करके) दोनों को कॉन्फ़िगर किया, लेकिन इसने केवल लोड में मामूली कमी (10-15 प्रतिशत) दी। अधिकांश भाग के लिए, कैशिंग डेटा के लिए ज़िम्मेदार पैरामीटर हमारे लिए उपयुक्त नहीं हैं, क्योंकि हमारा मुख्य बोझ डेटा को अपडेट कर रहा है, पढ़ना नहीं। आधार एसएएस डिस्क पर स्थित है, लेकिन गति अभी भी पर्याप्त नहीं है। बाइनरी लॉग एक अन्य डिस्क पर हैं (दास से डेटाबेस का बैकअप लेने के लिए उपयोग किया जाता है)।



पूर्ण RAID खरीदकर डिस्क सिस्टम के काम में तेजी लाने के कारण इसकी उच्च कीमत हमारे लिए उपयुक्त नहीं है। लेकिन सर्वर स्वयं लगभग निष्क्रिय है, यदि आप डिस्क पर विचार नहीं करते हैं। MyISAM में डिस्क पर लिखने से पहले मेमोरी में डेटा को संपीड़ित करने की कोई संभावना नहीं है, लेकिन अभी तक किसी अन्य इंजन पर स्विच करने की कोई संभावना नहीं है (फाल्कन को सक्षम होना चाहिए था, लेकिन Oracle ने MySQL खरीदने के बाद इसे छोड़ दिया)



हमारा डेटाबेस लगभग 2-2.5 Gb (tar.gz 700mb में) लेता है और लंबे समय तक हमने tmpfs (mylvmbackup पर आधारित एक विधि) में MySQL का उपयोग करने की कोशिश की, जिसने हमें डिस्क को लोड नहीं करने और बैकअप निर्माण को सरल बनाने की अनुमति दी। सौभाग्य से, हमने हाल ही में एक मुकुट को जोड़कर डेटाबेस को साफ किया, जो पुराने उपयोगकर्ताओं को हटा देता है जिन्होंने लगभग कभी परियोजना का उपयोग नहीं किया और कभी भुगतान नहीं किया। इसके अलावा, हमने आंकड़ों के लिए एकत्र किए गए पुराने डेटा को साफ किया और उन्हें लगभग दो महीने का जीवनकाल निर्धारित किया।



इस समस्या के त्वरित समाधान के रूप में, विचार मुख्य डेटाबेस को tmpfs में स्थानांतरित करने के लिए उत्पन्न हुआ। हमें क्या मिला:



और इसलिए हमारे पास 3 सर्वर थे:

1. सर्वर ए (एक मुकाबला बेस जहां राक्षसों ने दस्तक दी (हमारे पास इस पर 8 जी रैम है))

2. सर्वर बी (नि: शुल्क परिचालन के साथ एक ही मंच पर कोई भी सर्वर (हमारे पास 8 जी है जिसमें 5 जी मुफ्त है):

3. सर्वर बी (एक अन्य साइट पर यह अधिकतम रैम के साथ सभी परियोजनाओं के बैकअप के तहत जमीन है (हमारे पास 16 जी है)



और इसलिए सर्वर ए पर हम आधार फ़ाइलों के लिए tmpfs बढ़ाते हैं

आर-पार tmpfs -o आकार = 5G tmpfs / var / lib / mysql (बेस वेट से 2 गुना अधिक मार्जिन के साथ)

इसके अलावा, डेटाबेस के कॉन्फ़िगरेशन में लिखना न भूलें ताकि बिन लॉग एक अलग फ्री डिस्क (मास्टर उनके बिना काम न करें) को लिखे, और लोड के तहत, डेटाबेस इन लॉग्स को प्रति सेकंड 1M तक लिख सकता है। हम इन फ़ाइलों को 7 दिनों से अधिक समय तक संग्रहीत नहीं करते हैं (अब ज़रूरत नहीं है, क्योंकि स्लाइड्स होने पर डेटाबेस को पुनर्स्थापित करने के लिए)



तदनुसार, हम आधार को एक मास्टर के रूप में शुरू करते हैं। समान हार्डलोड के अंतर्गत सर्वर 1LA से बाहर नहीं जाता है और मेमोरी से 6G से अधिक नहीं होता है। औसत क्वेरी निष्पादन की गति दस गुना बढ़ी है, यदि पहले यह 0.1-0.3 सेकंड थी, तो यह 0.1-3 एमएस हो गई

अगला, सर्वर B पर, हम tmpfs में पहला दास भी बढ़ाते हैं, यहाँ आपको रिले-लॉग सेटिंग्स के बारे में नहीं भूलना चाहिए, क्योंकि यदि स्लाइड में कोई त्रुटि है, और विज़ार्ड इन लॉग्स में उपलब्ध है, तो वह उन अनुरोधों को लिखेगा जो विज़ार्ड में थे ... परिणामस्वरूप, इसे प्रति रात दस गीगाबाइट में मापा जा सकता है, इससे पहले कि आप स्लाइड को ठीक करें, हमारे पास प्रति घंटे लगभग 8-10 मिलियन गीगाबाइट्स हैं। हम दिन में 1-2 बार स्नैपशॉट के साथ इस बेस का बैकअप लेते हैं जब राक्षसों पर लोड न्यूनतम होता है। ऐसा गुलाम अधिकतम 0.2-0.3 विमान खाता है और आधार जितना वजन होता है उससे थोड़ा अधिक।



इसके अलावा, सर्वर बी पर, हमने तुरंत अपनी परियोजनाओं के लिए कई tmpfs स्लाइड्स को उठाया, वे सर्वर को लोड किए बिना बहुत तेज़ी से एक साथ रहते हैं, और साथ ही उन्हें हर 10 मिनट में स्नैपशॉट के साथ बैकअप दिया जाता है (यदि इस समय का विस्तार किया गया है, तो स्नैपशॉट लगभग 3 सेकंड में किया जाता है (बेस वजन 2.5 गीगा है) ) ठीक है, 6-7 मिनट के बारे में संग्रह में zhzhivanie) और एलए सर्वर पर भी 2 से अधिक नहीं है, यहां तक ​​कि जब बैकअप समय में ओवरलैप होता है। जाहिरा तौर पर, एक सर्वर पर बैकअप दासों की संख्या डेटाबेस के आकार और रैम की संख्या से निर्धारित होती है। हम 10 मिनट के लिए बैकअप स्टोर करते हैं - पिछले 24 घंटे, हर 6 घंटे - हम 30 दिन, हर 30 दिन - हमेशा के लिए स्टोर करते हैं।



इसके अलावा, अगर स्लाइड बी या सी अचानक गिर जाती है, तो इसे बिना किसी समस्या के मास्टर को छुए बिना किसी भी बैकअप से किसी भी बैकअप के साथ उठाएं, यहां तक ​​कि दोनों को मास्टर को छूने के बिना उठाने के लिए दोनों गिर जाते हैं - बैकअप की प्रतिलिपि बनाने की गति।

यदि मास्टर दुर्घटनाग्रस्त हो जाता है, अर्थात, स्वामी के पीछे अधिकतम 1-2 अपडेट के साथ उस पर दो दास होते हैं (मैंने स्लेव देरी (मास्टर के पीछे) को 0 सेकंड से अधिक नहीं देखा है), जबकि समस्या का तत्काल समाधान स्लेव बी से 5 मिनट के भीतर किया जाता है। मास्टर ... और राक्षसों का पुनर्निर्माण, परीक्षणों के दौरान वे एक ही सर्वर पर चुपचाप रहते हैं और एक-दूसरे के साथ हस्तक्षेप नहीं करते हैं।



नतीजतन, 3 कारों के लिए 2 अलग-अलग साइटों पर एक साथ गिरने की संभावना बहुत कम है कि किसी भी सर्वर या साइट फीडिंग पर आधार को बढ़ाने में 10 मिनट से अधिक नहीं लगेगा।



स्लाइस के अंतराल के माप के साथ 2 प्लेटफार्मों पर सूचनाएं (मुनिन, नगिओस, ज़ैबिक्स - जिसे आप पसंद करते हैं) स्थापित करना सुनिश्चित करें। आप एसएमएस या साबुन का उपयोग कर सकते हैं, हमारे पास एक नगियोस मॉनीटर है और उसी समय मुनिन उसके बारे में और ग्राफ खींचता है, जिस पर सब कुछ बहुत स्पष्ट रूप से viodno है क्या और कैसे और किससे।



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















यह ध्यान देने योग्य है कि डेटाबेस के अनुवाद के बाद, सी ++ में उपयोगकर्ता डेटा को बचाने के लिए अंतराल भी कम हो गए थे - इसलिए अपडेट की संख्या बढ़ गई।



सामान्य तौर पर, एकमात्र संभावित समस्या आधार की वृद्धि है। लेकिन अब सर्वरों में मेमोरी काफी सस्ती है और इसे बढ़ाने से कोई समस्या नहीं होगी (कुछ मशीनों पर हमारे पास 16 जीबी है, भाग 8 जीबी पर, लेकिन जहां तक ​​मुझे पता है, इसे सीलिंग 128 जीबी में डाला जा सकता है)। किसी भी स्थिति में, किसी ने डेटाबेस की क्लस्टरिंग को रद्द नहीं किया है और हम डेटाबेस को समान कॉन्फ़िगरेशन वाले कई सर्वरों में वितरित कर सकते हैं।



एक संदेह है कि यह पूरी तरह से सही नहीं है, या क्या है। लेकिन डेटाबेस को मेमोरी में ट्रांसफर करना अन्य डेटाबेस / इंजन को लागू करने की तुलना में बहुत आसान था। यदि कोई टिप्पणी है, तो मुझे टिप्पणी में उन्हें पढ़कर खुशी होगी।

किसी भी मामले में, शायद यह अनुभव किसी के लिए उपयोगी है।



InnoDB - dev.mysql.com/doc/refman/5.1/en/innodb.html

MyISAM - dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html

assandra - cassandra.apache.org

tokyo tyrant - fallabs.com/tokyotyrant

बर्कले DB - www.oracle.com/technetwork/database/berkeleydb/overview/index-0363636.html

mysqltuner - mysqltuner.com/mysqltuner.pl

फाल्कन - en.wikipedia.org/wiki/Falcon_ (storage_engine)

tmpfs - en.wikipedia.org/wiki/Tmpfs

mylvmbackup - www.lenzg.net/mylvmbackup