Citybill ۾، اسان MySQL ڊيٽابيس کي مستقل ڊيٽا جي مکيه اسٽوريج طور استعمال ڪندا آهيون. اسان وٽ مختلف خدمتن ۽ مقصدن لاءِ ڪيترائي ڊيٽابيس ڪلسٽر آھن.

ماسٽر جي مسلسل دستيابي سڄي سسٽم ۽ ان جي انفرادي حصن جي ڪارڪردگي جو هڪ نازڪ اشارو آهي. ماسٽر ناڪامي جي صورت ۾ خودڪار ڪلستر جي وصولي تمام گھٽ ڪري ٿي واقعي جي جوابي وقت ۽ سسٽم جي گھٽتائي جو وقت. هن آرٽيڪل ۾، مان ڏسندس هڪ اعلي دستيابي (HA) ڊيزائن لاءِ MySQL ڪلستر جي بنياد تي MySQL آرڪيسٽرٽر ۽ مجازي IP پتي (VIP).

HA حل VIP جي بنياد تي

پهرين، مان توهان کي مختصر طور تي ٻڌايان ٿو ته اسان جو ڊيٽا اسٽوريج سسٽم ڇا آهي.

اسان استعمال ڪريون ٿا هڪ کلاسک ريپليڪشن اسڪيم سان گڏ هڪ لکڻ جي قابل رسائي ماسٽر ۽ گهڻن صرف پڙهڻ لاءِ. هڪ ڪلستر هڪ وچولي ماسٽر تي مشتمل ٿي سگهي ٿو - هڪ نوڊ جيڪو ٻئي جي نقل ۽ ٻين لاء ماسٽر آهي. ڪلائنٽ HAProxy ذريعي نقلن تائين رسائي حاصل ڪن ٿا، جيڪا پڻ لوڊ ورهائڻ ۽ آسان اسڪيلنگ جي اجازت ڏئي ٿي. HAProxy جو استعمال تاريخي سببن جي ڪري آهي، ۽ اسان هن وقت ProxySQL ڏانهن لڏڻ جي عمل ۾ آهيون.

نقل جي بنياد تي نيم هم وقت ساز موڊ ۾ انجام ڏنو ويندو آهي GTID. هن جو مطلب اهو آهي ته گهٽ ۾ گهٽ هڪ نقل لازمي طور تي هڪ ٽرانزيڪشن کي لاگ ان ٿيڻ کان پهريان ان کي ڪامياب سمجهيو وڃي. هي نقل وارو طريقو ماسٽر نوڊ جي ناڪامي جي صورت ۾ ڪارڪردگي ۽ ڊيٽا جي حفاظت جي وچ ۾ هڪ بهترين توازن فراهم ڪري ٿو. بنيادي طور تي سڀني تبديلين کي استعمال ڪندي ماسٽر کان نقلن ڏانهن منتقل ڪيو ويو آهي Row Based Replication (RBR)، پر ڪجھ نوڊس ٿي سگھي ٿو mixed binlog format.

آرڪيسٽرٽر وقتي طور تي ڪلسٽر ٽوپولوجي جي حالت کي اپڊيٽ ڪري ٿو، حاصل ڪيل معلومات جو تجزيو ڪري ٿو، ۽ جيڪڏهن مسئلا پيدا ٿين ٿا، اهو هڪ خودڪار بحالي واري طريقيڪار شروع ڪري سگهي ٿو. ڊولپر ان عمل لاءِ پاڻ ذميوار آهي، ڇاڪاڻ ته ان کي مختلف طريقن سان لاڳو ڪري سگهجي ٿو: VIP، DNS جي بنياد تي، سروس دريافت ڪيل خدمتون استعمال ڪندي يا خود لکيل ميڪانيزم.

ماسٽر بحال ڪرڻ جو هڪ آسان طريقو جيڪڏهن اهو ناڪام ٿئي ٿو ته سچل VIP ايڊريس استعمال ڪرڻ آهي.

اڳتي وڌڻ کان اڳ توھان کي ھن حل بابت ڄاڻڻ جي ضرورت آھي:

• VIP هڪ IP پتو آهي جيڪو ڪنهن مخصوص جسماني نيٽ ورڪ انٽرفيس سان لاڳاپيل ناهي. جيڪڏهن ڪو نوڊ ناڪام ٿئي ٿو يا مقرر ڪيل سار سنڀال جي دوران، اسان وي آءِ پي کي مٽائي سگھون ٿا ٻئي وسيلا ۾ گھٽ ۾ گھٽ وقت سان.
• ورچوئل IP پتي جي رليز ۽ جاري ڪرڻ - سستا ۽ تڪڙو آپريشن.
• VIP سان ڪم ڪرڻ لاء، توهان کي SSH ذريعي سرور تائين رسائي جي ضرورت آهي، يا خاص استعمال جي استعمال جي ضرورت آهي، مثال طور، keepalived.

اچو ته اسان جي جادوگر سان ممڪن مسئلن تي نظر رکون ۽ تصور ڪريو ته خودڪار بحالي واري ميڪانيزم کي ڪيئن ڪم ڪرڻ گهرجي.

ماسٽر سان نيٽ ورڪ ڪنيڪشن غائب ٿي ويو آهي، يا هارڊويئر سطح تي ڪو مسئلو پيدا ٿيو آهي، ۽ سرور دستياب ناهي

1. آرڪيسٽرٽر ڪلسٽر ٽوپولوجي کي تازه ڪاري ڪري ٿو، هر نقل رپورٽ ڪري ٿو ته ماسٽر دستياب ناهي. آرڪيسٽرٽر نئين ماسٽر جي ڪردار لاءِ موزون هڪ نقل چونڊڻ جو عمل شروع ڪري ٿو ۽ بحالي شروع ڪري ٿو.
2. اسان ڪوشش ڪري رهيا آهيون VIP کي پراڻي ماسٽر کان هٽائڻ - بغير ڪاميابي.
3. ريپليڪا ماسٽر جي ڪردار کي تبديل ڪري ٿو. ٽوپولوجي کي ٻيهر تعمير ڪيو پيو وڃي.
4. VIP سان نئون نيٽ ورڪ انٽرفيس شامل ڪرڻ. جيئن ته VIP کي هٽائڻ ممڪن نه هو، اسان وقتي طور تي پس منظر ۾ درخواست موڪلڻ شروع ڪندا آهيون مفت ARP. هن قسم جي درخواست/جواب توهان کي IP ۽ MAC ايڊريس ميپنگ ٽيبل کي اپڊيٽ ڪرڻ جي اجازت ڏئي ٿو ڳنڍيل سوئچز تي، انهي سان توهان کي اطلاع ڏي ٿو ته اسان جي VIP منتقل ٿي وئي آهي. اهو امڪان گھٽائي ٿو split brain جڏهن پراڻي ماسٽر واپس.
5. سڀئي نوان ڪنيڪشن فوري طور تي نئين ماسٽر ڏانهن موڪليا ويا آهن. پراڻا ڪنيڪشن ناڪام ٿيندا آهن ۽ ڊيٽابيس کي بار بار ڪالون ايپليڪيشن سطح تي ڪيون وينديون آهن.

سرور عام موڊ ۾ ڪم ڪري رهيو آهي، ڊي بي ايم ايس سطح تي ناڪامي ٿي

الورورٿم پوئين ڪيس سان ملندڙ جلندڙ آهي: ٽوپولوجي کي اپڊيٽ ڪرڻ ۽ بحالي واري عمل کي شروع ڪرڻ. جيئن ته سرور موجود آهي، اسان ڪاميابيءَ سان VIP کي پراڻي ماسٽر تي جاري ڪيو، ان کي نئين ۾ منتقل ڪيو، ۽ ڪيترن ئي ARP درخواستون موڪليون. پراڻي ماسٽر جي ممڪن واپسي کي ٻيهر تعمير ٿيل ڪلستر ۽ ايپليڪيشن جي آپريشن کي متاثر نه ڪرڻ گهرجي.

ٻيا مسئلا

