Pinterest शेयरिंग: हमने अपने MySQL पार्क को कैसे बढ़ाया

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



"Shardirovat। या शारद न करें। बिना कोशिश किए। ”
- योदा

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

इससे पहले कि हम डेटा साझा करने के बारे में चर्चा करें, आइए उन्हें बेहतर तरीके से जानें। एक अच्छी रोशनी सेट करें, चॉकलेट में स्ट्रॉबेरी प्राप्त करें, स्टार ट्रेक के उद्धरण याद रखें ...

Pinterest आपकी रुचि के हर चीज़ का खोज इंजन है। डेटा के संदर्भ में, Pinterest दुनिया भर में मानव हितों का सबसे बड़ा ग्राफ है। इसमें 50 बिलियन से अधिक पिन शामिल हैं जिन्हें उपयोगकर्ताओं द्वारा एक बिलियन से अधिक बोर्डों पर सहेजा गया है। लोग अपने लिए कुछ पिन रखते हैं और अन्य पिनों की तरह, अन्य पिनों, बोर्डों और रुचियों की सदस्यता लेते हैं, सभी पिनों, बोर्डों और हितों के घर का फीड देखते हैं, जिनके लिए उन्होंने सदस्यता ली है। बहुत बढ़िया! अब इसे स्कैलेबल बनाते हैं!

दर्दनाक वृद्धि

2011 में, हमने गति हासिल करना शुरू कर दिया। कुछ अनुमानों से , हम उस समय ज्ञात किसी भी स्टार्टअप से अधिक तेजी से बढ़े। सितंबर 2011 के आसपास, हमारे बुनियादी ढांचे का हर घटक अतिभारित था। हमारे पास अपने निपटान में कई NoSQL प्रौद्योगिकियां थीं, और उनमें से सभी भयावह रूप से विफल रहीं। हमारे पास कई MySQL गुलाम भी थे, जिन्हें हम पढ़ते थे, जिससे बहुत अधिक असाधारण त्रुटियां हुईं, खासकर जब कैशिंग। हमने अपने पूरे स्टोरेज मॉडल को फिर से बनाया है। कुशलता से काम करने के लिए, हम ध्यान से आवश्यकताओं के विकास के पास पहुंचे।

आवश्यकताओं

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

वास्तुकला और नोट्स के दर्शन

चूँकि हम इस डेटा को कई डेटाबेसों के लिए चाहते थे, इसलिए हम सभी डेटा को इकट्ठा करने के लिए सिर्फ एक जॉइन, फॉरेन कीज़ और इंडेक्स का उपयोग नहीं कर सकते थे, हालाँकि इनका इस्तेमाल उन सबक्वेरीज़ के लिए किया जा सकता है जो डेटाबेस में नहीं होती हैं।

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

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

अंत में, हमें अपनी सभी वस्तुओं के लिए सार्वभौमिक विशिष्ट पहचानकर्ता (यूयूआईडी) उत्पन्न करने के लिए एक अच्छे तरीके की आवश्यकता है।

हमने कैसे शार्पिंग की

हम जो बनाने जा रहे थे, आवश्यकताओं को पूरा करना था, सामान्य रूप से काम करना, व्यावहारिक और रखरखाव करना। यही कारण है कि हमने अंतर्निहित प्रौद्योगिकी के रूप में पहले से ही काफी परिपक्व MySQL प्रौद्योगिकी को चुना है। हम जानबूझकर स्वचालित स्केलिंग MongoDB, Cassandra और Membase के लिए नई तकनीकों से सावधान हैं, क्योंकि वे परिपक्वता से काफी दूर थे (और हमारे मामले में वे प्रभावशाली तरीके से टूट गए!)।

इसके अलावा: मैं अभी भी नई विचित्र चीजों से बचने के लिए स्टार्टअप की सलाह देता हूं - बस MySQL का उपयोग करने का प्रयास करें। मुझ पर भरोसा रखो। मैं इसे निशान से साबित कर सकता हूं।

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



प्रत्येक MySQL मास्टर-मास्टर सर्वर को प्राथमिक विफलता की स्थिति में बैकअप होस्ट के लिए दोहराया जाता है। हमारे उत्पादन सर्वर केवल मास्टर को पढ़ते या लिखते हैं। मेरी सलाह है कि आप भी ऐसा ही करें। यह प्रतिकृति विलंब के साथ त्रुटियों को बहुत सरल करता है और रोकता है।

प्रत्येक MySQL इकाई में कई डेटाबेस होते हैं:



ध्यान दें कि प्रत्येक डेटाबेस का विशिष्ट नाम है: db00000, db00001 से dbNNNN। प्रत्येक डेटाबेस हमारे डेटा का एक हिस्सा है। हमने एक वास्तुशिल्प निर्णय लिया, जिसके आधार पर डेटा का केवल हिस्सा ही शार्क में आता है, और यह कभी भी इस शार्क से आगे नहीं जाता है। हालाँकि, आप अन्य मशीनों पर शार्क को ले जाकर अधिक क्षमता प्राप्त कर सकते हैं (हम बाद में इस बारे में बात करेंगे)।

हम एक कॉन्फ़िगरेशन तालिका के साथ काम करते हैं जो यह दर्शाता है कि किन मशीनों में धार है:

[{“range”: (0,511), “master”: “MySQL001A”, “slave”: “MySQL001B”}, {“range”: (512, 1023), “master”: “MySQL002A”, “slave”: “MySQL002B”}, ... {“range”: (3584, 4095), “master”: “MySQL008A”, “slave”: “MySQL008B”}] 

यह कॉन्फ़िगरेशन तभी बदलता है जब हमें शार्प को स्थानांतरित करने या होस्ट को बदलने की आवश्यकता होती है। यदि master मृत्यु हो जाती है, तो हम मौजूदा slave उपयोग कर सकते हैं, और फिर एक नया उठा सकते हैं। कॉन्फ़िगरेशन चिड़ियाघरकीपर में स्थित है और, जब अद्यतन किया जाता है, तो MySQL शार्क की सेवा करने वाली सेवाओं को भेजा जाता है।

प्रत्येक शार्क के पास तालिकाओं का एक ही सेट होता है: pins , boards , users_has_pins , users_likes_pins , pin_liked_by_user , आदि। मैं इस बारे में थोड़ी देर बाद बात करूंगा।

हम इन शार्क के लिए डेटा कैसे वितरित करते हैं?

हम 64-बिट आईडी बनाते हैं जिसमें शार्द की आईडी, उसमें मौजूद डेटा का प्रकार, और वह स्थान जहां यह डेटा तालिका (स्थानीय आईडी) है। शार्द आईडी में 16 बिट्स होते हैं, टाइप आईडी 10 बिट्स होती है, और लोकल आईडी 36 बिट्स होती है। उन्नत गणितज्ञ ध्यान देंगे कि केवल 62 बिट्स हैं। संकलक और सर्किट बोर्ड डेवलपर के रूप में मेरे पिछले अनुभव ने मुझे सिखाया है कि बैकअप बिट्स सोने में उनके वजन के लायक हैं। तो, हमारे पास दो ऐसे बिट्स हैं (शून्य पर सेट)।

 ID = (shard ID << 46) | (type ID << 36) | (local ID<<0) 

आइए इस पिन को लें: https://www.pinterest.com/pin/241294492511762325/ , आइए इसकी आईडी 241294492511762325 का विश्लेषण करें:

 Shard ID = (241294492511762325 >> 46) & 0xFFFF = 3429 Type ID = (241294492511762325 >> 36) & 0x3FF = 1 Local ID = (241294492511762325 >> 0) & 0xFFFFFFFFF = 7075733 

इस प्रकार, पिन ऑब्जेक्ट 3429 शार्क में रहता है। इसका प्रकार "1" (यानी "पिन") है, और यह पिन टेबल में 7075733 लाइन पर है। उदाहरण के लिए, आइए कल्पना करें कि यह शार्क MySQL012A में है। हम इसे इस प्रकार प्राप्त कर सकते हैं:

 conn = MySQLdb.connect(host=”MySQL012A”) conn.execute(“SELECT data FROM db03429.pins where local_id=7075733”) 

डेटा दो प्रकार के होते हैं: ऑब्जेक्ट और मैपिंग। ऑब्जेक्ट्स में पिन डेटा जैसे भाग होते हैं।

ऑब्जेक्ट टेबल्स

