آرکیسٹریٹر اور VIP ایک MySQL کلسٹر کے لیے HA حل کے طور پر

سٹی موبل میں ہم ایک MySQL ڈیٹا بیس کو اپنے اہم مستقل ڈیٹا اسٹوریج کے طور پر استعمال کرتے ہیں۔ ہمارے پاس مختلف خدمات اور مقاصد کے لیے کئی ڈیٹا بیس کلسٹر ہیں۔

ماسٹر کی مستقل دستیابی پورے نظام اور اس کے انفرادی حصوں کی کارکردگی کا ایک اہم اشارہ ہے۔ ماسٹر فیل ہونے کی صورت میں خودکار کلسٹر ریکوری واقعے کے ردعمل کے وقت اور سسٹم کے ڈاؤن ٹائم کو بہت کم کر دیتی ہے۔ اس مضمون میں، میں ایک MySQL کلسٹر کے لیے ایک اعلی دستیابی (HA) ڈیزائن کو دیکھوں گا MySQL آرکیسٹریٹر اور ورچوئل IP ایڈریس (VIP)۔

آرکیسٹریٹر اور VIP ایک MySQL کلسٹر کے لیے HA حل کے طور پر

VIP پر مبنی HA حل

سب سے پہلے، میں آپ کو مختصراً بتاؤں گا کہ ہمارا ڈیٹا اسٹوریج سسٹم کیا ہے۔

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

کی بنیاد پر نیم ہم وقت ساز موڈ میں نقل کی جاتی ہے۔ GTID. اس کا مطلب یہ ہے کہ کم از کم ایک نقل کو کامیاب سمجھے جانے سے پہلے ایک لین دین کو لاگ کرنا ضروری ہے۔ یہ نقل کاری موڈ ماسٹر نوڈ کی ناکامی کی صورت میں کارکردگی اور ڈیٹا کی حفاظت کے درمیان ایک بہترین توازن فراہم کرتا ہے۔ بنیادی طور پر تمام تبدیلیاں ماسٹر سے نقل کا استعمال کرتے ہوئے منتقل کی جاتی ہیں۔ Row Based Replication (RBR)، لیکن کچھ نوڈس ہو سکتے ہیں۔ mixed binlog format.

آرکیسٹریٹر وقتاً فوقتاً کلسٹر ٹوپولوجی کی حالت کو اپ ڈیٹ کرتا ہے، موصول ہونے والی معلومات کا تجزیہ کرتا ہے، اور اگر مسائل پیدا ہوتے ہیں، تو یہ خودکار بحالی کا طریقہ کار شروع کر سکتا ہے۔ ڈویلپر خود اس طریقہ کار کے لیے ذمہ دار ہے، کیونکہ اسے مختلف طریقوں سے لاگو کیا جا سکتا ہے: VIP، DNS کی بنیاد پر، سروس کی دریافت کی خدمات یا خود تحریری میکانزم کا استعمال کرتے ہوئے۔

اگر ماسٹر ناکام ہوجاتا ہے تو اسے بحال کرنے کا ایک آسان طریقہ تیرتے VIP ایڈریسز کا استعمال کرنا ہے۔

آگے بڑھنے سے پہلے آپ کو اس حل کے بارے میں کیا جاننے کی ضرورت ہے:

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

آئیے اپنے وزرڈ کے ساتھ ممکنہ مسائل کو دیکھیں اور تصور کریں کہ خودکار بحالی کا طریقہ کار کیسے کام کرے۔

