वर्डप्रेस वेबसाइटों के लिए डेटाबेस विफलता

प्रत्येक लाभदायक उद्यम को उच्च उपलब्धता की आवश्यकता होती है। वेबसाइट और ब्लॉग अलग नहीं हैं क्योंकि छोटी कंपनियों और व्यक्तियों को भी अपनी प्रतिष्ठा बनाए रखने के लिए अपनी साइटों को लाइव रहने की आवश्यकता होती है।

WordPress, अब तक, दुनिया में सबसे लोकप्रिय CMS है, जो छोटी से लेकर बड़ी तक लाखों वेबसाइटों को सशक्त बनाता है। लेकिन आप यह कैसे सुनिश्चित कर सकते हैं कि आपकी वेबसाइट लाइव रहे। अधिक विशेष रूप से, मैं कैसे सुनिश्चित कर सकता हूं कि मेरे डेटाबेस की अनुपलब्धता मेरी वेबसाइट को प्रभावित नहीं करेगी?

इस ब्लॉग पोस्ट में हम दिखाएंगे कि ClusterControl का उपयोग करके अपनी वर्डप्रेस वेबसाइट के लिए विफलता कैसे प्राप्त करें।

इस ब्लॉग के लिए हम जिस सेटअप का उपयोग करेंगे, वह Percona Server 5.7 का उपयोग करेगा। हमारे पास एक और होस्ट होगा जिसमें अपाचे और वर्डप्रेस एप्लिकेशन शामिल हैं। हम एप्लिकेशन के उच्च-उपलब्धता वाले हिस्से को नहीं छूएंगे, लेकिन यह कुछ ऐसा भी है जिसे आप सुनिश्चित करना चाहते हैं। हम उपलब्धता सुनिश्चित करने के लिए डेटाबेस को प्रबंधित करने के लिए ClusterControl का उपयोग करेंगे और हम ClusterControl को स्थापित और सेटअप करने के लिए तीसरे होस्ट का उपयोग करेंगे।

यह मानते हुए कि ClusterControl चालू है और चल रहा है, हमें इसमें अपना मौजूदा डेटाबेस आयात करना होगा।

ClusterControl के साथ एक डेटाबेस क्लस्टर आयात करना

परिनियोजन विज़ार्ड में मौजूदा सर्वर/डेटाबेस आयात करें विकल्प पर जाएं।

हमें SSH कनेक्टिविटी को कॉन्फ़िगर करना होगा क्योंकि यह ClusterControl के लिए एक आवश्यकता है। नोड्स को प्रबंधित करने में सक्षम हो।

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

अत्यधिक उपलब्ध वातावरण को स्थापित करने के लिए, हमें एक जोड़े को निष्पादित करने की आवश्यकता है क्रियाओं का। हमारे पर्यावरण में निम्न शामिल होंगे...

• मास्टर - गुलाम जोड़ी
• पढ़ने/लिखने के विभाजन और टोपोलॉजी का पता लगाने के लिए दो ProxySQL उदाहरण
• वर्चुअल आईपी प्रबंधन के लिए दो सुरक्षित उदाहरण

विचार सरल है - हम दास को अपने स्वामी के पास तैनात करेंगे ताकि मास्टर के विफल होने पर हमारे पास विफल होने का दूसरा उदाहरण होगा। ClusterControl विफलता का पता लगाने के लिए जिम्मेदार होगा और मास्टर के अनुपलब्ध होने पर यह दास को बढ़ावा देगा। ProxySQL प्रतिकृति टोपोलॉजी का ट्रैक रखेगा और यह ट्रैफ़िक को सही नोड पर पुनर्निर्देशित करेगा - राइट्स मास्टर को भेजे जाएंगे, चाहे वह किसी भी नोड में हो, रीड्स या तो मास्टर-ओनली को भेजे जा सकते हैं या मास्टर और स्लेव्स में वितरित किए जा सकते हैं . अंत में, Keepalived को ProxySQL के साथ जोड़ा जाएगा और यह एप्लिकेशन को कनेक्ट करने के लिए VIP प्रदान करेगा। उस VIP को हमेशा ProxySQL इंस्टेंस में से एक को सौंपा जाएगा और Keepalived इसे दूसरे में ले जाएगा, "मुख्य" ProxySQL नोड विफल होने पर।

यह सब कहने के बाद, आइए इसे ClusterControl का उपयोग करके कॉन्फ़िगर करें। यह सब कुछ ही क्लिक में किया जा सकता है। हम दास को जोड़ने के साथ शुरू करेंगे।

ClusterControl के साथ डेटाबेस स्लेव जोड़ना

हम "प्रतिकृति दास जोड़ें" नौकरी चुनने से शुरू करते हैं। फिर हमें एक फॉर्म भरने के लिए कहा जाता है:

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

आखिरकार, एक बार कार्य सफलतापूर्वक पूरा हो जाने के बाद, दास पर दिखाई देना चाहिए क्लस्टर सूची।

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

कार्य शुरू करने का स्थान है मैनेज -> लोडबैलेंसर।

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

ProxySQL में स्पिट पढ़ने/लिखने के फायदे और नुकसान

रीड/राइट स्प्लिट का उपयोग करने का मुख्य लाभ यह है कि सभी SELECT ट्रैफिक को मास्टर और स्लेव के बीच वितरित किया जाएगा। इसका मतलब है कि नोड्स पर लोड कम होगा और प्रतिक्रिया समय भी कम होना चाहिए। यह अच्छा लगता है, लेकिन ध्यान रखें कि यदि एक नोड विफल हो जाता है, तो दूसरे नोड को सभी ट्रैफ़िक को समायोजित करने में सक्षम होना चाहिए। स्वचालित विफलता होने का कोई मतलब नहीं है यदि एक नोड के नुकसान का मतलब है कि दूसरा नोड अतिभारित हो जाएगा और, वास्तव में, अनुपलब्ध भी।

यदि आपके पास एकाधिक दास हैं तो लोड को वितरित करना समझ में आता है - पांच में से एक नोड खोना दो में से एक को खोने से कम प्रभावशाली होता है। कोई फर्क नहीं पड़ता कि आप क्या तय करते हैं, आप ProxySQL नोड पर जाकर और नियम टैब पर क्लिक करके आसानी से व्यवहार बदल सकते हैं।

नियम 200 को देखना सुनिश्चित करें (वह जो सभी सेलेक्ट स्टेटमेंट को पकड़ता है) ) नीचे स्क्रीनशॉट पर आप देख सकते हैं कि गंतव्य होस्टग्रुप 20 है, जिसका अर्थ है कि क्लस्टर में सभी नोड्स - रीड/राइट स्प्लिट और स्केल-आउट सक्षम है। हम इस नियम को संपादित करके और गंतव्य होस्टग्रुप को 10 (जिसमें मास्टर शामिल है) में बदलकर इसे आसानी से अक्षम कर सकते हैं।

यदि आप पढ़ना/लिखना विभाजन सक्षम करना चाहते हैं, तो आप आसानी से कर सकते हैं इस क्वेरी नियम को फिर से संपादित करके और गंतव्य होस्टग्रुप को 20 पर वापस सेट करके ऐसा करें।

अब, दूसरा ProxySQL परिनियोजित करते हैं।

सभी कॉन्फ़िगरेशन विकल्पों को फिर से पास करने से बचने के लिए हम "आयात कॉन्फ़िगरेशन" का उपयोग कर सकते हैं ” विकल्प चुनें और हमारे मौजूदा ProxySQL को स्रोत के रूप में चुनें।

जब यह कार्य पूरा हो जाएगा तब भी हमें अपने परिवेश को स्थापित करने का अंतिम चरण पूरा करना होगा। हमें ProxySQL इंस्टेंस के शीर्ष पर Keepalived को तैनात करना होगा।

ProxySQL इंस्टेंस के शीर्ष पर रख-रखाव को परिनियोजित करना

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

जैसा कि आप देख सकते हैं, अब हमारे पास पूरा सेटअप तैयार है। हमारे पास 10.0.0.111 का VIP है जो ProxySQL इंस्टेंस में से एक को सौंपा गया है। ProxySQL इंस्टेंस हमारे ट्रैफ़िक को सही बैकएंड MySQL नोड्स पर रीडायरेक्ट करेगा और ClusterControl ज़रूरत पड़ने पर फेलओवर करने वाले वातावरण पर नज़र रखेगा। डेटाबेस से कनेक्ट करने के लिए वर्चुअल आईपी का उपयोग करने के लिए वर्डप्रेस को फिर से कॉन्फ़िगर करने के लिए हमें अंतिम क्रिया करनी है।

ऐसा करने के लिए, हमें wp-config.php को संपादित करना होगा और DB_HOST वैरिएबल को हमारे वर्चुअल आईपी में बदलना होगा:

/** MySQL hostname */

define( 'DB_HOST', '10.0.0.111' );

निष्कर्ष

अब से Wordpress VIP और ProxySQL का उपयोग करके डेटाबेस से जुड़ जाएगा। यदि मास्टर नोड विफल हो जाता है, तो ClusterControl विफल हो जाएगा।

जैसा कि आप देख सकते हैं, नया मास्टर चुना गया है और ProxySQL भी इस ओर इशारा करता है होस्टग्रुप 10 में नया मास्टर।

हमें उम्मीद है कि यह ब्लॉग पोस्ट आपको इस बारे में कुछ जानकारी देगा कि किसी Wordpress वेबसाइट के लिए अत्यधिक उपलब्ध डेटाबेस वातावरण को कैसे डिज़ाइन किया जाए और कैसे ClusterControl का उपयोग इसके सभी तत्वों को परिनियोजित करने के लिए किया जा सकता है।