सबसे पहले, सेंटिनल रेडिस के लिए लोड बैलेंसर या प्रॉक्सी नहीं है।
दूसरा, सभी विफलताएं मेजबान की मृत्यु नहीं हैं। कभी-कभी सर्वर कुछ समय के लिए हैंग हो जाता है, कभी-कभी नेटवर्क केबल अनप्लग हो जाता है, आदि। क्योंकि f यह, आपके Redis इंस्टेंस के समान होस्ट पर सेंटीनेल को चलाने के लिए अच्छा अभ्यास नहीं है। यदि आप फेलओवर को प्रबंधित करने के लिए सेंटिनल का उपयोग कर रहे हैं, तो आपके रेडिस मास्टर और दास के अलावा अन्य नोड्स पर चलने वाले तीन प्रहरी से कम कुछ भी परेशानी के लिए पूछ रहा है।
प्रहरी एक विफलता और दास पर मतदान करने के लिए एक कोरम तंत्र का उपयोग करता है। दो से कम प्रहरी के साथ आप विभाजित मस्तिष्क का जोखिम उठाते हैं जहां दो या अधिक रेडिस सर्वर सोचते हैं कि वे मास्टर हैं।
उस परिदृश्य की कल्पना करें जहां आप दो सर्वर चलाते हैं और प्रत्येक पर प्रहरी चलाते हैं। यदि आप एक खो देते हैं तो आप विश्वसनीय विफलता क्षमता खो देते हैं।
ग्राहक केवल वर्तमान मास्टर कनेक्शन जानकारी जानने के लिए प्रहरी से जुड़ते हैं। जब भी क्लाइंट कनेक्टिविटी खो देता है तो वे इस प्रक्रिया को दोहराते हैं। प्रहरी रेडिस के लिए प्रॉक्सी नहीं है - रेडिस के लिए आदेश सीधे रेडिस पर जाते हैं।
सेंटिनल को तीन से कम प्रहरी के साथ चलाने का एकमात्र विश्वसनीय कारण सेवा खोज है, जिसका अर्थ है कि इसका उपयोग विफलता प्रबंधन के लिए नहीं करना है।
दो मेजबान परिदृश्य पर विचार करें:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
यदि होस्ट बी अस्थायी रूप से होस्ट ए से नेटवर्क कनेक्टिविटी खो देता है तो इस परिदृश्य में होस्टबी खुद को मास्टर के रूप में बढ़ावा देगा। अब आपके पास:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
कोई भी क्लाइंट जो सेंटिनल 2 से जुड़ता है, उसे बताया जाएगा कि होस्ट बी मास्टर है, जबकि सेंटिनल 1 से कनेक्ट होने वाले क्लाइंट को होस्ट ए मास्टर बताया जाएगा (जो, यदि आपके पास लोड बैलेंसर के पीछे आपके प्रहरी हैं, तो इसका मतलब है कि आपके आधे क्लाइंट)।
इस प्रकार न्यूनतम स्वीकार्य विश्वसनीय विफलता प्रबंधन प्राप्त करने के लिए आपको जो चलाने की आवश्यकता है वह है:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
आपके क्लाइंट प्रहरी से जुड़ते हैं और रेडिस इंस्टेंस (नाम से) के लिए वर्तमान मास्टर प्राप्त करते हैं, फिर उससे कनेक्ट होते हैं। यदि मास्टर की मृत्यु हो जाती है, तो क्लाइंट द्वारा कनेक्शन छोड़ दिया जाना चाहिए, जिसके बाद क्लाइंट को सेंटिनल से फिर से जुड़ना चाहिए और नई जानकारी प्राप्त करनी चाहिए।
प्रत्येक ग्राहक पुस्तकालय इसे कितनी अच्छी तरह संभालता है यह पुस्तकालय पर निर्भर करता है।
आदर्श रूप से होस्ट सी, डी, और ई या तो उसी होस्ट पर होते हैं जहां से आप रेडिस से कनेक्ट होते हैं (यानी क्लाइंट होस्ट)। या उन्हें मिला एक अच्छे नमूने का प्रतिनिधित्व करते हैं। यहां मुख्य जोर यह सुनिश्चित करना है कि आप जांच कर रहे हैं कि आपको रेडिस से कनेक्ट करने की आवश्यकता कहां से है। विफल होने पर उन्हें उसी डीसी/रैक/क्षेत्र में क्लाइंट के रूप में रखा जाता है।
यदि आप चाहते हैं कि आपके क्लाइंट लोड बैलेंसर से बात करें तो यदि संभव हो तो अपने प्रहरी को उन एलबी नोड्स पर रखने की कोशिश करें, अतिरिक्त गैर-एलबी मेजबानों को जोड़ने के लिए एक विषम संख्या में प्रहरी प्राप्त करने के लिए> 2. इसका एक अपवाद है यदि आपका क्लाइंट होस्ट इस मायने में गतिशील हैं कि उनमें से संख्या असंगत है (वे ट्रैफ़िक के लिए बड़े पैमाने पर, धीमी अवधि के लिए नीचे, उदाहरण के लिए)। इस परिदृश्य में आपको अपने प्रहरी को गैर-क्लाइंट और गैर-रेडिस-सर्वर होस्ट पर चलाना चाहिए।
ध्यान दें कि यदि आप ऐसा करते हैं तो आपको एक डेमॉन लिखने की आवश्यकता होगी जो एलबी को अपडेट करने के लिए मास्टर स्विच इवेंट के लिए सेंटिनल PUBSUB चैनल की निगरानी करता है - जिसे आपको केवल वर्तमान मास्टर से बात करने के लिए कॉन्फ़िगर करना होगा (कभी भी दोनों से बात करने का प्रयास न करें)। ऐसा करने के लिए और अधिक काम है लेकिन क्लाइंट के लिए सेंटिनल का पारदर्शी उपयोग करता है - जो केवल एलबी आईपी/पोर्ट से बात करना जानता है।