ماسٹر سے نیٹ ورک کنیکٹیویٹی غائب ہو گئی ہے، یا ہارڈ ویئر کی سطح پر کوئی مسئلہ پیدا ہو گیا ہے، اور سرور دستیاب نہیں ہے۔

  1. آرکیسٹریٹر کلسٹر ٹوپولوجی کو اپ ڈیٹ کرتا ہے، ہر ایک نقل رپورٹ کرتا ہے کہ ماسٹر دستیاب نہیں ہے۔ آرکیسٹریٹر نئے ماسٹر کے کردار کے لیے موزوں نقل کے انتخاب کا عمل شروع کرتا ہے اور بحالی شروع کرتا ہے۔
  2. ہم وی آئی پی کو پرانے ماسٹر سے ہٹانے کی کوشش کر رہے ہیں - کامیابی کے بغیر۔
  3. نقل ماسٹر کے کردار میں بدل جاتی ہے۔ ٹوپولوجی کو دوبارہ بنایا جا رہا ہے۔
  4. VIP کے ساتھ ایک نیا نیٹ ورک انٹرفیس شامل کرنا۔ چونکہ VIP کو ہٹانا ممکن نہیں تھا، اس لیے ہم وقتاً فوقتاً پس منظر میں درخواست بھیجنا شروع کر دیتے ہیں۔ مفت ARP. اس قسم کی درخواست/جواب آپ کو منسلک سوئچز پر IP اور MAC ایڈریس میپنگ ٹیبل کو اپ ڈیٹ کرنے کی اجازت دیتا ہے، اس طرح آپ کو مطلع کیا جاتا ہے کہ ہمارا VIP منتقل ہو گیا ہے۔ یہ امکان کو کم کرتا ہے۔ split brain پرانے ماسٹر کو واپس کرتے وقت.
  5. تمام نئے کنکشن فوری طور پر نئے ماسٹر کو بھیجے جاتے ہیں۔ پرانے کنکشن فیل ہو جاتے ہیں اور ڈیٹا بیس پر بار بار کالیں ایپلیکیشن لیول پر کی جاتی ہیں۔

سرور نارمل موڈ میں کام کر رہا ہے، DBMS سطح پر ایک ناکامی واقع ہو گئی۔

الگورتھم پچھلے کیس کی طرح ہے: ٹوپولوجی کو اپ ڈیٹ کرنا اور بحالی کا عمل شروع کرنا۔ چونکہ سرور دستیاب ہے، ہم کامیابی کے ساتھ پرانے ماسٹر پر VIP جاری کرتے ہیں، اسے نئے میں منتقل کرتے ہیں، اور کئی ARP درخواستیں بھیجتے ہیں۔ پرانے ماسٹر کی ممکنہ واپسی سے دوبارہ تعمیر شدہ کلسٹر اور درخواست کے آپریشن کو متاثر نہیں کرنا چاہیے۔

دیگر مسائل

نقل یا انٹرمیڈیٹ ماسٹرز کی ناکامی۔ قیادت نہیں کرتا خودکار کارروائیوں کے لیے اور دستی مداخلت کی ضرورت ہے۔

ایک ورچوئل نیٹ ورک انٹرفیس ہمیشہ عارضی طور پر شامل کیا جاتا ہے، یعنی سرور ریبوٹ کے بعد، VIP خود بخود تفویض نہیں ہوتا ہے۔ ہر ڈیٹا بیس کی مثال بطور ڈیفالٹ صرف پڑھنے کے موڈ میں شروع ہوتی ہے، آرکیسٹریٹر خود بخود نئے ماسٹر کو لکھنے کے لیے سوئچ کرتا ہے اور انسٹال کرنے کی کوشش کرتا ہے۔ read only پرانے ماسٹر پر. ان اقدامات کا مقصد امکان کو کم کرنا ہے۔ split brain.

بحالی کے عمل کے دوران مسائل پیدا ہو سکتے ہیں، جس کی اطلاع معیاری نگرانی کے آلات کے علاوہ آرکیسٹریٹر UI کے ذریعے بھی دی جانی چاہیے۔ ہم نے اس خصوصیت کو شامل کرکے REST API کو بڑھا دیا ہے (PR فی الحال زیر جائزہ)۔

HA حل کا عمومی خاکہ ذیل میں پیش کیا گیا ہے۔

آرکیسٹریٹر اور VIP ایک MySQL کلسٹر کے لیے HA حل کے طور پر

ایک نئے ماسٹر کا انتخاب

آرکیسٹریٹر کافی ہوشیار ہے اور انتخاب کرنے کی کوشش کرتا ہے۔ سب سے مناسب نقل مندرجہ ذیل معیار کے مطابق ایک نئے ماسٹر کے طور پر:

  • نقل ماسٹر کے پیچھے رہ جاتی ہے۔
  • ماسٹر اور نقل کا MySQL ورژن؛
  • نقل کی قسم (RBR، SBR یا مخلوط)؛
  • ایک ہی یا مختلف ڈیٹا سینٹرز میں مقام؛
  • دستیابی errant GTID - وہ لین دین جو نقل پر عمل میں آئے تھے اور ماسٹر پر نہیں ہیں۔
  • اپنی مرضی کے انتخاب کے قواعد کو بھی مدنظر رکھا جاتا ہے۔