replicas يا وچڙ ماسٽرس جي ناڪامي اڳواڻي نه ڪندو آهي خودڪار عملن لاءِ ۽ دستي مداخلت جي ضرورت آهي.

هڪ مجازي نيٽ ورڪ انٽرفيس هميشه عارضي طور تي شامل ڪيو ويندو آهي، اهو آهي، سرور ريبوٽ کان پوء، VIP خودڪار طور تي مقرر نه ڪيو ويو آهي. هر ڊيٽابيس جو مثال ڊفالٽ طور صرف پڙهڻ واري موڊ ۾ شروع ٿئي ٿو، آرڪيسٽرٽر خودڪار طريقي سان نئين ماسٽر کي لکڻ لاءِ سوئچ ڪري ٿو ۽ انسٽال ڪرڻ جي ڪوشش ڪري ٿو. read only پراڻي ماسٽر تي. انهن عملن جو مقصد امڪان کي گهٽائڻ آهي split brain.

بحالي جي عمل دوران مسئلا پيدا ٿي سگهن ٿا، جن کي معياري نگراني اوزار کان علاوه آرڪيسٽرٽر UI ذريعي پڻ اطلاع ڏنو وڃي. اسان هن خصوصيت کي شامل ڪندي REST API کي وڌايو آهي (PR في الحال جائزو هيٺ).

HA حل جو عام خاڪو هيٺ پيش ڪيو ويو آهي.

نئون ماسٽر چونڊڻ

آرڪيسٽرٽر ڪافي هوشيار آهي ۽ چونڊڻ جي ڪوشش ڪندو آهي سڀ کان وڌيڪ مناسب نقل هيٺ ڏنل معيار مطابق نئين ماسٽر جي طور تي:

• نقل ماسٽر جي پويان رهي ٿو؛
• ماسٽر ۽ نقل جو MySQL نسخو؛
• نقل جو قسم (RBR، SBR يا مخلوط)؛
• ساڳئي يا مختلف ڊيٽا سينٽرن ۾ هنڌ؛
• دستياب errant GTID - ٽرانزيڪشن جيڪي نقل تي عمل ڪيا ويا آهن ۽ ماسٽر تي نه آهن؛
• ڪسٽم چونڊ ضابطن کي پڻ حساب ۾ ورتو وڃي ٿو.

هر ڪُو ماسٽر لاءِ مثالي اميدوار ناهي. مثال طور، هڪ نقل ڊيٽا کي بيڪ اپ ڪرڻ لاء استعمال ڪري سگهجي ٿو، يا سرور کي ڪمزور هارڊويئر ترتيب آهي. آرڪيسٽرو مدد ڪري ٿو دستي ضابطا جنهن سان توهان پنهنجي اميدوار جي چونڊ ترجيحن کي ترتيب ڏئي سگھو ٿا سڀ کان وڌيڪ ترجيح کان نظرانداز ٿيل.

جواب ۽ وصولي وقت

ڪنهن واقعي جي صورت ۾، اهو ضروري آهي ته سسٽم ڊائون ٽائم کي گهٽ ۾ گهٽ، تنهن ڪري اچو ته غور ڪريون MySQL پيرا ميٽرز جيڪي آرڪيسٽرٽر طرفان ڪلسٽر ٽوپولوجي جي تخليق ۽ تازه ڪاري کي متاثر ڪن ٿا:

• slave_net_timeout - سيڪنڊن جو تعداد جنهن دوران ريپليڪا نئين ڊيٽا جي وصولي جي توقع رکي ٿي يا ماسٽر کان HeartBeat-سگنل، ان کان اڳ جو ڪنيڪشن گم ٿيل طور تسليم ڪيو وڃي ۽ وصولي ڪئي وڃي. جيتري قدر ننڍي هوندي، اوتري ئي تيزيءَ سان ريپليڪا اهو طئي ڪرڻ جي قابل ٿي ويندي ته ماسٽر سان لاڳاپو ڀڄي ويو آهي. اسان هن قيمت کي 5 سيڪنڊن جي برابر ڪيو.
• MASTER_CONNECT_RETRY - ٻيهر ڪنيڪشن جي ڪوششن جي وچ ۾ سيڪنڊن جو تعداد. نيٽ ورڪ مسئلن جي صورت ۾، هن پيٽرولر لاء گهٽ قيمت جلدي ٻيهر ڪنيڪشن جي اجازت ڏيندو ۽ ڪلستر جي بحالي واري عمل کي شروع ٿيڻ کان روڪيو. تجويز ڪيل قدر 1 سيڪنڊ آهي.
• MASTER_RETRY_COUNT - ٻيهر ڪنيڪشن جي ڪوششن جو وڌ ۾ وڌ تعداد.
• MASTER_HEARTBEAT_PERIOD - سيڪنڊن ۾ وقفو جنهن کان پوء ماسٽر هڪ دل جي ڌڙڪڻ سگنل موڪلي ٿو. اڌ قيمت تي ڊفالٽ slave_net_timeout.

آرڪيسٽرٽر پيٽرولر:

• DelayMasterPromotionIfSQLThreadNotUpToDate - جيڪڏهن برابر true، پوءِ ماسٽر رول اميدوار ريپليڪا تي لاڳو نه ڪيو ويندو جيستائين ريپليڪا جي SQL ٿريڊ ريلي لاگ مان سڀ غير لاڳو ٿيل ٽرانزيڪشن مڪمل نه ڪري. اسان هي اختيار استعمال ڪندا آهيون ٽرانزيڪشن کي وڃائڻ کان بچڻ لاءِ جڏهن سڀئي اميدوار ريپليڪس پوئتي پوندا آهن.
• InstancePollSeconds - ٽوپولوجي جي تعمير ۽ تازه ڪاري جي تعدد.
• RecoveryPollSeconds - ٽوپولاجي تجزيي جي تعدد. جيڪڏهن ڪو مسئلو معلوم ٿئي ٿو، ٽوپولوجي جي بحالي شروع ڪئي وئي آهي. هي مسلسل1 سيڪنڊ جي برابر.

هر ڪلستر نوڊ هر هڪ ڀيرو آرڪيسٽرٽر طرفان پول ڪيو ويندو آهي InstancePollSeconds سيڪنڊ جڏهن هڪ مسئلو معلوم ٿئي ٿو، ڪلستر رياست کي مجبور ڪيو ويندو آهي اپڊيٽ ڪيو ويو، ۽ پوءِ بحالي کي انجام ڏيڻ لاءِ حتمي فيصلو ڪيو ويو آهي. مختلف ڊيٽابيس ۽ آرڪيسٽرٽر پيٽرولن سان تجربا ڪرڻ سان، اسان 30 سيڪنڊن تائين جواب ۽ بحالي واري وقت کي گھٽائڻ جي قابل هئاسين.

ٽيسٽ اسٽينڊ

اسان مقامي ترقي سان ايڇ اي اسڪيم جي جاچ شروع ڪئي ٽيسٽ بينچ ۽ امتحان ۽ پيداوار جي ماحول ۾ وڌيڪ عمل درآمد. مقامي اسٽينڊ مڪمل طور تي Docker جي بنياد تي خودڪار آهي ۽ توهان کي آرڪيسٽرٽر ۽ نيٽ ورڪ جي ترتيب سان تجربو ڪرڻ جي اجازت ڏئي ٿو، ڪلستر کي 2-3 سرورز کان ڪيترن ئي درجن تائين، ۽ محفوظ ماحول ۾ مشقون منظم ڪرڻ جي اجازت ڏئي ٿو.

مشق دوران، اسان هڪ مسئلي جي ايموليشن طريقن مان هڪ چونڊيندا آهيون: فوري طور تي ماسٽر کي استعمال ڪندي گول ڪيو kill -9، نرمي سان عمل کي ختم ڪريو ۽ سرور کي روڪيو (docker-compose stop)، استعمال ڪندي نيٽ ورڪ مسئلن کي نقل ڪريو iptables -j REJECT يا iptables -j DROP. اسان کي هيٺين نتيجن جي اميد آهي:

• آرڪيسٽرٽر ماسٽر سان مسئلا معلوم ڪندو ۽ 10 سيڪنڊن کان وڌيڪ نه ۾ ٽوپولوجي کي اپڊيٽ ڪندو؛
• وصولي جو طريقو خودڪار طريقي سان شروع ٿيندو: نيٽ ورڪ جي جوڙجڪ تبديل ٿي ويندي، ماسٽر جو ڪردار نقل ڏانهن منتقل ٿيندو، ٽوپولوجي ٻيهر تعمير ڪيو ويندو؛
• نئون ماسٽر قابل تحرير بڻجي ويندو، جيو replicas ٻيهر تعمير جي عمل دوران گم نه ڪيو ويندو؛
• ڊيٽا نئين ماسٽر ڏانهن لکڻ شروع ڪيو ويندو ۽ نقل ڪيو ويندو؛
• مجموعي وصولي جو وقت 30 سيڪنڊن کان وڌيڪ نه هوندو.

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

پهچڻ

مکيه اسٽوريج سسٽم نوڊ جي صحت SRE ۽ آپريشن ٽيم جي مکيه ڪمن مان هڪ آهي. VIP جي بنياد تي آرڪيسٽرٽر ۽ HA حل جو نفاذ اسان کي هيٺين نتيجن حاصل ڪرڻ جي اجازت ڏني:

• ڊيٽابيس ڪلستر جي ٽوپولوجي سان مسئلن جي قابل اعتماد ڳولڻ؛
• ماسٽر سان لاڳاپيل واقعن لاء خودڪار ۽ تيز جواب، سسٽم جي گھٽتائي کي گھٽائڻ.

بهرحال، حل ان جون حدون ۽ نقصان آهن:

• HA اسڪيم کي ڪيترن ئي ڊيٽا سينٽرن تائين اسڪيل ڪرڻ لاءِ انهن جي وچ ۾ هڪ واحد L2 نيٽ ورڪ جي ضرورت پوندي.
• نئين ماسٽر تي VIP تفويض ڪرڻ کان اڳ، اسان کي ان کي پراڻي تي ڇڏڻ جي ضرورت آهي. اهو عمل ترتيب وار آهي، جيڪو وصولي وقت وڌائي ٿو؛
• VIP جاري ڪرڻ لاءِ SSH سرور تائين رسائي جي ضرورت آهي، يا ڪنهن ٻئي طريقي سان ڪال ڪرڻ جي ريموٽ طريقيڪار. جيئن ته سرور يا ڊيٽابيس مشڪلاتن جو تجربو ڪري رهيو آهي جيڪو بحالي جي عمل جو سبب بڻيو، اسان يقين نه ٿا ڪري سگهون ته VIP هٽائڻ ڪاميابي سان مڪمل ٿي ويندي. ۽ اهو ساڳيو مجازي IP پتي ۽ هڪ مسئلو سان ٻن سرورن جي ظاهر ٿيڻ جي ڪري سگھي ٿو split brain.

بچڻ split brain، توهان جو طريقو استعمال ڪري سگهو ٿا اسٽونٿ (“Shoot the other Node in the Head”)، جيڪو مڪمل طور تي مسئلو نوڊ کي الڳ يا غير فعال ڪري ٿو. ڪلستر جي اعلي دستيابي کي لاڳو ڪرڻ جا ٻيا طريقا آهن: VIP ۽ DNS جو هڪ ميلاپ، سروس دريافت ۽ پراکسي خدمتون، هم وقت سازي جي نقل ۽ ٻيا طريقا جن جا پنهنجا نقصان ۽ فائدا آهن.

مون هڪ MySQL ناڪامي ڪلستر ٺاهڻ لاءِ اسان جي طريقي جي باري ۾ ڳالهايو. اهو لاڳو ڪرڻ آسان آهي ۽ موجوده حالتن ۾ قابل قبول سطح فراهم ڪري ٿو. جيئن ته سڄو نظام عام طور تي ۽ انفراسٽرڪچر خاص طور تي ترقي ڪندو، اهو طريقو بلاشبہ ترقي ڪندو.

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