تعارف
ڪجهه عرصو اڳ مون کي هڪ فيل اوور ڪلسٽر ٺاهڻ جو ڪم ڏنو ويو هو ، هڪ شهر اندر آپٽيڪل فائبر سان ڳنڍيل ڪيترن ئي ڊيٽا سينٽرن ۾ ڪم ڪري رهيا آهن، ۽ هڪ ڊيٽا سينٽر جي ناڪامي (مثال طور، بليڪ آئوٽ) کي برداشت ڪرڻ جي قابل آهن. جيئن ته سافٽ ويئر جيڪو غلطي رواداري لاء ذميوار آهي، مون چونڊيو آهي ڇاڪاڻ ته هي آهي سرڪاري حل RedHat کان ناڪامي ڪلستر ٺاهڻ لاءِ. اهو سٺو آهي ڇو ته RedHat ان لاءِ مدد فراهم ڪري ٿي، ۽ ڇاڪاڻ ته هي حل آفاقي آهي (ماڊلر). ان جي مدد سان، اهو ممڪن ٿيندو ته غلطي رواداري کي يقيني بڻائڻ نه رڳو PostgreSQL، پر ٻين خدمتن جي، يا ته معياري ماڊل استعمال ڪندي يا انهن کي مخصوص ضرورتن لاءِ ٺاهي.
اهو فيصلو هڪ معقول سوال اٿاريو: هڪ ناڪامي ڪلستر ڪيئن غلطي برداشت ڪندو؟ ھن جي تحقيق ڪرڻ لاءِ، مون ھڪڙي ٽيسٽ بينچ ٺاھيو آھي جيڪو ڪلستر نوڊس تي مختلف ناڪامين کي سمائي ٿو، سروس بحال ٿيڻ جو انتظار ڪري ٿو، ناڪام ٿيل نوڊ کي بحال ڪري ٿو، ۽ لوپ ۾ جاچ جاري رکي ٿو. هن پروجيڪٽ کي اصل ۾ hapgsql سڏيو ويندو هو، پر وقت سان گڏ مون کي ان نالي سان بور ڪيو ويو، جنهن ۾ صرف هڪ واول هو. تنهن ڪري، مون غلطي برداشت ڪندڙ ڊيٽابيس کي سڏڻ شروع ڪيو (۽ فلوٽ IP انهن ڏانهن اشارو ڪندي) ڪروگن (ڪمپيوٽر گيم مان هڪ ڪردار جنهن ۾ سڀ اهم عضوا نقل ٿيل آهن) ۽ نوڊس، ڪلسٽر ۽ پروجيڪٽ پاڻ ئي آهن ٽوچنڪا (هي ڌرتي جتي ڪروگن رهن ٿا).
هاڻي انتظاميا اجازت ڏني آهي . README جلد ئي انگريزيءَ ۾ ترجمو ڪيو ويندو (ڇاڪاڻ ته اميد آهي ته مکيه صارف Pacemaker ۽ PostgreSQL ڊولپر هوندا)، ۽ مون فيصلو ڪيو ته README جو پراڻو روسي ورزن (جزوي طور) هن آرٽيڪل جي صورت ۾ پيش ڪرڻ جو.
ڪلستر ورچوئل مشينن تي لڳايا ويا آهن . مجموعي طور تي 12 ورچوئل مشينون (مجموعي طور تي 36GiB) مقرر ڪيون وينديون، جيڪي 4 غلطي برداشت ڪندڙ ڪلسٽرز (مختلف اختيارن) ٺاهينديون. پهريان ٻه ڪلسٽر ٻن PostgreSQL سرورن تي مشتمل آهن، جيڪي مختلف ڊيٽا سينٽرن ۾ واقع آهن، ۽ هڪ عام سرور شاھد c ڪورم ڊوائيس (هڪ ٽين ڊيٽا سينٽر ۾ هڪ سستو ورچوئل مشين تي ميزباني)، جيڪو غير يقيني صورتحال کي حل ڪري ٿو 50٪ / 50٪، پنهنجو ووٽ ڪنهن هڪ پارٽي کي ڏيو. ٽيون ڪلستر ٽن ڊيٽا سينٽرن ۾: هڪ ماسٽر، ٻه غلام، نه ڪورم ڊوائيس. چوٿون ڪلستر چار PostgreSQL سرورن تي مشتمل آهي، ٻه في ڊيٽا سينٽر: هڪ ماسٽر، باقي replicas، ۽ پڻ استعمال شاھد c ڪورم ڊوائيس. چوٿين ٻن سرورن يا هڪ ڊيٽا سينٽر جي ناڪامي کي برداشت ڪري سگهي ٿي. جيڪڏهن ضروري هجي ته اهو حل وڏي تعداد ۾ نقل ڪري سگهجي ٿو.
صحيح وقت جي خدمت غلطي رواداري لاء پڻ ٻيهر ترتيب ڏني وئي، پر اهو طريقو پاڻ کي استعمال ڪري ٿو ntpd (يتيم موڊ). گڏيل سرور شاھد مرڪزي NTP سرور جي طور تي ڪم ڪري ٿو، ان جو وقت سڀني ڪلسٽرن ۾ ورهائي ٿو، ان ڪري سڀني سرورن کي ھڪ ٻئي سان هم وقت سازي ڪري ٿو. جيڪڏهن شاھد ناڪام ٿئي ٿو يا الڳ ٿي وڃي ٿو، پوءِ ڪلسٽر سرورز مان هڪ (ڪلسٽر جي اندر) پنهنجو وقت ورهائڻ شروع ڪندو. معاون ڪيشنگ HTTP پراکسي ڏانهن پڻ وڌايو شاھد، ان جي مدد سان، ٻيون ورچوئل مشينون يوم مخزن تائين پهچن ٿيون. حقيقت ۾، خدمتون جهڙوڪ صحيح وقت ۽ پراڪسز اڪثر ڪري سرشار سرورز تي ميزباني ڪيا ويندا، پر بوٿ ۾ اهي ميزبان آهن شاھد صرف مجازي مشينن ۽ خلا جو تعداد بچائڻ لاء.
ورژن
v0. VirtualBox 7 تي CentOS 11 ۽ PostgreSQL 6.1 سان ڪم ڪري ٿو.
ڪلستر جي جوڙجڪ
سڀ ڪلسٽر ڪيترن ئي ڊيٽا سينٽرن ۾ واقع ٿيڻ لاءِ ٺهيل آهن، هڪ فليٽ نيٽ ورڪ ۾ گڏيل ۽ هڪ واحد ڊيٽا سينٽر جي ناڪامي يا نيٽ ورڪ جي اڪيلائي کي منهن ڏيڻ لازمي آهي. هن ڪري ناممڪن آهي جي خلاف تحفظ لاء استعمال ورهايل دماغ معياري Pacemaker ٽيڪنالاجي سڏيو ويندو آهي اسٽونٿ (سر ۾ ٻئي نوڊ کي گول ڪريو) يا باهه. ان جو خلاصو: جيڪڏهن ڪلستر ۾ نوڊس شڪ ڪرڻ شروع ڪن ٿا ته ڪجهه نوڊ سان ڪجهه غلط آهي، اهو جواب نه ڏئي رهيو آهي يا غلط طريقي سان عمل ڪري رهيو آهي، پوء اهي زبردستي ان کي "بيروني" ڊوائيسز ذريعي بند ڪري ڇڏيندا آهن، مثال طور، IPMI يا UPS ڪنٽرول ڪارڊ. . پر اهو صرف ڪيسن ۾ ڪم ڪندو جتي، هڪ ناڪامي جي صورت ۾، IPMI يا UPS سرور ڪم ڪرڻ جاري رکي. هتي اسان هڪ وڌيڪ تباهي واري ناڪامي جي خلاف حفاظت ڪرڻ جو منصوبو ٺاهيو، جڏهن سڄي ڊيٽا سينٽر ناڪام ٿئي ٿي (مثال طور، طاقت وڃائي ٿو). ۽ اهڙي انڪار سان، سڀ ڪجهه اسٽونٿڊوائيسز (IPMI، UPS، وغيره) پڻ ڪم نه ڪندا.
ان جي بدران، نظام ڪورم جي خيال تي ٻڌل آهي. سڀني نوڊس جو آواز آھي، ۽ صرف اھي جيڪي ڏسي سگھن ٿا اڌ کان وڌيڪ سڀني نوڊس ڪم ڪري سگھن ٿا. هن مقدار کي "اڌ + 1" سڏيو ويندو آهي ڪورم. جيڪڏهن ڪورم نه پهچي وڃي ته پوءِ نوڊ فيصلو ڪري ٿو ته اهو نيٽ ورڪ آئسوليشن ۾ آهي ۽ ان جا وسيلا بند ڪرڻ گهرجن، يعني. اھو اھو آھي جيڪو اھو آھي ورهايل دماغ جي حفاظت. جيڪڏهن سافٽ ويئر جيڪو هن رويي لاء ذميوار آهي ڪم نه ڪندو، پوء هڪ واچ ڊاگ، مثال طور، IPMI جي بنياد تي، ڪم ڪرڻو پوندو.
جيڪڏهن نوڊس جو تعداد برابر آهي (ٻن ڊيٽا سينٽرن ۾ هڪ ڪلستر)، ته پوءِ نام نهاد غير يقيني صورتحال پيدا ٿي سگهي ٿي. 50٪ / 50٪ (اڌو اڌ) جڏهن نيٽ ورڪ جي اڪيلائي ڪلستر کي اڌ ۾ ورهائي ٿي. تنهن ڪري، نوڊس جي هڪ برابر تعداد لاء، اسان شامل ڪندا آهيون ڪورم ڊوائيس ھڪڙو غير ضروري ڊيمون آھي جيڪو ٽين ڊيٽا سينٽر ۾ سستي ترين ورچوئل مشين تي لانچ ڪري سگھجي ٿو. هو پنهنجو ووٽ ڪنهن هڪ حصي کي ڏئي ٿو (جنهن کي هو ڏسي ٿو) ۽ ان سان 50%/50% غير يقيني صورتحال کي حل ڪري ٿو. مون ان سرور جو نالو ڏنو جنهن تي ڪورم ڊيوائس شروع ڪئي ويندي شاھد (اصطلاح repmgr کان، مون ان کي پسند ڪيو).
وسيلا هڪ هنڌ کان ٻئي هنڌ منتقل ڪري سگھجن ٿا، مثال طور، ناقص سرورن کان صحتمندن تائين، يا سسٽم ايڊمنسٽريٽرن جي حڪم تي. انهي ڪري ته گراهڪ ڄاڻن ٿا ته انهن وسيلن جي ضرورت ڪٿي آهي (ڪٿي ڳنڍڻ؟)، سچل IP (فلوٽ IP). اهي IPs آهن جيڪي Pacemaker نوڊس جي چوڌاري منتقل ڪري سگهن ٿا (هر شي هڪ فليٽ نيٽ ورڪ تي آهي). انهن مان هر هڪ وسيلن (سروس) جي علامت آهي ۽ اهو واقع هوندو جتي توهان کي هن خدمت تائين رسائي حاصل ڪرڻ لاءِ ڳنڍڻ جي ضرورت آهي (اسان جي صورت ۾، هڪ ڊيٽابيس).
Tuchanka1 (ڪمپيشن سان سرڪٽ)
ساخت
خيال اهو هو ته اسان وٽ گهٽ لوڊ سان ڪيترائي ننڍا ڊيٽابيس آهن، جن لاءِ صرف پڙهڻ واري ٽرانزيڪشن لاءِ گرم اسٽينڊ بائي موڊ ۾ وقف ٿيل غلام سرور کي برقرار رکڻ غير منافع بخش آهي (انهن وسيلن جي ضايع ڪرڻ جي ڪا ضرورت ناهي).
هر ڊيٽا سينٽر ۾ هڪ سرور آهي. هر سرور وٽ ٻه PostgreSQL مثال آهن (PostgreSQL اصطلاح ۾ انهن کي ڪلسٽر سڏيو ويندو آهي، پر مونجهاري کان بچڻ لاءِ آئون انهن کي مثال سڏيندس (ٻين ڊيٽابيس سان تشبيهه سان)، ۽ مان صرف Pacemaker ڪلسٽر ڪلسٽر سڏيندس). ھڪڙو مثال ماسٽر موڊ ۾ ھلندو آھي، ۽ صرف اھو خدمتون مهيا ڪري ٿو (صرف فلوٽ IP ان جي طرف وٺي ٿو). ٻيو مثال ٻئي ڊيٽا سينٽر لاءِ غلام طور ڪم ڪري ٿو، ۽ خدمتون مهيا ڪندو صرف ان صورت ۾ جڏهن ان جو ماسٽر ناڪام ٿئي. اڪثر وقت کان وٺي ٻن مان صرف هڪ مثال (ماسٽر) خدمتون مهيا ڪندو (درخواستن کي انجام ڏيو)، سرور جا سڀئي وسيلا ماسٽر لاءِ بهتر ڪيا ويا آهن (ميموري مختص ڪئي وئي آهي حصيداري_بفرز ڪيش وغيره لاءِ)، پر انهي ڪري ته ٻيو مثال ڊيٽا سينٽرن مان هڪ جي ناڪامي جي صورت ۾ پڻ ڪافي وسيلا آهن (جيتوڻيڪ فائل سسٽم ڪيش ذريعي ذيلي اپٽيمل آپريشن لاءِ). غلام ڪلستر جي عام آپريشن دوران خدمتون مهيا نٿو ڪري (صرف پڙهڻ جي درخواستن کي انجام نٿو ڏئي)، انهي ڪري ته ساڳئي مشين تي ماسٽر سان وسيلن جي جنگ ناهي.
ٻن نوڊس جي صورت ۾، غلطي رواداري صرف غير مطابقت واري نقل سان ممڪن آهي، ڇاڪاڻ ته هم وقت سازي جي نقل سان، غلام جي ناڪامي ماسٽر جي بند ٿيڻ جي ڪري ٿي.
شاهدي ڏيڻ ۾ ناڪامي
شاهدي ڏيڻ ۾ ناڪامي (ڪورم ڊوائيس) مان صرف Tuchanka1 ڪلستر لاء غور ڪندس، ٻين سڀني سان گڏ اهو ساڳيو ڪهاڻي هوندو. جيڪڏهن شاهدي ناڪام ٿئي ٿي، ڪلستر جي جوڙجڪ ۾ ڪجھ به تبديل نه ٿيندو، هر شيء ساڳئي طريقي سان ڪم ڪندي رهندي. پر ڪورم 2 مان 3 ٿي ويندو، ۽ ان ڪري ڪا به ناڪامي ڪلستر لاءِ موتمار ثابت ٿيندي. اهو اڃا تائين فوري طور تي طئي ڪرڻو پوندو.
Tuchanka1 انڪار
Tuchanka1 لاء ڊيٽا سينٽرن مان هڪ جي ناڪامي. هن معاملي ۾ شاھد پنهنجي ووٽ کي هڪ سيڪنڊ ڊيٽا سينٽر ۾ هڪ سيڪنڊ نوڊ ڏانهن وڌايو. اتي، اڳوڻو غلام هڪ ماسٽر ۾ بدلجي ٿو، نتيجي طور، ٻئي ماسٽر هڪ ئي سرور تي ڪم ڪن ٿا ۽ انهن جا ٻئي فلوٽ IP انهن ڏانهن اشارو ڪن ٿا.
Tuchanka2 (ڪلاسيڪل)
ساخت
ٻن نوڊس جو کلاسي اسڪيم. هڪ تي مالڪ ڪم ڪندو آهي، غلام ٻئي تي. ٻئي درخواستن تي عمل ڪري سگھن ٿا (غلام صرف پڙھيل آھي)، تنھنڪري ٻئي طرف اشارو ڪيو ويو آھي فلوٽ IP: krogan2 ماسٽر آھي، krogan2s1 غلام آھي. آقا ۽ غلام ٻنهي ۾ عيب برداشت هوندو.
ٻن نوڊس جي صورت ۾، غلطي رواداري صرف غير مطابقت واري نقل سان ممڪن آهي، ڇاڪاڻ ته هم وقت سازي جي نقل سان، غلام جي ناڪامي ماسٽر جي بند ٿيڻ جي ڪري ٿي.
Tuchanka2 انڪار
جيڪڏهن ڊيٽا سينٽرن مان هڪ ناڪام ٿي وڃي شاھد ٻئي لاء ووٽ. صرف ڪم ڪندڙ ڊيٽا سينٽر تي، ماسٽر بلند ڪيو ويندو، ۽ ٻئي فلوٽ IPs ان ڏانهن اشارو ڪندا: ماسٽر ۽ غلام. يقينا، مثال کي اهڙي طرح ترتيب ڏيڻ گهرجي ته ان وٽ ڪافي وسيلا آهن (ڪنيڪشن جون حدون، وغيره) هڪ ئي وقت ماسٽر ۽ غلام فلوٽ IP کان سڀني ڪنيڪشن ۽ درخواستن کي قبول ڪرڻ لاءِ. اهو آهي، عام آپريشن دوران ان کي حدن جي ڪافي فراهمي هجڻ گهرجي.
Tuchanka4 (ڪيترائي غلام)
ساخت
اڳ ۾ ئي هڪ ٻي انتهائي. اهڙا ڊيٽابيس آهن جيڪي صرف پڙهڻ لاءِ تمام گهڻيون درخواستون وصول ڪندا آهن (هڪ عام ڪيس هڪ اعلي لوڊ سائيٽ جو). Tuchanka4 هڪ اهڙي صورتحال آهي جتي اهڙين درخواستن کي سنڀالڻ لاءِ ٽي يا وڌيڪ غلام ٿي سگهن ٿا، پر اڃا به تمام گهڻا نه آهن. غلامن جي هڪ تمام وڏي تعداد سان، اهو ضروري هوندو ته هڪ hierarchical نقل واري نظام کي ايجاد ڪرڻ. گھٽ ۾ گھٽ صورت ۾ (تصوير ۾)، ٻن ڊيٽا سينٽرن مان ھر ھڪ وٽ ٻه سرور آھن، ھر ھڪ PostgreSQL مثال سان.
هن اسڪيم جي هڪ ٻي خاصيت اها آهي ته اهو اڳ ۾ ئي ممڪن آهي ته هڪ هم وقت سازي کي ترتيب ڏيڻ. ان کي نقل ڪرڻ لاءِ ترتيب ڏنو ويو آهي، جيڪڏهن ممڪن هجي، ٻئي ڊيٽا سينٽر ڏانهن، بجاءِ ساڳي ڊيٽا سينٽر ۾ نقل ڪرڻ جي بجاءِ ماسٽر جي طور تي. ماسٽر ۽ هر غلام کي فلوٽ IP جي طرف اشارو ڪيو ويو آهي. خوشقسمتيء سان، غلامن جي وچ ۾ اهو ضروري هوندو ته ڪنهن به طريقي سان درخواستن کي توازن ڪرڻ لاء sql proxy، مثال طور، ڪلائنٽ جي پاسي تي. گراهڪن جي مختلف قسمن جي مختلف قسمن جي ضرورت ٿي سگھي ٿي sql proxy، ۽ صرف ڪلائنٽ ڊولپرز کي خبر آهي ته ڪنهن کي ڪهڙي ضرورت آهي. هي ڪارڪردگي يا ته خارجي ڊيمن يا ڪلائنٽ لائبريري (ڪنيڪشن پول) وغيره ذريعي لاڳو ٿي سگهي ٿو. هي سڀ هڪ ناڪامي ڊيٽابيس ڪلستر جي موضوع کان ٻاهر آهي (failover SQL پراکسي ڪلائنٽ جي غلطي رواداري سان گڏ، آزاديء سان لاڳو ٿي سگھي ٿو).
Tuchanka4 انڪار
جيڪڏهن هڪ ڊيٽا سينٽر (يعني ٻه سرورز) ناڪام ٿي وڃن ٿا، ووٽن جي شاهدي ٻئي لاءِ. نتيجي طور، ٻئي ڊيٽا سينٽر ۾ ٻه سرور هلائي رهيا آهن: هڪ ماسٽر هلائي رهيو آهي، ۽ ماسٽر فلوٽ IP ان ڏانهن اشارو ڪري ٿو (پڙهڻ-لکڻ جي درخواستون حاصل ڪرڻ لاء)؛ ۽ ٻئي سرور تي هڪ غلام آهي جيڪو هم وقت سازي جي نقل سان هلندو آهي، ۽ هڪ غلام فلوٽ IPs ان ڏانهن اشارو ڪري ٿو (صرف پڙهڻ جي درخواستن لاءِ).
نوٽ ڪرڻ جي پهرين شيء اها آهي ته نه سڀئي غلام فلوٽ IPs مزدور هوندا، پر صرف هڪ. ۽ ان سان گڏ صحيح ڪم ڪرڻ لاء ضروري آهي ته sql proxy سڀني درخواستن کي صرف باقي فلوٽ IP ڏانهن منتقل ڪيو؛ ۽ جيڪڏهن sql proxy نه، ته پوءِ توهان ڪنيڪشن URL ۾ ڪاما سان الڳ ڪيل سڀئي فلوٽ IP غلام لسٽ ڪري سگهو ٿا. هن معاملي ۾، سان libpq ڪنيڪشن پهرين ڪم ڪندڙ IP سان هوندو، اهو خودڪار ٽيسٽنگ سسٽم ۾ ڪيو ويندو آهي. شايد ٻين لائبريرين ۾، مثال طور، JDBC، اهو ڪم نه ڪندو ۽ ضروري آهي sql proxy. اهو ڪيو ويو آهي ڇو ته غلامن لاءِ فلوٽ IPs هڪ سرور تي گڏ ٿيڻ کان منع ٿيل آهن، انهي ڪري اهي غلام سرورن ۾ برابر طور تي ورهايا ويندا آهن جيڪڏهن انهن مان ڪيترائي هلن ٿا.
ٻيو: جيتوڻيڪ ڊيٽا سينٽر جي ناڪامي جي صورت ۾، هم وقت سازي جي نقل برقرار رکي ويندي. ۽ جيتوڻيڪ جيڪڏهن هڪ ثانوي ناڪامي ٿئي ٿي، اهو آهي، باقي ڊيٽا سينٽر ۾ ٻن سرورن مان هڪ ناڪام ٿئي ٿو، ڪلستر، جيتوڻيڪ اهو خدمتون مهيا ڪرڻ بند ڪري ڇڏيندو، اڃا تائين سڀني انجام ڏيڻ واري ٽرانزيڪشن بابت معلومات برقرار رکندو، جنهن جي لاء هن انجام جي تصديق ڪئي آهي. (ثانوي ناڪامي جي صورت ۾ نقصان جي ڪا ڄاڻ نه هوندي).
Tuchanka3 (3 ڊيٽا مرڪز)
ساخت
هي هڪ اهڙي صورتحال لاءِ ڪلسٽر آهي جتي ٽي مڪمل طور تي ڪم ڪندڙ ڊيٽا سينٽر آهن، جن مان هر هڪ وٽ مڪمل طور تي ڪم ڪندڙ ڊيٽابيس سرور آهي. هن معاملي ۾ ڪورم ڊوائيس ضرورت ناهي. هڪ ڊيٽا سينٽر هڪ ماسٽر طرفان اسٽاف آهي، ٻيا ٻه غلامن طرفان اسٽاف آهن. نقل هم وقت سازي آهي، ٽائپ ڪريو ANY (slave1، slave2)، اهو آهي، ڪلائنٽ هڪ عزم جي تصديق حاصل ڪندو جڏهن غلامن مان ڪو به پهريون جواب ڏيڻ وارو آهي ته هن واعدو قبول ڪيو آهي. وسيلا ظاهر ڪيا ويا آهن هڪ فلوٽ IP ماسٽر لاءِ ۽ ٻه غلامن لاءِ. Tuchanka4 جي برعڪس، سڀئي ٽي فلوٽ IPs غلطي برداشت ڪندڙ آھن. صرف پڙهڻ لاءِ SQL سوالن کي توازن ڪرڻ لاءِ توهان استعمال ڪري سگهو ٿا sql proxy (الڳ غلطي رواداري سان)، يا ھڪڙي غلام فلوٽ IP کي ڪلائنٽ جي اڌ کي، ۽ ٻيو اڌ سيڪنڊ کي تفويض ڪريو.
Tuchanka3 انڪار
جيڪڏهن ڊيٽا سينٽرن مان هڪ ناڪام ٿئي ٿو، ٻه باقي آهن. هڪ ۾، ماسٽر مان ماسٽر ۽ فلوٽ IP اٿاريو ويو آهي، ٻئي ۾ - غلام ۽ ٻئي غلام فلوٽ IPs (مثال طور ٻنهي غلام فلوٽ IPs کان سڀني ڪنيڪشن کي قبول ڪرڻ لاءِ وسيلن جو ٻٽي ذخيرو هجڻ لازمي آهي). مالڪن ۽ غلامن جي وچ ۾ هم وقت سازي. انهي سان گڏ، ڪلستر ٻن ڊيٽا سينٽرن جي تباهي جي صورت ۾ (جيڪڏهن اهي هڪ ئي وقت تباهه نه ڪيا ويا آهن) جي صورت ۾ عزم ۽ تصديق ٿيل ٽرانزيڪشن بابت معلومات محفوظ ڪندو (انفارميشن جو ڪو نقصان نه ٿيندو).
مون فيصلو ڪيو ته فائل جي جوڙجڪ ۽ ترتيب جي تفصيلي وضاحت شامل نه ڪجي. ڪو به ماڻهو جيڪو راند ڪرڻ چاهي ٿو اهو سڀ ڪجهه README ۾ پڙهي سگهي ٿو. مان صرف پاڻمرادو جاچ جي وضاحت مهيا ڪري رهيو آهيان.
خودڪار ٽيسٽ سسٽم
مختلف نقصن کي تخليق ڪندي ڪلستر جي غلطي رواداري کي جانچڻ لاءِ، هڪ خودڪار ٽيسٽنگ سسٽم ٺاهيو ويو آهي. اسڪرپٽ طرفان شروع ڪيو ويو test/failure. اسڪرپٽ وٺي سگھي ٿو پيرا ميٽرن جو تعداد ڪلسٽرن جو جيڪو توھان جانچڻ چاھيو ٿا. مثال طور هي حڪم:
test/failure 2 3صرف ٻئي ۽ ٽئين ڪلستر کي جانچيندو. جيڪڏهن پيٽرول بيان نه ڪيا ويا آهن، پوء سڀني ڪلستر کي جانچيو ويندو. سڀئي ڪلستر متوازي ۾ آزمايا ويا آهن، ۽ نتيجو ڏيکاريل آهي tmux پينل ۾. Tmux ھڪڙو وقف ٿيل tmux سرور استعمال ڪري ٿو، تنھنڪري اسڪرپٽ کي ڊفالٽ tmux جي ھيٺان هلائي سگھجي ٿو، جنھن جي نتيجي ۾ ھڪڙو nested tmux. مان سفارش ڪريان ٿو ٽرمينل کي وڏي ونڊو ۾ ۽ ننڍي فونٽ سان. جاچ شروع ٿيڻ کان اڳ، اسڪرپٽ مڪمل ٿيڻ وقت سموريون ورچوئل مشينون سنيپ شاٽ ڏانھن واپس ورھجن ٿيون setup.
ٽرمينل کي ڪالمن ۾ ورهايو ويو آھي ڪلستر جي تعداد جي مطابق آزمائشي؛ ڊفالٽ طور (اسڪرين شاٽ ۾) چار آھن. مان Tuchanka2 جو مثال استعمال ڪندي ڪالمن جي مواد کي بيان ڪندس. اسڪرين شاٽ ۾ پينل نمبر ڏنل آھن:
- ٽيسٽ جا انگ اکر ڏيکاريا ويا آهن هتي. ڪالم:
- ناڪام - ٽيسٽ جو نالو (اسڪرپٽ ۾ فنڪشن) جيڪو غلطي کي نقل ڪري ٿو.
- رد - رياضي وارو سراسري وقت سيڪنڊن ۾ جنهن دوران ڪلستر پنهنجي ڪارڪردگي بحال ڪئي. اهو اسڪرپٽ جي شروعات کان ماپيو ويندو آهي هڪ غلطي کي نقل ڪندي ان وقت تائين جڏهن ڪلستر پنهنجي ڪارڪردگي کي بحال ڪري ٿو ۽ خدمتون مهيا ڪرڻ جاري رکڻ جي قابل آهي. جيڪڏهن وقت تمام ننڍو آهي، مثال طور، ڇهه سيڪنڊ (اهو ڪيترن ئي غلامن سان ڪلستر ۾ ٿئي ٿو (Tuchanka3 ۽ Tuchanka4))، هن جو مطلب آهي ته غلطي غير مطابقت واري غلام تي هئي ۽ ڪارڪردگي تي ڪنهن به طريقي سان اثر انداز نه ڪيو؛ ڪو به نه هو. ڪلستر اسٽيٽ سوئچز.
- انحرافي - ڏيکاري ٿو پکيڙ (درستگي) قدر جي رد معياري انحراف جو طريقو استعمال ڪندي.
- ڳڻپ - هي امتحان ڪيترا ڀيرا ڪيو ويو.
- هڪ مختصر لاگ توهان کي اندازو لڳائڻ جي اجازت ڏئي ٿو ته ڪلستر هن وقت ڇا ڪري رهيو آهي. تکرار (ٽيسٽ) نمبر، ٽائم اسٽيمپ ۽ آپريشن جو نالو ڏيکاريل آھي. تمام ڊگهو هلڻ (> 5 منٽ) هڪ مسئلو ظاهر ڪري ٿو.
- دل (دل) - موجوده وقت. ڪارڪردگي جي بصري تشخيص لاء ماستر موجوده وقت مسلسل فلوٽ IP ماسٽر استعمال ڪندي پنهنجي ٽيبل تي لکيو ويو آهي. جيڪڏهن ڪامياب ٿيو، نتيجو هن پينل ۾ ڏيکاريل آهي.
- نزاڪت (نبض) - "موجوده وقت"، جيڪو اڳ ۾ اسڪرپٽ طرفان رڪارڊ ڪيو ويو هو دل ماسٽر ڪرڻ لاء، هاڻي کان پڙهو غلام ان جي فلوٽ IP ذريعي. توهان کي بصري طور تي غلام ۽ نقل جي ڪارڪردگي جو جائزو وٺڻ جي اجازت ڏئي ٿي. Tuchanka1 ۾ فلوٽ IP سان ڪو به غلام نه آهي (ڪو به غلام خدمتون فراهم نه ڪندو آهي)، پر اتي ٻه مثالون (DBs) آهن، تنهنڪري اهو هتي نه ڏيکاريو ويندو. نزاڪت۽ دل ٻيو مثال.
- افاديت استعمال ڪندي ڪلستر صحت جي نگراني
pcs mon. ڏيکاري ٿو جوڙجڪ، وسيلن جي ورڇ نوڊس ۽ ٻين مفيد معلومات ۾. - ڪلستر ۾ هر ورچوئل مشين مان سسٽم مانيٽرنگ هتي ڏيکاريل آهي. ٿي سگهي ٿو وڌيڪ اهڙا پينل ان تي منحصر آهن ته ڪلستر وٽ ڪيتريون ورچوئل مشينون آهن. ٻه گراف سي پي يو لوڊ (مجازي مشينن ۾ ٻه پروسيسر آهن)، ورچوئل مشين جو نالو، سسٽم لوڊ (نالو لوڊ اوسط ڇاڪاڻ ته اهو اوسط 5، 10 ۽ 15 منٽ کان مٿي آهي)، پروسيس ڊيٽا ۽ ميموري مختص ڪرڻ.
- اسڪرپٽ جي جاچ پڙتال ڪندي. خرابي جي صورت ۾ - آپريشن جي اوچتو مداخلت يا لامحدود انتظار جي چڪر - هتي توهان هن رويي جو سبب ڏسي سگهو ٿا.
جاچ ٻن مرحلن ۾ ڪيو ويندو آهي. پهريون، اسڪرپٽ سڀني قسمن جي تجربن مان گذري ٿو، بي ترتيب طور تي هڪ مجازي مشين کي چونڊيو جنهن تي هن ٽيسٽ کي لاڳو ڪرڻ لاء. پوءِ جاچ جو هڪ لامحدود چڪر ڪيو ويندو آهي، ورچوئل مشينون ۽ غلطي هر وقت بي ترتيب طور تي چونڊجي ويندي آهي. ٽيسٽنگ اسڪرپٽ جو اوچتو ختم ٿيڻ (هيٺيان پينل) يا ڪنهن شيءِ جي انتظار جو لامحدود لوپ (> هڪ آپريشن لاءِ 5 منٽ جي عمل جو وقت، اهو سراغ ۾ ڏسي سگهجي ٿو) ظاهر ڪري ٿو ته هن ڪلستر تي ڪجهه ٽيسٽ ناڪام ٿي چڪا آهن.
هر ٽيسٽ هيٺين عملن تي مشتمل آهي:
- ھڪڙو فنڪشن شروع ڪريو جيڪو ھڪڙي غلطي کي نقل ڪري ٿو.
- تيار؟ - ڪلستر جي بحالي جي انتظار ۾ (جڏهن سڀ خدمتون مهيا ڪيون وينديون آهن).
- ڏيکاري ٿو ڪلستر جي بحالي جو وقت ختم (رد).
- درست ڪريو - ڪلستر کي "مرمت" ڪيو پيو وڃي. جنهن کان پوء ان کي مڪمل طور تي آپريشنل رياست ڏانهن موٽڻ گهرجي ۽ ايندڙ خرابي لاء تيار ٿيڻ گهرجي.
هتي ٽيسٽن جي هڪ فهرست آهي جنهن جي وضاحت سان اهي جيڪي ڪندا آهن:
- فورڪ بم: ڪانٽو بم استعمال ڪندي "آئوٽ آف ياداشت" ٺاهي ٿو.
- خلا کان ٻاهر: هارڊ ڊرائيو ڀريل آهي. پر امتحان بلڪه علامتي آهي؛ غير معمولي لوڊ سان جيڪو ٽيسٽ دوران پيدا ٿئي ٿو، PostgreSQL عام طور تي ناڪام نٿو ٿئي جڏهن هارڊ ڊرائيو مڪمل آهي.
- پوسٽ گريس- مارڻ: حڪم سان PostgreSQL کي ماريندو آهي
killall -KILL postgres. - پوسٽ گريس-اسٽاپ: hangs PostgreSQL حڪم
killall -STOP postgres. - پاور اوف: ڪمانڊ سان ورچوئل مشين کي ”ڊي-انرجيز“ ڪري ٿو
VBoxManage controlvm "виртуалка" poweroff. - مٽائڻ: ورچوئل مشين کي ڪمانڊ سان اوور لوڊ ڪري ٿو
VBoxManage controlvm "виртуалка" reset. - SBD-اسٽاپ: SBD شيطان کي حڪم سان معطل ڪري ٿو
killall -STOP sbd. - بند ڪريو: SSH ذريعي مجازي مشين ڏانهن هڪ حڪم موڪلي ٿو
systemctl poweroff، سسٽم کي شاندار طور تي بند ڪري ٿو. - Unlink: نيٽ ورڪ اڪيلائي، حڪم
VBoxManage controlvm "виртуалка" setlinkstate1 off.
ٽيسٽ کي مڪمل ڪرڻ يا ته معياري tmux ڪمانڊ استعمال ڪندي "Kill-window" Ctrl-b &، يا "detach-client" حڪم Ctrl-b ڊي: هن نقطي تي جاچ ختم ٿي ويندي آهي، tmux بند ٿي ويندي آهي، مجازي مشينون بند ٿي وينديون آهن.
جاچ دوران مشڪلاتن جي نشاندهي ڪئي وئي
-
هن وقت واچ ڊاگ شيطان ايس بي ڊي مشاهدو ڊيمن کي روڪڻ تي ڪم ڪري ٿو، پر انهن کي منجمد نه ڪرڻ. ۽، نتيجي طور، نقص جيڪي صرف منجمد ٿيڻ جي ڪري ٿي ڪوروسينڪ и pacemaker، پر لٽڪيل نه ايس بي ڊي. چڪاس لاءِ ڪوروسينڪ اڳ ۾ ئي آهي ، سلسلي کي قبول ڪيو رکن ٿا. انهن واعدو ڪيو (PR # 83 ۾) ته Pacemaker لاءِ به ڪجهه ساڳيو هوندو ، مون کي اميد آهي ته طرفان ريٽ هٽي 8 ڪندو. پر اهڙيون ”خرابيون“ قياس آرائي واريون آهن ۽ آساني سان مصنوعي طور استعمال ڪري سگھجن ٿيون، مثال طور،
killall -STOP corosyncپر حقيقي زندگي ۾ ڪڏهن به نه ملن. -
У pacemaker لاء نسخو ۾ CentOS 7 غلط مقرر sync_timeout у ڪورم ڊوائيس، نتيجي طور جنهن ڏانهن ماسٽر کي وڃڻو هو. وڌائڻ سان علاج sync_timeout у ڪورم ڊوائيس مقرري دوران (اسڪرپٽ ۾
setup/setup1). هي ترميم ڊولپرز طرفان قبول نه ڪيو ويو pacemaker، ان جي بدران انهن انفراسٽرڪچر کي اهڙي طرح نئين سر ترتيب ڏيڻ جو واعدو ڪيو (ڪجهه اڻ ڄاڻايل مستقبل ۾) ته اهو وقت ختم ٿيڻ جو حساب پاڻمرادو ڪيو ويندو. -
جيڪڏهن ڊيٽابيس جي ٺاھ جوڙ بيان ڪري ٿي ته
LC_MESSAGES(ٽيڪسٽ پيغام) يونيڪوڊ استعمال ڪري سگھجي ٿو، مثال طورru_RU.UTF-8، پوءِ شروعات ۾ پوسٽ هڪ ماحول ۾ جتي مقامي UTF-8 نه آهي، هڪ خالي ماحول ۾ چئو (هتي پيسي ميڪر+pgsqlms(paf) ڊوڙندو آهي پوسٽ) پوء . PostgreSQL ڊولپرز اتفاق نه ڪيو آهي ته هن معاملي ۾ ڇا ڪجي. اهو خرچ، توهان کي انسٽال ڪرڻ جي ضرورت آهيLC_MESSAGES=en_US.UTF-8جڏهن ترتيب ڏيڻ (ٺاهي) هڪ ڊيٽابيس مثال. -
جيڪڏهن wal_receiver_timeout مقرر ڪيو ويو آهي (ڊفالٽ طور اهو 60s آهي)، پوءِ پوسٽ گري ايس ايس ايل-اسٽاپ ٽيسٽ دوران ماسٽر تي tuchanka3 ۽ tuchanka4 ڪلستر . نقل اتي هم وقت سازي آهي، تنهنڪري نه رڳو غلام روڪي ٿو، پر نئون مالڪ پڻ. wal_receiver_timeout=0 ترتيب ڏيڻ جي چوڌاري ڪم ڪري ٿو جڏهن PostgreSQL ترتيب ڏيڻ.
-
ڪڏهن ڪڏهن مون ڏٺو ته نقل منجمد ٿي وئي PostgreSQL ۾ ForkBomb ٽيسٽ (ميموري اوور فلو). . مون هن کي صرف tuchanka3 ۽ tuchanka4 ڪلستر ۾ ڏٺو آهي، جتي ماسٽر هم وقت سازي جي ڪري منجمد ٿي ويو آهي. مسئلو هڪ ڊگهي وقت (اٽڪل ٻن ڪلاڪن) کان پوء پاڻ تي هليو ويو. انهي کي درست ڪرڻ لاء وڌيڪ تحقيق جي ضرورت آهي. علامتون اڳئين بگ سان ملندڙ جلندڙ آهن، جيڪو مختلف سببن جي ڪري، پر ساڳئي نتيجن سان.
ڪروگن تصوير تان ورتل ليکڪ جي اجازت سان:
جو ذريعو: www.habr.com