هڪ پراڊڪٽ تي اچي رهيو آهي جيڪو هڪ ڏهاڪي کان وڌيڪ ترقي ڪري رهيو آهي، ان ۾ پراڻي ٽيڪنالاجيون ڳولڻ بلڪل تعجب جي ڳالهه ناهي. پر ڇا جيڪڏهن ڇهن مهينن ۾ توهان کي لوڊ 10 ڀيرا وڌيڪ رکڻو پوندو، ۽ زوال جي قيمت سئو ڀيرا وڌي ويندي؟ انهي حالت ۾، توهان کي هڪ بهترين هاء لوڊ انجنيئر جي ضرورت آهي. پر نوڪرياڻيءَ جي غير موجودگيءَ ۾ هنن مون کي مسئلو حل ڪرڻ جي ذميواري سونپي. آرٽيڪل جي پهرين حصي ۾ آئون توهان کي ٻڌايان ٿو ته ڪيئن اسان ريڊس کان ريڊس-ڪلستر ڏانهن منتقل ڪيو ويو آهي، ۽ ٻئي حصي ۾ آئون مشورو ڏيندس ته ڪيئن ڪلستر استعمال ڪرڻ شروع ڪيو وڃي ۽ ان کي استعمال ڪرڻ وقت ڇا ڌيان ڏيڻ گهرجي.

ٽيڪنالاجي چونڊ

ڇا اهو خراب آهي؟ الڳ ريڊس (اسٽينڊل ريڊس) 1 ماسٽر ۽ اين غلامن جي ترتيب ۾؟ مان ان کي فرسوده ٽيڪنالاجي ڇو سڏيان؟

نه، ريڊس ايترو خراب نه آهي... تنهن هوندي به، ڪجھه نقص آهن جن کي نظرانداز نٿو ڪري سگهجي.

• پهريون، ريڊس ماسٽر ناڪام ٿيڻ کانپوءِ آفت جي بحالي واري ميڪانيزم کي سپورٽ نٿو ڪري. هن مسئلي کي حل ڪرڻ لاء، اسان هڪ نئين ماسٽر ڏانهن VIPs جي خودڪار منتقلي سان هڪ ترتيب استعمال ڪيو، هڪ غلام جي ڪردار کي تبديل ڪرڻ ۽ باقي کي تبديل ڪرڻ. هن ميڪانيزم ڪم ڪيو، پر اهو هڪ قابل اعتماد حل نه ٿو چئي سگهجي. پهرين، غلط الارم واقع ٿيا، ۽ ٻيو، اهو ڊسپوزيبل هو، ۽ آپريشن کان پوء بهار کي چارج ڪرڻ لاء دستي ڪارناما گهربل هئا.

• ٻيو، صرف هڪ ماسٽر هجڻ سبب ڇڪڻ جو مسئلو پيدا ٿيو. اسان کي ڪيترائي آزاد ڪلسٽر ٺاهڻا پوندا ”1 ماسٽر ۽ اين غلام،“ پوءِ دستي طور تي ڊيٽابيس کي انهن مشينن ۾ ورهايو ۽ اميد رکون ته سڀاڻي ڊيٽابيس مان هڪ به ايترو نه سوڙندو جو ان کي الڳ مثال ڏانهن منتقل ڪرڻو پوندو.

ڪهڙا اختيار آهن؟

• سڀ کان مهانگو ۽ امير ترين حل Redis-Enterprise آهي. هي مڪمل ٽيڪنيڪل سپورٽ سان هڪ باڪس ٿيل حل آهي. ان حقيقت جي باوجود ته اها ٽيڪنيڪل نقطي نظر کان مثالي نظر اچي ٿي، اها نظرياتي سببن جي ڪري اسان کي مناسب نه هئي.
• ريڊيس- ڪلسٽر. دٻي مان ٻاهر ماسٽر ناڪامي ۽ شارڊنگ لاءِ سپورٽ آهي. انٽرفيس تقريبن باقاعده ورزن کان مختلف ناهي. اهو واعدو ڏسڻ ۾ اچي ٿو، اسان بعد ۾ نقصانن بابت ڳالهائينداسين.
• Tarantool، Memcache، Aerospike ۽ ٻيا. اهي سڀئي اوزار تمام گهڻو ڪم ڪن ٿا. پر هر هڪ پنهنجي پنهنجي نقص آهي. اسان فيصلو ڪيو ته اسان جا سڀئي انڊا هڪ ٽوڪري ۾ نه رکنداسين. اسان Memcache ۽ Tarantool استعمال ڪندا آهيون ٻين ڪمن لاءِ، ۽ اڳتي ڏسندي، مان چوندس ته اسان جي عمل ۾ انهن سان وڌيڪ مسئلا هئا.

استعمال جون خاصيتون

اچو ته هڪ نظر رکون ته ڪهڙا مسئلا اسان تاريخي طور تي حل ڪيا آهن ريڊس سان ۽ ڪهڙي ڪارڪردگي اسان استعمال ڪئي آهي:

• 2GIS وانگر ريموٽ سروسز جي درخواستن کان اڳ ڪيش | گولانگ
  

  حاصل ڪريو MGET MSET "چونڊ ڊي بي"