पिंस, उपयोगकर्ता, बोर्ड और टिप्पणियों जैसे ऑब्जेक्ट टेबल में एक आईडी (स्थानीय आईडी, स्वचालित रूप से बढ़ती प्राथमिक कुंजी के साथ) और एक बूँद होती है जिसमें सभी ऑब्जेक्ट डेटा के साथ JSON होता है।

 CREATE TABLE pins ( local_id INT PRIMARY KEY AUTO_INCREMENT, data TEXT, ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB; 

उदाहरण के लिए, पिन ऑब्जेक्ट इस तरह दिखते हैं:

 {“details”: “New Star Wars character”, “link”: “http://webpage.com/asdf”, “user_id”: 241294629943640797, “board_id”: 241294561224164665, …} 

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

पिन को संपादित करने के लिए, हम MySQL लेनदेन का उपयोग करके JSON को संशोधित-संशोधित करते हैं:

 > BEGIN > SELECT blob FROM db03429.pins WHERE local_id=7075733 FOR UPDATE [Modify the json blob] > UPDATE db03429.pins SET blob='<modified blob>' WHERE local_id=7075733 > COMMIT 

पिन निकालने के लिए, आप MySQL में इसकी पंक्ति हटा सकते हैं। हालाँकि, JSON में "सक्रिय" फ़ील्ड को जोड़ना और इसे "गलत" पर सेट करना बेहतर है, साथ ही क्लाइंट साइड पर परिणामों को फ़िल्टर करना है।

मैपिंग टेबल्स

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

 CREATE TABLE board_has_pins ( board_id INT, pin_id INT, sequence INT, INDEX(board_id, pin_id, sequence) ) ENGINE=InnoDB; 

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

 SELECT pin_id FROM board_has_pins WHERE board_id=241294561224164665 ORDER BY sequence LIMIT 50 OFFSET 150 

यह आपको 50 से अधिक pin_id देगा, जिसे आप पिन ऑब्जेक्ट्स की खोज के लिए उपयोग कर सकते हैं।
हमने अभी जो किया है वह एक लेयर लेयर जॉइन है (बोर्ड_ड -> पिन_िड -> पिन ऑब्जेक्ट्स)। एप्लिकेशन स्तर पर कनेक्शन के अद्भुत गुणों में से एक यह है कि आप छवि को ऑब्जेक्ट से अलग से कैश कर सकते हैं। हम मेन्चैच क्लस्टर में पिन ऑब्जेक्ट के कैश में pin_id स्टोर करते हैं, हालांकि हम red_ क्लस्टर में pin_id में board_id को सेव करते हैं। यह हमें सही तकनीक का चयन करने की अनुमति देता है जो कैश्ड ऑब्जेक्ट के लिए सबसे उपयुक्त है।

क्षमता बढ़ाएं

हमारी प्रणाली में क्षमता बढ़ाने के तीन मुख्य तरीके हैं। मशीन को अपडेट करने का सबसे आसान तरीका (अंतरिक्ष को बढ़ाने के लिए, तेज हार्ड ड्राइव, अधिक रैम डालें)।
क्षमता बढ़ाने का अगला तरीका नई सीमाएँ खोलना है। प्रारंभ में, हमने कुल 4096 शार्क बनाईं, इस तथ्य के बावजूद कि शार्क आईडी में 16 बिट्स (कुल 64k शार्क) शामिल थे। नई वस्तुओं को केवल इन पहले 4k शार्क में बनाया जा सकता है। कुछ बिंदु पर, हमने 4096 से 8191 तक की शार्क के साथ नए MySQL सर्वर बनाने का फैसला किया और उन्हें भरना शुरू किया।

अंतिम तरीके से हमने क्षमता बढ़ाई है कि कुछ शार्क को नई मशीनों में स्थानांतरित किया जाए। यदि हम MySQL001A (0 से 511 के बीच की शार्क के साथ) की क्षमता बढ़ाना चाहते हैं, तो हम निम्नलिखित संभावित नामों (MySQL009A और B) के साथ एक नई मास्टर-मास्टर जोड़ी बनाते हैं और MySQL001A से प्रतिकृति शुरू करते हैं।



जैसे ही प्रतिकृति पूरी हो जाती है, हम अपने कॉन्फ़िगरेशन को बदल देते हैं ताकि MySQL001A में केवल 0 से 255 तक शार्क हों, और MySQL009A में 256 से 511 हो। अब प्रत्येक सर्वर को केवल आधी शार्क को ही संसाधित करना चाहिए, जो कि पहले संसाधित हुई थी।

कुछ शांत सुविधाएँ

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

आप में से जिन लोगों ने MySQL टेबल में अधिक कॉलम जोड़ने के लिए ALTER का प्रदर्शन किया है, वे जानते हैं कि वे बहुत धीरे-धीरे काम कर सकते हैं और एक बड़ी समस्या बन सकते हैं। हमारे दृष्टिकोण को किसी भी MySQL स्तर के बदलाव की आवश्यकता नहीं है। Pinterest पर, हमने संभवतः पिछले तीन वर्षों में केवल एक ALTER बनाया है। ऑब्जेक्ट में नए फ़ील्ड जोड़ने के लिए, बस अपनी सेवाओं को बताएं कि JSON स्कीमा में कई नए फ़ील्ड हैं। आप डिफ़ॉल्ट मान को बदल सकते हैं ताकि किसी नए क्षेत्र के बिना किसी ऑब्जेक्ट से JSON का डिसेरलाइज़ करते समय, आपको डिफ़ॉल्ट मान मिले। यदि आपको एक मैपिंग टेबल की आवश्यकता है, तो एक नया मैपिंग टेबल बनाएं और जब चाहें इसे पॉप्युलेट करना शुरू करें। और जब हो जाए, आप भेज सकते हैं!

मॉड शार्द

यह लगभग पूरी तरह से अलग केवल एक दस्ते की तरह है।

कुछ वस्तुओं को एक आईडी के बिना खोजने की आवश्यकता है। उदाहरण के लिए, यदि कोई उपयोगकर्ता फेसबुक अकाउंट से लॉग इन करता है, तो हमें फेसबुक आईडी से पिनटरेस्ट आईडी तक मैपिंग की आवश्यकता है। हमारे लिए, फेसबुक आईडी सिर्फ बिट्स हैं, इसलिए हम उन्हें एक अलग शार्प सिस्टम में स्टोर करते हैं जिसे mod shard कहा जाता है।

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

 shard = md5(“1.2.3.4") % 4096 

इस स्थिति में, शार्क 1524 के बराबर होगी। हम शार्प आईडी के अनुरूप कॉन्फ़िगरेशन फ़ाइल को संसाधित करते हैं:

 [{“range”: (0, 511), “master”: “msdb001a”, “slave”: “msdb001b”}, {“range”: (512, 1023), “master”: “msdb002a”, “slave”: “msdb002b”}, {“range”: (1024, 1535), “master”: “msdb003a”, “slave”: “msdb003b”}, …] 

इस प्रकार, आईपी पते 1.2.3.4 पर डेटा खोजने के लिए, हमें निम्नलिखित करने की आवश्यकता होगी:

 conn = MySQLdb.connect(host=”msdb003a”) conn.execute(“SELECT data FROM msdb001a.ip_data WHERE ip='1.2.3.4'”) 

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

अंतिम विचार

यह प्रणाली 3.5 साल से Pinterest पर उत्पादन चला रही है, और हमेशा वहाँ रहने की संभावना है। इसे लागू करना अपेक्षाकृत सरल था, लेकिन इसे ऑपरेशन में डालना और पुरानी मशीनों से सभी डेटा को स्थानांतरित करना कठिन था। यदि आप किसी समस्या का सामना तब करते हैं जब आपने एक नया शार्क बनाया था, तो अपने डेटा को पुराने डेटाबेस से स्क्रिप्ट के साथ अपने नए शार्क पर ले जाने के लिए पृष्ठभूमि डेटा प्रोसेसिंग मशीन (संकेत: पाइरेस का उपयोग करें) का एक क्लस्टर बनाने पर विचार करें। मैं गारंटी देता हूं कि डेटा का वह हिस्सा खो जाएगा, चाहे आप कितनी भी कोशिश कर लें (यह सभी gremlins है, मैं कसम खाता हूं), इसलिए बार-बार डेटा ट्रांसफर को दोहराएं जब तक कि शार्क में नई जानकारी की मात्रा बहुत कम या बिल्कुल नहीं हो जाती।

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

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