एक कामकाजी दिन में हम लाखों देशों में कैसे चले गए

190 मिलियन उपयोगकर्ताओं के साथ नए लोगों से मिलने के लिए दुनिया का सबसे बड़ा सोशल नेटवर्क है।
सभी डेटा दो डेटा केंद्रों - यूरोपीय और अमेरिकी में संग्रहीत हैं। कुछ समय पहले, हमने एशिया से अपने उपयोगकर्ताओं से इंटरनेट कनेक्शन की गुणवत्ता की जांच की और पाया कि 7 मिलियन उपयोगकर्ताओं के लिए हमारी साइट 2 गुना तेजी से लोड होगी यदि हम उन्हें यूरोपीय डेटा सेंटर से अमेरिकी एक में स्थानांतरित करते हैं। पहली बार, हमने डेटा केंद्रों के बीच उपयोगकर्ता डेटा के बड़े पैमाने पर प्रवासन के कार्य का सामना किया, जिसे हमने सफलतापूर्वक प्रबंधित किया: हमने सीखा कि एक कार्य दिवस में 1.5 मिलियन उपयोगकर्ताओं को कैसे स्थानांतरित किया जाए! हम पूरे देशों को स्थानांतरित करने में सक्षम थे! पहले भाग में हम अपने सामने निर्धारित कार्य के बारे में और हमारे द्वारा प्राप्त किए गए परिणाम के बारे में विस्तार से बात करेंगे।

स्थापत्य कला

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



MySQL के अलावा, हमारे पास कई सी / सी ++ सेवाएं हैं जो विभिन्न डेटा संग्रहीत करती हैं: सत्र, साइट पर अंतिम यात्रा की तारीखें, मतदान के लिए उपयोगकर्ताओं की तस्वीरें, खोज के लिए सभी उपयोगकर्ताओं का मूल डेटा।

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

इसके अलावा, हमारे पास कई "केंद्रीय" MySQL डेटाबेस हैं जो सभी उपयोगकर्ताओं के बारे में सामान्य जानकारी संग्रहीत करते हैं, और अलग-अलग बिलिंग डेटाबेस हैं जो एक ही बार में सभी लॉगिन उपयोगकर्ताओं के लिए जानकारी संग्रहीत करते हैं। इसके अलावा, हमारे पास अपलोड किए गए फ़ोटो और वीडियो के लिए अलग-अलग रिपॉजिटरी हैं, जो एक अलग लेख होगा। यह डेटा भी स्थानांतरित किया जाना चाहिए।

समस्या का बयान

यह कार्य बहुत सरल रूप से तैयार किया गया है: एक कार्य दिवस में पूरे देश से उपयोगकर्ता डेटा स्थानांतरित करने के लिए, ताकि प्रवास के दौरान ये उपयोगकर्ता साइट का उपयोग कर सकें। उन लोगों का सबसे बड़ा देश जिसे हमने "विस्थापित किया" थाईलैंड है, जिसमें हमारे लगभग 1.5 मिलियन पंजीकृत उपयोगकर्ता हैं। यदि हम इस संख्या को 8 कार्य घंटों (प्लस दोपहर के भोजन) में विभाजित करते हैं, तो हमें आवश्यक प्रवासन दर मिलती है, जो प्रति घंटे लगभग 170 हजार उपयोगकर्ता है।
एक कार्य दिवस में देश से पलायन करने की आवश्यकता इस तथ्य से तय होती है कि इस समय कुछ भी हो सकता है। उदाहरण के लिए, वे "लेट" कर सकते हैं या कुछ सर्वर या सेवाओं को धीमा करना शुरू कर सकते हैं, और फिर उन पर बनाए गए लोड को कम करने के लिए कोड को "लाइव" करना आवश्यक होगा। माइग्रेशन कोड में त्रुटियां भी हो सकती हैं जो उपयोगकर्ताओं के लिए समस्याएं पैदा करेंगी, और फिर इस प्रक्रिया को जल्दी से देखने और इस प्रक्रिया को रोकने (या रोल बैक) करने का अवसर होना चाहिए। संक्षेप में, उपयोगकर्ताओं को स्थानांतरित करने के लिए इस तरह के बड़े पैमाने पर संचालन के कार्यान्वयन के लिए आवश्यक रूप से एक "ऑपरेटर" की उपस्थिति की आवश्यकता होती है जो निगरानी करेगा कि क्या हो रहा है और ऑपरेशन के दौरान आवश्यक समायोजन करें।

तकनीकी रूप से, प्रत्येक उपयोगकर्ता के लिए, आपको सभी MySQL इंस्टेंस के सभी तालिकाओं से चयन करने की आवश्यकता होती है, जिस पर इस उपयोगकर्ता के बारे में डेटा स्थित हो सकता है, साथ ही C / C ++ सेवाओं में संग्रहीत डेटा को स्थानांतरित भी किया जा सकता है। इसके अलावा, सेवाओं में से एक के लिए आपको स्वयं डेमन को स्थानांतरित करने की आवश्यकता है, न कि दोनों डेटा केंद्रों में चल रहे डेमॉन इंस्टेंस के बीच डेटा।
डेटा केंद्रों के बीच डेटा ट्रांसफर में देरी लगभग 100 एमएस है, इसलिए ऑपरेशन को अनुकूलित किया जाना चाहिए ताकि डेटा स्ट्रीम द्वारा डाउनलोड किया जाए, न कि बड़ी संख्या में छोटे अनुरोधों द्वारा। माइग्रेशन के दौरान, प्रत्येक उपयोगकर्ता के लिए साइट की अयोग्यता का समय कम से कम होना चाहिए, इसलिए प्रक्रिया को प्रत्येक उपयोगकर्ता के लिए व्यक्तिगत रूप से किया जाना चाहिए, न कि एक बड़ी बंडल। जिस समय हमने ध्यान केंद्रित किया वह किसी विशिष्ट उपयोगकर्ता (अधिमानतः 1-2 मिनट) के लिए 5 मिनट से अधिक की साइट की अक्षमता नहीं थी।

कार्य योजना

इस तथ्य के आधार पर कि हमें प्रति घंटे 170,000 उपयोगकर्ताओं को माइग्रेट करना था, और प्रत्येक उपयोगकर्ता का माइग्रेशन समय लगभग 2-3 मिनट होना चाहिए, हमने समानांतर में निष्पादित थ्रेड्स की संख्या की गणना की जो इन शर्तों को पूरा करने के लिए आवश्यक होगी। प्रत्येक थ्रेड प्रति घंटे औसतन 25 उपयोगकर्ताओं को स्थानांतरित कर सकता है, इसलिए थ्रेड्स की कुल संख्या 6,800 (यानी 170,000 / 25) निकली। वास्तव में, हम खुद को "केवल" 2,000 धागे तक सीमित करने में सक्षम थे, क्योंकि अधिकांश समय, उपयोगकर्ता विभिन्न घटनाओं (उदाहरण के लिए, डेटा केंद्रों के बीच MySQL प्रतिकृति) की घटना को "उम्मीद" करता है। इस प्रकार, प्रत्येक थ्रेड ने तीन उपयोगकर्ताओं को एक ही समय में प्रसंस्करण में ले लिया और उनके बीच स्विच किया जब उनमें से एक किसी चीज के लिए प्रतीक्षा की स्थिति में चला गया।

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

हमारे कार्यों की संरचना और अनुक्रम

तैयारी के कदम
हम इस समय उपयोगकर्ता को "माइग्रेटिंग" के रूप में चिह्नित करते हैं और पृष्ठभूमि स्क्रिप्ट द्वारा उसके प्रसंस्करण के अंत की प्रतीक्षा करते हैं, यदि कोई हो। इस कदम ने हमें लगभग एक मिनट का समय दिया, जिसके दौरान एक अन्य उपयोगकर्ता उसी स्ट्रीम में माइग्रेट कर सकता है।

बिलिंग डेटा माइग्रेशन
देश के प्रवास के दौरान, हमने इसमें बिल को पूरी तरह से बंद कर दिया, इसलिए इसके लिए कोई विशेष कार्य और ताले की आवश्यकता नहीं थी - डेटा को केवल एक केंद्रीय MySQL डेटाबेस से दूसरे में स्थानांतरित किया गया था। प्रत्येक डेटाबेस से एक MySQL कनेक्शन इस डेटाबेस के लिए स्थापित किया गया था, इसलिए बिलिंग डेटाबेस से कनेक्शन की कुल संख्या 2,000 से अधिक थी।

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

उपयोगकर्ता मास्टर डेटा भरें
इस चरण में, हमने प्रत्येक उपयोगकर्ता के डेटा का एक SQL डंप उत्पन्न किया और इसे रिमोट साइड पर लागू किया। इसी समय, पुराने डेटा को इस चरण में हटाया नहीं गया था।

ऑथराइज़र सेवा में डेटा अपडेट करना
लेखक सेवा उपयोगकर्ता आईडी और सर्वर आईडी के बीच पत्राचार को संग्रहीत करती है, और जब तक हम इस सेवा में डेटा को अपडेट नहीं करते हैं, तब तक स्क्रिप्ट उपयोगकर्ता डेटा के लिए पुरानी जगह पर जाएगी।

पुराने स्थान से उपयोगकर्ता डेटा निकाल रहा है
प्रश्नों से DELETE का उपयोग करते हुए, हम स्रोत MySQL सर्वर पर उपयोगकर्ता डेटा को साफ़ करते हैं।

केंद्रीय डेटाबेस से डेटा स्थानांतरित करने के लिए कदम
सुवक्ता नाम Misc (अंग्रेजी से विविध - अलग) के अंतर्गत एक केंद्रीय डेटाबेस में बहुत सारी अलग-अलग तालिकाएँ हैं, और उनमें से प्रत्येक के लिए हमने प्रति उपयोगकर्ता एक चयन और DELETE किया। हमने खराब डेटाबेस से प्रति सेकंड 40,000 एसक्यूएल प्रश्नों को निचोड़ लिया और 2,000 से अधिक कनेक्शनों को खुला रखा।

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

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

अंतिम चरण
हम उपयोगकर्ता को माइग्रेशन पूरा करने के रूप में चिह्नित करते हैं और उसे पहले ही नए डेटा सेंटर में साइट पर लॉग इन करने की अनुमति देते हैं।

MySQL डेटा ट्रांसफर

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

अधिकांश MySQL सर्वर के लिए एक ही योजना के अनुसार डेटा आंदोलन किया गया था (ध्यान दें कि किसी भी त्रुटि के कारण संपूर्ण चरण क्रैश हो जाता है और थोड़े समय के अंतराल के बाद फिर से शुरू होता है):

• हम "रिसीवर साइड" पर जाते हैं और जांचते हैं कि क्या वहां पहले से ही उपयोगकर्ता डेटा है। यदि वहाँ है, तो डेटा अपलोड सफल रहा, लेकिन कदम सही ढंग से पूरा नहीं हुआ था।
• यदि दूरस्थ पक्ष पर कोई डेटा नहीं है, तो उपयोगकर्ता द्वारा फ़िल्टरिंग के साथ सभी आवश्यक तालिकाओं से चयन करें और शुरुआत में BEGIN युक्त SQL डंप बनाएं और अंत में COMMIT करें।
• SSH के माध्यम से डंप को दूरस्थ तरफ "प्रॉक्सी" पर भरें और mysql कंसोल उपयोगिता का उपयोग करके इसका उपयोग करें। ऐसा हो सकता है कि एक COMMIT अनुरोध पास हो जाए, लेकिन हम नेटवर्क समस्याओं के कारण, उदाहरण के लिए, इसका उत्तर नहीं पा सकेंगे। ऐसा करने के लिए, हम पहले जांच करते हैं कि पिछले प्रयास में डंप बाढ़ गया था या नहीं। इसके अलावा, कुछ डेटाबेस में, उपयोगकर्ता के लिए डेटा की कमी एक सामान्य स्थिति है, और यह जांचने में सक्षम होने के लिए कि डेटा ट्रांसफर किया गया था, ऐसे मामलों में हमने INSERT को एक विशेष तालिका में जोड़ा, जिसके अनुसार हमने आवश्यक होने पर जाँच की।
• हम उसी डेटा के साथ DELETE FROM का उपयोग करके मूल डेटा को हटाते हैं जो चयन प्रश्नों में थे। एक नियम के रूप में, जहां शर्तों में user_id शामिल था, और कुछ तालिकाओं के लिए यह क्षेत्र विभिन्न कारणों से प्राथमिक कुंजी का हिस्सा नहीं था। जहां संभव हो, एक सूचकांक जोड़ा गया था। जहाँ यह मुश्किल या अव्यवहारिक था, डेटा हटाते समय, user_id को पहले चुना गया था, और फिर प्राथमिक कुंजी को हटा दिया गया था, जिसने पढ़ने के ताले से बचा था और इस प्रक्रिया को काफी तेज कर दिया था।

यदि हम यह सुनिश्चित करने के लिए जानते हैं कि हमने इससे पहले कभी कदम नहीं उठाया है, तो हम दूरस्थ तरफ डेटा की उपलब्धता की जांच करना छोड़ देते हैं। यह हमें प्रत्येक सर्वर के लिए एक सेकंड के लिए जीतने की अनुमति देता है जिसमें हम डेटा स्थानांतरित करते हैं (जो प्रत्येक पैकेट के लिए 100 एमएस की देरी के कारण होता है)।

प्रवास के दौरान, हमें कई समस्याओं का सामना करना पड़ा, जिनके बारे में हम बात करना चाहते हैं।

स्वतः-वृद्धि क्षेत्र (auto_increment)

ऑटो-इन्क्रीमेंट फ़ील्ड का उपयोग बिलिंग डेटाबेस में सक्रिय रूप से किया जाता है, इसलिए उनके लिए मुझे नए लोगों के लिए "मैपिंग" पुरानी आईडी का जटिल तर्क लिखना था।
कठिनाई यह थी कि तालिकाओं से डेटा, जहां केवल उपर्युक्त अनुक्रम_आईडी प्राथमिक कुंजी में शामिल है, को केवल स्थानांतरित नहीं किया जा सकता है, क्योंकि अनुक्रम_आईडी केवल सर्वर के भीतर अद्वितीय है। अनुक्रम_आईडी को NULL के साथ बदलना भी असंभव है, जिससे नई ऑटो-इन्क्रिमेंट वैल्यू का उत्पादन होता है, क्योंकि, सबसे पहले, सीक्वेंस_ड की पीढ़ी को एक तालिका में डेटा सम्मिलित करके किया जाता है, और परिणामी मान का उपयोग दूसरे में किया जाता है। और दूसरी बात, अन्य टेबल अनुक्रम_ड का उपयोग करके तालिका को संदर्भित करते हैं। यही है, आपको सर्वर पर ऑटो-इन्क्रीमेंट फ़ील्ड मानों की सही मात्रा प्राप्त करने की आवश्यकता है जहां डेटा स्थानांतरित किया जाता है, पुराने अनुक्रम_id को उपयोगकर्ता डेटा में नए के साथ बदलें और तैयार INSERTs को एक फ़ाइल में लिखें जो बाद में mysql कंसोल उपयोगिता द्वारा उपयोग किया जाएगा।
ऐसा करने के लिए, हमने प्राप्त सर्वर पर एक लेनदेन खोला, आवेषण की आवश्यक संख्या बनाई, जिसे mysql_insert_id () कहा जाता है, जो, यदि एक लेन-देन में कई पंक्तियाँ डाली गई थीं, तो पहली पंक्ति के लिए ऑटो-इंक्रीमेंट मान लौटाता है, और फिर लेन-देन वापस कर दिया। इस मामले में, लेन-देन को वापस ले जाने के बाद, डेटाबेस सर्वर रिबूट होने तक ऑटो-इंक्रीमेंट हमारे द्वारा डाली गई पंक्तियों की संख्या में वृद्धि होगी। ऑटो-इन्क्रीमेंट वैल्यू जो हमें चाहिए, प्राप्त करने के बाद, हमने उपयुक्त प्रविष्टि अनुरोधों का गठन किया, जिसमें ऑटो-इंक्रीमेंट पैदा करने के लिए जिम्मेदार तालिका भी शामिल है। लेकिन इन अनुरोधों में, लेन-देन वापस होने के बाद उसमें बने छेदों को भरने के लिए ऑटो-इंक्रीमेंट के मूल्यों को पहले ही स्पष्ट रूप से इंगित किया गया था।

Max_connections और MySQL लोड

प्रत्येक थ्रेड ने सर्वर से एक MySQL कनेक्शन बनाया जिसके साथ उसे सौदा करना था। इसलिए, हमने सभी केंद्रीय MySQL सर्वर पर 2,000 कनेक्शन रखे। अधिक कनेक्शन के साथ, MySQL ने अनुचित व्यवहार करना शुरू कर दिया, जब तक कि गिरावट (हम संस्करण 5.1 और 5.5 का उपयोग करते हैं)।

एक बार, प्रवास के दौरान, केंद्रीय MySQL सर्वरों में से एक दुर्घटनाग्रस्त हो गया (उनमें से एक जो बहुत भारी भार था)। प्रवासन तुरंत समाप्त कर दिया गया था, और हम गिरावट के कारण का पता लगाने लगे। यह पता चला कि एक RAID नियंत्रक ने बस उस पर "उड़ान भरी"। और यद्यपि व्यवस्थापकों ने कहा कि यह उस लोड के कारण नहीं था जो हमने इस सर्वर को दिया था, लेकिन "तलछट बनी हुई है।"

InnoDB, MVCC, और DELETE से: नुकसान

चूंकि हम सभी डेटा को InnoDB में संग्रहीत करते हैं और सभी हस्तांतरित डेटा को तुरंत हटा दिया गया था, इसलिए हमने उन सभी लिपियों को धीमा करना शुरू कर दिया, जो कुछ सर्वरों पर तालिका में मौजूद कतारों को रेक करते हैं। हम यह देखकर आश्चर्यचकित थे कि एक खाली मेज से चयन मिनटों में कैसे हो गया। MySQL पर्ज थ्रेड में हटाए गए रिकॉर्ड्स को खाली करने का समय नहीं था, और इस तथ्य के बावजूद कि कतारों वाली तालिकाएं खाली थीं, बहुत सारे हटाए गए रिकॉर्ड थे जो अभी तक भौतिक रूप से हटाए नहीं गए थे और भ्रूण लेते समय बस MySQL द्वारा छोड़ दिए गए थे। सफाई रिकॉर्ड के लिए कतार की लंबाई का एक मात्रात्मक विवरण SHOW इंजन INNODB STATUS टाइप करके और लाइन इतिहास सूची की लंबाई को देखकर प्राप्त किया जा सकता है। सबसे बड़ा मूल्य जो हमने देखा है वह कई मिलियन रिकॉर्ड है। हम अनुशंसा करते हैं कि आप बहुत ध्यान से DELETE FROM का उपयोग करते हुए InnoDB तालिकाओं से कई रिकॉर्ड हटा दें। इससे बचना और उपयोग करना बहुत बेहतर है, उदाहरण के लिए, यदि संभव हो तो TRUNCATE TABLE। TRUNCATE TABLE के फ़ॉर्म की तालिका पूरी तरह से साफ़ हो जाती है, और ये ऑपरेशन DDL हैं, इसलिए हटाए गए रिकॉर्ड पूर्ववत / रीडू लॉग में नहीं जुड़ते हैं (InnoDB DDL संचालन के लिए लेनदेन का समर्थन नहीं करता है)।
यदि आपको DELETE FROM का उपयोग करके सभी डेटा को हटाने के बाद तालिका से चयन करने की आवश्यकता है, तो प्राथमिक कुंजी पर BETWEEN शर्त लगाने का प्रयास करें। उदाहरण के लिए, यदि आप auto_increment का उपयोग करते हैं, तो तालिका से MIN (id) और MAX (id) चुनें, और फिर उनके बीच के सभी रिकॉर्ड का चयन करें - यह किसी प्रकार की सीमा के साथ या फॉर्म आईडी की शर्तों में से केवल एक के साथ रिकॉर्ड चुनने की तुलना में बहुत तेज़ है > N या आईडी <एन । MIN (id) और MAX (id) प्राप्त करने वाले अनुरोधों में बहुत लंबा समय लगेगा क्योंकि InnoDB हटाए गए रिकॉर्ड को छोड़ देगा। लेकिन दूसरी ओर, मुख्य सीमाओं पर प्रश्नों को हमेशा की तरह उसी गति से निष्पादित किया जाएगा - ऐसे प्रश्नों के चयन में हटाए गए रिकॉर्ड शामिल नहीं किए जाएंगे।

हमें उस फॉर्म से DELETE के कई "हैंगिंग" प्रश्नों को देखकर भी आश्चर्य हुआ, जहां user_id =, जहाँ सभी क्वेरीज़ में समान क्वेरी होती है, और इस तालिका में कोई user_id इंडेक्स नहीं है। जैसा कि यह पता चला, MySQL संस्करण 5.1 (और कुछ हद तक 5.5) में ऐसे प्रश्नों की बहुत खराब मापनीयता है यदि रिकॉर्ड हटाते समय पूर्ण स्कैन तालिकाएं बनाई जाती हैं और अलगाव स्तर READATABLE READ (डिफ़ॉल्ट रूप से) है। समान रिकॉर्ड के लिए तालों की एक बहुत ही उच्च प्रतिस्पर्धा है, जो क्वेरी प्रसंस्करण समय में हिमस्खलन जैसी वृद्धि की ओर जाता है।
समस्या के संभावित समाधानों में से एक है लेन-देन के लिए आइसोलेशन लेवल READ COMM निर्धारित करना, जो डेटा को डिलीट कर देता है, और फिर InnoDB उन पंक्तियों पर ताले नहीं लगाएगा जो WHERE क्लॉज में फिट नहीं होती हैं। यह बताने के लिए कि यह एक गंभीर समस्या कैसे थी, यहाँ प्रवास के दौरान लिया गया एक स्क्रीनशॉट है। स्क्रीनशॉट में tmp.tiw_fix टेबल में लगभग 60 प्रविष्टियाँ (!) हैं और user_id पर कोई इंडेक्स शामिल नहीं है।

उपयोगकर्ता स्ट्रीम आवंटन

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

• जब एक MySQL सर्वर धीमा होने लगा, तो इस सर्वर पर रहने वाले उपयोगकर्ताओं का प्रवास धीमा हो गया। जैसा कि सभी अन्य धागे निष्पादित करना जारी रखते थे, वे धीरे-धीरे समस्या सर्वर पर रहने वाले उपयोगकर्ता तक भी पहुंच गए। धीरे-धीरे, इस सर्वर पर जमा होने वाले धागों की बढ़ती संख्या, और यह और भी धीमा होने लगा। सर्वर को क्रैश होने से बचाने के लिए, हमने ऑपरेशन के दौरान कोड में अस्थायी पैच पेश किए, इस सर्वर पर लोड को सीमित करने के लिए विभिन्न "बैसाखी" का उपयोग किया।
• MySQL- MySQL-, , MySQL-, max_connections.

, MySQL-. , «» , .

…

, . , 2 000 16 - , .

youROCK , PHP-
antonstepanenko , Team Lead, PHP-