• MYSQL کان اڳ ڪيش | پي ايڇ پي
  

  حاصل ڪريو MGET MSET اسڪين "KEY BY PATTERN" "DB چونڊيو"

• سيشن ۽ ڊرائيور ڪوآرڊينيٽس سان ڪم ڪرڻ جي خدمت لاءِ مکيه اسٽوريج | گولانگ
  

  حاصل ڪريو MGET MSET "چونڊيو DB" "جيو ڪي شامل ڪريو" "جيو ڪي حاصل ڪريو" اسڪين

جئين توهان ڏسي سگهو ٿا، اعلي رياضي نه. پوءِ مشڪل ڇا آهي؟ اچو ته هر طريقي کي الڳ الڳ ڏسو.

طريقو
بيان
Redis-cluster جون خاصيتون
فيصلو

سيٽ حاصل ڪريو
لکڻ/پڙهڻ جي چاٻي

MGET MSET
لکو/پڙھو گھڻن چاٻيون
ڪنجيون مختلف نوڊس تي هونديون. تيار ٿيل لائبريريون صرف هڪ نوڊ اندر گھڻن آپريشن کي انجام ڏئي سگھن ٿيون
MGET کي N GET عملن جي پائپ لائن سان تبديل ڪريو

ڊي بي چونڊيو
بنياد چونڊيو جيڪو اسان ڪم ڪنداسين
گھڻن ڊيٽابيس کي سپورٽ نٿو ڪري
ھڪڙي ڊيٽابيس ۾ سڀڪنھن شيء کي رکو. اڳياڙين کي چابيون شامل ڪريو

اسڪان
ڊيٽابيس ۾ سڀني ڪنجين ذريعي وڃو
جيئن ته اسان وٽ هڪ ڊيٽابيس آهي، ڪلستر ۾ سڀني ڪنجين ذريعي وڃڻ تمام مهانگو آهي
ھڪڙي ڪنجي اندر ھڪڙي غير متغير برقرار رکو ۽ ھن ڪنجي تي HSCAN ڪريو. يا مڪمل طور تي رد ڪريو

ش
جيوڪي سان آپريشن
geokey sharded نه آهي

KEY BY PATTERN
نموني جي ذريعي چاٻي جي ڳولا
جيئن ته اسان وٽ هڪ ڊيٽابيس آهي، اسان ڪلستر جي سڀني ڪنجين ۾ ڳوليندا سين. تمام گهڻو قيمتي
رد ڪريو يا ان کي برقرار رکو، جيئن SCAN جي صورت ۾

ريڊس بمقابله ريڊس-ڪلسٽر

اسان ڇا وڃايون ٿا ۽ ڇا حاصل ڪريون ٿا جڏهن هڪ ڪلستر کي تبديل ڪريون؟

• نقصانات: اسان ڪيترن ئي ڊيٽابيس جي ڪارڪردگي کي وڃائي ڇڏيو.
  • جيڪڏهن اسان منطقي طور تي غير لاڳاپيل ڊيٽا کي هڪ ڪلستر ۾ ذخيرو ڪرڻ چاهيون ٿا، اسان کي اڳيڪس جي صورت ۾ ڪرچس ٺاهڻو پوندو.
  • اسان سڀ "بنيادي" عملن کي وڃائي ڇڏيو، جهڙوڪ SCAN، DBSIZE، CLEAR DB، وغيره.
  • ملٽي آپريشنز کي لاڳو ڪرڻ تمام گهڻو ڏکيو ٿي چڪو آهي ڇاڪاڻ ته ان کي ڪيترن ئي نوڊس تائين رسائي جي ضرورت ٿي سگھي ٿي.
• Pluses:
  • ماسٽر ناڪامي جي صورت ۾ غلطي رواداري.
  • ريڊيس پاسي تي شارڊنگ.
  • ڊيٽا کي منتقلي نوڊس جي وچ ۾ ايٽمي ۽ بغير وقت جي.
  • شامل ڪريو ۽ ٻيهر ورهايو گنجائش ۽ لوڊ لوڊ ڪرڻ جي بغير.

مان سمجهان ٿو ته جيڪڏهن توهان کي اعلي سطحي غلطي رواداري فراهم ڪرڻ جي ضرورت ناهي، ته پوء ڪلستر ڏانهن منتقل ڪرڻ ان جي قابل ناهي، ڇاڪاڻ ته اهو هڪ غير معمولي ڪم ٿي سگهي ٿو. پر جيڪڏهن توهان شروعاتي طور تي هڪ الڳ ورزن ۽ ڪلستر ورزن جي وچ ۾ چونڊيندا آهيو، ته پوءِ توهان کي هڪ ڪلستر چونڊڻ گهرجي، ڇو ته اهو وڌيڪ خراب ناهي ۽ اضافي طور تي، توهان کي ڪجهه سر دردن کان نجات ڏياريندو.

هلڻ جي تياري

اچو ته منتقل ڪرڻ جي ضرورتن سان شروع ڪريون:

• اهو بيحد هجڻ گهرجي. 5 منٽن لاءِ سروس جو مڪمل اسٽاپ اسان لاءِ مناسب ناهي.
• اهو ممڪن طور تي محفوظ ۽ تدريجي طور تي هجڻ گهرجي. مان صورتحال تي ڪجهه ڪنٽرول ڪرڻ چاهيان ٿو. اسان نه ٿا چاهيون ته هر شي کي هڪ ڀيرو ڊمپ ڪريو ۽ رول بيڪ بٽڻ تي دعا ڪريو.
• گھٽ ۾ گھٽ ڊيٽا نقصان جڏهن حرڪت. اسان سمجھون ٿا ته اهو ايٽمي طور تي منتقل ڪرڻ تمام ڏکيو ٿيندو، ان ڪري اسان ڊيٽا جي وچ ۾ باقاعده ۽ ڪلستر ٿيل ريڊس ۾ ڪجهه غير مطابقت جي اجازت ڏين ٿا.

ڪلستر جي سار سنڀال

بس هلڻ کان اڳ، اسان کي سوچڻ گهرجي ته ڇا اسان ڪلستر جي حمايت ڪري سگهون ٿا:

• چارٽ. اسان Prometheus ۽ Grafana استعمال ڪريون ٿا گراف ڪرڻ لاءِ سي پي يو لوڊ، ميموري استعمال، ڪلائنٽ جو تعداد، نمبر GET، SET، AUTH آپريشنز وغيره.
• ماهر. تصور ڪريو ته سڀاڻي توهان جي ذميواري هيٺ هڪ وڏو ڪلستر هوندو. جيڪڏهن اهو ڀڃي، ڪو به نه پر توهان ان کي درست ڪري سگهو ٿا. جيڪڏهن هو سست ٿيڻ شروع ڪري، هرڪو توهان ڏانهن ڊوڙندو. جيڪڏهن توهان کي وسيلن کي شامل ڪرڻ يا لوڊ کي ٻيهر ورهائڻ جي ضرورت آهي، توهان ڏانهن واپس اچو. 25 تي گرين نه ٿيڻ لاء، اهو مشورو ڏنو ويو آهي ته انهن ڪيسن لاء مهيا ڪيو وڃي ۽ اڳ ۾ چيڪ ڪريو ته ٽيڪنالاجي ڪجهه عملن جي تحت ڪيئن عمل ڪندو. اچو ته ان بابت وڌيڪ تفصيل سان "ماهر" سيڪشن ۾ ڳالهايون.
• نگراني ۽ خبرداري. جڏهن هڪ ڪلستر ڀڄي ويندو آهي، توهان ان جي باري ۾ ڄاڻڻ لاء پهريون ٿيڻ چاهيو ٿا. هتي اسان پاڻ کي هڪ نوٽيفڪيشن تائين محدود ڪيو آهي ته سڀئي نوڊس ڪلستر جي حالت بابت ساڳي معلومات واپس ڪن ٿا (ها، اهو مختلف طور تي ٿئي ٿو). ۽ ٻيا مسئلا وڌيڪ جلدي نوٽيس ڪري سگھجن ٿا ريڊيس ڪلائنٽ سروسز کان.

منتقل ٿيڻ

اسان ڪيئن منتقل ڪنداسين:

• سڀ کان پهريان، توهان کي ڪلستر سان ڪم ڪرڻ لاء هڪ لائبريري تيار ڪرڻ جي ضرورت آهي. اسان Go-redis کي Go ورزن جي بنياد طور ورتو ۽ ان کي ٿورو تبديل ڪيو پاڻ کي مناسب ڪرڻ لاءِ. اسان پائيپ لائينن ذريعي ملٽي طريقن کي لاڳو ڪيو، ۽ ٻيهر درخواستن کي ورجائڻ لاءِ ضابطن کي به ٿورو درست ڪيو. PHP ورزن ۾ وڌيڪ مسئلا هئا، پر اسان آخرڪار php-redis تي آباد ٿي ويا. انهن تازو متعارف ڪرايو ڪلستر سپورٽ ۽ اهو اسان جي راء ۾ سٺو لڳندو آهي.
• اڳيون توهان کي ڪلستر کي ترتيب ڏيڻ جي ضرورت آهي. اهو لفظي طور تي ڪيو ويو آهي ٻن حڪمن ۾ ترتيب واري فائل جي بنياد تي. اسان هيٺ ڏنل سيٽنگ تي وڌيڪ تفصيل سان بحث ڪنداسين.
• تدريجي حرڪت لاءِ اسان استعمال ڪندا آهيون خشڪ موڊ. جيئن ته اسان وٽ لائبريري جا ٻه ورجن هڪ ئي انٽرفيس سان آهن (هڪ ريگيول ورزن لاءِ، ٻيو ڪلسٽر لاءِ)، ان کي هڪ لفافي ٺاهڻ ۾ ڪا به قيمت نه آهي جيڪو ڪم ڪندو هڪ الڳ ورزن سان ۽ متوازي طور تي سڀني درخواستن کي ڪلستر ڏانهن نقل ڪري، جوابن جي ڀيٽ ڪريو ۽ لاگن ۾ اختلاف لکو (اسان جي صورت ۾ نيو ريلڪ ۾). ان ڪري، جيتوڻيڪ ڪلسٽر ورزن رول آئوٽ دوران ٽوڙيو، اسان جي پيداوار متاثر نه ٿيندي.
• خشڪ موڊ ۾ ڪلستر کي ختم ڪرڻ کان پوء، اسان آرام سان جواب جي تضاد جي گراف کي ڏسي سگهون ٿا. جيڪڏهن غلطي جي شرح آهستي آهستي پر يقيني طور تي ڪجهه ننڍڙن مسلسل طرف هلندي، پوء سڀ ڪجهه ٺيڪ آهي. اڃا تائين اختلاف ڇو آهن؟ ڇاڪاڻ ته هڪ الڳ ورزن ۾ رڪارڊنگ ڪلستر جي ڀيٽ ۾ ٿورو اڳ ٿئي ٿي، ۽ microlag جي ڪري، ڊيٽا مختلف ٿي سگهي ٿي. باقي اهو آهي ته تفاوت جي لاگن کي ڏسڻ لاءِ، ۽ جيڪڏهن اهي سڀ بيان ڪيا وڃن ته رڪارڊ جي غير ائٽميٽي، ته پوءِ اسان اڳتي وڌي سگهون ٿا.
• ھاڻي توھان مٽائي سگھوٿا خشڪ موڊ کي مخالف طرف ۾. اسان ڪلستر مان لکنداسين ۽ پڙھنداسين، ۽ ان کي الڳ ورزن ۾ نقل ڪنداسين. ڇا جي لاءِ؟ ايندڙ هفتي دوران آئون ڪلستر جي ڪم جو مشاهدو ڪرڻ چاهيندس. جيڪڏهن اوچتو اهو ظاهر ٿئي ٿو ته چوٽي لوڊ تي مسئلا آهن، يا اسان ڪجهه حساب ۾ نه ورتو آهي، اسان وٽ هميشه پراڻي ڪوڊ ڏانهن ايمرجنسي رول بيڪ آهي ۽ موجوده ڊيٽا کي خشڪ موڊ جي مهرباني.
• باقي رهي ٿو خشڪ موڊ کي بند ڪرڻ ۽ الڳ ورزن کي ختم ڪرڻ.

ماهر

پهرين، مختصر طور تي ڪلستر ڊيزائن بابت.

سڀ کان پهريان، ريڊس هڪ اهم قيمتي اسٽور آهي. ثالثي اسٽرنگ کي ڪنجي طور استعمال ڪيو ويندو آهي. انگ، اسٽرنگ، ۽ پوري جوڙجڪ قدر طور استعمال ڪري سگھجن ٿيون. ان کان پوءِ تمام گهڻا آهن، پر عام ڍانچي کي سمجهڻ لاءِ اهو اسان لاءِ ضروري ناهي.
چاٻين کان پوءِ خلاصي جي ايندڙ سطح سلاٽ (SLOTS) آهي. هر چاٻي 16 سلاٽ مان هڪ سان تعلق رکي ٿي. هر سلاٽ جي اندر ڪي به ڪي به چاٻيون ٿي سگهن ٿيون. اهڙيءَ طرح، سڀئي ڪنجيون 383 ڌار ڌار سيٽن ۾ ورهايل آهن.

اڳيون، ڪلستر ۾ N ماسٽر نوڊس ھئڻ گھرجي. هر نوڊ کي هڪ الڳ Redis مثال طور سمجهي سگهجي ٿو جيڪو ڪلستر جي اندر ٻين نوڊس بابت سڀ ڪجهه ڄاڻي ٿو. هر ماسٽر نوڊ ۾ ڪيترائي سلاٽ شامل آهن. هر سلاٽ صرف هڪ ماسٽر نوڊ سان تعلق رکي ٿو. سڀني سلاٽ کي نوڊس جي وچ ۾ ورهائڻ جي ضرورت آهي. جيڪڏهن ڪجهه سلاٽ مختص نه ڪيا ويا آهن، ته پوء انهن ۾ محفوظ ڪيل چابيون ناقابل رسائي هونديون. اهو سمجھ ۾ اچي ٿو ته هر ماسٽر نوڊ کي الڳ منطقي يا جسماني مشين تي هلائڻ لاء. اهو پڻ ياد رکڻ جي قابل آهي ته هر نوڊ صرف هڪ ڪور تي هلندو آهي، ۽ جيڪڏهن توهان هڪ ئي منطقي مشين تي ڪيترن ئي ريڊس مثالن کي هلائڻ چاهيو ٿا، پڪ ڪريو ته اهي مختلف ڪور تي هلن ٿا (اسان اها ڪوشش نه ڪئي آهي، پر نظريي ۾ اهو ڪم ڪرڻ گهرجي) . لازمي طور تي، ماسٽر نوڊس باقاعده شارڊنگ مهيا ڪن ٿا، ۽ وڌيڪ ماسٽر نوڊس لکڻ ۽ پڙهڻ جي درخواستن کي ماپ ڪرڻ جي اجازت ڏين ٿا.

