ایک ایسی پراڈکٹ کی طرف آنا جو ایک دہائی سے زیادہ عرصے سے تیار ہو رہی ہے، اس میں فرسودہ ٹیکنالوجیز کو تلاش کرنا بالکل بھی حیران کن نہیں ہے۔ لیکن کیا ہوگا اگر چھ ماہ میں آپ کو بوجھ 10 گنا زیادہ رکھنا پڑے اور گرنے کی قیمت سینکڑوں گنا بڑھ جائے؟ اس صورت میں، آپ کو ایک ٹھنڈے ہائی لوڈ انجینئر کی ضرورت ہے۔ لیکن نوکرانی کی غیر موجودگی میں انہوں نے مسئلہ حل کرنے کی ذمہ داری مجھے سونپ دی۔ مضمون کے پہلے حصے میں میں آپ کو بتاؤں گا کہ ہم Redis سے Redis-cluster میں کیسے منتقل ہوئے، اور دوسرے حصے میں میں مشورہ دوں گا کہ کلسٹر کا استعمال کیسے شروع کیا جائے اور اسے استعمال کرتے وقت کن چیزوں پر توجہ دینی چاہیے۔

ٹیکنالوجی کا انتخاب

کیا یہ اتنا برا ہے؟ علیحدہ Redis (اسٹینڈ اسٹون ریڈیس) 1 ماسٹر اور این غلاموں کی ترتیب میں؟ میں اسے فرسودہ ٹیکنالوجی کیوں کہوں؟

نہیں، Redis اتنا برا نہیں ہے... تاہم، کچھ خامیاں ہیں جنہیں نظر انداز نہیں کیا جا سکتا۔

• سب سے پہلے، ریڈیس ماسٹر فیل ہونے کے بعد ڈیزاسٹر ریکوری میکانزم کی حمایت نہیں کرتا ہے۔ اس مسئلے کو حل کرنے کے لیے، ہم نے VIPs کی ایک نئے آقا کو خودکار منتقلی کے ساتھ ایک کنفیگریشن کا استعمال کیا، غلاموں میں سے ایک کا کردار تبدیل کیا اور باقی کو تبدیل کیا۔ اس طریقہ کار نے کام کیا، لیکن اسے قابل اعتماد حل نہیں کہا جا سکتا۔ سب سے پہلے، غلط الارم ہوا، اور دوسرا، یہ ڈسپوزایبل تھا، اور آپریشن کے بعد دستی کارروائیوں کو بہار کو چارج کرنے کی ضرورت تھی.

• دوم، صرف ایک ماسٹر ہونے کی وجہ سے شارڈنگ کا مسئلہ پیدا ہوا۔ ہمیں کئی آزاد کلسٹرز "1 ماسٹر اور این غلام" بنانے تھے، پھر ان مشینوں کے درمیان ڈیٹا بیس کو دستی طور پر تقسیم کرنا تھا اور امید ہے کہ کل ڈیٹا بیس میں سے کوئی اتنا نہیں بڑھے گا کہ اسے الگ مثال میں منتقل کرنا پڑے۔

اختیارات کیا ہیں؟

• سب سے مہنگا اور امیر ترین حل Redis-Enterprise ہے۔ یہ مکمل تکنیکی مدد کے ساتھ ایک باکسڈ حل ہے۔ اس حقیقت کے باوجود کہ یہ تکنیکی نقطہ نظر سے مثالی نظر آتا ہے، یہ نظریاتی وجوہات کی بنا پر ہمارے لیے مناسب نہیں تھا۔
• ریڈیس کلسٹر۔ باکس سے باہر ماسٹر فیل اوور اور شارڈنگ کے لیے سپورٹ موجود ہے۔ انٹرفیس تقریباً باقاعدہ ورژن سے مختلف نہیں ہے۔ یہ امید افزا لگتا ہے، ہم بعد میں نقصانات کے بارے میں بات کریں گے۔
• Tarantool، Memcache، Aerospike اور دیگر۔ یہ تمام ٹولز تقریبا ایک ہی کام کرتے ہیں۔ لیکن ہر ایک کی اپنی خامیاں ہیں۔ ہم نے اپنے تمام انڈے ایک ٹوکری میں نہ ڈالنے کا فیصلہ کیا۔ ہم دوسرے کاموں کے لیے Memcache اور Tarantool کا استعمال کرتے ہیں، اور، آگے دیکھتے ہوئے، میں کہوں گا کہ ہمارے عمل میں ان کے ساتھ زیادہ مسائل تھے۔

استعمال کی تفصیلات

آئیے ایک نظر ڈالیں کہ ہم نے تاریخی طور پر ریڈیس کے ساتھ کن مسائل کو حل کیا ہے اور ہم نے کون سی فعالیت استعمال کی ہے:

• 2GIS جیسی ریموٹ سروسز کی درخواستوں سے پہلے کیش | گولانگ
  

  GET SET MGET MSET "منتخب DB" حاصل کریں

• MYSQL سے پہلے کیشے | پی ایچ پی
  

  GET SET MGET MSET SCAN "کی بائے پیٹرن" "منتخب DB" حاصل کریں

• سیشنز اور ڈرائیور کوآرڈینیٹ کے ساتھ کام کرنے کی خدمت کے لیے اہم ذخیرہ | گولانگ
  

  MGET MSET حاصل کریں "DB کو منتخب کریں" "جیو کلید شامل کریں" "جیو کلید حاصل کریں" اسکین کریں

جیسا کہ آپ دیکھ سکتے ہیں، کوئی اعلیٰ ریاضی نہیں۔ پھر مشکل کیا ہے؟ آئیے ہر طریقہ کو الگ الگ دیکھتے ہیں۔

طریقہ۔
تفصیل
ریڈیس کلسٹر کی خصوصیات
حل

تیار
کلید لکھیں/پڑھیں۔

ایم جی ای ٹی ایم ایس ای ٹی
متعدد کلیدیں لکھیں/پڑھیں۔
چابیاں مختلف نوڈس پر ہوں گی۔ ریڈی میڈ لائبریریاں صرف ایک نوڈ کے اندر ملٹی آپریشن کر سکتی ہیں۔
MGET کو N GET آپریشنز کی پائپ لائن سے بدل دیں۔

ڈی بی کو منتخب کریں۔
وہ بنیاد منتخب کریں جس کے ساتھ ہم کام کریں گے۔
متعدد ڈیٹا بیس کی حمایت نہیں کرتا ہے۔
ہر چیز کو ایک ڈیٹا بیس میں رکھیں۔ چابیاں میں سابقے شامل کریں۔

اسکین
ڈیٹا بیس میں تمام چابیاں کے ذریعے جائیں
چونکہ ہمارے پاس ایک ڈیٹا بیس ہے، اس لیے کلسٹر میں موجود تمام کلیدوں سے گزرنا بہت مہنگا ہے۔
ایک کلید کے اندر غیر متغیر کو برقرار رکھیں اور اس کلید پر HSCAN کریں۔ یا مکمل انکار کر دیں۔

جیو
جیوکی کے ساتھ آپریشنز
جیوکی کٹی ہوئی نہیں ہے۔

پیٹرن کے لحاظ سے کلید
پیٹرن کے لحاظ سے کلید تلاش کرنا
چونکہ ہمارے پاس ایک ڈیٹا بیس ہے، اس لیے ہم کلسٹر میں موجود تمام کیز کو تلاش کریں گے۔ بہت مہنگا
SCAN کے معاملے کی طرح، انویرینٹ سے انکار یا برقرار رکھیں

ریڈیس بمقابلہ ریڈیس کلسٹر

کلسٹر پر سوئچ کرتے وقت ہم کیا کھوتے ہیں اور کیا حاصل کرتے ہیں؟

• نقصانات: ہم کئی ڈیٹا بیس کی فعالیت کھو دیتے ہیں۔
  • اگر ہم منطقی طور پر غیر متعلقہ ڈیٹا کو ایک کلسٹر میں محفوظ کرنا چاہتے ہیں تو ہمیں سابقے کی شکل میں بیساکھی بنانا پڑے گی۔
  • ہم تمام "بیس" آپریشنز کھو دیتے ہیں، جیسے SCAN، DBSIZE، CLEAR DB، وغیرہ۔
  • ملٹی آپریشنز کو نافذ کرنا بہت مشکل ہو گیا ہے کیونکہ اس کے لیے کئی نوڈس تک رسائی کی ضرورت پڑ سکتی ہے۔
• Pluses:
  • ماسٹر فیل اوور کی شکل میں غلطی کی رواداری۔
  • Redis طرف Sharding.
  • ڈیٹا کو نوڈس کے درمیان ایٹم اور بغیر ٹائم کے منتقل کریں۔
  • ڈاون ٹائم کے بغیر صلاحیت اور بوجھ کو شامل کریں اور دوبارہ تقسیم کریں۔

میں یہ نتیجہ اخذ کروں گا کہ اگر آپ کو اعلی درجے کی غلطی رواداری فراہم کرنے کی ضرورت نہیں ہے، تو ایک جھرمٹ میں منتقل ہونا اس کے قابل نہیں ہے، کیونکہ یہ ایک غیر معمولی کام ہوسکتا ہے۔ لیکن اگر آپ ابتدائی طور پر ایک الگ ورژن اور کلسٹر ورژن کے درمیان انتخاب کرتے ہیں، تو آپ کو ایک کلسٹر کا انتخاب کرنا چاہیے، کیونکہ یہ کوئی برا نہیں ہے اور اس کے علاوہ، آپ کو کچھ سر درد سے نجات دلائے گا۔

منتقل کرنے کی تیاری

آئیے منتقل کرنے کی ضروریات کے ساتھ شروع کریں:

• یہ ہموار ہونا چاہئے. 5 منٹ کے لیے سروس کا مکمل سٹاپ ہمارے لیے مناسب نہیں ہے۔
• یہ ممکن حد تک محفوظ اور بتدریج ہونا چاہئے۔ میں حالات پر کچھ قابو پانا چاہتا ہوں۔ ہم سب کچھ ایک ساتھ پھینکنا اور رول بیک بٹن پر دعا نہیں کرنا چاہتے۔
• حرکت کرتے وقت ڈیٹا کا کم سے کم نقصان۔ ہم سمجھتے ہیں کہ جوہری طور پر حرکت کرنا بہت مشکل ہوگا، اس لیے ہم ریگولر اور کلسٹرڈ Redis میں ڈیٹا کے درمیان کچھ غیر ہم آہنگی کی اجازت دیتے ہیں۔

کلسٹر کی دیکھ بھال

اس اقدام سے ذرا پہلے، ہمیں سوچنا چاہیے کہ آیا ہم کلسٹر کی حمایت کر سکتے ہیں:

• چارٹس۔ ہم CPU لوڈ، میموری کے استعمال، کلائنٹس کی تعداد، GET، SET، AUTH آپریشنز وغیرہ کو گراف کرنے کے لیے Prometheus اور Grafana کا استعمال کرتے ہیں۔
• مہارت۔ تصور کریں کہ کل آپ کی ذمہ داری کے تحت ایک بہت بڑا جھرمٹ ہوگا۔ اگر یہ ٹوٹ جائے تو آپ کے علاوہ کوئی بھی اسے ٹھیک نہیں کر سکتا۔ اگر وہ سست ہونے لگے تو سب آپ کی طرف بھاگیں گے۔ اگر آپ کو وسائل شامل کرنے یا بوجھ کو دوبارہ تقسیم کرنے کی ضرورت ہے، تو آپ کے پاس واپس آئیں۔ 25 سال کی عمر میں خاکستری نہ ہونے کے لیے، یہ مشورہ دیا جاتا ہے کہ ان معاملات کے لیے فراہم کیا جائے اور پیشگی جانچ پڑتال کی جائے کہ ٹیکنالوجی کچھ اقدامات کے تحت کیسا برتاؤ کرے گی۔ آئیے اس کے بارے میں مزید تفصیل سے "ماہر" سیکشن میں بات کرتے ہیں۔
• نگرانی اور انتباہات۔ جب کوئی کلسٹر ٹوٹ جاتا ہے، تو آپ اس کے بارے میں جاننے والے پہلے بننا چاہتے ہیں۔ یہاں ہم نے خود کو ایک اطلاع تک محدود رکھا کہ تمام نوڈس کلسٹر کی حالت کے بارے میں ایک ہی معلومات واپس کرتے ہیں (ہاں، یہ مختلف طریقے سے ہوتا ہے)۔ اور دیگر مسائل کو Redis کلائنٹ سروسز کے انتباہات کے ذریعے زیادہ تیزی سے دیکھا جا سکتا ہے۔

نقل مکانی

ہم کیسے منتقل ہوں گے:

• سب سے پہلے، آپ کو کلسٹر کے ساتھ کام کرنے کے لیے ایک لائبریری تیار کرنے کی ضرورت ہے۔ ہم نے Go-redis کو گو ورژن کی بنیاد کے طور پر لیا اور اسے اپنے مطابق کرنے کے لیے تھوڑا سا تبدیل کیا۔ ہم نے پائپ لائنوں کے ذریعے ملٹی میتھڈز کو لاگو کیا، اور درخواستوں کو دہرانے کے اصولوں کو بھی قدرے درست کیا۔ پی ایچ پی ورژن میں مزید مسائل تھے، لیکن ہم آخر کار پی ایچ پی ریڈیس پر طے پا گئے۔ انہوں نے حال ہی میں کلسٹر سپورٹ متعارف کرایا ہے اور یہ ہماری رائے میں اچھا لگتا ہے۔
• اگلا آپ کو خود کلسٹر کو تعینات کرنے کی ضرورت ہے۔ یہ کنفیگریشن فائل کی بنیاد پر دو کمانڈز میں لفظی طور پر کیا جاتا ہے۔ ہم ذیل میں مزید تفصیل سے ترتیب پر تبادلہ خیال کریں گے۔
• بتدریج حرکت کرنے کے لیے ہم ڈرائی موڈ استعمال کرتے ہیں۔ چونکہ ہمارے پاس ایک ہی انٹرفیس کے ساتھ لائبریری کے دو ورژن ہیں (ایک باقاعدہ ورژن کے لیے، دوسرا کلسٹر کے لیے)، اس لیے ایسا ریپر بنانے میں کچھ بھی خرچ نہیں آتا جو ایک الگ ورژن کے ساتھ کام کرے اور متوازی طور پر کلسٹر کی تمام درخواستوں کو نقل کرے، جوابات کا موازنہ کریں اور نوشتہ جات میں تضادات لکھیں ( ہمارے معاملے میں نیو ریلیک میں)۔ اس طرح، چاہے کلسٹر ورژن رول آؤٹ کے دوران ٹوٹ جائے، ہماری پیداوار متاثر نہیں ہوگی۔
• کلسٹر کو ڈرائی موڈ میں رول آؤٹ کرنے کے بعد، ہم سکون سے جوابی تضادات کے گراف کو دیکھ سکتے ہیں۔ اگر غلطی کی شرح آہستہ آہستہ لیکن یقینی طور پر کسی چھوٹے مستقل کی طرف بڑھ جاتی ہے، تو سب کچھ ٹھیک ہے۔ اب بھی تضادات کیوں ہیں؟ کیونکہ الگ ورژن میں ریکارڈنگ کلسٹر کے مقابلے میں تھوڑی دیر پہلے ہوتی ہے، اور مائیکرولاگ کی وجہ سے ڈیٹا مختلف ہو سکتا ہے۔ باقی صرف تضادات کے نوشتہ جات کو دیکھنا ہے، اور اگر ان سب کی وضاحت ریکارڈ کی غیر جوہری حیثیت سے کر دی جائے، تو ہم آگے بڑھ سکتے ہیں۔
• اب آپ ڈرائی موڈ کو مخالف سمت میں تبدیل کر سکتے ہیں۔ ہم کلسٹر سے لکھیں گے اور پڑھیں گے، اور اسے الگ ورژن میں نقل کریں گے۔ کس لیے؟ اگلے ہفتے میں کلسٹر کے کام کا مشاہدہ کرنا چاہوں گا۔ اگر یہ اچانک پتہ چلتا ہے کہ چوٹی کے بوجھ میں مسائل ہیں، یا ہم نے کسی چیز کو مدنظر نہیں رکھا ہے، تو ہمارے پاس ہمیشہ پرانے کوڈ اور موجودہ ڈیٹا پر ڈرائی موڈ کی بدولت ہنگامی رول بیک ہوتا ہے۔
• باقی صرف خشک موڈ کو غیر فعال کرنا اور علیحدہ ورژن کو ختم کرنا ہے۔

مہارت

سب سے پہلے، کلسٹر ڈیزائن کے بارے میں مختصر طور پر.

سب سے پہلے، Redis ایک کلیدی قدر کی دکان ہے۔ صوابدیدی تاروں کو چابیاں کے طور پر استعمال کیا جاتا ہے۔ اعداد، تار، اور پورے ڈھانچے کو قدروں کے طور پر استعمال کیا جا سکتا ہے۔ مؤخر الذکر میں سے بہت سارے ہیں، لیکن عام ڈھانچے کو سمجھنے کے لیے یہ ہمارے لیے اہم نہیں ہے۔
چابیاں کے بعد تجرید کی اگلی سطح سلاٹس (SLOTS) ہے۔ ہر کلید 16 سلاٹوں میں سے ایک سے تعلق رکھتی ہے۔ ہر سلاٹ کے اندر کسی بھی تعداد میں چابیاں ہوسکتی ہیں۔ اس طرح، تمام کلیدوں کو 383 جداگانہ سیٹوں میں تقسیم کیا گیا ہے۔

اگلا، کلسٹر میں N ماسٹر نوڈس ہونے چاہئیں۔ ہر نوڈ کو ایک علیحدہ Redis مثال کے طور پر سوچا جا سکتا ہے جو کلسٹر کے اندر موجود دیگر نوڈس کے بارے میں سب کچھ جانتا ہے۔ ہر ماسٹر نوڈ میں کئی سلاٹ ہوتے ہیں۔ ہر سلاٹ کا تعلق صرف ایک ماسٹر نوڈ سے ہے۔ تمام سلاٹس کو نوڈس کے درمیان تقسیم کرنے کی ضرورت ہے۔ اگر کچھ سلاٹ مختص نہیں کیے گئے ہیں، تو ان میں ذخیرہ شدہ چابیاں ناقابل رسائی ہوں گی۔ ہر ماسٹر نوڈ کو الگ منطقی یا فزیکل مشین پر چلانا سمجھ میں آتا ہے۔ یہ بھی یاد رکھنے کے قابل ہے کہ ہر نوڈ صرف ایک کور پر چلتا ہے، اور اگر آپ ایک ہی منطقی مشین پر ایک سے زیادہ Redis مثالوں کو چلانا چاہتے ہیں، تو یقینی بنائیں کہ وہ مختلف کور پر چلتے ہیں (ہم نے اس کی کوشش نہیں کی، لیکن نظریہ طور پر اسے کام کرنا چاہیے) . بنیادی طور پر، ماسٹر نوڈس باقاعدگی سے شارڈنگ فراہم کرتے ہیں، اور مزید ماسٹر نوڈس لکھنے اور پڑھنے کی درخواستوں کو پیمانے کی اجازت دیتے ہیں۔

تمام چابیاں سلاٹس میں تقسیم ہونے کے بعد، اور سلاٹس ماسٹر نوڈس کے درمیان بکھرے ہوئے ہیں، ہر ماسٹر نوڈ میں سلیو نوڈس کی صوابدیدی تعداد کو شامل کیا جا سکتا ہے۔ اس طرح کے ہر ماسٹر غلام لنک کے اندر، عام نقل کام کرے گی۔ پڑھنے کی درخواستوں کو پیمانے کے لیے اور ماسٹر کی ناکامی کی صورت میں فیل اوور کے لیے غلاموں کی ضرورت ہوتی ہے۔

اب بات کرتے ہیں آپریشنز کے بارے میں جو کرنے کے قابل ہونا بہتر ہوگا۔

ہم Redis-CLI کے ذریعے سسٹم تک رسائی حاصل کریں گے۔ چونکہ Redis کے پاس ایک بھی انٹری پوائنٹ نہیں ہے، اس لیے آپ کسی بھی نوڈس پر درج ذیل آپریشن کر سکتے ہیں۔ ہر نقطہ پر میں بوجھ کے تحت آپریشن کو انجام دینے کے امکان پر الگ سے توجہ مبذول کرتا ہوں۔

• پہلی اور سب سے اہم چیز جس کی ہمیں ضرورت ہے وہ ہے کلسٹر نوڈس آپریشن۔ یہ کلسٹر کی حالت واپس کرتا ہے، نوڈس کی فہرست، ان کے کردار، سلاٹ کی تقسیم وغیرہ دکھاتا ہے۔ مزید معلومات کلسٹر معلومات اور کلسٹر سلاٹس کا استعمال کرتے ہوئے حاصل کی جا سکتی ہیں۔
• نوڈس کو شامل کرنے اور ہٹانے کے قابل ہونا اچھا ہوگا۔ اس مقصد کے لیے کلسٹر میٹ اور کلسٹر بھولنے کے آپریشنز ہیں۔ براہ کرم نوٹ کریں کہ کلسٹر بھولنے کا اطلاق ہر نوڈ پر ہونا چاہیے، ماسٹرز اور ریپلیکس دونوں۔ اور کلسٹر میٹ کو صرف ایک نوڈ پر بلانے کی ضرورت ہے۔ یہ فرق پریشان کن ہو سکتا ہے، لہذا اپنے کلسٹر کے ساتھ لائیو ہونے سے پہلے اس کے بارے میں جان لینا بہتر ہے۔ نوڈ کو شامل کرنا جنگ میں محفوظ طریقے سے کیا جاتا ہے اور کسی بھی طرح سے کلسٹر کے آپریشن کو متاثر نہیں کرتا ہے (جو کہ منطقی ہے)۔ اگر آپ کلسٹر سے نوڈ کو ہٹانے جا رہے ہیں، تو آپ کو یہ یقینی بنانا چاہیے کہ اس پر کوئی سلاٹ باقی نہیں ہے (بصورت دیگر آپ کو اس نوڈ پر موجود تمام کیز تک رسائی کھونے کا خطرہ ہے)۔ اس کے علاوہ، غلاموں والے مالک کو حذف نہ کریں، ورنہ نئے آقا کے لیے غیر ضروری ووٹ دیا جائے گا۔ اگر نوڈس میں مزید سلاٹ نہیں ہیں، تو یہ ایک چھوٹا مسئلہ ہے، لیکن اگر ہم پہلے غلاموں کو حذف کر سکتے ہیں تو ہمیں اضافی انتخاب کی ضرورت کیوں ہے۔
• اگر آپ کو ماسٹر اور غلام کی پوزیشنز کو زبردستی تبدیل کرنے کی ضرورت ہے، تو کلسٹر فیل اوور کمانڈ کرے گی۔ اسے جنگ میں بلاتے وقت، آپ کو یہ سمجھنا ہوگا کہ آپریشن کے دوران ماسٹر دستیاب نہیں ہوگا۔ عام طور پر سوئچ ایک سیکنڈ سے بھی کم وقت میں ہوتا ہے، لیکن ایٹم نہیں ہوتا۔ آپ توقع کر سکتے ہیں کہ اس دوران ماسٹر سے کچھ درخواستیں ناکام ہو جائیں گی۔
• کلسٹر سے نوڈ کو ہٹانے سے پہلے، اس پر کوئی سلاٹ باقی نہیں رہنا چاہیے۔ cluster reshard کمانڈ کا استعمال کرتے ہوئے انہیں دوبارہ تقسیم کرنا بہتر ہے۔ سلاٹ ایک ماسٹر سے دوسرے ماسٹر میں منتقل کیے جائیں گے۔ پورے آپریشن میں کئی منٹ لگ سکتے ہیں، یہ ڈیٹا کی منتقلی کے حجم پر منحصر ہے، لیکن منتقلی کا عمل محفوظ ہے اور کلسٹر کے آپریشن کو کسی بھی طرح متاثر نہیں کرتا ہے۔ اس طرح، تمام ڈیٹا کو ایک نوڈ سے دوسرے نوڈ میں براہ راست بوجھ کے تحت، اور اس کی دستیابی کی فکر کیے بغیر منتقل کیا جا سکتا ہے۔ تاہم، باریکیاں بھی ہیں. سب سے پہلے، ڈیٹا کی منتقلی وصول کنندہ اور بھیجنے والے نوڈس پر ایک خاص بوجھ سے منسلک ہوتی ہے۔ اگر وصول کنندہ نوڈ پہلے سے ہی پروسیسر پر بہت زیادہ لوڈ ہے، تو آپ کو نیا ڈیٹا حاصل کرنے کے ساتھ اسے لوڈ نہیں کرنا چاہیے۔ دوسری بات یہ کہ جیسے ہی بھیجنے والے آقا پر ایک بھی سلاٹ باقی نہیں رہے گا، اس کے تمام غلام فوراً اس آقا کے پاس چلے جائیں گے جس کو یہ سلاٹ منتقل کیے گئے تھے۔ اور مسئلہ یہ ہے کہ یہ تمام بندے ایک ساتھ ڈیٹا کو سنکرونائز کرنا چاہیں گے۔ اور آپ خوش قسمت ہوں گے اگر یہ مکمل مطابقت پذیری کے بجائے جزوی ہو۔ اس کو مدنظر رکھیں اور سلاٹس کی منتقلی اور غلاموں کو غیر فعال/منتقل کرنے کے عمل کو یکجا کریں۔ یا امید ہے کہ آپ کے پاس حفاظت کا کافی مارجن ہے۔
• آپ کو کیا کرنا چاہیے اگر، منتقلی کے دوران، آپ کو معلوم ہو کہ آپ نے اپنی جگہیں کہیں کھو دی ہیں؟ مجھے امید ہے کہ یہ مسئلہ آپ کو متاثر نہیں کرے گا، لیکن اگر ایسا ہوتا ہے تو، ایک کلسٹر فکس آپریشن ہے۔ کم از کم، وہ بے ترتیب ترتیب میں نوڈس میں سلاٹوں کو بکھیر دے گی۔ میں تجویز کرتا ہوں کہ پہلے کلسٹر سے تقسیم شدہ سلاٹ والے نوڈ کو ہٹا کر اس کے آپریشن کو چیک کریں۔ چونکہ غیر مختص شدہ سلاٹس میں ڈیٹا پہلے سے ہی دستیاب نہیں ہے، اس لیے ان سلاٹس کی دستیابی سے متعلق مسائل کے بارے میں فکر کرنے میں بہت دیر ہو چکی ہے۔ بدلے میں، آپریشن تقسیم شدہ سلاٹس کو متاثر نہیں کرے گا۔
• ایک اور مفید آپریشن مانیٹر ہے۔ یہ آپ کو حقیقی وقت میں نوڈ پر جانے والی درخواستوں کی پوری فہرست دیکھنے کی اجازت دیتا ہے۔ مزید یہ کہ، آپ اسے پکڑ سکتے ہیں اور معلوم کر سکتے ہیں کہ کیا ضروری ٹریفک موجود ہے۔

یہ ماسٹر فیل اوور طریقہ کار کا بھی ذکر کرنے کے قابل ہے۔ مختصر میں، یہ موجود ہے، اور، میری رائے میں، یہ بہت اچھا کام کرتا ہے. تاہم، یہ نہ سوچیں کہ اگر آپ ماسٹر نوڈ والی مشین پر پاور کورڈ کو ان پلگ کرتے ہیں، تو Redis فوری طور پر سوئچ کر دے گا اور کلائنٹس کو نقصان کا نوٹس نہیں ہوگا۔ میری مشق میں، سوئچنگ چند سیکنڈ میں ہوتی ہے۔ اس وقت کے دوران، کچھ ڈیٹا دستیاب نہیں ہوگا: ماسٹر کی عدم دستیابی کا پتہ چلا ہے، نوڈس ایک نئے کو ووٹ دیتے ہیں، غلاموں کو تبدیل کیا جاتا ہے، ڈیٹا کو ہم آہنگ کیا جاتا ہے۔ اپنے لیے یہ یقینی بنانے کا بہترین طریقہ ہے کہ اسکیم کام کر رہی ہے مقامی مشقیں کرنا ہے۔ اپنے لیپ ٹاپ پر کلسٹر بڑھائیں، اسے کم سے کم بوجھ دیں، کریش کی نقل بنائیں (مثال کے طور پر، بندرگاہوں کو بلاک کرکے)، اور سوئچنگ کی رفتار کا اندازہ کریں۔ میری رائے میں، ایک یا دو دن تک اس طرح کھیلنے کے بعد ہی آپ ٹیکنالوجی کے آپریشن میں پراعتماد رہ سکتے ہیں۔ ٹھیک ہے، یا امید ہے کہ وہ سافٹ ویئر جو انٹرنیٹ کا نصف استعمال کرتا ہے شاید کام کرتا ہے۔

تشکیل

اکثر، ٹول کے ساتھ کام شروع کرنے کے لیے آپ کو سب سے پہلے کنفیگریشن کی ضرورت ہوتی ہے۔ اور جب سب کچھ کام کرتا ہے، تو آپ کنفیگریشن کو چھونا بھی نہیں چاہتے۔ اپنے آپ کو ترتیبات پر واپس جانے اور احتیاط سے ان کے ذریعے جانے کے لیے مجبور کرنے میں کچھ محنت درکار ہوتی ہے۔ میری یاد میں، ترتیب میں عدم توجہی کی وجہ سے ہمیں کم از کم دو سنگین ناکامیاں ہوئیں۔ درج ذیل نکات پر خصوصی توجہ دیں:

• ٹائم آؤٹ 0
  وہ وقت جس کے بعد غیر فعال کنکشن بند ہو جاتے ہیں (سیکنڈ میں)۔ 0 - بند نہ کریں۔
  ہماری ہر لائبریری صحیح طریقے سے کنکشن بند کرنے کے قابل نہیں تھی۔ اس ترتیب کو غیر فعال کرنے سے، ہم کلائنٹس کی تعداد کی حد تک پہنچنے کا خطرہ رکھتے ہیں۔ دوسری طرف، اگر ایسا کوئی مسئلہ ہے، تو گمشدہ کنکشن کا خودکار طور پر ختم ہونا اس پر نقاب ڈال دے گا، اور ہو سکتا ہے کہ ہم اس پر توجہ نہ دیں۔ اس کے علاوہ، آپ کو اس سیٹنگ کو فعال نہیں کرنا چاہیے جب پرسسٹ کنکشنز استعمال کریں۔
• xy کو محفوظ کریں اور صرف ہاں ملائیں۔
  RDB سنیپ شاٹ محفوظ کرنا۔
  ہم ذیل میں RDB/AOF کے مسائل پر تفصیل سے بات کریں گے۔
• stop-writes-on-bgsave-error no اور slave-serve-stale-data ہاں
  فعال ہونے پر، اگر RDB سنیپ شاٹ ٹوٹ جاتا ہے، تو ماسٹر تبدیلی کی درخواستوں کو قبول کرنا بند کر دے گا۔ اگر آقا سے رابطہ منقطع ہو جائے تو، غلام درخواستوں کا جواب دینا جاری رکھ سکتا ہے (ہاں)۔ یا جواب دینا بند کر دے گا (نہیں)
  ہم اس صورتحال سے خوش نہیں ہیں جس میں ریڈیس کدو میں بدل جاتا ہے۔
• repl-ping-slave-period 5
  اس مدت کے بعد، ہم فکر کرنے لگیں گے کہ ماسٹر ٹوٹ گیا ہے اور یہ ناکامی کے طریقہ کار کو انجام دینے کا وقت ہے.
  آپ کو دستی طور پر غلط مثبت اور فیل اوور کو متحرک کرنے کے درمیان توازن تلاش کرنا ہوگا۔ ہماری مشق میں یہ 5 سیکنڈ ہے۔
• repl-backlog-size 1024mb اور epl-backlog-ttl 0
  ہم ایک ناکام نقل کے لیے اتنا ڈیٹا بفر میں محفوظ کر سکتے ہیں۔ اگر بفر ختم ہوجاتا ہے، تو آپ کو مکمل طور پر ہم آہنگ کرنا پڑے گا۔
  پریکٹس سے پتہ چلتا ہے کہ زیادہ قیمت مقرر کرنا بہتر ہے۔ بہت ساری وجوہات ہیں جن کی وجہ سے ایک نقل پیچھے ہونا شروع ہو سکتی ہے۔ اگر یہ پیچھے رہ جاتا ہے، تو زیادہ تر امکان ہے کہ آپ کا ماسٹر پہلے ہی اس سے نمٹنے کے لئے جدوجہد کر رہا ہے، اور مکمل ہم آہنگی آخری تنکے ہو گی۔
• maxclients 10000
  ایک بار کے کلائنٹس کی زیادہ سے زیادہ تعداد۔
  ہمارے تجربے میں، یہ ایک اعلی قیمت مقرر کرنے کے لئے بہتر ہے. Redis 10k کنکشن بالکل ٹھیک ہینڈل کرتا ہے۔ بس اس بات کو یقینی بنائیں کہ سسٹم پر کافی ساکٹ موجود ہیں۔
• maxmemory-policy volatile-ttl
  وہ اصول جس کے ذریعے دستیاب میموری کی حد تک پہنچنے پر کلیدوں کو حذف کر دیا جاتا ہے۔
  یہاں جو چیز اہم ہے وہ خود اصول نہیں ہے، بلکہ یہ سمجھنا ہے کہ ایسا کیسے ہوگا۔ جب میموری کی حد تک پہنچ جاتی ہے تو Redis کو عام طور پر کام کرنے کی صلاحیت کے لیے سراہا جا سکتا ہے۔

RDB اور AOF کے مسائل

اگرچہ Redis بذات خود تمام معلومات کو RAM میں محفوظ کرتا ہے، تاہم ڈیٹا کو ڈسک میں محفوظ کرنے کا ایک طریقہ کار بھی موجود ہے۔ مزید واضح طور پر، تین میکانزم:

• RDB-snapshot - تمام ڈیٹا کا مکمل سنیپ شاٹ۔ SAVE XY کنفیگریشن کا استعمال کرتے ہوئے سیٹ کریں اور "اگر کم از کم Y کیز تبدیل ہو گئی ہوں تو ہر X سیکنڈ میں تمام ڈیٹا کا مکمل سنیپ شاٹ محفوظ کریں۔"
• صرف اپینڈ فائل - کارروائیوں کی فہرست جس ترتیب سے وہ انجام پاتے ہیں۔ فائل میں ہر X سیکنڈ یا ہر Y آپریشنز میں نئے آنے والے آپریشنز شامل کرتا ہے۔
• RDB اور AOF پچھلے دو کا مجموعہ ہیں۔

تمام طریقوں کے اپنے فوائد اور نقصانات ہیں، میں ان سب کی فہرست نہیں دوں گا، میں صرف ان نکات کی طرف توجہ مبذول کروں گا جو میری رائے میں واضح نہیں ہیں۔

سب سے پہلے، RDB اسنیپ شاٹ کو محفوظ کرنے کے لیے FORK کو کال کرنا ضروری ہے۔ اگر بہت زیادہ ڈیٹا ہے، تو یہ چند ملی سیکنڈ سے ایک سیکنڈ کے عرصے کے لیے تمام Redis کو لٹکا سکتا ہے۔ اس کے علاوہ، سسٹم کو اس طرح کے اسنیپ شاٹ کے لیے میموری مختص کرنے کی ضرورت ہوتی ہے، جس کی وجہ سے لاجیکل مشین پر ریم کی دوہری سپلائی رکھنے کی ضرورت ہوتی ہے: اگر Redis کے لیے 8 GB مختص کیے گئے ہیں، تو ورچوئل مشین پر 16 GB دستیاب ہونا چاہیے۔ یہ.

دوم، جزوی ہم آہنگی کے ساتھ مسائل ہیں. AOF موڈ میں، جب غلام کو دوبارہ جوڑ دیا جاتا ہے، جزوی ہم وقت سازی کے بجائے، مکمل مطابقت پذیری کی جا سکتی ہے۔ ایسا کیوں ہوتا ہے، میں سمجھ نہیں پایا۔ لیکن یہ یاد رکھنے کے قابل ہے۔

یہ دو نکات ہمیں پہلے ہی یہ سوچنے پر مجبور کرتے ہیں کہ کیا ہمیں واقعی ڈسک پر اس ڈیٹا کی ضرورت ہے اگر سب کچھ پہلے ہی غلاموں کے ذریعہ نقل کیا گیا ہو۔ ڈیٹا صرف اسی صورت میں ضائع ہو سکتا ہے جب تمام بندے ناکام ہو جائیں، اور یہ "فائر ان دی ڈی سی" سطح کا مسئلہ ہے۔ سمجھوتے کے طور پر، آپ صرف غلاموں پر ڈیٹا محفوظ کرنے کی تجویز دے سکتے ہیں، لیکن اس معاملے میں آپ کو یہ یقینی بنانا ہوگا کہ یہ غلام کبھی بھی ڈیزاسٹر ریکوری کے دوران ماسٹر نہیں بنیں گے (اس کے لیے ان کی تشکیل میں غلام کی ترجیح کی ترتیب ہے)۔ اپنے لیے، ہر مخصوص معاملے میں ہم اس بارے میں سوچتے ہیں کہ آیا ڈیٹا کو ڈسک میں محفوظ کرنا ضروری ہے، اور اکثر جواب "نہیں" ہوتا ہے۔

حاصل يہ ہوا

آخر میں، میں امید کرتا ہوں کہ میں ایک عام خیال دینے کے قابل تھا کہ ریڈیز-کلسٹر ان لوگوں کے لیے کس طرح کام کرتا ہے جنہوں نے اس کے بارے میں بالکل بھی نہیں سنا ہے، اور ان لوگوں کے لیے کچھ غیر واضح نکات کی طرف بھی توجہ مبذول کرائی جو اسے استعمال کر رہے ہیں۔ ایک طویل وقت کے لئے.
آپ کے وقت کا شکریہ اور، ہمیشہ کی طرح، موضوع پر تبصرے کا خیرمقدم ہے۔

ماخذ: www.habr.com