ہر اشارہ ماسٹر کے لیے مثالی امیدوار نہیں ہے۔ مثال کے طور پر، ایک نقل ڈیٹا کو بیک اپ کرنے کے لیے استعمال کی جا سکتی ہے، یا سرور کی ہارڈ ویئر کی ترتیب کمزور ہے۔ آرکیسٹریٹر کی حمایت کرتا ہے دستی قواعد جن کی مدد سے آپ اپنی امیدوار کے انتخاب کی ترجیحات کو سب سے زیادہ ترجیحی سے نظر انداز کر سکتے ہیں۔

جواب اور بحالی کا وقت

کسی واقعے کی صورت میں، سسٹم کے ڈاؤن ٹائم کو کم سے کم کرنا ضروری ہے، لہذا آئیے MySQL پیرامیٹرز پر غور کریں جو آرکیسٹریٹر کے ذریعے کلسٹر ٹوپولوجی کی تخلیق اور اپ ڈیٹ کو متاثر کرتے ہیں:

  • slave_net_timeout - سیکنڈوں کی تعداد جس کے دوران نقل نئے ڈیٹا یا ہارٹ بیٹ سگنل کے ماسٹر کی طرف سے آنے کا انتظار کرتی ہے اس سے پہلے کہ کنکشن کو کھوئے ہوئے اور دوبارہ منسلک ہونے کی پہچان ہو۔ قدر جتنی کم ہوگی، نقل اتنی ہی تیزی سے اس بات کا تعین کر سکتی ہے کہ ماسٹر کے ساتھ بات چیت ٹوٹ گئی ہے۔ ہم اس قدر کو 5 سیکنڈ پر سیٹ کرتے ہیں۔
  • MASTER_CONNECT_RETRY - دوبارہ کنکشن کی کوششوں کے درمیان سیکنڈوں کی تعداد۔ نیٹ ورک کے مسائل کی صورت میں، اس پیرامیٹر کی کم قیمت فوری دوبارہ کنکشن کی اجازت دے گی اور کلسٹر ریکوری کے عمل کو شروع ہونے سے روکے گی۔ تجویز کردہ قدر 1 سیکنڈ ہے۔
  • MASTER_RETRY_COUNT - دوبارہ کنکشن کی کوششوں کی زیادہ سے زیادہ تعداد۔
  • MASTER_HEARTBEAT_PERIOD - سیکنڈوں میں وقفہ جس کے بعد ماسٹر دل کی دھڑکن کا سگنل بھیجتا ہے۔ ڈیفالٹس آدھی قدر پر slave_net_timeout.

آرکیسٹریٹر کے اختیارات:

  • DelayMasterPromotionIfSQLThreadNotUpToDate - اگر برابر true، پھر امیدوار کی نقل پر ماسٹر رول اس وقت تک لاگو نہیں کیا جائے گا جب تک کہ ریپلیکا کے ایس کیو ایل تھریڈ نے ریلے لاگ سے تمام غیر لاگو ٹرانزیکشنز کو مکمل نہیں کر لیا ہے۔ جب تمام امیدواروں کی نقلیں پیچھے ہو جاتی ہیں تو ہم لین دین کو کھونے سے بچنے کے لیے اس اختیار کا استعمال کرتے ہیں۔
  • InstancePollSeconds ٹوپولوجی کی تعمیر اور اپ ڈیٹ کرنے کی فریکوئنسی۔
  • RecoveryPollSeconds ٹوپولوجی تجزیہ کی فریکوئنسی۔ اگر کسی مسئلے کا پتہ چل جاتا ہے تو، ٹوپولوجی کی بحالی شروع کی جاتی ہے۔ یہ مستقل1 سیکنڈ کے برابر۔

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

ٹیسٹ سٹینڈ