سڀني چابين کي سلاٽ جي وچ ۾ ورهائڻ کان پوء، ۽ سلاٽ ماسٽر نوڊس جي وچ ۾ پکڙيل آهن، هر ماسٽر نوڊ ۾ غلام نوڊس جو هڪ خودمختيار نمبر شامل ڪري سگهجي ٿو. هر هڪ اهڙي ماسٽر-غلام لنڪ جي اندر، عام نقل ڪم ڪندو. پڙهيل درخواستن کي ماپڻ لاءِ ۽ ماسٽر جي ناڪامي جي صورت ۾ ناڪامي لاءِ غلامن جي ضرورت آهي.

هاڻي اچو ته آپريشنز جي ڳالهه ڪريون ته بهتر ٿيندو ته ڪم ڪرڻ جي قابل ٿي وڃي.

اسان سسٽم تائين رسائي ڪنداسين Redis-CLI ذريعي. جيئن ته Redis وٽ ھڪڙو داخلا پوائنٽ نه آھي، توھان ھيٺ ڏنل عملن کي انجام ڏئي سگھو ٿا ڪنھن ھڪڙي نوڊس تي. هر نقطي تي آئون الڳ الڳ ڌيان ڏيان ٿو آپريشن کي لوڊ ڪرڻ جي امڪان تي.

• پهرين ۽ سڀ کان اهم شيء جيڪا اسان کي گهربل آهي ڪلستر نوڊس آپريشن. اهو ڪلستر جي حالت کي واپس ڏئي ٿو، نوڊس جي هڪ فهرست ڏيکاري ٿو، انهن جا ڪردار، سلاٽ ورهائڻ، وغيره. وڌيڪ معلومات ڪلستر جي ڄاڻ ۽ ڪلستر سلاٽ استعمال ڪندي حاصل ڪري سگھجي ٿي.
• اهو سٺو هوندو ته نوڊس شامل ڪرڻ ۽ ختم ڪرڻ جي قابل ٿي. ان مقصد لاءِ ڪلسٽر ميٽ ۽ ڪلسٽر فرام آپريشنز آهن. مهرباني ڪري نوٽ ڪريو ته ڪلستر فراموش هر نوڊ تي لاڳو ڪيو وڃي، ٻنهي ماسٽرز ۽ ريپليڪس. ۽ ڪلستر ملڻ کي صرف ھڪڙي نوڊ تي سڏڻ جي ضرورت آھي. اهو فرق پريشان ڪندڙ ٿي سگهي ٿو، تنهنڪري اهو بهتر آهي ته توهان پنهنجي ڪلستر سان گڏ رهڻ کان اڳ ان بابت ڄاڻو. نوڊ شامل ڪرڻ جنگ ۾ محفوظ طور تي ڪيو ويندو آهي ۽ ڪلستر جي آپريشن کي ڪنهن به طريقي سان متاثر نٿو ڪري (جيڪو منطقي آهي). جيڪڏهن توهان ڪلستر مان هڪ نوڊ کي هٽائڻ وارا آهيو، توهان کي پڪ ڪرڻ گهرجي ته ان تي ڪو به سلاٽ باقي نه آهي (ٻي صورت ۾ توهان هن نوڊ تي سڀني چابين تائين رسائي وڃائڻ جو خطرو آهي). انهي سان گڏ، ڪنهن مالڪ کي نه هٽايو جنهن ۾ غلام آهن، ٻي صورت ۾ هڪ غير ضروري ووٽ هڪ نئين ماسٽر لاء انجام ڏنو ويندو. جيڪڏهن نوڊس ۾ هاڻي سلاٽ نه آهن، پوء اهو هڪ ننڍڙو مسئلو آهي، پر اسان کي اضافي اختيارن جي ضرورت ڇو آهي جيڪڏهن اسان پهرين غلامن کي ختم ڪري سگهون ٿا.
• جيڪڏهن توهان کي زبردستي ماسٽر ۽ غلام پوزيشن کي تبديل ڪرڻ جي ضرورت آهي، پوء ڪلستر ناڪامي حڪم ڪندو. جڏهن ان کي جنگ ۾ سڏي، توهان کي سمجهڻ جي ضرورت آهي ته ماسٽر آپريشن دوران موجود نه ٿيندو. عام طور تي سوئچ هڪ سيڪنڊ کان به گهٽ وقت ۾ ٿئي ٿو، پر ايٽمي نه آهي. توهان اميد ڪري سگهو ٿا ته ماسٽر ڏانهن ڪجهه درخواستون هن وقت ۾ ناڪام ٿينديون.
• ڪلستر مان نوڊ کي هٽائڻ کان اڳ، ان تي ڪو به سلاٽ نه ڇڏڻ گهرجي. اهو بهتر آهي ته انهن کي ٻيهر ورهايو وڃي ڪلستر reshard ڪمانڊ استعمال ڪندي. سلاٽ هڪ ماسٽر کان ٻئي ڏانهن منتقل ڪيا ويندا. سڄي آپريشن ۾ ڪيترائي منٽ لڳن ٿا، ان جو دارومدار ان ڊيٽا جي مقدار تي آهي جيڪو منتقل ڪيو پيو وڃي، پر منتقلي جو عمل محفوظ آهي ۽ ڪلستر جي آپريشن کي ڪنهن به طرح متاثر نٿو ڪري. اهڙيء طرح، سڀني ڊيٽا کي منتقل ڪري سگهجي ٿو هڪ نوڊ کان ٻئي ڏانهن سڌو سنئون لوڊ هيٺ، ۽ ان جي دستيابي جي باري ۾ پريشان ٿيڻ کان سواء. بهرحال، اتي پڻ subtleties آهن. پهرين، ڊيٽا جي منتقلي وصول ڪندڙ ۽ موڪليندڙ نوڊس تي هڪ خاص لوڊ سان لاڳاپيل آهي. جيڪڏهن وصول ڪندڙ نوڊ اڳ ۾ ئي وڏي پيماني تي پروسيسر تي لوڊ ڪيو ويو آهي، پوء توهان ان کي نئين ڊيٽا حاصل ڪرڻ سان لوڊ نه ڪرڻ گهرجي. ٻيو ته جيئن ئي موڪلائيندڙ آقا وٽ هڪ به جاءِ نه بچي ته ان جا سڀئي غلام هڪدم ان مالڪ ڏانهن ويندا، جنهن ڏانهن اهي سلاٽ منتقل ڪيا ويا هئا. ۽ مسئلو اهو آهي ته اهي سڀئي غلام هڪ ڀيرو ڊيٽا کي هم وقت سازي ڪرڻ چاهيندا. ۽ توھان خوش قسمت ھوندؤ جيڪڏھن اھو جزوي آھي بجاءِ مڪمل هم وقت سازي. ھن کي حساب ۾ وٺو ۽ سلاٽ جي منتقلي جي عملن کي گڏ ڪريو ۽ غلامن کي غير فعال ڪرڻ/منتقل ڪرڻ. يا اميد آهي ته توهان وٽ حفاظت جو ڪافي مارجن آهي.
• توهان کي ڇا ڪرڻ گهرجي جيڪڏهن، منتقلي دوران، توهان کي معلوم ٿئي ٿو ته توهان پنهنجي سلاٽ ڪٿي وڃائي ڇڏيو آهي؟ اميد اٿم ته هي مسئلو توهان کي متاثر نه ڪندو، پر جيڪڏهن اهو ٿئي ٿو، اتي هڪ ڪلستر فڪس آپريشن آهي. گهٽ ۾ گهٽ، هوء هڪ بي ترتيب ترتيب ۾ نوڊس ۾ سلاٽ کي ٽوڙي ڇڏيندو. مان سفارش ڪريان ٿو ته ان جي آپريشن کي چيڪ ڪريو پهريان نوڊ کي هٽائڻ سان ڪلستر مان ورهايل سلاٽ سان. جيئن ته غير مختص ٿيل سلاٽس ۾ ڊيٽا اڳ ۾ ئي دستياب ناهي، انهن سلاٽ جي دستيابي سان مسئلن بابت پريشان ٿيڻ جي دير ٿي چڪي آهي. موڙ ۾، آپريشن ورهايل سلاٽ کي متاثر نه ڪندو.
• هڪ ٻيو مفيد آپريشن مانيٽر آهي. اهو توهان کي حقيقي وقت ڏسڻ جي اجازت ڏئي ٿو درخواستن جي مڪمل فهرست نوڊ ڏانهن وڃڻ. ان کان علاوه، توھان ان کي گريپ ڪري سگھو ٿا ۽ معلوم ڪريو ته ضروري ٽرئفڪ آھي.

اهو پڻ قابل ذڪر آهي ماسٽر ناڪامي جي طريقيڪار. مختصر ۾، اهو موجود آهي، ۽، منهنجي خيال ۾، اهو عظيم ڪم ڪري ٿو. بهرحال، اهو نه سوچيو ته جيڪڏهن توهان ماسٽر نوڊ سان هڪ مشين تي پاور ڪنڊ انپلگ ڪريو ٿا، ريڊس فوري طور تي سوئچ ڪندو ۽ گراهڪ نقصان کي نوٽيس نه ڪندا. منهنجي مشق ۾، سوئچنگ چند سيڪنڊن ۾ ٿيندي آهي. هن عرصي دوران، ڪجهه ڊيٽا دستياب نه هوندا: ماسٽر جي غير موجودگي معلوم ڪئي وئي آهي، نوڊس هڪ نئين لاء ووٽ ڪندا آهن، غلامن کي تبديل ڪيو ويندو آهي، ڊيٽا هم وقت سازي ڪئي وئي آهي. پنهنجي لاءِ پڪ ڪرڻ جو بهترين طريقو اهو آهي ته اهو منصوبو ڪم ڪري رهيو آهي مقامي مشقون ڪرڻ. پنھنجي ليپ ٽاپ تي ڪلستر کي وڌايو، ان کي گھٽ ۾ گھٽ لوڊ ڏيو، ھڪڙي حادثي کي ٺاھيو (مثال طور، بندرگاھن کي بلاڪ ڪندي)، ۽ سوئچنگ جي رفتار جو جائزو وٺو. منهنجي خيال ۾، صرف هڪ يا ٻه ڏينهن لاء هن طريقي سان راند ڪرڻ کان پوء، توهان ٽيڪنالاجي جي آپريشن ۾ اعتماد ڪري سگهو ٿا. خير، يا اميد آهي ته اهو سافٽ ويئر جيڪو اڌ انٽرنيٽ استعمال ڪري ٿو شايد ڪم ڪري ٿو.

ڪنفگريشن

گهڻو ڪري، ترتيب اها پهرين شيء آهي جيڪا توهان کي اوزار سان ڪم ڪرڻ شروع ڪرڻ جي ضرورت آهي. ۽ جڏهن سڀ ڪجهه ڪم ڪري ٿو، توهان اڃا به نه ٿا چاهيو ته ترتيب کي ڇڪڻ. اهو ڪجهه ڪوشش وٺندو آهي پاڻ کي مجبور ڪرڻ لاءِ سيٽنگون ڏانهن واپس وڃڻ ۽ انهن جي ذريعي احتياط سان. منهنجي ياداشت ۾، اسان کي گهٽ ۾ گهٽ ٻه سنگين ناڪامي هئي، ڇاڪاڻ ته ترتيب ڏيڻ ۾ غفلت جي ڪري. هيٺ ڏنل نقطن تي خاص ڌيان ڏيو:

• وقت ختم ٿيڻ 0
  وقت جنهن کان پوء غير فعال ڪنيڪشن بند ٿي ويا آهن (سيڪنڊن ۾). 0 - بند نه ڪريو
  اسان جي هر لائبريري صحيح طريقي سان ڪنيڪشن بند ڪرڻ جي قابل نه هئي. ھن سيٽنگ کي غير فعال ڪرڻ سان، اسان ڪلائنٽ جي تعداد جي حد کي مارڻ جو خطرو آھي. ٻئي طرف، جيڪڏهن ڪو اهڙو مسئلو آهي، ته پوءِ گم ٿيل ڪنيڪشن جو خودڪار ختم ٿيڻ ان کي ڇڪي ڇڏيندو، ۽ اسان شايد نوٽيس نه ڪري سگهون. اضافي طور تي، توهان کي هن سيٽنگ کي فعال نه ڪرڻ گهرجي جڏهن مسلسل ڪنيڪشن استعمال ڪندي.
• محفوظ ڪريو xy ۽ ضميمو صرف ها
  آر ڊي بي سنيپ شاٽ محفوظ ڪرڻ.
  اسان هيٺ ڏنل تفصيل سان RDB/AOF مسئلن تي بحث ڪنداسين.
• stop-writes-on-bgsave-error no ۽ slave-serve-stale-data ها
  جيڪڏهن فعال ٿيو، جيڪڏهن RDB سنيپ شاٽ ڀڃي، ماسٽر تبديلي جي درخواستن کي قبول ڪرڻ بند ڪري ڇڏيندو. جيڪڏهن مالڪ سان رابطو گم ٿي ويو آهي، غلام درخواستن جو جواب ڏيڻ جاري رکي سگهي ٿو (ها). يا جواب ڏيڻ بند ڪندو (نه)
  اسان ان صورتحال کان خوش نه آهيون جنهن ۾ ريڊس ڪدو ۾ بدلجي وڃي ٿي.
• ريپل-پنگ-غلام-دوري 5
  وقت جي هن عرصي کان پوء، اسان پريشان ٿيڻ شروع ڪنداسين ته ماسٽر ڀڄي ويو آهي ۽ اهو وقت آهي ناڪامي جي طريقيڪار تي عمل ڪرڻ جو.
  توهان کي دستي طور تي غلط مثبت ۽ ناڪام ٿيڻ جي وچ ۾ توازن ڳولڻو پوندو. اسان جي مشق ۾ اهو 5 سيڪنڊ آهي.
• repl-backlog-size 1024mb ۽ epl-backlog-ttl 0
  اسان بلڪل ايتري ڊيٽا محفوظ ڪري سگھون ٿا بفر ۾ ناڪامي ريپليڪا لاءِ. جيڪڏهن بفر ختم ٿي وڃي، توهان کي مڪمل طور تي هم وقت سازي ڪرڻو پوندو.
  مشق مشورو ڏئي ٿو ته اهو بهتر آهي ته اعلي قيمت مقرر ڪرڻ. اهڙا ڪيترائي سبب آهن ڇو ته هڪ نقل ٿيڻ شروع ٿي سگهي ٿي. جيڪڏهن اهو دير ٿي ويو آهي، ته گهڻو ڪري توهان جو ماسٽر اڳ ۾ ئي مقابلو ڪرڻ لاء جدوجهد ڪري رهيو آهي، ۽ مڪمل هم وقت سازي آخري اسٽري هوندي.
• وڌ ۾ وڌ 10000
  ھڪڙي وقت جي گراهڪن جو وڌ ۾ وڌ تعداد.
  اسان جي تجربي ۾، اهو بهتر آهي ته اعلي قيمت مقرر ڪرڻ. ريڊس 10k ڪنيڪشن کي ٺيڪ ڪري ٿو. بس پڪ ڪريو ته سسٽم تي ڪافي ساکٽ آهن.
• maxmemory-policy volatile-ttl
  ضابطو جنهن جي ذريعي چابيون ختم ٿي وينديون آهن جڏهن دستياب ميموري جي حد تائين پهچي وڃي ٿي.
  هتي ضروري آهي ته قاعدو نه آهي، پر اهو سمجهڻ آهي ته اهو ڪيئن ٿيندو. ريڊس کي عام طور تي ڪم ڪرڻ جي صلاحيت جي ساراهه ڪري سگهجي ٿو جڏهن ياداشت جي حد تائين پهچي وڃي ٿي.

RDB ۽ AOF مسئلا

جيتوڻيڪ Redis پاڻ سموري معلومات کي RAM ۾ محفوظ ڪري ٿو، اتي پڻ ڊيٽا کي ڊسڪ ۾ محفوظ ڪرڻ لاء هڪ ميکانيزم آهي. وڌيڪ واضح طور تي، ٽي ميڪانيزم:

• آر ڊي بي سنيپ شاٽ - سڀني ڊيٽا جو هڪ مڪمل سنيپ شاٽ. SAVE XY جي ترتيب کي استعمال ڪندي سيٽ ڪريو ۽ پڙهي ٿو "سڀني ڊيٽا جو مڪمل سنيپ شاٽ محفوظ ڪريو هر X سيڪنڊن ۾ جيڪڏهن گهٽ ۾ گهٽ Y ڪنجيون تبديل ٿي ويون آهن."
• صرف شامل ڪريو فائل - عملن جي ھڪڙي فهرست ان ترتيب ۾ جيڪي اھي ڪيا ويا آھن. هر X سيڪنڊن يا هر Y عملن کي فائل ۾ نوان ايندڙ عمل شامل ڪري ٿو.
• RDB ۽ AOF پوئين ٻن جو مجموعو آهي.

سڀني طريقن جا پنهنجا فائدا ۽ نقصان آهن، مان انهن سڀني کي لسٽ نه ڪندس، مان صرف انهن نقطن ڏانهن ڌيان ڏيندس جيڪي، منهنجي خيال ۾، واضح نه آهن.

پهريون، هڪ RDB سنيپ شاٽ بچائڻ لاءِ FORK کي ڪال ڪرڻ جي ضرورت آهي. جيڪڏهن ڊيٽا جو تمام گهڻو آهي، اهو سڀني ريڊس کي ڪجهه سيڪنڊن کان سيڪنڊن جي عرصي تائين لڪائي سگهي ٿو. ان کان علاوه، سسٽم کي اهڙي سنيپ شاٽ لاء ميموري کي مختص ڪرڻ جي ضرورت آهي، جيڪا منطقي مشين تي ريم جي ٻٽي سپلائي رکڻ جي ضرورت آهي: جيڪڏهن 8 GB ريڊس لاء مختص ڪيا ويا آهن، پوء 16 GB سان گڏ مجازي مشين تي دستياب هجڻ گهرجي. اهو.

ٻيو، جزوي هم وقت سازي سان مسئلا آهن. AOF موڊ ۾، جڏهن غلام ٻيهر ڳنڍيو ويندو آهي، جزوي هم وقت سازي جي بدران، مڪمل هم وقت سازي ڪري سگهجي ٿو. ائين ڇو ٿو ٿئي، مان سمجهي نه سگهيس. پر اهو ياد رکڻ جي قابل آهي.

اهي ٻه نقطا اڳ ۾ ئي اسان کي سوچڻ جي ضرورت آهي ته ڇا اسان کي ڊسڪ تي هن ڊيٽا جي ضرورت آهي جيڪڏهن هر شيء اڳ ۾ ئي غلام طرفان نقل ٿيل آهي. ڊيٽا صرف گم ٿي سگهي ٿي جيڪڏهن سڀئي غلام ناڪام ٿين، ۽ اهو هڪ "ڊي سي ۾ باهه" سطح جو مسئلو آهي. سمجھوتا ​​جي طور تي، توھان تجويز ڪري سگھوٿا ڊيٽا کي صرف غلامن تي محفوظ ڪرڻ، پر ھن صورت ۾ توھان کي پڪ ڪرڻ جي ضرورت آھي ته اھي غلام ڪڏھن بھ آفت جي بحالي دوران مالڪ نه ٿيندا (ان لاءِ انھن جي ترتيب ۾ ھڪڙي غلام جي ترجيح آھي). پاڻ لاء، هر مخصوص صورت ۾ اسان سوچيو ته ڇا اهو ضروري آهي ته ڊيٽا کي ڊسڪ ۾ محفوظ ڪرڻ لاء، ۽ اڪثر ڪري جواب "نه" آهي.

ٿڪل

نتيجي ۾، مون کي اميد آهي ته آئون هڪ عام خيال ڏيڻ جي قابل ٿي چڪو آهيان ته ڪيئن redis-cluster ڪم ڪري ٿو انهن لاءِ جن ان جي باري ۾ ڪجهه به نه ٻڌو آهي، ۽ انهن لاءِ ڪجهه غير واضح نقطن ڏانهن ڌيان پڻ ڏنو جيڪي ان کي استعمال ڪري رهيا آهن. گهڻي وقت تائين.
توهان جي وقت جي مهرباني ۽، هميشه وانگر، موضوع تي تبصرو ڀليڪار آهي.

جو ذريعو: www.habr.com