Patroni جو بنيادي مقصد PostgreSQL لاءِ اعليٰ دستيابي مهيا ڪرڻ آهي. پر Patroni صرف هڪ ٽيمپليٽ آهي، نه هڪ تيار ٿيل اوزار (جنهن کي، عام طور تي، دستاويز ۾ چيو ويندو آهي). پهرين نظر ۾، پيٽروني کي ٽيسٽ ليب ۾ قائم ڪرڻ تي، توهان ڏسي سگهو ٿا ته اهو ڪهڙو بهترين اوزار آهي ۽ اهو ڪلستر کي ٽوڙڻ جي اسان جي ڪوشش کي ڪيتري آساني سان سنڀاليندو آهي. بهرحال، عملي طور تي، پيداوار جي ماحول ۾، هر شيء هميشه طور تي خوبصورت ۽ خوبصورت طور تي نه ٿيندي آهي جيئن هڪ ٽيسٽ ليب ۾.
مان توهان کي پنهنجي باري ۾ ٿورو ٻڌايان ٿو. مون هڪ سسٽم ايڊمنسٽريٽر طور شروع ڪيو. ويب ڊولپمينٽ ۾ ڪم ڪيو. مان 2014 کان ڊيٽا ايگرٽ تي ڪم ڪري رهيو آهيان. ڪمپني Postgres جي ميدان ۾ مشاورت ۾ مصروف آهي. ۽ اسان بلڪل خدمت ڪريون ٿا Postgres، ۽ اسان هر روز Postgres سان ڪم ڪريون ٿا، تنهنڪري اسان وٽ آپريشن سان لاڳاپيل مختلف ماهر آهن.
۽ 2018 جي آخر ۾، اسان سست رفتار سان Patroni استعمال ڪرڻ شروع ڪيو. ۽ ڪجهه تجربو گڏ ڪيو ويو آهي. اسان ڪنهن نه ڪنهن طرح ان جي تشخيص ڪئي، ان کي ترتيب ڏنو، اسان جي بهترين عملن تي آيو. ۽ هن رپورٽ ۾ آئون انهن بابت ڳالهائيندس.
Postgres کان سواء، مون کي لينڪس پسند آهي. مون کي ان جي چوڌاري ڇڪڻ ۽ ڳولڻ پسند آهي، مون کي ڪور گڏ ڪرڻ پسند آهي. مون کي ورچوئلائيزيشن، ڪنٽينرز، ڊاڪر، ڪبرنيٽس پسند آهن. هي سڀ مون کي دلچسپي آهي، ڇاڪاڻ ته پراڻي منتظم جون عادتون اثر انداز ٿي رهيون آهن. مان مانيٽرنگ سان معاملو ڪرڻ پسند ڪندو آهيان. ۽ مون کي پسند آهي پوسٽ گريس شين سان لاڳاپيل انتظاميه، يعني نقل، بيڪ اپ. ۽ پنهنجي فارغ وقت ۾ گو ۾ لکندو آهيان. مان سافٽ ويئر انجنيئر نه آهيان، مان صرف پنهنجي لاءِ گو ۾ لکندو آهيان. ۽ اهو مون کي خوشي ڏئي ٿو.
- منهنجو خيال آهي ته توهان مان گهڻا ڄاڻن ٿا ته پوسٽ گريس وٽ دٻي مان HA (هاءِ دستيابي) نه آهي. HA حاصل ڪرڻ لاء، توھان کي ڪجھھ انسٽال ڪرڻ جي ضرورت آھي، ان کي ترتيب ڏيو، ڪوشش ڪريو ۽ حاصل ڪريو.
- اتي ڪيترائي اوزار آھن ۽ Patroni انھن مان ھڪڙو آھي جيڪو حل ڪري ٿو HA خوبصورت ۽ تمام سٺو. پر اهو سڀ ڪجهه ٽيسٽ ليب ۾ رکڻ ۽ ان کي هلائڻ سان، اسان ڏسي سگهون ٿا ته اهو سڀ ڪم ڪري ٿو، اسان ڪجهه مسئلا ٻيهر پيدا ڪري سگهون ٿا، ڏسو ته ڪيئن پيٽروني انهن جي خدمت ڪري ٿو. ۽ اسان ڏسنداسين ته اهو سڀ ڪجهه عظيم ڪم ڪري ٿو.
- پر عملي طور تي، اسان کي مختلف مسئلن کي منهن ڏيڻو پيو. ۽ مان انهن مسئلن بابت ڳالهائيندس.
- مان توهان کي ٻڌايان ٿو ته اسان ان جي تشخيص ڪيئن ڪئي، ڇا اسان ٽائيڪ ڪيو - ڇا اهو اسان جي مدد ڪئي يا نه.
- مان توهان کي نه ٻڌايان ٿو ته Patroni کي ڪيئن نصب ڪيو وڃي، ڇو ته توهان انٽرنيٽ تي گوگل ڪري سگهو ٿا، توهان ترتيب ڏيڻ واري فائلن کي ڏسي سگهو ٿا اهو سمجهڻ لاء ته اهو سڀ ڪيئن شروع ٿئي ٿو، اهو ڪيئن ترتيب ڏنو ويو آهي. توھان سمجھي سگھوٿا اسڪيمون، فن تعمير، انٽرنيٽ تي ان جي باري ۾ معلومات ڳولڻ.
- مان ڪنهن ٻئي جي تجربي بابت نه ڳالهائيندس. مان صرف انهن مسئلن جي باري ۾ ڳالهائيندس جيڪي اسان کي منهن ڏيڻو پيو.
- ۽ مان انهن مسئلن بابت نه ڳالهائيندس جيڪي Patroni ۽ PostgreSQL کان ٻاهر آهن. جيڪڏهن، مثال طور، توازن سان لاڳاپيل مسئلا آهن، جڏهن اسان جو ڪلستر ختم ٿي ويو آهي، مان ان بابت نه ڳالهائيندس.
۽ اسان جي رپورٽ شروع ڪرڻ کان پهريان هڪ ننڍڙو اعلان.
اهي سڀئي مسئلا جيڪي اسان کي سامهون آيا، اسان انهن کي آپريشن جي پهرين 6-7-8 مهينن ۾ ڪيو. وقت سان گڏ، اسان کي اسان جي اندروني بهترين عملن تي آيو. ۽ اسان جا مسئلا غائب ٿي ويا. تنهن ڪري، رپورٽ جو اعلان تقريبا ڇهه مهينا اڳ ڪيو ويو، جڏهن اهو سڀ ڪجهه منهنجي ذهن ۾ تازو هو ۽ مون کي اهو سڀ ڪجهه مڪمل طور تي ياد هو.
رپورٽ تيار ڪرڻ دوران، مون اڳ ۾ ئي پراڻي پوسٽ مارٽم کي وڌايو، لاگز کي ڏٺو. ۽ مسئلن جي تجزيي دوران ڪجھ تفصيلن کي وساري سگھجي ٿو، يا ڪجھ تفصيل مڪمل طور تي تحقيق نه ٿي سگھيا آھن، ان ڪري ڪجھ نقطن تي لڳي سگھي ٿو ته مسئلا مڪمل طور تي غور نه ڪيا ويا آھن، يا ڪجھ معلومات جي کوٽ آھي. ۽ تنهن ڪري مان توهان کان پڇان ٿو ته مون کي هن پل لاء معافي ڏيو.
Patroni ڇا آهي؟
- هي HA تعمير ڪرڻ لاء هڪ ٽيمپليٽ آهي. اھو اھو آھي جيڪو دستاويز ۾ چوي ٿو. ۽ منهنجي نقطي نظر کان، هي هڪ بلڪل صحيح وضاحت آهي. Patroni چانديءَ جي گولي نه آهي جيڪا توهان جا سمورا مسئلا حل ڪري ڇڏي، يعني توهان کي ان کي ڪم ڪرڻ ۽ فائدا حاصل ڪرڻ لاءِ ڪوشش ڪرڻي پوندي.
- هي هڪ ايجنٽ سروس آهي جيڪا هر ڊيٽابيس سروس تي نصب ٿيل آهي ۽ توهان جي پوسٽ گريس لاءِ هڪ قسم جو انٽ سسٽم آهي. اهو پوسٽ گريس شروع ٿئي ٿو، اسٽاپ، ٻيهر شروع، ٻيهر ترتيب، ۽ توهان جي ڪلستر جي ٽوپولوجي کي تبديل ڪري ٿو.
- انهي جي مطابق، ڪلستر جي حالت کي ذخيرو ڪرڻ لاء، ان جي موجوده نمائندگي، جيئن اهو ڏسڻ ۾ اچي ٿو، ڪجهه قسم جي اسٽوريج جي ضرورت آهي. ۽ انهيءَ نقطه نگاهه کان پتروني رياست کي خارجي نظام ۾ محفوظ ڪرڻ جو رستو اختيار ڪيو. اهو هڪ ورهايل ترتيب واري اسٽوريج سسٽم آهي. اهو ٿي سگهي ٿو Etcd، Consul، ZooKeeper، يا kubernetes Etcd، يعني انهن اختيارن مان هڪ.
- ۽ Patroni جي خاصيتن مان هڪ آهي ته توهان آٽو فائلر کي دٻي مان ٻاهر ڪڍو، صرف ان کي ترتيب ڏيڻ سان. جيڪڏهن اسان مقابلي لاءِ Repmgr وٺون ٿا، پوءِ فائلر اتي شامل آهي. Repmgr سان، اسان هڪ سوئچ اوور حاصل ڪندا آهيون، پر جيڪڏهن اسان هڪ آٽوفيلر چاهيون ٿا، پوء اسان کي ان کي اضافي طور تي ترتيب ڏيڻ جي ضرورت آهي. Patroni اڳ ۾ ئي هڪ آٽو فائلر آهي دٻي مان ٻاهر.
- ۽ ٻيون به ڪيتريون ئي شيون آهن. مثال طور، ترتيبن جي سار سنڀال، نئين ريپليڪس، بيڪ اپ، وغيره. پر اهو رپورٽ جي دائري کان ٻاهر آهي، مان ان بابت نه ڳالهائيندس.
۽ هڪ ننڍڙو نتيجو اهو آهي ته Patroni جو بنيادي ڪم هڪ آٽو فائل کي چڱي طرح ۽ قابل اعتماد طريقي سان ڪرڻ آهي ته جيئن اسان جو ڪلستر جاري رهي ۽ ايپليڪيشن ڪلستر جي ٽوپولوجي ۾ تبديلين کي نوٽيس نه ڪري.
پر جڏهن اسان Patroni استعمال ڪرڻ شروع ڪريون ٿا، اسان جو نظام ٿورو وڌيڪ پيچيده ٿي وڃي ٿو. جيڪڏهن اڳ ۾ اسان وٽ پوسٽ گريس هوندو هو، پوءِ جڏهن Patroni استعمال ڪندا آهيون ته اسان Patroni پاڻ حاصل ڪندا آهيون، اسان DCS حاصل ڪندا آهيون جتي رياست ذخيرو ٿيل آهي. ۽ اهو سڀ ڪجهه ڪم ڪرڻو پوندو. پوء ڇا غلط ٿي سگهي ٿو؟
ڀڃي سگھي ٿو:
- پوسٽ گريس ڀڄي سگھي ٿو. اهو هڪ ماسٽر يا هڪ نقل ٿي سگهي ٿو، انهن مان هڪ ناڪام ٿي سگهي ٿو.
- پيٽروني پاڻ ڀڄي سگهي ٿو.
- DCS جتي رياست محفوظ ٿيل آهي ڀڄي سگهي ٿي.
- ۽ نيٽ ورڪ ٽوڙي سگهي ٿو.
اهي سڀئي نقطا آئون رپورٽ ۾ غور ڪندس.
مان ڪيسن تي غور ڪندس جيئن اهي وڌيڪ پيچيده ٿي وڃن، نه ته ان نقطي نظر کان ته ڪيس ۾ ڪيترائي جزا شامل آهن. ۽ موضوعي احساسن جي نقطي نظر کان، ته اهو ڪيس مون لاءِ ڏکيو هو، ان کي ڌار ڪرڻ ڏکيو هو... ۽ ان جي برعڪس، ڪجهه ڪيس هلڪو هو ۽ ان کي ڌار ڪرڻ آسان هو.
۽ پهريون ڪيس سڀ کان آسان آهي. اهو معاملو آهي جڏهن اسان هڪ ڊيٽابيس ڪلستر ورتو ۽ اسان جي ڊي سي ايس اسٽوريج کي ساڳئي ڪلستر تي لڳايو. هي سڀ کان عام غلطي آهي. آرڪيٽيڪچر جي تعمير ۾ هي هڪ غلطي آهي، يعني مختلف حصن کي هڪ جاءِ تي گڏ ڪرڻ.
تنهن ڪري، هڪ فائيلر هو، اچو ته معاملو ڪرڻ لاء ڇا ٿيو.
۽ هتي اسان کي دلچسپي آهي جڏهن فائلر ٿيو. اهو آهي، اسان هن وقت ۾ دلچسپي وٺندا آهيون جڏهن ڪلستر رياست تبديل ٿي وئي.
پر فائلر هميشه فوري طور تي نه آهي، يعني اهو وقت جو ڪو يونٽ نٿو وٺي، دير ٿي سگهي ٿو. اهو ڊگهو ٿي سگهي ٿو.
تنهن ڪري، ان ۾ هڪ شروعاتي وقت ۽ هڪ آخري وقت آهي، يعني اهو هڪ مسلسل واقعو آهي. ۽ اسان سڀني واقعن کي ٽن وقفن ۾ ورهايو ٿا: اسان وٽ وقت آهي فائلر کان اڳ، فائلر جي دوران ۽ فائلر کان پوء. اهو آهي، اسان هن ٽائم لائن ۾ سڀني واقعن تي غور ڪندا آهيون.
۽ پهرين شيء، جڏهن هڪ فائيلر ٿيو، اسان ان جي سبب کي ڳوليندا آهيون ته ڇا ٿيو، ڇا جو سبب هو جيڪو فائيلر جي ڪري ٿي.
جيڪڏهن اسان لاگز تي نظر اچن ٿا، اهي کلاسک پيٽروني لاگز هوندا. هو اسان کي انهن ۾ ٻڌائي ٿو ته سرور مالڪ بڻجي ويو آهي، ۽ ماسٽر جو ڪردار هن نوڊ تائين گذري چڪو آهي. هتي اهو نمايان آهي.
اڳيون، اسان کي سمجهڻ جي ضرورت آهي ته فائيلر ڇو ٿيو، يعني ڪهڙا واقعا پيش آيا جن جي ڪري ماسٽر رول هڪ نوڊ کان ٻئي ڏانهن منتقل ٿي ويو. ۽ هن معاملي ۾، سڀڪنھن شيء کي سادو آهي. اسان کي اسٽوريج سسٽم سان لهه وچڙ ۾ هڪ غلطي آهي. ماسٽر محسوس ڪيو ته هو ڊي سي ايس سان ڪم نٿو ڪري سگهي، اهو آهي، رابطي سان ڪجهه قسم جو مسئلو هو. ۽ هو چوي ٿو ته هو هاڻي ماسٽر نٿو رهي سگهي ۽ استعيفي ڏئي ٿو. هي لڪير "خود کي ختم ڪيو" بلڪل ائين ئي چوي ٿو.
جيڪڏهن اسان انهن واقعن تي نظر رکون ٿا جيڪي فائلر کان اڳ آهن، اسان اتي ڏسي سگهون ٿا اهي ئي سبب آهن جن جي ڪري جادوگر کي جاري رکڻ جو مسئلو آهي.
جيڪڏهن اسان Patroni لاگز تي نظر وجهون ٿا، اسان ڏسنداسين ته اسان وٽ ڪيتريون ئي غلطيون آهن، ٽائيم آئوٽ، يعني Patroni ايجنٽ DCS سان ڪم نٿو ڪري سگهي. هن معاملي ۾، هي قونصل ايجنٽ آهي، جيڪو بندرگاهه 8500 تي رابطو ڪري رهيو آهي.
۽ هتي مسئلو اهو آهي ته Patroni ۽ ڊيٽابيس ساڳئي ميزبان تي هلائي رهيا آهن. ۽ قونصل سرور ساڳئي نوڊ تي شروع ڪيا ويا. سرور تي لوڊ پيدا ڪرڻ سان، اسان قونصلن جي سرورز لاء پڻ مسئلا پيدا ڪيو. اهي صحيح طرح سان رابطو نه ڪري سگهيا.
ڪجهه وقت کان پوء، جڏهن لوڊ گهٽجي ويو، اسان جي سرپرست ٻيهر ايجنٽ سان رابطو ڪرڻ جي قابل ٿي ويو. معمول جو ڪم وري شروع ٿيو. ۽ ساڳيو Pgdb-2 سرور وري ماسٽر ٿيو. اهو آهي، اتي هڪ ننڍڙو فلپ هو، جنهن جي ڪري نوڊ ماسٽر جي اختيارات کي استعيفي ڏني، ۽ پوء انهن کي ٻيهر هٿ ڪيو، اهو آهي، هر شيء واپس موٽيو جيئن هو.
۽ اهو هڪ غلط الارم سمجهي سگهجي ٿو، يا اهو سمجهي سگهجي ٿو ته Patroni سڀ ڪجهه صحيح ڪيو. اهو آهي، هن محسوس ڪيو ته هو ڪلستر جي حالت کي برقرار رکي نه سگهيو ۽ پنهنجي اختيار کي هٽائي ڇڏيو.
۽ هتي مسئلو پيدا ٿيو انهي حقيقت جي ڪري ته قونصل سرور ساڳيا هارڊويئر تي آهن جيئن بيس. ان جي مطابق، ڪو به لوڊ: ڇا اهو ڊسڪ يا پروسيسرز تي لوڊ آهي، اهو پڻ ڪنسل ڪلستر سان رابطي کي متاثر ڪري ٿو.
۽ اسان فيصلو ڪيو ته ان کي گڏ نه رهڻ گهرجي، اسان قونصل لاءِ الڳ ڪلستر مختص ڪيو. ۽ Patroni اڳ ۾ ئي هڪ الڳ قونصل سان ڪم ڪري رهيو هو، اهو آهي، اتي هڪ الڳ پوسٽ گريس ڪلستر هو، هڪ الڳ قونصل ڪلستر. هي هڪ بنيادي هدايت آهي ته انهن سڀني شين کي ڪيئن کڻڻ ۽ رکڻو آهي ته جيئن اهو گڏ نه رهي.
هڪ اختيار جي طور تي، توهان ttl، loop_wait، retry_timeout جي پيراگرافن کي موڙي سگھو ٿا، يعني انهن پيرا ميٽرز کي وڌائي انهن مختصر مدت جي لوڊ چوٽي کي بچائڻ جي ڪوشش ڪريو. پر اهو سڀ کان وڌيڪ مناسب اختيار نه آهي، ڇاڪاڻ ته هي لوڊ وقت ۾ ڊگهو ٿي سگهي ٿو. ۽ اسان صرف انهن پيراگرافن جي انهن حدن کان ٻاهر وڃون ٿا. ۽ اهو شايد واقعي مدد نه ڪري سگھي.
پهريون مسئلو، جيئن توهان سمجهي، سادو آهي. اسان ورتو ۽ ڊي سي ايس کي بنياد سان گڏ ڪيو، اسان کي مسئلو مليو.
ٻيو مسئلو پھرين جھڙو آھي. اهو ساڳيو آهي ته اسان وٽ ٻيهر ڊي سي ايس سسٽم سان مداخلت جا مسئلا آهن.
جيڪڏهن اسان لاگز تي نظر وجهون ٿا، اسان ڏسنداسين ته اسان وٽ ٻيهر هڪ مواصلاتي غلطي آهي. ۽ پيٽروني چوي ٿو ته مان ڊي سي ايس سان رابطو نه ٿو ڪري سگهان، تنهن ڪري موجوده ماسٽر ريپليڪا موڊ ۾ وڃي ٿو.
پراڻو ماسٽر هڪ نقل بڻجي ويندو آهي، هتي پيٽروني ڪم ڪري ٿو، جيئن اهو هجڻ گهرجي. اهو هلندو آهي pg_rewind ٽرانزيڪشن لاگ کي ريوائنڊ ڪرڻ ۽ پوءِ نئين ماسٽر سان ڳنڍڻ لاءِ نئين ماسٽر سان. هتي پيٽروني ڪم ڪري ٿو، جيئن هن کي گهرجي.
هتي اسان کي اها جڳهه ڳولڻ گهرجي جيڪا فائلر کان اڳ هئي، يعني اهي غلطيون جن جي ڪري اسان وٽ فائلر آهي. ۽ انهي سلسلي ۾، Patroni لاگ ان سان گڏ ڪم ڪرڻ لاء ڪافي آسان آهن. هو هڪ خاص وقفي تي ساڳيا پيغام لکي ٿو. ۽ جيڪڏهن اسان انهن لاگز کي جلدي اسڪرول ڪرڻ شروع ڪريون ته پوءِ اسان لاگز مان ڏسنداسين ته لاگز تبديل ٿي ويا آهن، جنهن جو مطلب آهي ته ڪجهه مسئلا شروع ٿي ويا آهن. اسان جلدي واپس هن جڳهه تي، ڏسو ته ڇا ٿئي.
۽ هڪ عام صورتحال ۾، لاگ ان وانگر ڪجهه نظر اچن ٿا. تالا جي مالڪ جي چڪاس ڪئي وئي آهي. ۽ جيڪڏھن مالڪ، مثال طور، تبديل ٿي ويو آھي، پوء ڪجھ واقعا ٿي سگھي ٿو ته Patroni کي جواب ڏيڻ گھرجي. پر هن معاملي ۾، اسان ٺيڪ آهيون. اسان ان هنڌ ڳولي رهيا آهيون جتي غلطيون شروع ٿيون.
۽ ان نقطي تي سکرول ڪيو جتي غلطيون ظاهر ٿيڻ شروع ٿي ويون، اسان ڏسون ٿا ته اسان وٽ هڪ خودڪار فائل اوور آهي. ۽ جيئن ته اسان جون غلطيون ڊي سي ايس سان رابطي سان لاڳاپيل هيون ۽ اسان جي صورت ۾ اسان قونصل کي استعمال ڪيو، اسان پڻ قونصل لاگز کي ڏسو، اتي ڇا ٿيو.
فائلر جي وقت ۽ قونصل جي لاگن ۾ وقت جي ڀيٽ ۾، اسان ڏسون ٿا ته قونصل ڪلستر ۾ اسان جي پاڙيسرين قونصل ڪلستر جي ٻين ميمبرن جي وجود تي شڪ ڪرڻ شروع ڪيو.
۽ جيڪڏھن توھان ٻين قونصلن جي ايجنٽن جي لاگن کي ڏسندا، توھان پڻ ڏسي سگھوٿا ته اتي ھڪڙي قسم جو نيٽ ورڪ ختم ٿي رھيو آھي. ۽ قونصل ڪلستر جا سڀئي ميمبر هڪ ٻئي جي وجود تي شڪ ڪن ٿا. ۽ اهو فائلر لاءِ محرڪ هو.
جيڪڏهن توهان ڏسندا ته انهن غلطين کان اڳ ڇا ٿيو هو، توهان ڏسي سگهو ٿا ته هر قسم جون غلطيون آهن، مثال طور، آخري وقت، آر پي سي ختم ٿي وئي، اهو آهي، واضح طور تي قونصل ڪلستر جي ميمبرن جي هڪ ٻئي سان رابطي ۾ ڪجهه قسم جو مسئلو آهي. .
آسان جواب نيٽ ورڪ جي مرمت ڪرڻ آهي. پر مون لاء، پوڊيم تي بيٺو، اهو چوڻ آسان آهي. پر حالتون اهڙيون آهن ته صارف هميشه نيٽ ورڪ کي مرمت ڪرڻ جي متحمل نه ٿي سگهي. هو هڪ ڊي سي ۾ رهي سگهي ٿو ۽ شايد نيٽ ورڪ جي مرمت ڪرڻ جي قابل نه هجي، سامان کي متاثر ڪري. ۽ پوء ڪجهه ٻين اختيارن جي ضرورت آهي.
اتي اختيار آهن:
- آسان ترين اختيار، جيڪو لکيو ويو آهي، منهنجي خيال ۾، جيتوڻيڪ دستاويزن ۾، قونصل چيڪن کي غير فعال ڪرڻ آهي، اهو آهي، صرف هڪ خالي صف پاس ڪريو. ۽ اسان قونصل ايجنٽ کي چئون ٿا ته ڪو به چيڪ استعمال نه ڪن. انهن چيڪن سان، اسان انهن نيٽ ورڪ طوفان کي نظر انداز ڪري سگهون ٿا ۽ فائلر شروع نه ڪري سگهون ٿا.
- ٻيو اختيار آهي ٻه ڀيرا چيڪ ڪرڻ لاءِ raft_multiplier. هي خود قونصل سرور جو هڪ پيٽرولر آهي. ڊفالٽ طور، اهو مقرر ڪيو ويو آهي 5. هي قدر سفارش ڪئي وئي آهي دستاويزن جي اسٽيجنگ ماحول لاءِ. حقيقت ۾، هي قونصلر نيٽ ورڪ جي ميمبرن جي وچ ۾ پيغام جي تعدد کي متاثر ڪري ٿو. حقيقت ۾، هي پيٽرولر قونصل ڪلستر جي ميمبرن جي وچ ۾ خدمت رابطي جي رفتار کي متاثر ڪري ٿو. ۽ پيداوار لاء، اهو اڳ ۾ ئي ان کي گهٽائڻ جي سفارش ڪئي وئي آهي ته جيئن نوڊس پيغامن کي گهڻو ڪري مٽائي.
- هڪ ٻيو اختيار جيڪو اسان کڻي آيا آهيون اهو آهي ڪنسل جي عملن جي ترجيح کي وڌائڻ لاءِ ٻين عملن جي وچ ۾ آپريٽنگ سسٽم جي پروسيس شيڊيولر لاءِ. اتي ھڪڙو "سٺو" پيٽرولر آھي، اھو صرف عملن جي ترجيح کي طئي ڪري ٿو جيڪو OS شيڊولر طرفان حساب ۾ ورتو ويندو آھي جڏھن شيڊول ڪرڻ. اسان قونصلن جي ايجنٽن لاءِ سٺي قيمت پڻ گھٽائي ڇڏي آھي، يعني. ترجيح کي وڌايو ته جيئن آپريٽنگ سسٽم قونصلن کي ڪم ڪرڻ ۽ انهن جي ڪوڊ تي عمل ڪرڻ لاء وڌيڪ وقت ڏئي. اسان جي حالت ۾، اهو اسان جو مسئلو حل ڪيو.
- ٻيو اختيار اهو آهي ته قونصل استعمال نه ڪيو وڃي. منهنجو هڪ دوست آهي جيڪو Etcd جو وڏو حامي آهي. ۽ اسان باقاعدگي سان هن سان بحث ڪندا آهيون ته ڪير بهتر آهي Etcd يا قونصل. پر جنهن لحاظ کان بهتر آهي، اسان عام طور تي هن سان متفق آهيون ته قونصل وٽ هڪ ايجنٽ آهي جيڪو هر نوڊ تي ڊيٽابيس سان گڏ هلڻ گهرجي. اهو آهي، Patroni جو رابطو قونصل ڪلستر سان هن ايجنٽ ذريعي ٿئي ٿو. ۽ هي ايجنٽ هڪ رڪاوٽ بڻجي ويندو آهي. جيڪڏهن ايجنٽ کي ڪجهه ٿئي ٿو ته پوءِ پيٽروني هاڻي قونصل ڪلسٽر سان گڏ ڪم نه ڪري سگهندو. ۽ اهو مسئلو آهي. Etcd منصوبي ۾ ڪو به ايجنٽ ناهي. Patroni سڌو ڪم ڪري سگھي ٿو Etcd سرور جي فهرست سان ۽ اڳ ۾ ئي انھن سان ڳالھ ٻولھ. ان سلسلي ۾، جيڪڏهن توهان پنهنجي ڪمپني ۾ Etcd استعمال ڪندا آهيو، ته پوءِ Etcd شايد قونصل کان بهتر انتخاب هوندو. پر اسان اسان جي گراهڪن تي هميشه محدود آهيون جيڪي ڪلائنٽ چونڊيو ۽ استعمال ڪيو آهي. ۽ اسان وٽ قونصل آهي سڀ کان وڌيڪ حصو سڀني گراهڪن لاءِ.
- ۽ آخري نقطو نظر ثاني ڪرڻ آهي پيٽرول جي قيمتن کي. اسان اميد ڪري سگھون ٿا ته انهن پيرا ميٽرز کي مٿي ڪري سگهون ٿا ته اسان جا مختصر مدي وارا نيٽ ورڪ مسئلا مختصر هوندا ۽ انهن پيٽرولن جي حد کان ٻاهر نه هوندا. هن طريقي سان اسان Patroni جي جارحيت کي گھٽائي سگھون ٿا آٽوفائل ۾ جيڪڏهن ڪجهه نيٽ ورڪ مسئلا پيدا ٿين ٿيون.
مان سمجهان ٿو ته ڪيترائي استعمال ڪندڙ پيٽروني هن حڪم سان واقف آهن.
هي حڪم ڪلستر جي موجوده حالت ڏيکاري ٿو. ۽ پهرين نظر ۾، هي تصوير عام لڳي سگهي ٿي. اسان وٽ هڪ ماسٽر آهي، اسان وٽ هڪ نقل آهي، نقل ڪرڻ ۾ ڪا دير ناهي. پر اها تصوير بلڪل عام آهي جيستائين اسان ڄاڻون ٿا ته هن ڪلستر کي ٽي نوڊس هجڻ گهرجن، ٻه نه.
مطابق، اتي هڪ autofile هو. ۽ هن خودڪار فائل کان پوء، اسان جي نقل غائب ٿي وئي. اسان کي اهو معلوم ڪرڻو پوندو ته هوءَ ڇو غائب ٿي وئي ۽ هن کي واپس آڻيو، ان کي بحال ڪيو. ۽ اسان ٻيهر لاگز ڏانهن وڃو ۽ ڏسو ته اسان وٽ هڪ خودڪار فائل اوور ڇو هو.
انهي حالت ۾، ٻيو نقل ماسٽر بڻجي ويو. اهو سڀ ڪجهه هتي آهي.
۽ اسان کي ان نقل کي ڏسڻ جي ضرورت آهي جيڪا بند ٿي وئي ۽ جيڪا ڪلستر ۾ ناهي. اسان Patroni لاگز کوليو ۽ ڏسون ٿا ته اسان کي pg_rewind اسٽيج تي ڪلستر سان ڳنڍڻ جي عمل دوران مسئلو هو. ڪلسٽر سان ڳنڍڻ لاءِ، توهان کي ٽرانزيڪشن لاگ کي ريوائنڊ ڪرڻ جي ضرورت آهي، ماسٽر کان گهربل ٽرانزيڪشن لاگ جي درخواست ڪريو، ۽ ان کي ماسٽر سان پڪڙڻ لاءِ استعمال ڪريو.
انهي حالت ۾، اسان وٽ ٽرانزيڪشن لاگ نه آهي ۽ نقل شروع نه ٿي سگهي. ان جي مطابق، اسان پوسٽ گريس کي غلطي سان روڪيو. ۽ تنهن ڪري اهو ڪلستر ۾ نه آهي.
اسان کي سمجهڻ جي ضرورت آهي ته اهو ڪلستر ۾ ڇو نه آهي ۽ ڇو لاگ ان نه هئا. اسان نئين ماسٽر ڏانهن وڃو ۽ ڏسو ته هن جي لاگن ۾ ڇا آهي. اهو ظاهر ٿيو ته جڏهن pg_rewind ڪيو ويو، هڪ چيڪ پوائنٽ واقع ٿي. ۽ ڪجھ پراڻن ٽرانزيڪشن لاگز جو نالو تبديل ڪيو ويو. جڏهن پراڻي ماسٽر نئين ماسٽر سان ڳنڍڻ جي ڪوشش ڪئي ۽ انهن لاگن کي پڇڻ جي ڪوشش ڪئي، اهي اڳ ۾ ئي تبديل ڪيا ويا هئا، اهي صرف موجود نه هئا.
مون ٽائم اسٽيمپس جو مقابلو ڪيو جڏهن اهي واقعا ٿيا. ۽ اتي فرق لفظي طور تي 150 مليسيڪنڊ آهي، اهو آهي، چيڪ پوائنٽ 369 مليسيڪنڊن ۾ مڪمل ڪيو ويو، وال حصن جو نالو تبديل ڪيو ويو. ۽ لفظي طور تي 517 ۾، 150 مليسيڪنڊن کان پوء، پراڻي نقل تي ٻيهر شروع ڪيو. اهو آهي، لفظي طور تي 150 مليسيڪنڊ اسان لاء ڪافي هو ته جيئن ريپليڪا ڳنڍڻ ۽ ڪمائي نه سگهي.
ڪهڙا اختيار آهن؟
اسان شروعات ۾ استعمال ڪيو نقل سلاٽ. اسان سوچيو ته اهو سٺو هو. جيتوڻيڪ آپريشن جي پهرين مرحلي ۾ اسان سلاٽ بند ڪيو. اهو اسان کي لڳي ٿو ته جيڪڏهن سلاٽ ڪيترن ئي وال حصن کي گڏ ڪري، اسان ماسٽر کي ڇڏي سگهون ٿا. هو گرندو. اسان ڪجھ دير تائين بغير سلاٽ جي تڪليف ڪئي. ۽ اسان محسوس ڪيو ته اسان کي سلاٽ جي ضرورت آهي، اسان سلاٽ واپس ڪيو.
پر هتي هڪ مسئلو آهي، ته جڏهن ماسٽر ريپليڪا ڏانهن وڃي ٿو، اهو سلاٽ کي حذف ڪري ٿو ۽ سلاٽ سان گڏ وال حصن کي حذف ڪري ٿو. ۽ هن مسئلي کي ختم ڪرڻ لاء، اسان فيصلو ڪيو wal_keep_segments پيٽرولر کي وڌائڻ. اهو ڊفالٽ 8 حصن ۾. اسان ان کي 1 تائين وڌايو ۽ ڏٺو ته اسان وٽ ڪيتري خالي جاء آهي. ۽ اسان wal_keep_segments لاءِ 000 گيگا بائيٽ عطيو ڪيو. اهو آهي، جڏهن سوئچنگ، اسان وٽ هميشه سڀني نوڊس تي 16 گيگا بائيٽ ٽرانزيڪشن لاگز جو ذخيرو آهي.
۽ گڏوگڏ - اهو اڃا تائين لاڳاپيل آهي ڊگهي مدت جي سار سنڀال جي ڪمن لاء. اچو ته چوندا آهن ته اسان کي هڪ ريپليڪس کي اپڊيٽ ڪرڻ جي ضرورت آهي. ۽ اسان ان کي بند ڪرڻ چاهيون ٿا. اسان کي سافٽ ويئر کي اپڊيٽ ڪرڻ جي ضرورت آهي، شايد آپريٽنگ سسٽم، ٻيو ڪجهه. ۽ جڏهن اسان هڪ ريپليڪا کي بند ڪريون ٿا، ته ان نقل لاءِ سلاٽ به هٽايو ويندو آهي. ۽ جيڪڏهن اسان هڪ ننڍڙو wal_keep_segments استعمال ڪريون ٿا، ته پوءِ نقل جي ڊگهي غير موجودگي سان، ٽرانزيڪشن لاگز گم ٿي ويندا. اسان هڪ نقل بلند ڪنداسين، اهو انهن ٽرانزيڪشن لاگن جي درخواست ڪندو جتي اهو روڪيو ويو، پر اهي ماسٽر تي نه هوندا. ۽ نقل به ڳنڍڻ جي قابل نه هوندا. ان ڪري، اسان رسالن جو وڏو ذخيرو رکون ٿا.
اسان وٽ پيداوار جو بنياد آهي. اڳ ۾ ئي منصوبا جاري آهن.
اتي هڪ فائيلر هو. اسان اندر وياسين ۽ ڏٺوسين - سڀڪنھن شيءِ جي ترتيب ۾ آھي، نقل جڳه ۾ آھن، نقل ڪرڻ ۾ ڪا به دير نه آھي. لاگن ۾ ڪا به غلطي نه آهي، هر شيء ترتيب ۾ آهي.
پراڊڪٽ ٽيم جو چوڻ آهي ته ڪجهه ڊيٽا هجڻ گهرجي، پر اسان ان کي هڪ ذريعو مان ڏسون ٿا، پر اسان ان کي ڊيٽابيس ۾ نه ٿا ڏسو. ۽ اسان کي اهو سمجهڻ گهرجي ته انهن سان ڇا ٿيو.
اهو واضح آهي ته pg_rewind انهن کي ياد ڪيو. اسان هڪدم اها ڳالهه سمجهي وياسين، پر ڏسڻ وياسين ته ڇا ٿي رهيو آهي.
لاگن ۾، اسان هميشه ڳولي سگهون ٿا ته فائلر ڪڏهن ٿيو، جيڪو ماسٽر ٿيو، ۽ اسان اهو طئي ڪري سگهون ٿا ته پراڻو ماسٽر ڪير هو ۽ جڏهن هو ريپليڪا ٿيڻ چاهي ٿو، يعني اسان کي انهن لاگز جي ضرورت آهي ته ٽرانزيڪشن لاگ جي رقم کي ڳولڻ لاء. گم ٿي ويو.
اسان جو پراڻو ماسٽر ريبوٽ ڪيو آهي. ۽ Patroni autorun ۾ رجسٽر ٿيو. Patroni شروع ڪيو. ان کان پوء هن Postgres شروع ڪيو. وڌيڪ واضح طور تي، پوسٽ گريس شروع ڪرڻ کان اڳ ۽ ان کي نقل ڪرڻ کان اڳ، پيٽروني شروع ڪيو pg_rewind عمل. ان جي مطابق، هن ٽرانزيڪشن لاگز جو حصو ختم ڪيو، نئون ڊائون لوڊ ڪيو ۽ ڳنڍيل. هتي Patroni هوشيار ڪم ڪيو، اهو آهي، جيئن توقع ڪئي وئي. ڪلستر بحال ڪيو ويو آهي. اسان وٽ 3 نوڊس آھن، فائلر 3 نوڊس کان پوء - سڀ ڪجھ ٿڌو آھي.
اسان ڪجھ ڊيٽا وڃائي ڇڏيو آھي. ۽ اسان کي اهو سمجهڻ گهرجي ته اسان ڪيترو وڃائي ڇڏيو آهي. اسان صرف ان لمحي کي ڳولي رهيا آهيون جڏهن اسان کي واپس ڪيو ويو هو. اسان ان کي اهڙي جرنل داخلن ۾ ڳولي سگهون ٿا. ريوائنڊ شروع ٿيو، اتي ڪجهه ڪيو ۽ ختم ٿيو.
اسان کي ٽرانزيڪشن لاگ ۾ پوزيشن ڳولڻ جي ضرورت آهي جتي پراڻو ماسٽر ڇڏي ويو. هن معاملي ۾، هي نشان آهي. ۽ اسان کي هڪ ٻيو نشان جي ضرورت آهي، اهو آهي، فاصلو جنهن جي ذريعي پراڻي ماسٽر نئين کان مختلف آهي.
اسان عام pg_wal_lsn_diff وٺون ٿا ۽ انھن ٻن نشانين جو مقابلو ڪريون ٿا. ۽ انهي صورت ۾، اسان 17 ميگا بائيٽ حاصل ڪندا آهيون. تمام گهڻو يا ٿورو، هرڪو پاڻ لاء فيصلو ڪري ٿو. ڇاڪاڻ ته ڪنهن لاءِ 17 ميگا بائيٽ گهڻو نه آهي، ڪنهن لاءِ اهو تمام گهڻو ۽ ناقابل قبول آهي. هتي، هر فرد پنهنجي لاء ڪاروبار جي ضرورتن جي مطابق طئي ڪري ٿو.
پر اسان پاڻ لاءِ ڇا ڳولي ورتو آهي؟
پهرين، اسان کي پاڻ لاء فيصلو ڪرڻ گهرجي - ڇا اسان کي هميشه سسٽم ريبوٽ کان پوء خودڪار شروع ڪرڻ لاء Patroni جي ضرورت آهي؟ اڪثر ائين ٿيندو آهي ته اسان کي پراڻي ماسٽر وٽ وڃڻو پوندو آهي، ڏسو ته هو ڪيترو پري ويو آهي. شايد ٽرانزيڪشن لاگ جي حصن جو معائنو ڪريو، ڏسو ته اتي ڇا آھي. ۽ سمجھڻ لاء ته ڇا اسان ھن ڊيٽا کي وڃائي سگھون ٿا يا ڇا اسان کي پراڻي ماسٽر کي اسٽينڊل موڊ ۾ هلائڻ جي ضرورت آھي ھن ڊيٽا کي ڪڍڻ لاء.
۽ صرف ان کان پوء اسان کي اهو فيصلو ڪرڻ گهرجي ته ڇا اسان هن ڊيٽا کي رد ڪري سگهون ٿا يا اسان ان کي بحال ڪري سگهون ٿا، هن نوڊ کي اسان جي ڪلستر کي نقل جي طور تي ڳنڍي.
ان کان علاوه، ھڪڙو "maximum_lag_on_failover" پيٽرولر آھي. ڊفالٽ طور، جيڪڏهن منهنجي ياداشت مون کي ڪم ڪري ٿي، هن پيٽرولر جي قيمت 1 ميگا بائيٽ آهي.
هو ڪيئن ڪم ڪندو آهي؟ جيڪڏهن اسان جي نقل 1 ميگا بائيٽ ڊيٽا جي نقل جي وقفي ۾ پوئتي آهي، ته پوء هي نقل چونڊن ۾ حصو نه وٺندو. ۽ جيڪڏهن اوچتو هڪ فائيل اوور آهي، Patroni ڏسجي ٿو ته ڪهڙيون نقلون پوئتي پيل آهن. جيڪڏهن اهي ٽرانزيڪشن لاگن جي وڏي تعداد جي پويان آهن، اهي ماسٽر نه ٿي سگهن. هي هڪ تمام سٺو سيڪيورٽي خاصيت آهي جيڪو توهان کي تمام گهڻو ڊيٽا وڃائڻ کان روڪي ٿو.
پر اتي ھڪڙو مسئلو آھي ته پيٽروني ڪلستر ۽ ڊي سي ايس ۾ نقل جي وقفي ھڪڙي خاص وقفي تي اپڊيٽ ڪئي وئي آھي. مان سمجهان ٿو 30 سيڪنڊ ڊفالٽ ttl قدر آهي.
ان جي مطابق، اتي هڪ صورتحال ٿي سگهي ٿي جتي DCS ۾ ريپليڪس لاء هڪ replication lag آهي، پر حقيقت ۾ اتي هڪ مڪمل طور تي مختلف وقفو ٿي سگهي ٿو يا اتي ڪا به دير نه ٿي سگهي ٿي، يعني اها شيء حقيقي وقت ناهي. ۽ اهو هميشه حقيقي تصوير کي ظاهر نٿو ڪري. ۽ ان تي فينسي منطق ڪرڻ جي قابل ناهي.
۽ نقصان جو خطرو هميشه رهي ٿو. ۽ بدترين صورت ۾، هڪ فارمولا، ۽ اوسط صورت ۾، ٻيو فارمولا. اهو آهي، جڏهن اسان پيٽروني تي عمل ڪرڻ جو منصوبو ٺاهيو ۽ اندازو لڳايو ته اسان ڪيترو ڊيٽا وڃائي سگهون ٿا، اسان کي انهن فارمولن تي ڀروسو ڪرڻ گهرجي ۽ تقريبا تصور ڪرڻ گهرجي ته اسان ڪيترو ڊيٽا وڃائي سگهون ٿا.
۽ اتي سٺي خبر آهي. جڏهن پراڻو ماسٽر اڳتي وڌي چڪو آهي، هو ڪجهه پس منظر جي عملن جي ڪري اڳتي وڌي سگهي ٿو. اهو آهي، اتي ڪجهه قسم جو autovacuum هو، هن ڊيٽا لکيو، انهن کي ٽرانزيڪشن لاگ ۾ محفوظ ڪيو. ۽ اسان آساني سان نظرانداز ڪري سگھون ٿا ۽ هن ڊيٽا کي وڃائي سگهون ٿا. ان ۾ ڪو مسئلو ناهي.
۽ اهو ڪيئن لاگ ان وانگر نظر اچي ٿو جيڪڏهن وڌ ۾ وڌ_lag_on_failover سيٽ ڪيو ويو آهي ۽ هڪ فائيلر اچي چڪو آهي، ۽ توهان کي نئين ماسٽر چونڊڻ جي ضرورت آهي. ريپليڪا پاڻ کي چونڊن ۾ حصو وٺڻ جي قابل نه سمجهي. ۽ هوء اڳواڻ جي نسل ۾ حصو وٺڻ کان انڪار ڪري ٿي. ۽ هوء هڪ نئين ماسٽر جي چونڊ ٿيڻ جو انتظار ڪري ٿي، انهي ڪري ته هوء ان سان ڳنڍي سگهي ٿي. هي ڊيٽا نقصان جي خلاف هڪ اضافي ماپ آهي.
هتي اسان وٽ هڪ پراڊڪٽ ٽيم آهي جنهن لکيو آهي ته انهن جي پيداوار پوسٽ گريس سان مسئلو آهي. ساڳئي وقت، ماسٽر پاڻ تائين رسائي نه ٿو ڪري سگھجي، ڇاڪاڻ ته اهو SSH ذريعي دستياب ناهي. ۽ خودڪار فائل به نه ٿي ٿئي.
هن ميزبان کي مجبور ڪيو ويو ته ريبوٽ. ريبوٽ جي ڪري، هڪ خودڪار فائل ٿيو، جيتوڻيڪ اهو ممڪن هو ته هڪ دستي آٽو فائل ڪرڻ، جيئن مان هاڻي سمجهان ٿو. ۽ ريبوٽ کان پوء، اسان اڳ ۾ ئي ڏسڻ وارا آهيون ته اسان وٽ موجوده ماسٽر سان ڇا هو.
ساڳئي وقت، اسان اڳ ۾ ئي ڄاڻون ٿا ته اسان وٽ ڊسڪ سان مسئلا هئا، اهو آهي، اسان اڳ ۾ ئي ڄاڻون ٿا ته مانيٽرنگ کان ڪٿي کڏڻ ۽ ڇا ڳولڻ لاء.
اسان پوسٽ گريس لاگ ۾ وياسين، ڏسڻ شروع ڪيو ته اتي ڇا ٿي رهيو آهي. اسان ڏٺا ڪميٽ جيڪي اتي هڪ، ٻه، ٽي سيڪنڊن لاءِ آهن، جيڪي بلڪل عام ناهن. اسان ڏٺو ته اسان جو آٽو ويڪيوم تمام سست ۽ عجيب انداز سان شروع ٿئي ٿو. ۽ اسان ڊسڪ تي عارضي فائلون ڏٺيون. اهو آهي، اهي ڊسڪ سان مسئلن جا سڀ اشارا آهن.
اسان سسٽم ۾ ڏٺو dmesg (kernel log). ۽ اسان ڏٺو ته اسان وٽ هڪ ڊسڪ سان مسئلو آهي. ڊسڪ سبسسٽم سافٽ ويئر ريڊ هو. اسان /proc/mdstat تي ڏٺو ۽ ڏٺو ته اسان هڪ ڊرائيو وڃائي رهيا آهيون. اهو آهي، اتي 8 ڊسڪ جو هڪ حملو آهي، اسان هڪ غائب آهيون. جيڪڏھن توھان غور سان سلائڊ کي ڏسو، پوءِ ٻاھرين ۾ توھان ڏسي سگھوٿا ته اسان وٽ sde نه آھي. اسان وٽ، مشروط طور تي ڳالهائڻ، ڊسڪ ڪڍي ڇڏيو آهي. اهو ڊسڪ مسئلن کي ڇڪايو، ۽ ايپليڪيشنون پڻ مشڪلاتن جو تجربو ڪيو جڏهن پوسٽ گريس ڪلستر سان ڪم ڪري رهيو آهي.
۽ انهي صورت ۾، Patroni اسان کي ڪنهن به طريقي سان مدد نه ڪندو، ڇاڪاڻ ته Patroni سرور جي حالت جي نگراني ڪرڻ جو ڪم نه آهي، ڊسڪ جي حالت. ۽ اسان کي گهرجي ته اهڙين حالتن کي ٻاهرين نگراني ذريعي مانيٽر ڪريون. اسان جلدي شامل ڪيو ڊسڪ مانيٽرنگ کي خارجي نگراني ۾.
۽ اتي هڪ اهڙي سوچ هئي - ڇا باهه يا واچ ڊاگ سافٽ ويئر اسان جي مدد ڪري سگهي ٿي؟ اسان جو خيال هو ته هن معاملي ۾ اسان جي مشڪل سان مدد ڪئي هوندي، ڇاڪاڻ ته مسئلن دوران پتروني ڊي سي ايس ڪلسٽر سان رابطو ڪندو رهيو ۽ کيس ڪو به مسئلو نظر نه آيو. اهو آهي، DCS ۽ Patroni جي نقطي نظر کان، ڪلستر سان هر شيء ٺيڪ هئي، جيتوڻيڪ حقيقت ۾ ڊسڪ سان مسئلا هئا، ڊيٽابيس جي دستيابي سان مسئلا هئا.
منهنجي خيال ۾، هي هڪ عجيب مسئلو آهي جنهن تي مون هڪ ڊگهي وقت تائين تحقيق ڪئي آهي، مون تمام گهڻو لاگ پڙهيو آهي، ٻيهر چونڊيو آهي ۽ ان کي ڪلستر سموليٽر سڏيو آهي.
مسئلو اهو هو ته پراڻي ماسٽر هڪ عام نقل نه ٿي سگهي، يعني پيٽروني ان کي شروع ڪيو، پيٽروني ظاهر ڪيو ته هي نوڊ هڪ نقل جي طور تي موجود هو، پر ساڳئي وقت اهو هڪ عام نقل نه هو. هاڻي توهان ڏسندا ته ڇو. اھو اھو آھي جيڪو مون ان مسئلي جي تجزيو کان رکيو آھي.
۽ اهو سڀ ڪيئن شروع ٿيو؟ اهو شروع ٿيو، جيئن اڳئين مسئلي ۾، ڊسڪ برڪ سان. اسان هڪ سيڪنڊ لاءِ ڪم ڪيو هو، ٻه.
رابطا ٽوڙيا ويا، يعني گراهڪ ٽٽي ويا.
اتي مختلف شدت جي رڪاوٽون هيون.
۽، مطابق، ڊسڪ سب سسٽم تمام جوابدار نه آهي.
۽ مون لاءِ سڀ کان وڌيڪ پراسرار شيءِ آهي فوري بند ٿيڻ جي درخواست جيڪا پهچي وئي. Postgres ۾ ٽي شٽ ڊائون موڊ آھن:
- اھو مھربان آھي جڏھن اسان انتظار ڪندا آھيون سڀ ڪلائنٽ پنھنجي پاڻ کان ڌار ٿيڻ لاءِ.
- اتي تيز آهي جڏهن اسان گراهڪ کي ڊسڪنيڪٽ ڪرڻ تي مجبور ڪندا آهيون ڇو ته اسان بند ٿيڻ وارا آهيون.
- ۽ فوري. انهي صورت ۾، فوري طور تي گراهڪ کي بند ڪرڻ لاء به نه ٻڌائيندو آهي، اهو صرف بغير ڪنهن ڊيڄاريندڙ کي بند ڪري ٿو. ۽ سڀني ڪلائنٽ ڏانهن، آپريٽنگ سسٽم اڳ ۾ ئي هڪ RST پيغام موڪلي ٿو (هڪ TCP پيغام جيڪو ڪنيڪشن ۾ مداخلت آهي ۽ ڪلائنٽ کي پڪڙڻ لاء وڌيڪ ڪجهه ناهي).
هي سگنل ڪنهن موڪليو؟ پوسٽ گريس پس منظر وارا عمل هڪ ٻئي ڏانهن اهڙا سگنل نه موڪليندا آهن، يعني هي آهي kill-9. اهي اهڙيون شيون هڪ ٻئي ڏانهن نه موڪليندا آهن، اهي صرف اهڙين شين تي رد عمل ڪندا آهن، يعني هي پوسٽ گريس جي هڪ هنگامي بحالي آهي. ڪنهن موڪليو، مون کي خبر ناهي.
مون ”آخري“ ڪمانڊ ڏانھن ڏٺو ۽ مون ھڪڙي ماڻھوءَ کي ڏٺو، جيڪو پڻ اسان سان گڏ ھن سرور ۾ لاگ اِن ٿيو ھو، پر مون کي ھڪ سوال پڇڻ ۾ ڏاڍو شرم آيو. شايد اهو قتل هو -9. مان لاگن ۾ مار -9 ڏسندو، ڇاڪاڻ ته پوسٽ گريس چوي ٿو ته ان کي ماريو ويو -9، پر مون ان کي لاگ ان ۾ نه ڏٺو.
اڳتي ڏسندي ڏٺم ته Patroni 54 سيڪنڊن لاءِ ڪافي عرصي کان لاگ ۾ نه لکيو هو. ۽ جيڪڏھن اسان ٻن ٽائم اسٽيمپن جو مقابلو ڪريون، اٽڪل 54 سيڪنڊن لاءِ ڪوبه پيغام نه ھو.
۽ ان دوران اتي هڪ autofile هو. Patroni هتي ٻيهر هڪ عظيم ڪم ڪيو. اسان جو پوڙهو ماستر موجود نه هو، کيس ڪجهه ٿيو. ۽ نئين ماسٽر جي چونڊ شروع ٿي. هتي هر شي چڱي طرح ڪم ڪيو. اسان جو pgsql01 نئون ليڊر بڻجي ويو آهي.
اسان وٽ هڪ نقل آهي جيڪو هڪ ماسٽر بڻجي چڪو آهي. ۽ ٻيو جواب آهي. ۽ ٻئي نقل سان مسئلا هئا. هوء ٻيهر ترتيب ڏيڻ جي ڪوشش ڪئي. جيئن ته مان سمجهان ٿو، هوء recovery.conf کي تبديل ڪرڻ جي ڪوشش ڪئي، پوسٽ گريس کي ٻيهر شروع ڪيو ۽ نئين ماسٽر سان ڳنڍيو. هوءَ هر 10 سيڪنڊن ۾ پيغام لکندي آهي ته هوءَ ڪوشش ڪري رهي آهي، پر هوءَ ڪامياب نه ٿي رهي آهي.
۽ انهن ڪوششن دوران، هڪ فوري بند سگنل پراڻي ماسٽر تي اچي ٿو. ماسٽر ٻيهر شروع ڪيو ويو آهي. ۽ بحالي پڻ روڪي ٿي ڇو ته پراڻي ماسٽر ريبوٽ ۾ وڃي ٿي. اهو آهي، نقل ان سان ڳنڍي نٿو سگهي، ڇاڪاڻ ته اهو بند موڊ ۾ آهي.
ڪجهه نقطي تي، اهو ڪم ڪيو، پر نقل شروع نه ٿيو.
منهنجو صرف اندازو آهي ته recovery.conf ۾ هڪ پراڻو ماسٽر ايڊريس هو. ۽ جڏهن هڪ نئون ماسٽر ظاهر ٿيو، ٻيو نقل اڃا تائين پراڻي ماسٽر سان ڳنڍڻ جي ڪوشش ڪئي.
جڏهن پيٽروني ٻئي نقل تي شروع ڪيو، نوڊ شروع ڪيو پر نقل نه ٿي سگهيو. ۽ هڪ نقلي وقفو ٺهرايو ويو، جيڪو ڪجهه هن طرح ڏٺو. يعني، ٽيئي نوڊ پنهنجي جاءِ تي هئا، پر ٻيو ڪونڊ پوئتي رهجي ويو.
ساڳئي وقت، جيڪڏهن توهان انهن لاگن تي نظر رکون ٿا جيڪي لکيل هئا، توهان ڏسي سگهو ٿا ته نقل شروع نه ٿي سگهيو آهي ڇاڪاڻ ته ٽرانزيڪشن لاگ مختلف هئا. ۽ اهي ٽرانزيڪشن لاگز جيڪي ماسٽر پيش ڪري ٿو، جيڪي recovery.conf ۾ بيان ڪيا ويا آهن، بس اسان جي موجوده نوڊ کي مناسب نه ٿا ڪن.
۽ هتي مون هڪ غلطي ڪئي. مون کي اچڻو هو ۽ ڏسڻو هو ته recovery.conf ۾ ڇا آهي منهنجي مفروضي کي جانچڻ لاءِ ته اسان غلط ماسٽر سان ڳنڍي رهيا آهيون. پر پوءِ مان صرف ان سان معاملو ڪري رهيو هوس ۽ اهو مون کي نه ٿيو، يا مون ڏٺو ته نقل پوئتي رهجي وئي هئي ۽ ان کي ٻيهر ڀرڻو پوندو، يعني مون ڪنهن نه ڪنهن طرح لاپرواهي سان ڪم ڪيو. هي منهنجو گڏيل هو.
30 منٽن کان پوء، منتظم اڳ ۾ ئي آيو، يعني مون ريپليڪا تي Patroni کي ٻيهر شروع ڪيو. مون اڳ ۾ ئي ان کي ختم ڪيو، مون سوچيو ته ان کي ٻيهر ڀرڻو پوندو. ۽ مون سوچيو - مان پيٽروني کي ٻيهر شروع ڪندس، شايد ڪجهه سٺو نڪرندو. بحالي شروع ٿي. ۽ بنياد پڻ کوليو ويو، اهو ڪنيڪشن قبول ڪرڻ لاء تيار هو.
نقل شروع ٿي چڪو آهي. پر هڪ منٽ بعد، هوء هڪ غلطي سان بند ٿي وئي ته ٽرانزيڪشن لاگ ان لاء مناسب نه آهن.
مون سوچيو ته مان ٻيهر شروع ڪندس. مون پيٽروني کي ٻيهر شروع ڪيو، ۽ مون پوسٽ گريس کي ٻيهر شروع نه ڪيو، پر پيٽروني کي ان اميد ۾ ٻيهر شروع ڪيو ته اهو ڊيٽابيس کي جادوئي طور تي شروع ڪندو.
نقل ٻيهر شروع ٿيو، پر ٽرانزيڪشن لاگ ۾ نشان مختلف هئا، اهي اڳئين شروعاتي ڪوشش وانگر نه هئا. نقل ٻيهر بند ٿي وئي. ۽ پيغام اڳ ۾ ئي ٿورو مختلف هو. ۽ اهو مون لاء تمام معلوماتي نه هو.
۽ پوءِ اهو مون سان ٿئي ٿو - ڇا جيڪڏهن آئون پوسٽ گريس کي ٻيهر شروع ڪريان ، هن وقت آئون موجوده ماسٽر تي هڪ چيڪ پوائنٽ ٺاهيان ٿو ته ٽرانزيڪشن لاگ ۾ پوائنٽ کي ٿورو اڳتي وڌايو ته جيئن بحالي ڪنهن ٻئي لمحي کان شروع ٿئي؟ ان سان گڏ، اسان وٽ اڃا تائين WAL جو اسٽاڪ هو.
مون پيٽروني کي ٻيهر شروع ڪيو، ماسٽر تي ٻه چيڪ پوائنٽس ڪيا، ريپليڪا تي ٻه ريسٽارٽ پوائنٽون جڏهن اهو کوليو. ۽ اها مدد ڪئي. مون هڪ ڊگهي وقت تائين سوچيو ته اهو ڇو مدد ڪئي ۽ اهو ڪيئن ڪم ڪيو. ۽ نقل شروع ڪيو. ۽ نقل هاڻي ٽٽي نه وئي هئي.
مون لاءِ اهڙو مسئلو هڪ وڌيڪ پراسرار مسئلو آهي، جنهن تي مان اڃا تائين حيران آهيان ته اتي ڇا ٿيو هو.
هتي ڪهڙا اثر آهن؟ Patroni ارادي طور ڪم ڪري سگهي ٿو ۽ بغير ڪنهن غلطي جي. پر ساڳئي وقت، اهو هڪ 100٪ گارنٽي ناهي ته هر شي اسان سان ٺيڪ آهي. ريپليڪا شروع ٿي سگھي ٿي، پر اھو ٿي سگھي ٿو نيم ڪم ڪندڙ حالت ۾، ۽ ايپليڪيشن اھڙي ريپليڪا سان ڪم نه ڪري سگھي، ڇاڪاڻ ته اتي پراڻي ڊيٽا ھوندي.
۽ فائلر کان پوء، توهان کي هميشه چيڪ ڪرڻ جي ضرورت آهي ته هر شي ڪلستر سان ترتيب ۾ آهي، اهو آهي، نقلن جو گهربل تعداد آهي، نقل ڪرڻ ۾ ڪا دير ناهي.
۽ جيئن ته اسان انهن مسئلن ذريعي وڃون ٿا، آئون سفارشون ڪندس. مون انهن کي ٻن سلائڊن ۾ گڏ ڪرڻ جي ڪوشش ڪئي. ممڪن آهي ته، سڀني ڪهاڻين کي ٻن سلائڊن ۾ گڏ ڪري صرف ٻڌايو وڃي.
جڏهن توهان Patroni استعمال ڪريو ٿا، توهان کي نگراني ڪرڻ گهرجي. توهان کي هميشه ڄاڻڻ گهرجي جڏهن هڪ آٽو فائيل اوور واقع ٿيو، ڇو ته جيڪڏهن توهان کي خبر ناهي ته توهان وٽ هڪ آٽو فائيل اوور آهي، توهان وٽ ڪلستر تي ڪو به ڪنٽرول ناهي. ۽ اهو خراب آهي.
هر فائلر کان پوء، اسان کي هميشه دستي طور تي ڪلستر چيڪ ڪرڻو پوندو. اسان کي پڪ ڪرڻ جي ضرورت آهي ته اسان وٽ هميشه ريپليڪس جو هڪ تازه ترين نمبر آهي، نقل ڪرڻ ۾ ڪا به دير ناهي، اسٽريمنگ ريپليڪشن سان لاڳاپيل لاگز ۾ ڪا به غلطي ناهي، پيٽروني سان، ڊي سي ايس سسٽم سان.
خودڪار طريقي سان ڪم ڪري سگهي ٿو، Patroni هڪ تمام سٺو اوزار آهي. اهو ڪم ڪري سگهي ٿو، پر اهو ڪلستر کي گهربل حالت ۾ نه آڻيندو. ۽ جيڪڏھن اسان کي ان جي باري ۾ معلوم نه ڪندا آھن، اسان کي مصيبت ۾ ٿيندو.
۽ Patroni چانديء جي گولي نه آهي. اسان کي اڃا تائين سمجهڻ جي ضرورت آهي ته پوسٽ گريس ڪيئن ڪم ڪري ٿو، نقل ڪيئن ڪم ڪري ٿو ۽ ڪيئن پيٽروني پوسٽ گريس سان ڪم ڪري ٿو، ۽ نوڊس جي وچ ۾ رابطي کي ڪيئن مهيا ڪيو ويو آهي. اهو ضروري آهي ته توهان جي هٿن سان مسئلا حل ڪرڻ جي قابل ٿي وڃي.
مان تشخيص جي مسئلي کي ڪيئن حاصل ڪري سگهان ٿو؟ اهو ائين ٿيو آهي ته اسان مختلف ڪلائنٽ سان ڪم ڪريون ٿا ۽ ڪنهن وٽ به ELK اسٽيڪ ناهي، ۽ اسان کي 6 ڪنسولز ۽ 2 ٽيب کولڻ سان لاگ ان کي ترتيب ڏيڻو پوندو. هڪ ٽيب ۾، اهي آهن Patroni لاگ هر نوڊ لاءِ، ٻئي ٽئب ۾، اهي آهن ڪنسل لاگز، يا ضروري هجي ته Postgres. هن جي تشخيص ڪرڻ تمام ڏکيو آهي.
مون ڪھڙا طريقا ٺاھيا آھن؟ پهريون، مان هميشه ڏسان ٿو جڏهن فائيلر اچي چڪو آهي. ۽ منهنجي لاءِ هي پاڻي آهي. مان ڏسان ٿو ته فائلر کان اڳ، فائلر جي دوران ۽ فائلر کان پوء ڇا ٿيو. فائل اوور جا ٻه نشان آهن: هي آهي شروعات ۽ آخري وقت.
اڳيون، مان فائلر کان اڳ واقعن جي لاگن ۾ ڏسان ٿو، جيڪي فائلر کان اڳ آھن، يعني مان انھن سببن کي ڳوليان ٿو ڇو ته فائلر ٿيو.
۽ اهو سمجھڻ جي هڪ تصوير ڏئي ٿو ته ڇا ٿيو ۽ مستقبل ۾ ڇا ٿي سگهي ٿو ته جيئن اهڙيون حالتون نه هجن (۽ نتيجي طور، ڪو به فائيلر نه آهي).
۽ اسان عام طور تي ڪٿي ڏسون ٿا؟ مان ڏسان ٿو:
- پهريون، Patroni لاگن ڏانهن.
- اڳيون، مان پوسٽ گريس لاگز، يا ڊي سي ايس لاگز کي ڏسان ٿو، ان تي منحصر ڪري ٿو جيڪو پيٽروني لاگز ۾ مليو هو.
- ۽ سسٽم لاگ پڻ ڪڏهن ڪڏهن سمجھندا آهن ته فائيلر جو سبب ڇا آهي.
مان Patroni بابت ڪيئن محسوس ڪريان؟ پترونيءَ سان منهنجا سٺا تعلقات آهن. منهنجي خيال ۾، اهو سڀ کان بهتر آهي جيڪو اڄ آهي. مان ڪيترن ئي ٻين شين کي ڄاڻان ٿو. اهي آهن Stolon، Repmgr، Pg_auto_failover، PAF. 4 اوزار. مون انهن سڀني جي ڪوشش ڪئي. Patroni منهنجو پسنديده آهي.
جيڪڏهن اهي مون کان پڇن ٿا: "ڇا مان سفارش ڪريان ٿو Patroni؟". مان چوندس ها، ڇاڪاڻ ته مون کي پتروني پسند آهي. ۽ مان سمجهان ٿو ته مون سکيو ته ان کي ڪيئن پچائڻ.
جيڪڏھن توھان ڏسڻ ۾ دلچسپي رکو ٿا ته پيٽروني سان گڏ ٻيا مسئلا آھن جن جو مون ذڪر ڪيو آھي، توھان ھميشہ چيڪ ڪري سگھوٿا صفحو GitHub تي. اتي ڪيتريون ئي مختلف ڪهاڻيون آهن ۽ ڪيترائي دلچسپ مسئلا اتي بحث ٿيل آهن. ۽ نتيجي طور، ڪجھ ڪيڙا متعارف ڪرايا ويا ۽ حل ڪيا ويا، اھو آھي، اھو ھڪڙو دلچسپ پڙھڻ آھي.
ماڻهو پاڻ کي پيرن ۾ گوليون هڻڻ بابت ڪجهه دلچسپ ڪهاڻيون آهن. ڏاڍو معلوماتي. توهان پڙهو ۽ سمجھو ته ائين ڪرڻ ضروري ناهي. مون پاڻ کي چيڪ ڪيو.
۽ مان چوڻ چاهيان ٿو ته Zalando جي وڏي مهرباني جو هن منصوبي کي ترقي ڪرڻ لاء، يعني اليگزينڊر ڪوڪوشڪن ۽ Alexey Klyukin کي. Aleksey Klyukin هڪ ساٿي ليکڪ آهي، هو هاڻي Zalando ۾ ڪم نٿو ڪري، پر هي ٻه ماڻهو آهن جن هن پراڊڪٽ سان ڪم ڪرڻ شروع ڪيو آهي.
۽ مان سمجهان ٿو ته Patroni هڪ تمام سٺي شيء آهي. مان خوش آهيان ته هوء موجود آهي، ان سان گڏ دلچسپ آهي. ۽ وڏي مهرباني انهن سڀني مدد ڪندڙن جو جن Patroni تي پيچ لکيا. مون کي اميد آهي ته پيٽروني عمر سان گڏ وڌيڪ پختو، ٿڌو ۽ ڪارائتو ٿيندو. اهو اڳ ۾ ئي فنڪشنل آهي، پر مون کي اميد آهي ته اهو اڃا به بهتر ٿيندو. تنهن ڪري، جيڪڏهن توهان Patroni استعمال ڪرڻ جو ارادو ڪيو، پوء ڊپ نه ٿيو. اهو هڪ سٺو حل آهي، اهو لاڳو ۽ استعمال ڪري سگهجي ٿو.
اهو ئي سڀ ڪجهه آهي. جيڪڏھن توھان وٽ سوال آھن، پڇو.
توهان جا سوال
رپورٽ لاءِ مهرباني! جيڪڏهن هڪ فائلر کان پوء توهان کي اڃا تائين تمام احتياط سان ڏسڻ جي ضرورت آهي، پوء اسان کي خودڪار فائلر جي ضرورت ڇو آهي؟
ڇاڪاڻ ته اها نئين شيء آهي. اسان صرف هڪ سال لاء هن سان گڏ ڪيو ويو آهي. محفوظ ٿيڻ بهتر آهي. اسان اندر اچڻ چاهيون ٿا ۽ ڏسڻ چاهيون ٿا ته هر شي واقعي طريقي سان ڪم ڪيو جيئن ان کي گهرجي. هي بالغ بي اعتمادي جي سطح آهي - اهو بهتر آهي ته ٻه ڀيرا چيڪ ڪريو ۽ ڏسو.
مثال طور، اسان صبح جو ويا ۽ ڏٺو، صحيح؟
صبح جو نه، اسان عام طور تي آٽو فائل بابت تقريبا فوري طور تي سکندا آهيون. اسان نوٽيفڪيشن وصول ڪندا آهيون، اسان ڏسون ٿا ته هڪ خودڪار فائل ٿي چڪي آهي. اسان تقريبن فوري طور تي وڃو ۽ ڏسو. پر انهن سڀني چيڪن کي مانيٽرنگ ليول تي آندو وڃي. جيڪڏهن توهان رسائي ڪريو Patroni ذريعي REST API، اتي هڪ تاريخ آهي. تاريخ جي ذريعي توهان ڏسي سگهو ٿا ٽائيم اسٽيمپس جڏهن فائلر ٿيو. ان جي بنياد تي، نگراني ڪري سگهجي ٿو. تاريخ ڏسو، ڪيترا واقعا ٿيا. جيڪڏهن اسان وٽ وڌيڪ واقعا آهن، ته پوء هڪ خودڪار فائل ٿي چڪي آهي. توهان وڃو ۽ ڏسي سگهو ٿا. يا اسان جي مانيٽرنگ آٽوميشن چيڪ ڪيو ته اسان وٽ سڀئي نقل آهن، اتي ڪا دير ناهي ۽ سڀ ڪجهه ٺيڪ آهي.
مهرباني
عظيم ڪهاڻي لاء تمام گهڻو مهرباني! جيڪڏهن اسان DCS ڪلسٽر کي پوسٽ گريس ڪلستر کان پري ڪنهن هنڌ منتقل ڪيو ته پوءِ هن ڪلسٽر کي به وقتي طور تي سروس ڪرڻ جي ضرورت آهي؟ ڪھڙا بھترين طريقا آھن جيڪي DCS ڪلستر جي ڪجھ ٽڪرن کي بند ڪرڻ جي ضرورت آھي، انھن سان ڪجھھ ڪيو وڃي، وغيره؟ هي سڄو ڍانچو ڪيئن بچندو؟ ۽ توهان اهي شيون ڪيئن ٿا ڪريو؟
ھڪڙي ڪمپني لاء، اھو ضروري آھي ته مسئلن جو ھڪڙو ميٽرڪس ٺاھيو، ڇا ٿيندو جيڪڏھن ھڪڙو اجزاء يا ڪيترائي حصا ناڪام ٿين. هن ميٽرڪس جي مطابق، اسان ترتيب سان سڀني حصن جي ذريعي وڃون ٿا ۽ انهن حصن جي ناڪامي جي صورت ۾ منظرنامو ٺاهيندا آهيون. انهي جي مطابق، هر ناڪامي جي صورتحال لاء، توهان کي وصولي لاء هڪ عمل جو منصوبو حاصل ڪري سگهو ٿا. ۽ DCS جي صورت ۾، اهو اچي ٿو معياري زيربنا جو حصو. ۽ منتظم ان کي سنڀاليندو آهي، ۽ اسان اڳ ۾ ئي انهن منتظمين تي ڀروسو ڪندا آهيون جيڪي ان جو انتظام ڪن ٿا ۽ حادثن جي صورت ۾ ان کي درست ڪرڻ جي صلاحيت رکن ٿا. جيڪڏهن ڪو به ڊي سي ايس ناهي، ته پوءِ اسان ان کي ترتيب ڏيون ٿا، پر ساڳئي وقت اسان ان جي نگراني نٿا ڪريون، ڇاڪاڻ ته اسان انفراسٽرڪچر جا ذميوار نه آهيون، پر اسان سفارشون ڏيون ٿا ته ڪيئن ۽ ڪهڙي نگراني ڪجي.
اھو آھي، ڇا مون صحيح طور تي سمجھيو آھي ته مون کي پيٽروني کي غير فعال ڪرڻ، فائلر کي غير فعال ڪرڻ، ميزبان سان ڪجھھ ڪرڻ کان پھريان سڀڪنھن شيء کي غير فعال ڪرڻ جي ضرورت آھي؟
اهو منحصر آهي ته اسان وٽ ڊي سي ايس ڪلستر ۾ ڪيترا نوڊس آهن. جيڪڏهن ڪيترائي نوڊس آهن ۽ جيڪڏهن اسان صرف هڪ نوڊس کي بند ڪريون ٿا (ريپليڪا)، ته ڪلستر هڪ ڪورم برقرار رکي ٿو. ۽ Patroni آپريشنل رهي ٿو. ۽ ڪجھ به نه ٺهيو. جيڪڏهن اسان وٽ ڪي پيچيده عمل آهن جيڪي وڌيڪ نوڊس کي متاثر ڪن ٿا، جن جي غير موجودگي ڪورم کي خراب ڪري سگهي ٿي، ته پوءِ - ها، پيٽروني کي روڪڻ جو مطلب ٿي سگهي ٿو. ان ۾ هڪ لاڳاپيل حڪم آهي - patronictl pause، patronictl resume. اسان صرف روڪيو ۽ آٽو فائلر ان وقت ڪم نٿو ڪري. اسان ڊي سي ايس ڪلستر تي سار سنڀال ڪندا آهيون، پوء اسان روڪي ڇڏيو ۽ جيئرو جاري رکون ٿا.
توهان جي مهرباني
توهان جي رپورٽ لاء تمام گهڻو مهرباني! ڊيٽا جي گم ٿيڻ بابت پراڊڪٽ ٽيم ڪيئن محسوس ڪري ٿي؟
پراڊڪٽ ٽيمن کي پرواه ناهي، ۽ ٽيم جا اڳواڻ پريشان آهن.
اتي ڪهڙيون ضمانتون آهن؟
ضمانتون ڏاڍا ڏکيا آهن. اليگزينڊر ڪوڪوشڪن وٽ هڪ رپورٽ آهي “ڪيئن حساب ڪجي RPO ۽ RTO”، يعني وصولي جو وقت ۽ اسان ڪيترو ڊيٽا وڃائي سگهون ٿا. منهنجو خيال آهي ته اسان کي اهي سلائڊ ڳولڻ گهرجن ۽ انهن جو مطالعو ڪرڻ گهرجي. جيتري قدر مون کي ياد آهي، انهن شين کي ڪيئن ڳڻڻ لاءِ مخصوص مرحلا آهن. اسان ڪيترا ٽرانزيڪشن وڃائي سگهون ٿا، ڪيترو ڊيٽا وڃائي سگهون ٿا. هڪ اختيار جي طور تي، اسان Patroni سطح تي هم وقت سازي جي نقل کي استعمال ڪري سگهون ٿا، پر هي هڪ ٻه طرفي تلوار آهي: اسان وٽ يا ته ڊيٽا جي قابل اعتماد آهي، يا اسان رفتار کي وڃائي ڇڏيو آهي. اتي هم وقت سازي نقل آهي، پر اهو پڻ ڊيٽا جي نقصان جي خلاف 100٪ تحفظ جي ضمانت نٿو ڏئي.
Alexey، وڏي رپورٽ لاء مهرباني! صفر سطح جي تحفظ لاءِ Patroni استعمال ڪرڻ سان ڪو تجربو؟ اهو آهي، هم وقت سازي اسٽينڊ سان گڏ؟ هي پهريون سوال آهي. ۽ ٻيو سوال. توھان مختلف حل استعمال ڪيا آھن. اسان استعمال ڪيو Repmgr، پر بغير آٽوفيلر، ۽ ھاڻي اسان آٽو فائلر شامل ڪرڻ جي منصوبابندي ڪري رھيا آھيون. ۽ اسان Patroni کي متبادل حل طور سمجهون ٿا. توهان Repmgr جي مقابلي ۾ فائدن جي طور تي ڇا چئي سگهو ٿا؟
پهريون سوال هم وقت سازي جي باري ۾ هو. هتي ڪو به هم وقت ساز نقل استعمال نٿو ڪري، ڇاڪاڻ ته هرڪو خوفزده آهي (ڪيترائي گراهڪ اڳ ۾ ئي استعمال ڪري رهيا آهن، اصول ۾، انهن ڪارڪردگي جي مسئلن کي نوٽيس نه ڪيو - اسپيڪر جو نوٽ). پر اسان پنهنجي لاءِ هڪ قاعدو ٺاهيو آهي ته هڪ هم وقت ساز ريپليڪيشن ڪلسٽر ۾ گهٽ ۾ گهٽ ٽي نوڊس هجڻ گهرجن، ڇاڪاڻ ته جيڪڏهن اسان وٽ ٻه نوڊس آهن ۽ جيڪڏهن ماسٽر يا ريپليڪا ناڪام ٿئي ٿي ته پوءِ پيٽروني هن نوڊ کي اسٽينڊل موڊ ۾ تبديل ڪري ٿو ته جيئن ايپليڪيشن جاري رهي. ڪم انهي حالت ۾، ڊيٽا جي نقصان جو خطرو آهي.
ٻئي سوال جي حوالي سان، اسان استعمال ڪيو آهي Repmgr ۽ اڃا تائين ڪجهه گراهڪن سان تاريخي سببن لاء. ڇا چئي سگهجي ٿو؟ Patroni باڪس مان هڪ آٽو فائلر سان گڏ اچي ٿو، Repmgr آٽو فائلر سان گڏ هڪ اضافي خصوصيت جي طور تي اچي ٿو جنهن کي فعال ٿيڻ جي ضرورت آهي. اسان کي هر نوڊ تي Repmgr ڊيمن کي هلائڻ جي ضرورت آهي ۽ پوء اسان خودڪار طريقي سان ترتيب ڏئي سگهون ٿا.
Repmgr چيڪ ڪري ٿو ته پوسٽ گريس نوڊس زنده آهن. Repmgr پروسيس هڪ ٻئي جي وجود جي جانچ ڪن ٿا، اهو هڪ تمام ڪارائتو طريقو ناهي. نيٽ ورڪ جي اڪيلائي جا پيچيده ڪيس ٿي سگهن ٿا جن ۾ هڪ وڏو Repmgr ڪلسٽر جدا ٿي سگهي ٿو ڪيترن ئي ننڍن ۾ ۽ ڪم جاري رکي. مان هڪ ڊگهي وقت تائين Repmgr جي پيروي نه ڪيو ويو آهي، شايد اهو طئي ڪيو ويو آهي ... يا شايد نه. پر ڊي سي ايس ۾ ڪلستر جي حالت بابت معلومات کي هٽائڻ، جيئن اسٽولون، پيٽروني ڪندو آهي، سڀ کان وڌيڪ قابل عمل اختيار آهي.
اليڪسي، مون وٽ هڪ سوال آهي، شايد هڪ لامر. پهرين مثالن مان هڪ ۾، توهان DCS کي مقامي مشين مان ريموٽ ميزبان ڏانهن منتقل ڪيو. اسان سمجهون ٿا ته نيٽ ورڪ هڪ اهڙي شيءِ آهي جنهن جون پنهنجون خاصيتون آهن، اهو پنهنجي مرضيءَ سان زندهه رهي ٿو. ۽ ڇا ٿيندو جيڪڏهن ڪنهن سبب جي ڪري ڊي سي ايس ڪلسٽر دستياب نه ٿي وڃي؟ مان سببن کي نه چوندس، انهن مان تمام گهڻو ٿي سگهي ٿو: نيٽ ورڪرز جي ڪڙي هٿن کان حقيقي مسئلن تائين.
مون ان کي زور سان نه چيو، پر ڊي سي ايس ڪلسٽر کي به ناڪام ٿيڻو پوندو، يعني اهو ڪورم پورو ڪرڻ لاءِ نوڊس جو بيحد تعداد آهي. ڇا ٿيندو جيڪڏهن ڊي سي ايس ڪلسٽر دستياب نه ٿي وڃي، يا ڪورم پورو نه ٿي سگهي، يعني ڪنهن قسم جي نيٽ ورڪ جي تقسيم يا نوڊ ناڪامي؟ انهي حالت ۾، پيٽروني ڪلستر صرف پڙهڻ واري موڊ ۾ وڃي ٿو. پيٽروني ڪلستر ڪلستر جي حالت جو تعين نٿو ڪري سگهي ۽ ڇا ڪجي. اهو DCS سان رابطو نٿو ڪري سگهي ۽ اتي نئين ڪلستر اسٽيٽ کي ذخيرو ڪري ٿو، تنهنڪري سڄو ڪلستر صرف پڙهڻ ۾ وڃي ٿو. ۽ انتظار ڪري ٿو يا ته آپريٽر کان دستي مداخلت لاءِ يا ڊي سي ايس جي بحالي لاءِ.
عام طور تي ڳالهائڻ، ڊي سي ايس اسان لاء هڪ خدمت بڻجي وڃي ٿي جيئن بنيادي طور تي اهم آهي؟
ها ها. ڪيترين ئي جديد ڪمپنين ۾، سروس دريافت انفراسٹرڪچر جو هڪ لازمي حصو آهي. ان تي عمل ڪيو پيو وڃي ان کان اڳ به انفراسٽرڪچر ۾ ڊيٽابيس موجود هو. نسبتا ڳالهائڻ، انفراسٽرڪچر شروع ڪيو ويو، ڊي سي ۾ مقرر ڪيو ويو، ۽ اسان کي فوري طور تي سروس دريافت ڪيو. جيڪڏهن اهو قونصلر آهي، ته پوء ڊي اين ايس ان تي ٺاهي سگهجي ٿو. جيڪڏهن اهو آهي Etcd، پوءِ ٿي سگهي ٿو ڪوبرنيٽس ڪلستر مان هڪ حصو، جنهن ۾ ٻيو سڀ ڪجهه لڳايو ويندو. اهو مون کي لڳي ٿو ته سروس دريافت اڳ ۾ ئي جديد انفراسٽرڪچر جو هڪ لازمي حصو آهي. ۽ اھي ان بابت سوچيندا آھن گھڻو اڳ ڊيٽابيس بابت.
مهرباني
جو ذريعو: www.habr.com