ہم نے ایک مقامی کی ترقی کے ساتھ HA اسکیم کی جانچ شروع کی۔ ٹیسٹ بینچ اور ٹیسٹ اور پیداوار کے ماحول میں مزید عمل درآمد۔ مقامی اسٹینڈ مکمل طور پر ڈوکر کی بنیاد پر خودکار ہے اور آپ کو آرکیسٹریٹر اور نیٹ ورک کی ترتیب کے ساتھ تجربہ کرنے، کلسٹر کو 2-3 سرورز سے کئی درجن تک پیمانہ کرنے، اور محفوظ ماحول میں مشقیں کرنے کی اجازت دیتا ہے۔

مشقوں کے دوران، ہم مسئلہ ایمولیشن طریقوں میں سے ایک کا انتخاب کرتے ہیں: فوری طور پر ماسٹر کو استعمال کرتے ہوئے گولی مار دیں۔ kill -9، آہستہ سے عمل کو ختم کریں اور سرور کو روکیں (docker-compose stop) کا استعمال کرتے ہوئے نیٹ ورک کے مسائل کی نقل کریں۔ iptables -j REJECT یا iptables -j DROP. ہم مندرجہ ذیل نتائج کی توقع کرتے ہیں:

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

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

نتائج

مین اسٹوریج سسٹم نوڈ کی صحت SRE اور آپریشنز ٹیم کے اہم کاموں میں سے ایک ہے۔ VIP پر مبنی آرکیسٹریٹر اور HA حل کے نفاذ نے ہمیں درج ذیل نتائج حاصل کرنے کی اجازت دی:

  • ڈیٹا بیس کلسٹر کی ٹوپولوجی کے ساتھ مسائل کا قابل اعتماد پتہ لگانا؛
  • ماسٹر سے متعلقہ واقعات کے لیے خودکار اور تیز ردعمل، سسٹم کے ڈاؤن ٹائم کو کم کرتا ہے۔

تاہم، حل کی اپنی حدود اور نقصانات ہیں:

  • HA اسکیم کو کئی ڈیٹا سینٹرز تک پھیلانے کے لیے ان کے درمیان ایک L2 نیٹ ورک کی ضرورت ہوگی۔
  • نئے ماسٹر پر VIP تفویض کرنے سے پہلے، ہمیں اسے پرانے پر جاری کرنے کی ضرورت ہے۔ یہ عمل ترتیب وار ہے، جس سے بحالی کا وقت بڑھ جاتا ہے۔
  • VIP کو جاری کرنے کے لیے SSH سرور تک رسائی، یا ریموٹ طریقہ کار کو کال کرنے کا کوئی دوسرا طریقہ درکار ہے۔ چونکہ سرور یا ڈیٹا بیس کو مسائل کا سامنا ہے جس کی وجہ سے بازیابی کا عمل شروع ہوا، ہم اس بات کا یقین نہیں کر سکتے کہ VIP کو ہٹانا کامیابی سے مکمل ہو جائے گا۔ اور یہ ایک ہی ورچوئل IP ایڈریس اور ایک مسئلہ کے ساتھ دو سرورز کی ظاہری شکل کا باعث بن سکتا ہے۔ split brain.

بچنے کے لیے split brain، آپ طریقہ استعمال کر سکتے ہیں۔ اسٹونتھ ("سر میں دوسرے نوڈ کو گولی مارو")، جو مسئلہ نوڈ کو مکمل طور پر الگ یا غیر فعال کر دیتا ہے۔ کلسٹر اعلی دستیابی کو لاگو کرنے کے دوسرے طریقے ہیں: VIP اور DNS کا مجموعہ، سروس کی دریافت اور پراکسی خدمات، ہم وقت ساز نقل اور دوسرے طریقے جن کے اپنے نقصانات اور فوائد ہیں۔

میں نے MySQL فیل اوور کلسٹر بنانے کے لیے اپنے نقطہ نظر کے بارے میں بات کی۔ اس کو نافذ کرنا آسان ہے اور موجودہ حالات میں قابلِ قبول اعتبار کی سطح فراہم کرتا ہے۔ جیسا کہ عام طور پر پورا نظام اور خاص طور پر بنیادی ڈھانچہ ترقی کرتا ہے، یہ نقطہ نظر بلاشبہ ترقی کرے گا۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں