کوئی بھی بڑا پروجیکٹ کچھ سرورز کے ساتھ شروع ہوتا ہے۔ پہلے ایک ڈی بی سرور تھا، پھر پڑھنے کو پیمانے کے لیے اس میں غلاموں کو شامل کیا گیا۔ اور پھر - رکو! مالک ایک ہے، لیکن غلام بہت ہیں۔ اگر غلاموں میں سے ایک چلا جائے تو سب کچھ ٹھیک ہو جائے گا، لیکن اگر آقا چلا جائے تو برا ہو گا: ڈاؤن ٹائم، ایڈمنز سرور کو بڑھانے کی کوشش کر رہے ہیں۔ کیا کرنا ہے؟ ایک ماسٹر محفوظ کریں۔ میرے ساتھی پاول پہلے ہی اس کے بارے میں لکھ چکے ہیں۔ میں اسے نہیں دہراؤں گا۔ اس کے بجائے، میں آپ کو بتاؤں گا کہ آپ کو یقینی طور پر MySQL کے لیے آرکیسٹریٹر کی ضرورت کیوں ہے!
آئیے اہم سوال کے ساتھ شروع کریں: "جب ماسٹر چلا جائے گا تو ہم کوڈ کو نئی مشین میں کیسے تبدیل کریں گے؟"
- مجھے وی آئی پی (ورچوئل آئی پی) والی اسکیم سب سے زیادہ پسند ہے، ہم ذیل میں اس کے بارے میں بات کریں گے۔ یہ سب سے آسان اور سب سے واضح ہے، حالانکہ اس کی ایک واضح حد ہے: جس ماسٹر کو ہم محفوظ کریں گے وہ نئی مشین کے ساتھ L2 سیگمنٹ میں ہونا چاہیے، یعنی ہم دوسرے DC کو بھول سکتے ہیں۔ اور، خوشگوار طریقے سے، اگر آپ اس اصول کی پیروی کرتے ہیں کہ ایک بڑا L2 برا ہے، کیونکہ L2 صرف فی ریک ہے، اور L3 ریک کے درمیان ہے، اور ایسی اسکیم میں اور بھی پابندیاں ہیں۔
- آپ کوڈ میں DNS نام لکھ سکتے ہیں اور اسے /etc/hosts کے ذریعے حل کر سکتے ہیں۔ اصل میں، کوئی حل نہیں ہو گا. اسکیم کا فائدہ: پہلے طریقہ کی کوئی خاصیت نہیں ہے، یعنی کراس ڈی سی کو منظم کرنا ممکن ہے۔ لیکن پھر واضح سوال پیدا ہوتا ہے: ہم کتنی جلدی تبدیلی کو /etc/hosts کو Puppet-Ansible کے ذریعے پہنچا سکتے ہیں؟
- آپ دوسرے طریقہ کو تھوڑا سا تبدیل کر سکتے ہیں: تمام ویب سرورز پر کیشنگ DNS انسٹال کریں، جس کے ذریعے کوڈ ماسٹر ڈیٹا بیس میں جائے گا۔ آپ DNS میں اس اندراج کے لیے TTL 60 سیٹ کر سکتے ہیں۔ ایسا لگتا ہے کہ اگر صحیح طریقے سے لاگو کیا جائے تو، طریقہ اچھا ہے.
- سروس کی دریافت کے ساتھ ایک اسکیم، جس میں قونصل اور وغیرہ کے استعمال کا مطلب ہے۔
- کے ساتھ ایک دلچسپ آپشن . آپ کو تمام ٹریفک کو ProxySQL کے ذریعے MySQL کی طرف روٹ کرنے کی ضرورت ہے؛ ProxySQL خود اس بات کا تعین کر سکتا ہے کہ کون ماسٹر ہے۔ ویسے، آپ اس پروڈکٹ کو استعمال کرنے کے آپشنز میں سے ایک کے بارے میں پڑھ سکتے ہیں۔ .
آرکیسٹریٹر کے مصنف، گیتھب میں کام کرتے ہیں، نے پہلے وی آئی پی کے ساتھ پہلی اسکیم نافذ کی، اور پھر اسے قونصل کے ساتھ اسکیم میں تبدیل کردیا۔
عام بنیادی ڈھانچے کی ترتیب:
میں فوری طور پر ان واضح حالات کو بیان کروں گا جن پر غور کرنے کی ضرورت ہے:
- VIP ایڈریس کو کسی بھی سرور کی تشکیل میں رجسٹر نہیں کیا جانا چاہئے۔ آئیے ایک صورت حال کا تصور کریں: ماسٹر نے دوبارہ شروع کیا، اور جب یہ لوڈ ہو رہا تھا، آرکیسٹریٹر فیل اوور موڈ میں چلا گیا اور غلاموں میں سے ایک کو ماسٹر بنا دیا۔ پھر پرانا ماسٹر گلاب ہوا، اور اب VIP دو کاروں پر ہے۔ یہ برا ہے.
- آرکیسٹریٹر کے لیے، آپ کو پرانے ماسٹر اور نئے ماسٹر کو کال کرنے کے لیے اسکرپٹ لکھنے کی ضرورت ہوگی۔ پرانے ماسٹر پر آپ کو ifdown چلانے کی ضرورت ہے، اور نئے ماسٹر پر - ifup vip۔ اس اسکرپٹ میں یہ بھی شامل کرنا اچھا ہو گا کہ فیل اوور ہونے کی صورت میں، پرانے ماسٹر کے سوئچ پر موجود پورٹ کو کسی بھی تقسیم سے بچنے کے لیے بند کر دیا جاتا ہے۔
- آرکیسٹریٹر کی جانب سے پہلے VIP کو ہٹانے اور/یا سوئچ پر موجود پورٹ کو بجھانے کے لیے آپ کے اسکرپٹ کو کال کرنے کے بعد، اور پھر نئے ماسٹر پر VIP ریزنگ اسکرپٹ کو کال کرنے کے بعد، ہر کسی کو یہ بتانے کے لیے آرپنگ کمانڈ کا استعمال کرنا نہ بھولیں کہ نیا VIP اب ہے۔ یہاں
- تمام غلاموں کے پاس read_only=1 ہونا چاہیے، اور جیسے ہی آپ غلام کو آقا کے لیے پروموٹ کرتے ہیں، اس کا read_only=0 ہونا چاہیے۔
- یہ نہ بھولیں کہ جس غلام کو ہم نے اس کے لیے چنا ہے وہ مالک بن سکتا ہے (آرکیسٹریٹر کے پاس ایک مکمل ترجیحی طریقہ کار ہے جس کے لیے کس غلام کو نئے آقا کے لیے پہلے امیدوار کے طور پر غور کرنا چاہیے، کس کو دوسرے نمبر پر، اور کون سا غلام۔ کسی بھی حالت میں کسی بھی صورت میں منتخب نہ کیا جائے ماسٹر)۔ اگر غلام آقا بن جائے تو غلام کا بوجھ اس پر رہے گا اور آقا کا بوجھ بڑھ جائے گا، اس بات کو مدنظر رکھنا چاہیے۔
اگر آپ کے پاس نہیں ہے تو آپ کو آرکیسٹریٹر کی ضرورت کیوں ہے؟
- آرکیسٹریٹر کے پاس بہت صارف دوست گرافیکل انٹرفیس ہے جو پوری ٹوپولوجی کو دکھاتا ہے (نیچے اسکرین شاٹ دیکھیں)۔
- آرکیسٹریٹر ٹریک کر سکتا ہے کہ کون سے غلام پیچھے رہ گئے ہیں، اور کہاں نقل عام طور پر ٹوٹ گئی ہے (ہمارے پاس ایس ایم ایس بھیجنے کے لیے آرکیسٹریٹر کے ساتھ اسکرپٹ منسلک ہیں)۔
- آرکیسٹریٹر آپ کو بتاتا ہے کہ کن غلاموں میں GTID غلطی ہے۔
آرکیسٹریٹر انٹرفیس:
GTID غلطی کیا ہے؟
آرکیسٹریٹر کے کام کرنے کے لیے دو اہم تقاضے ہیں:
- یہ ضروری ہے کہ MySQL کلسٹر میں تمام مشینوں پر pseudo GTID فعال ہو؛ ہمارے پاس GTID فعال ہے۔
- یہ ضروری ہے کہ ہر جگہ ایک قسم کے binlogs ہوں، آپ اسٹیٹمنٹ استعمال کر سکتے ہیں۔ ہمارے پاس ایک ترتیب تھی جس میں آقا اور زیادہ تر غلاموں کے پاس Row تھا، اور دو تاریخی طور پر مخلوط موڈ میں رہے۔ نتیجے کے طور پر، آرکیسٹریٹر صرف ان غلاموں کو نئے آقا سے جوڑنا نہیں چاہتا تھا۔
یاد رکھیں کہ پیداواری غلام میں سب سے اہم چیز اس کی آقا کے ساتھ مستقل مزاجی ہے! اگر آپ نے اپنے آقا اور غلام دونوں پر گلوبل ٹرانزیکشن آئی ڈی (GTID) کو فعال کیا ہے، تو آپ gtid_subset فنکشن استعمال کر کے یہ معلوم کر سکتے ہیں کہ آیا ڈیٹا کی تبدیلیوں کے لیے وہی درخواستیں واقعی ان مشینوں پر عمل میں آئی ہیں۔ آپ اس بارے میں مزید پڑھ سکتے ہیں۔ .
اس طرح، آرکیسٹریٹر آپ کو GTID غلطی کے ذریعے دکھاتا ہے کہ غلام پر ایسے لین دین ہیں جو مالک پر نہیں ہیں۔ ایسا کیوں ہو رہا ہے؟
- Read_only=1 غلام پر فعال نہیں ہے، کسی نے منسلک کیا اور ڈیٹا کو تبدیل کرنے کی درخواست مکمل کی۔
- Super_read_only=1 غلام پر فعال نہیں ہے، پھر منتظم، سرور کو الجھا کر اندر گیا اور وہاں درخواست پر عمل درآمد کیا۔
- اگر آپ پچھلے دونوں نکات کو مدنظر رکھتے ہیں، تو پھر ایک اور چال ہے: MySQL میں، بِن لاگز کو فلش کرنے کی درخواست بھی بن لاگ کو جاتی ہے، اس لیے پہلے فلش پر، ایک GTID غلطی آقا اور تمام غلاموں پر ظاہر ہوگی۔ اس سے کیسے بچا جائے؟ Perona-5.7.25-28 نے binlog_skip_flush_commands=1 سیٹنگ متعارف کرائی، جو binlogs پر فلش لکھنے سے منع کرتی ہے۔ mysql.com ویب سائٹ پر ایک قائم ہے۔ .
مجھے مندرجہ بالا سب کا خلاصہ کرنے دو۔ اگر آپ ابھی تک فیل اوور موڈ میں آرکیسٹریٹر کا استعمال نہیں کرنا چاہتے ہیں، تو اسے مشاہدے کے موڈ میں رکھیں۔ تب آپ کی آنکھوں کے سامنے ہمیشہ MySQL مشینوں کے تعامل کا نقشہ اور بصری معلومات موجود ہوں گی کہ ہر مشین پر کس قسم کی نقل ہے، کیا غلام پیچھے رہ رہے ہیں، اور سب سے اہم بات یہ ہے کہ وہ مالک کے ساتھ کتنے مطابقت رکھتے ہیں!
واضح سوال یہ ہے کہ: "آرکیسٹریٹر کو کیسے کام کرنا چاہیے؟" اسے موجودہ غلاموں میں سے ایک نئے آقا کا انتخاب کرنا ہوگا، اور پھر تمام غلاموں کو اس سے دوبارہ جوڑنا ہوگا (اس کے لیے GTID کی ضرورت ہے۔ یہ صرف ناممکن ہے!) ہمارے پاس آرکیسٹریٹر ہونے سے پہلے، مجھے ایک بار یہ سب کچھ دستی طور پر کرنا پڑا۔ بوڑھا آقا ایک چھوٹی چھوٹی Adaptec کنٹرولر کی وجہ سے لٹکا ہوا تھا، اس میں تقریباً 10 بندے تھے۔ مجھے آقا سے غلاموں میں سے ایک کو VIP منتقل کرنے اور باقی تمام غلاموں کو اس سے دوبارہ جوڑنے کی ضرورت تھی۔ مجھے کتنے کنسولز کھولنے پڑے، میں نے بیک وقت کتنی کمانڈز داخل کیں... مجھے صبح 3 بجے تک انتظار کرنا پڑا، دو کے علاوہ تمام بندوں سے بوجھ ہٹانا پڑا، دو ماسٹروں میں سے پہلی مشین بنائیں، دوسری مشین کو فوراً جوڑ دیں۔ اس کے ساتھ، لہذا دوسرے تمام غلاموں کو نئے آقا سے جوڑیں اور بوجھ واپس کریں۔ مجموعی طور پر، خوفناک ...
جب آرکیسٹریٹر فیل اوور موڈ میں جاتا ہے تو کیسے کام کرتا ہے؟ یہ ایک ایسی صورت حال کی مثال سے سب سے زیادہ آسانی سے واضح ہوتا ہے جہاں ہم ایک ماسٹر کو اب کے مقابلے میں زیادہ طاقتور، زیادہ جدید مشین بنانا چاہتے ہیں۔
اعداد و شمار عمل کے وسط کو ظاہر کرتا ہے۔ اس وقت تک کیا کیا جا چکا ہے؟ ہم نے کہا کہ ہم کسی غلام کو نیا مالک بنانا چاہتے ہیں، آرکیسٹریٹر نے دوسرے تمام غلاموں کو آسانی سے اس سے جوڑنا شروع کیا، نئے آقا نے ٹرانزٹ مشین کے طور پر کام کیا۔ اس اسکیم کے ساتھ، کوئی غلطی نہیں ہوتی، تمام غلام کام کرتے ہیں، آرکیسٹریٹر VIP کو پرانے ماسٹر سے ہٹاتا ہے، اسے نئے میں منتقل کرتا ہے، Read_only=0 بناتا ہے اور پرانے ماسٹر کو بھول جاتا ہے۔ سب! ہماری سروس کا ڈاؤن ٹائم VIP ٹرانسفر کا وقت ہے، جو کہ 2-3 سیکنڈ ہے۔
آج کے لیے بس اتنا ہے، آپ سب کا شکریہ۔ آرکیسٹریٹر کے بارے میں جلد ہی دوسرا مضمون ہوگا۔ مشہور سوویت فلم "گیراج" میں ایک کردار نے کہا، "میں اس کے ساتھ جاسوسی نہیں کروں گا!" تو، آرکیسٹریٹر، میں آپ کے ساتھ جاسوسی پر جاؤں گا!
ماخذ: www.habr.com