🔚 🦐 👠 डायरेक्टिसआरएक्स सर्विसेज के लिए रेडिस स्केलिंग और फेलओवर 🏂 🍩 👉🏿

Redis पूरी तरह से RAM में रखा NoSQL वर्ग (गैर-संबंधपरक DBMS) का एक डेटाबेस प्रबंधन प्रणाली है। डेटा तक पहुंचने के लिए, "कुंजी" - "मूल्य" मॉडल का उपयोग किया जाता है। इस तरह के एक डीबीएमएस को अक्सर छवियों और छोटे डेटा के भंडारण के लिए स्केलेबल सेवाओं में कैश स्टोर करने के लिए उपयोग किया जाता है।

Redis DBMS का व्यापक रूप से उपयोग किया जाता है:

उच्च गति, क्योंकि सभी डेटा रैम में संग्रहीत हैं;
पार मंच;
बीएसडी लाइसेंस के तहत वितरण (ओपन सोर्स सॉफ्टवेयर पर लागू होता है)।

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

यदि आप DirectumRX सेवाओं की क्षैतिज स्केलिंग का उपयोग करते हैं, तो आपको DirectumRX संग्रहण सेवा और DirectumRX वेब एक्सेस सेवा के साथ सही तरीके से काम करने के लिए Redis असफल-सुरक्षित स्थापना का उपयोग करना चाहिए।

रेडिस परिचालन डेटा, कैश और अन्य जानकारी संग्रहीत करेगा जो स्केलिंग मोड में सेवाओं के संचालन के लिए आवश्यक है ताकि सिस्टम के साथ उपयोगकर्ता के संपर्क की प्रक्रिया उस स्थापना पर निर्भर न हो जिसके साथ वह वर्तमान में काम कर रहा है।

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

आधिकारिक रेडिस वेबसाइट पर, क्षैतिज स्केलिंग और दोष सहिष्णुता सुनिश्चित करने के 2 तरीके हैं:

Redis Sentiel का उपयोग करना।
Redis Cluster का उपयोग करना।

इन विकल्पों को अनुकूलित करने पर विचार करें।

Redis Sentiel कॉन्फ़िगर करें

Redis Sentiel (Redis Tracking Node) का उपयोग करने का विकल्प Redis 2.4 में लागू किया गया था और इसमें विज़ार्ड की उपलब्धता की निगरानी के लिए अतिरिक्त Redis Sentiel सेवा का उपयोग करना शामिल है। वह विज़ार्ड की विफलता के मामले में प्रतिकृति नोड्स का कॉन्फ़िगरेशन भी करता है। निर्धारित करता है कि SLAVE नोड्स में से कौन सा मास्टर बनेगा और चलते-फिरते पुनर्संरचना का प्रदर्शन करेगा।

क्लासिक योजना लागू करता है:

कई SLAVE नोड्स (आधिकारिक वेबसाइट के अनुसार 1000 तक) हो सकते हैं, उत्पादक कार्य के लिए कम से कम दो SLAVE नोड्स का उपयोग करने की सिफारिश की जाती है।

आमतौर पर, योजना इस तरह से कॉन्फ़िगर की जाती है कि Redis Sentiel सेवा को MASTER और SLAVE नोड पर कॉन्फ़िगर किया गया है, और यदि MASTER नोड विफल रहता है, तो शेष निगरानी नोड एक नया MASTER पेश करने का निर्णय लेते हैं।

Redis का वर्तमान संस्करण उत्पाद डेवलपर की आधिकारिक वेबसाइट से डाउनलोड के लिए उपलब्ध है । हालाँकि, वितरण साइट केवल लिनक्स के लिए उपलब्ध है। एक समय में, विंडोज के लिए रेडिस को पोर्ट करने की Microsoft परियोजना विकसित हो रही थी, लेकिन वर्तमान में इस परियोजना ने संस्करण 3.2.100 पर विकास को रोक दिया, इसलिए इस लेख में हम लिनक्स पर सबसे अधिक प्रासंगिक तैनाती विकल्प पर विचार करेंगे।

परीक्षण नोड्स के रूप में, हम डेबियन 10 के स्थापित लिनक्स वितरण के साथ दो वर्चुअल होस्ट्स redis1 और redis2 का उपयोग करेंगे।

सबसे पहले, डिफ़ॉल्ट रिपॉजिटरी से पैकेज सूचियों को अपडेट करें और Redis स्थापित करें:

apt-get update && apt-get upgrade apt install redis-server

संस्करण की जाँच करें:

 root@redis1:/home/user# redis-server -v Redis server v=5.0.3 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=afa0decbb6de285f

Redis1 को MASTER नोड के रूप में कार्य करते हैं और redis2 एक SLAVE नोड के रूप में कार्य करते हैं।

ऐसा करने के लिए, हम रेडिस कॉन्फ़िगरेशन फ़ाइलों में आवश्यक पैरामीटर लिखते हैं जो आपको एक प्रतिकृति बनाने की अनुमति देगा (अभी तक गलती-सहिष्णु नहीं)।

कॉन्फ़िगरेशन फ़ाइल /etc/redis/redis.conf में redis1 के लिए, निर्दिष्ट करें:

 # ,   MASTER     . requirepass TestPass

कॉन्फ़िगरेशन फ़ाइल /etc/redis/redis.conf में redis2 के लिए, निर्दिष्ट करें:

 #   MASTER  . slaveof redis1 6379 #      . masterauth TestPass #   ,         . requirepass TestPass

दोनों नोड्स पर रेडिस-सर्वर सेवाओं को पुनरारंभ करें:

 root@redis1:/etc/redis# /etc/init.d/redis-server stop [ ok ] Stopping redis-server (via systemctl): redis-server.service. root@redis1:/etc/redis# /etc/init.d/redis-server start [ ok ] Starting redis-server (via systemctl): redis-server.service. root@redis2:/etc/redis# /etc/init.d/redis-server stop [ ok ] Stopping redis-server (via systemctl): redis-server.service. root@redis2:/etc/redis# /etc/init.d/redis-server start [ ok ] Starting redis-server (via systemctl): redis-server.service.

हम मास्टर की तरफ देखते हैं कि नोड्स प्रतिकृतियां बन गईं और आवश्यक भूमिकाएं प्राप्त कीं:

 root@redis1:/etc/redis# redis-cli -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:master connected_slaves:1 slave0:ip=192.168.9.96,port=6379,state=online,offset=28,lag=0 master_replid:56b0a702d5823d107b0ca1ca2c80f8ef650a4b28 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:28 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:28

SLAVE की ओर, हम एक ही स्थिति देखते हैं:

 root@redis2:/etc/redis# redis-cli -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:slave master_host:redis1 master_port:6379 master_link_status:up master_last_io_seconds_ago:4 master_sync_in_progress:0 slave_repl_offset:14 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:56b0a702d5823d107b0ca1ca2c80f8ef650a4b28 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:14 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:14

अब आपको प्रतिकृति को कॉन्फ़िगर करने की आवश्यकता है ताकि नोड्स में से एक की विफलता के मामले में यह स्वचालित रूप से बहाल हो जाए। ऐसा करने के लिए, हमें Redis Sentinel ट्रैकिंग सेवा की आवश्यकता है।

प्रलेखन के आधार पर, Redis Sentinel निगरानी सेवा निम्नलिखित संचालन कर सकती है:

MASTER और SLAVE नोड्स की उपलब्धता की जाँच करता है और नोड्स की दुर्गमता के बारे में अलर्ट भेजने में सक्षम है।
यदि मास्टर नोड विफल हो जाता है, तो साक्षी नोड SLAVE नोड को मास्टर मोड में रख सकता है, साथ ही शेष SL नोड नोड को फिर से कॉन्फ़िगर कर सकता है, और वे नए मास्टर के साथ काम करना शुरू करते हैं।
MASTER और SLAVE नोड्स की कॉन्फ़िगरेशन फ़ाइलों में परिवर्तन करता है।

प्रयोग की शुद्धता के लिए, हम एक साक्षी सेवा को एक अलग रेडिस 3 वीएम पर रखेंगे।

हम उसी तरह से Redis रिपॉजिटरी को कनेक्ट करते हैं और Redis-sentinel पैकेज स्थापित करते हैं:

 apt install redis-sentinel

स्थापना के बाद, आपको मॉनिटरिंग नोड /etc/redis/sentinel.conline के कॉन्फ़िगरेशन फ़ाइल में सेटिंग्स करने की आवश्यकता है:

 #    redis1   6379. #   1 -      , #        MASTER-. #       , #     MASTER-. sentinel monitor master01 redis1 6379 1 #  3 ,       . sentinel down-after-milliseconds master01 3000 #    MASTER- sentinel failover-timeout master01 6000 # ,  SLAVE-   . #    ,    , #      . sentinel parallel-syncs master01 1 #    . bind 192.168.9.97 127.0.0.1 ::1 #    MASTER-. sentinel auth-pass master01 TestPass

सेटिंग्स करने के बाद सेवा को पुनरारंभ करें:

 root@redis3:/etc/redis# /etc/init.d/redis-sentinel restart [ ok ] Restarting redis-sentinel (via systemctl): redis-sentinel.service.

जाँच करें कि ट्रैकिंग सेवा ने मास्टर और स्लेव को देखा:

 root@redis3:/etc/redis# redis-cli -p 26379 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=master01,status=ok,address=192.168.9.95:6379,slaves=1,sentinels=1

हम प्रयोग शुरू करते हैं।

हम एक विफलता का अनुकरण करते हैं, redis1 नोड पर रेडिस-सर्वर सेवा को रोकते हैं और गवाह नोड की वर्तमान जानकारी प्राप्त करते हैं:

 root@redis3:/etc/redis# redis-cli -p 26379 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=master01,status=ok,address=192.168.9.96:6379,slaves=1,sentinels=1

हम देखते हैं कि मास्टर बदल गया है।

हम redis1 नोड के संचालन को पुनर्स्थापित करेंगे और इसकी स्थिति की जाँच करेंगे:

 root@redis3:/var/log/redis# redis-cli -h redis1 -p 6379 -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:slave master_host:192.168.9.96 master_port:6379 master_link_status:up master_last_io_seconds_ago:1 master_sync_in_progress:0 slave_repl_offset:15977 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:6c0c7d0eedccede56f211f2db74a98c4d0ff6d56 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:15977 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:15977

हम देखते हैं कि नोड को SLAVE भूमिका मिली है, और redis2 नोड एक मास्टर नोड है।

Redis2 नोड की विफलता का अनुकरण करें और गवाह नोड की स्थिति देखें:

 root@redis3:/var/log/redis# redis-cli -p 26379 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=master01,status=ok,address=192.168.9.95:6379,slaves=1,sentinels=1

और रेडिस 1 नोड की स्थिति:

 root@redis3:/var/log/redis# redis-cli -h redis1 -p 6379 -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:master connected_slaves:0 master_replid:6e9d67d6460815b925319c2bafb58bf2c435cffb master_replid2:6c0c7d0eedccede56f211f2db74a98c4d0ff6d56 master_repl_offset:33610 second_repl_offset:26483 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:33610

महान, तंत्र काम करता है। लेकिन अब यह सवाल उठने लगा है कि हम अपनी DirectumRX सेवाओं से कैसे जुड़ेंगे, क्योंकि उन्हें एक ही नोड पते की आवश्यकता है। हम HAProxy सेवा का उपयोग करके स्थिति को हल करेंगे।

रेडिस नोड प्रॉक्साइडिंग

कोई भी प्रॉक्सी tcp सेवा Redis नोड के लिए एक रिवर्स प्रॉक्सी के रूप में कार्य कर सकती है। इस लेख में, हम HAProxy के उपयोग पर विचार करेंगे, क्योंकि यह एक विशेष उपकरण है जो उच्च उपलब्धता और लोड संतुलन प्रदान करने के लिए डिज़ाइन किया गया है, और इसका उपयोग सार्वभौमिक रूप से ज्ञात ऑनलाइन सेवाओं द्वारा किया जाता है। डेवलपर पेज पर HAProxy के बारे में और पढ़ें।

Redis3 नोड पर HAProxy स्थापित करें:

 root@redis3:/var/log/redis# apt install haproxy

HAProxy कॉन्फ़िगरेशन फ़ाइल /etc/haproxy/haproxy.cfg में, Redis नोड्स के लिए अनुरोधों के लिए सेटिंग जोड़ें:

 … frontend ft_redis bind *:6379 name redis mode tcp default_backend bk_redis backend bk_redis mode tcp option tcp-check tcp-check connect #  ,         . tcp-check send AUTH\ TestPass\r\n tcp-check expect string +OK tcp-check send PING\r\n tcp-check expect string +PONG tcp-check send info\ replication\r\n #    MASTER, .. SLAVE      . tcp-check expect string role:master tcp-check send QUIT\r\n tcp-check expect string +OK server Redis1 redis1:6379 check inter 3s server Redis2 redis2:6379 check inter 3s

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

Hproxy सेवा को पुनरारंभ करें:

 root@redis3:/etc/haproxy# /etc/init.d/haproxy restart

आइए redis-cli क्लाइंट का उपयोग करके कनेक्ट करने और परीक्षण कुंजी बनाने का प्रयास करें:

 root@redis3:/etc/haproxy# redis-cli -p 6379 -a TestPass Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:6379> SET TestKey "Some test string" OK 127.0.0.1:6379> GET TestKey "Some test string" 127.0.0.1:6379> info keyspace # Keyspace db0:keys=1,expires=0,avg_ttl=0

Redis1 नोड बंद करें और क्वेरी फिर से कुंजियों की सूची:

 127.0.0.1:6379> info keyspace Error: Server closed the connection (3.01s) 127.0.0.1:6379> info keyspace # Keyspace db0:keys=1,expires=0,avg_ttl=0 (2.01s) 127.0.0.1:6379> GET TestKey "Some test string"

हम देखते हैं कि कुछ समय के लिए कनेक्शन काट दिया गया था, लेकिन फिर कनेक्शन फिर से बहाल कर दिया गया था और सभी डेटा जगह पर रहे।

अब Redis से कनेक्ट करने के लिए DirectumRX सेवाओं की कॉन्फ़िगरेशन फ़ाइलों में रिवर्स प्रॉक्सी पते को पंजीकृत करना पर्याप्त है।

रेडिस क्लस्टर कॉन्फ़िगर करें

Redis क्लस्टर क्लस्टर विकल्प, संस्करण redis 3.0 और उच्चतर के लिए लागू किया गया, डेटा विभाजन और प्रतिकृति के साथ क्लस्टर बनाने और प्रबंधित करने के लिए एक समाधान है। नोड प्रबंधन, प्रतिकृति, नोड्स पर डेटा सिंक्रनाइज़ेशन और कई मास्टर नोड्स में से एक के विफल होने की स्थिति में मास्टर नोड तक क्लाइंट एप्लिकेशन की पहुंच सुनिश्चित करने के कार्य करता है।

रेडिस क्लस्टर मल्टीमास्टर मोड में काम करता है, प्रत्येक मास्टर नोड में एक या अधिक SLAVE नोड्स (1000 तक) हो सकते हैं।

स्केलिंग क्लस्टर का मुख्य कार्य है। इसके अलावा, क्लस्टर रेडिस सेवा की गलती सहनशीलता की गारंटी दे सकता है:

यदि कुछ नोड्स काम नहीं करते हैं, तो क्लस्टर उनके लिए लोड को अन्य नोड्स में पुनर्वितरित करता है;
यदि कुंजी नोड काम नहीं करते हैं, तो संपूर्ण क्लस्टर समाप्त हो जाता है।

क्लाइंट 2 को M2 पर लिखने पर स्थिति उत्पन्न हो सकती है। एम 2 "ओके" का जवाब देता है और एस 2 को लिखने की कोशिश करता है। इसी समय, एम 2 एस 2 के साथ डेटा एक्सचेंज के सही समापन के लिए इंतजार नहीं करता है, लेकिन ग्राहक को तुरंत जवाब देता है। इस स्थिति में, S2 प्रतिकृति में सभी डेटा नहीं हो सकता है। इसलिए, कई SLAVE प्रतिकृतियों का उपयोग करने की सिफारिश की जाती है।

जब एम 1, एम 3 "एम 2" को देखने के लिए बंद हो जाता है, तो एक स्थिति उत्पन्न हो सकती है और क्लाइंट अभी भी एम 2 को डेटा लिखना जारी रखता है। यदि अनुपलब्धता कुछ समय (क्लस्टर-नोड-टाइमआउट पैरामीटर) के लिए जारी रहेगी, तो इस स्थिति में S2 को मास्टर मोड में डाल दिया जाएगा, और M2 अपने आप काम करना बंद कर देगा।

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

यदि कोई भौतिक नोड विफल रहता है, तो संबंधित SLAVE प्रतिकृतियां मास्टर मोड में चली जाएंगी, और संचालन बाधित नहीं होगा।

हम परीक्षण बेंच पर 3 आभासी मशीनों (redis1, redis2 और redis3) को लागू करते हैं, जिनमें से प्रत्येक 2 Red Hat इंस्टेंस को चलाएगा।

क्लाइंट एप्लिकेशन क्लाइंट कॉन्फ़िगरेशन फ़ाइल में निर्दिष्ट एक विशिष्ट पोर्ट से कनेक्ट होगा, इसलिए, मास्टर - SLAVE जोड़े को समान पोर्ट पर काम करना चाहिए।

जोड़ी M1 - S1 के लिए हम पोर्ट 6381 का उपयोग करेंगे
जोड़ी एम 2 - एस 2 के लिए हम पोर्ट 6382 का उपयोग करेंगे
जोड़ी एम 3 - एस 3 के लिए हम पोर्ट 6383 का उपयोग करेंगे

कॉन्फ़िगरेशन फ़ाइलों को तैयार करें

Redis1 पर:

 cp /etc/redis/redis.conf /etc/redis/m1_redis.conf cp /etc/redis/redis.conf /etc/redis/s2_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak

Redis2 पर:

 cp /etc/redis/redis.conf /etc/redis/m2_redis.conf cp /etc/redis/redis.conf /etc/redis/s3_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak

Redis3 पर:

 cp /etc/redis/redis.conf /etc/redis/m3_redis.conf cp /etc/redis/redis.conf /etc/redis/s1_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak

टेम्पलेट के अनुसार विन्यास फाइल भरें:

 bind <IP- > protected-mode no #      ,    . port <> pidfile /var/run/redis_<>.pid # <yes/no> -   Redis Cluster cluster-enabled yes # ,      : #  ,  ,    . #         . cluster-config-file nodes-<>.conf #  ,  master-   , #          slaves #    . cluster-node-timeout 15000

चलो रेडिस नोड्स लॉन्च करते हैं:

नोड रेडिस 1:

 root@redis1:/etc/redis# redis-server /etc/redis/m1_redis.conf root@redis1:/etc/redis# redis-server /etc/redis/s2_redis.conf

Redis2 नोड:

 root@redis2:/etc/redis# redis-server /etc/redis/m2_redis.conf root@redis2:/etc/redis# redis-server /etc/redis/s3_redis.conf

रेडिस 3 नोड:

 root@redis3:/etc/redis# redis-server /etc/redis/m3_redis.conf root@redis3:/etc/redis# redis-server /etc/redis/s1_redis.conf

क्लस्टर को कॉन्फ़िगर करने के लिए, आपको रेडिस-क्ली क्लाइंट उपयोगिता का उपयोग करने की आवश्यकता है, इसे आईपी की सूची से गुजरना होगा: सर्वर के पोर्ट जोड़े जो मास्टर और स्लेव की भूमिका निभाएंगे:

 redis-cli --cluster create redis1-ip:6381 redis2-ip:6382 redis3-ip:6383 redis1-ip:6382 redis2-ip:6383 redis3-ip:6381 --cluster-replicas 1

, जहां - thecluster-replicas 1 विकल्प बताता है कि प्रत्येक मास्टर के पास कितने SLAVE होंगे, और वे स्वचालित रूप से स्थानांतरित प्रतिकृतियों की सूची से चुने जाएंगे।

 root@redis1:~/redis/src# redis-cli --cluster create 192.168.9.51:6381 192.168.9.52:6382 192.168.9.53:6383 192.168.9.51:6382 192.168.9.52:6383 192.168.9.53:6381 --cluster-replicas 1 >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 192.168.9.52:6383 to 192.168.9.51:6381 Adding replica 192.168.9.51:6382 to 192.168.9.52:6382 Adding replica 192.168.9.53:6381 to 192.168.9.53:6383 >>> Trying to optimize slaves allocation for anti-affinity [OK] Perfect anti-affinity obtained! M: e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381 slots:[0-5460] (5461 slots) master M: d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382 slots:[5461-10922] (5462 slots) master M: 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383 slots:[10923-16383] (5461 slots) master S: 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382 replicates d499af3672b3063c7239572ec311ad3160f280ae S: 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383 replicates 3a41475e1613519c3ecdec695736a898262a24a5 S: 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381 replicates e92cb96fd6c20db7509662a248902e3751ebe95f Can I set the above configuration? (type 'yes' to accept): yes >>> Nodes configuration updated >>> Assign a different config epoch to each node >>> Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join ..... >>> Performing Cluster Check (using node 192.168.9.51:6381) M: e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381 slots:[0-5460] (5461 slots) master 1 additional replica(s) M: d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382 slots:[5461-10922] (5462 slots) master 1 additional replica(s) S: 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381 slots: (0 slots) slave replicates e92cb96fd6c20db7509662a248902e3751ebe95f S: 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382 slots: (0 slots) slave replicates d499af3672b3063c7239572ec311ad3160f280ae S: 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383 slots: (0 slots) slave replicates 3a41475e1613519c3ecdec695736a898262a24a5 M: 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383 slots:[10923-16383] (5461 slots) master 1 additional replica(s) [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered.

क्लस्टर सही ढंग से बनाया गया है। हम क्लस्टर के बारे में जानकारी प्रदर्शित करेंगे:

 root@redis1:~/redis/src# redis-cli -c -h 192.168.9.51 -p 6381 192.168.9.51:6381> CLUSTER INFO cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:6 cluster_my_epoch:1 cluster_stats_messages_ping_sent:1254 cluster_stats_messages_pong_sent:1243 cluster_stats_messages_sent:2497 cluster_stats_messages_ping_received:1238 cluster_stats_messages_pong_received:1254 cluster_stats_messages_meet_received:5 cluster_stats_messages_received:2497 192.168.9.51:6381>

रेडीस सेंटियल के साथ एक विशिष्ट प्रतिकृति का परीक्षण करने के लिए, आप INFO प्रतिकृति कमांड का उपयोग कर सकते हैं:

 root@redis1:~/redis/src# redis-cli -c -h 192.168.9.51 -p 6381 192.168.9.51:6381> INFO replication # Replication role:master connected_slaves:1 slave0:ip=192.168.9.53,port=6381,state=online,offset=1946,lag=0 master_replid:59cd95d394dad9d0e49042637fdfd5290db4abfe master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1946 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1946 192.168.9.51:6381>

आइए कई कुंजियाँ बनाने का प्रयास करें और सत्यापित करें कि ये कुंजियाँ प्रतिकृतियों पर दिखाई देती हैं:

 192.168.9.51:6381> SET key1 test1 -> Redirected to slot [9189] located at 192.168.9.52:6382 OK 192.168.9.52:6382> SET key2 test2 -> Redirected to slot [4998] located at 192.168.9.51:6381 OK 192.168.9.51:6381> SET key3 test3 OK 192.168.9.51:6381>

M2 पर जांचें:

 root@redis2:/home/user# redis-cli -c -h 192.168.9.52 -p 6382 192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.51:6381 "test2" 192.168.9.51:6381> GET key3 "test3" 192.168.9.51:6381>

और एम 3 पर:

 root@redis3:/home/user# redis-cli -c -h 192.168.9.53 -p 6383 192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.51:6381 "test2" 192.168.9.51:6381> GET key3 "test3" 192.168.9.51:6381>

हम redis1 नोड को निष्क्रिय करेंगे और जाँचेंगे कि S1 कैसे काम करता है:

 192.168.9.52:6382> CLUSTER NODES <b>182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave,fail d499af3672b3063c7239572ec311ad3160f280ae 1569509904727 1569509900000 4 connected</b> 485ffb786e9763955e6f10ffc59247690ad9bc11 <i>192.168.9.53:6381@16381 master</i> - 0 1569510017272 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569510018274 5 connected <b>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 master,fail - 1569509906731 1569509901721 1 connected</b> 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569510019275 3 connected 10923-16383 d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 myself,master - 0 1569510017000 2 connected 5461-10922

हम एम 1 और एस 2 की विफलता के बारे में जानकारी देखते हैं और एस 3 ने मास्टर मोड में बदल दिया है।

जांचें कि कुंजियां कहां संग्रहीत हैं:

 192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6381> GET key3 "test3" 192.168.9.53:6381>

कुंजी जो पहले redis1 पर संग्रहीत की गई थीं, अब redis3 पर उपलब्ध हैं।

Redis1 नोड के संचालन को पुनर्स्थापित करें और नोड्स M1 और S2 की स्थिति की जाँच करें:

 192.168.9.53:6381> CLUSTER NODES <i>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 slave 485ffb786e9763955e6f10ffc59247690ad9bc11 0 1569511658217 7 connected 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave d499af3672b3063c7239572ec311ad3160f280ae 0 1569511657000 4 connected</i> d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 master - 0 1569511656000 2 connected 5461-10922 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569511656000 3 connected 10923-16383 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381@16381 myself,master - 0 1569511656000 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569511657216 5 connected

M1 और S2 का स्वास्थ्य ठीक हो गया है, लेकिन अब M1 SLAVE मोड में है।

और चाबी भी redis3 नोड पर हैं:

 192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6383> GET key3 -> Redirected to slot [935] located at 192.168.9.53:6381 "test3"

क्लस्टर कॉन्फ़िगर किया गया है और Redis पुनर्प्राप्ति का परीक्षण किया गया है।

DirectumRX सेवाओं तक पहुंचने के लिए, आपको रिवर्स प्रॉक्सीज़ को कॉन्फ़िगर करने की भी आवश्यकता होगी, जैसा कि रेडिस सेंटीएल की स्थापना के मामले में है।

एक निष्कर्ष के बजाय

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

रिवर्स प्रॉक्सी (इस मामले में, HAProxy) के लिए, यह भी दोष सहिष्णुता प्रदान करने के लिए वांछनीय है, लेकिन यह मुद्दा भी इस लेख के दायरे से परे था। यदि आप विषय में रुचि रखते हैं, तो इन परिनियोजन विकल्पों को चरण-दर-चरण ट्यूनिंग और परिणामों के परीक्षण के साथ अलग-अलग लेखों में माना जा सकता है।

विषय के बारे में अधिक जानने के लिए आपको नीचे दिए गए लिंक मिल सकते हैं:
रेडिस क्लस्टर ट्यूटोरियल
रेडिस सेंटिनल डॉक्यूमेंटेशन
HAProxy कॉन्फ़िगरेशन मैनुअल ।

डायरेक्टिसआरएक्स सर्विसेज के लिए रेडिस स्केलिंग और फेलओवर

Redis Sentiel कॉन्फ़िगर करें

रेडिस नोड प्रॉक्साइडिंग

रेडिस क्लस्टर कॉन्फ़िगर करें

एक निष्कर्ष के बजाय

More articles: