منهنجو مشورو آهي ته توهان 2016 جي شروعات کان رپورٽ جو ٽرانسڪرپٽ پڙهو آندري سالنيڪوف جي ”ايپليڪيشنن ۾ عام غلطيون جيڪي پوسٽ گريسڪ ايل ۾ بلوٽ جو سبب بڻجن ٿيون“
هن رپورٽ ۾، آئون ايپليڪيشنن ۾ بنيادي غلطين جو تجزيو ڪندس جيڪي ايپليڪيشن ڪوڊ ڊزائين ڪرڻ ۽ لکڻ جي مرحلي ۾ پيدا ٿين ٿيون. ۽ مان صرف اهي غلطيون وٺندس جيڪي پوسٽ گريسڪ ايل ۾ ڦوٽو آڻين ٿيون. ضابطي جي طور تي، هي مڪمل طور تي توهان جي سسٽم جي ڪارڪردگي جي آخر جي شروعات آهي، جيتوڻيڪ شروعاتي طور تي هن لاء ڪا به شرط نه هئي.
سڀني کي ڀليڪار ڪرڻ لاء خوش ٿيو! هي رپورٽ ٽيڪنيڪل نه آهي جيئن منهنجي ساٿي کان اڳئين هڪ. هي رپورٽ بنيادي طور تي پس منظر سسٽم ڊولپرز جو مقصد آهي ڇو ته اسان وٽ وڏي تعداد ۾ ڪلائنٽ آهن. ۽ اهي سڀئي ساڳيون غلطيون ڪندا آهن. مان توهان کي انهن بابت ٻڌايان ٿو. مان وضاحت ڪندس ته اهي غلطيون ڪهڙيون موتمار ۽ خراب شيون آڻين ٿيون.
غلطيون ڇو ڪيون ويون آهن؟ اهي ٻن سببن جي ڪري ڪيا ويا آهن: بي ترتيب تي، ٿي سگهي ٿو اهو ڪم ڪندو ۽ ڪجهه ميڪانيزم جي اڻ ڄاڻائي جي ڪري، جيڪي ڊيٽابيس ۽ ايپليڪيشن جي وچ ۾ سطح تي ٿين ٿا، انهي سان گڏ ڊيٽابيس ۾.
مان توهان کي خوفناڪ تصويرن سان ٽي مثال ڏيندس ته ڪيئن خراب شيون پيدا ٿيون. مان توهان کي مختصر طور تي ٻڌايان ٿو ميڪانيزم بابت جيڪو اتي ٿئي ٿو. ۽ انهن سان ڪيئن ڊيل ڪجي، جڏهن اهي ٿيا، ۽ غلطين کي روڪڻ لاءِ ڪهڙا بچاءُ وارا طريقا استعمال ڪيا وڃن. مان توهان کي مددگار اوزارن جي باري ۾ ٻڌايان ٿو ۽ مفيد لنڪ فراهم ڪندس.
مون هڪ ٽيسٽ ڊيٽابيس استعمال ڪيو جتي مون وٽ ٻه ٽيبل هئا. ھڪڙي پليٽ ڪسٽمر اڪائونٽن سان، ٻيو انھن اڪائونٽن تي ٽرانزيڪشن سان. ۽ ڪجهه تعدد سان اسان انهن اڪائونٽن تي بيلنس کي اپڊيٽ ڪندا آهيون.
پليٽ جي شروعاتي ڊيٽا: اهو ڪافي ننڍڙو آهي، 2 ايم بي. ڊيٽابيس لاءِ جوابي وقت ۽ خاص طور تي نشاني لاءِ پڻ تمام سٺو آهي. ۽ ڪافي سٺي لوڊ - پليٽ جي مطابق في سيڪنڊ 2 آپريشن.
۽ هن رپورٽ ذريعي مان توهان کي گراف ڏيکاريندس ته جيئن توهان واضح طور تي سمجهي سگهو ته ڇا ٿي رهيو آهي. ھميشه 2 سلائڊ گرافس سان گڏ ھوندا. پهرين سلائڊ اهو آهي جيڪو عام طور تي سرور تي ٿئي ٿو.
۽ هن صورتحال ۾، اسان ڏسون ٿا ته اسان وٽ واقعي هڪ ننڍڙو نشان آهي. انڊيڪس 2 MB تي ننڍو آهي. هي پهريون گراف آهي کاٻي پاسي.
سرور تي اوسط جوابي وقت پڻ مستحڪم ۽ مختصر آهي. هي مٿي ساڄي گراف آهي.
هيٺيون کاٻي گراف ڏيکاري ٿو ڊگهو ٽرانزيڪشن. اسان ڏسون ٿا ته ٽرانزيڪشن جلدي مڪمل ٿي ويا آهن. ۽ آٽو ويڪيوم اڃا هتي ڪم نٿو ڪري، ڇاڪاڻ ته اهو هڪ شروعاتي امتحان هو. اهو ڪم جاري رهندو ۽ اسان لاء مفيد ٿيندو.
ٻئي سلائڊ هميشه پليٽ جي آزمائش لاء وقف ڪئي ويندي. هن صورتحال ۾، اسان مسلسل ڪلائنٽ جي اڪائونٽ بيلنس کي اپڊيٽ ڪندا آهيون. ۽ اسان ڏسون ٿا ته تازه ڪاري آپريشن لاءِ اوسط جوابي وقت ڪافي سٺو آهي، هڪ مليسيڪنڊ کان به گهٽ. اسان ڏسون ٿا ته پروسيسر وسيلا (هي مٿي ساڄي گراف آهي) پڻ استعمال ڪيا ويا آهن هڪجهڙائي ۽ ڪافي ننڍا.
هيٺيون ساڄي گراف ڏيکاري ٿو ته ڪيتري آپريٽنگ ۽ ڊسڪ ميموري اسان ان کي اپڊيٽ ڪرڻ کان پهريان اسان جي گهربل لائن جي ڳولا ۾ وڃون ٿا. ۽ نشاني جي مطابق عملن جو تعداد 2 في سيڪنڊ آھي، جيئن مون شروع ۾ چيو آھي.
۽ هاڻي اسان وٽ هڪ سانحو آهي. ڪجهه سببن لاء هڪ ڊگهي وساري ٽرانزيڪشن آهي. عام طور تي سڀ سبب آهن:
- سڀ کان وڌيڪ عام مان هڪ آهي ته اسان ايپليڪيشن ڪوڊ ۾ هڪ خارجي خدمت تائين رسائي شروع ڪيو. ۽ هي خدمت اسان کي جواب نه ڏيندو. اهو آهي، اسان هڪ ٽرانزيڪشن کوليو، ڊيٽابيس ۾ تبديلي ڪئي ۽ ميل پڙهڻ يا اسان جي انفراسٽرڪچر جي اندر ڪنهن ٻئي خدمت ڏانهن ايپليڪيشن کان ويا، ۽ ڪجهه سببن لاء اهو اسان کي جواب نٿو ڏئي. ۽ اسان جو اجلاس هڪ اهڙي حالت ۾ ڦاسي پيو آهي جتي اهو معلوم ناهي ته اهو ڪڏهن حل ٿيندو.
- ٻي صورتحال اها آهي جڏهن هڪ استثنا اسان جي ڪوڊ ۾ ڪجهه سببن جي ڪري ٿي. ۽ استثنا ۾ اسان ٽرانزيڪشن کي بند ڪرڻ تي عمل نه ڪيو. ۽ اسان هڪ کليل ٽرانزيڪشن سان پھانسي سيشن سان ختم ڪيو.
- ۽ آخري هڪ تمام عام ڪيس آهي. هي گهٽ معيار جو ڪوڊ آهي. ڪجهه فريم ورڪ هڪ ٽرانزيڪشن کي کوليو. اهو لٽڪيل آهي، ۽ توهان شايد ايپليڪيشن ۾ نه ڄاڻندا آهيو ته توهان وٽ اهو لٽڪيل آهي.
اهڙيون ڳالهيون ڪيڏانهن وڃن ٿيون؟
ان نقطي تائين ته اسان جا جدول ۽ انڊيڪس ڊرامائي طور تي سوڀ ڪرڻ شروع ڪن ٿا. اهو بلڪل ساڳيو bloat اثر آهي. ڊيٽابيس لاءِ، هن جو مطلب اهو ٿيندو ته ڊيٽابيس جو جواب وقت تمام تيزيءَ سان وڌي ويندو ۽ ڊيٽابيس سرور تي لوڊ وڌندو. ۽ نتيجي طور، اسان جي درخواست کي نقصان ٿيندو. ڇاڪاڻ ته جيڪڏهن توهان پنهنجي ڪوڊ ۾ 10 مليسيڪنڊ خرچ ڪيو ڊيٽابيس جي درخواست تي، 10 مليسيڪنڊ توهان جي منطق تي، پوء توهان جي فنڪشن مڪمل ٿيڻ ۾ 20 مليسيڪنڊ ورتو. ۽ هاڻي توهان جي حالت بلڪل اداس ٿي ويندي.
۽ اچو ته ڏسو ته ڇا ٿئي. هيٺيون کاٻي گراف ڏيکاري ٿو ته اسان وٽ هڪ ڊگهو ڊگهو ٽرانزيڪشن آهي. ۽ جيڪڏهن اسان اوپري کاٻي گراف تي نظر وجهون ٿا، اسان ڏسون ٿا ته اسان جي ٽيبل جي ماپ اوچتو ٻه ميگا بائيٽ کان 300 ميگا بائيٽ تائين وڌي وئي آهي. ساڳئي وقت، جدول ۾ ڊيٽا جي مقدار تبديل نه ڪئي وئي آهي، يعني اتي هڪ وڏي مقدار ۾ گندگي آهي.
سراسري سرور جي جوابي وقت جي حوالي سان عام صورتحال پڻ شدت جي ڪيترن ئي حڪمن سان تبديل ٿي وئي آهي. اهو آهي، سرور تي سڀني درخواستن کي مڪمل طور تي ڇڏڻ شروع ڪيو. ۽ ساڳئي وقت، اندروني Postgres پروسيس آٽو ويڪيوم جي صورت ۾ شروع ڪيا ويا، جيڪي ڪجهه ڪرڻ جي ڪوشش ڪري رهيا آهن ۽ وسيلن کي استعمال ڪري رهيا آهن.
اسان جي نشاني سان ڇا ٿي رهيو آهي؟ ساڳيو. نشاني جي مطابق اسان جي اوسط جوابي وقت ڪيترن ئي حڪمن جي شدت کي وڌايو آهي. خاص طور تي استعمال ٿيل وسيلن جي لحاظ کان، اسان ڏسون ٿا ته پروسيسر تي لوڊ تمام گهڻو وڌي چڪو آهي. هي مٿي ساڄي گراف آهي. ۽ اهو وڌي ويو آهي ڇاڪاڻ ته پروسيسر کي گهربل ضرورت جي ڳولا ۾ بيڪار لائينن جي هڪ گروپ ذريعي ترتيب ڏيڻو پوندو. هي هيٺيون ساڄي گراف آهي. ۽ نتيجي طور، اسان جي ڪالن جو تعداد في سيڪنڊ تمام گهڻو گهٽجڻ شروع ڪيو، ڇاڪاڻ ته ڊيٽابيس وٽ ساڳئي تعداد جي درخواستن تي عمل ڪرڻ جو وقت نه هو.
اسان کي زندگي ڏانهن واپس وڃڻ جي ضرورت آهي. اسان آن لائن وڃون ٿا ۽ ڳولھيو ٿا ته ڊگھي ٽرانزيڪشن مسئلا پيدا ڪري ٿي. اسان هن ٽرانزيڪشن کي ڳولي ۽ ماريندا آهيون. ۽ هر شيء اسان لاء عام ٿي رهيو آهي. هر شي ڪم ڪري ٿي جيئن ان کي گهرجي.
اسان آرام ڪيو، پر ٿوري دير کان پوء اسان کي نوٽيس شروع ڪيو ويو آهي ته ايپليڪيشن ساڳئي طريقي سان ڪم نه ڪندي جيئن ايمرجنسي کان اڳ. درخواستون اڃا به سست، ۽ خاص طور تي سست تي عمل ڪيون وينديون آهن. منهنجي مثال ۾ خاص طور تي هڪ اڌ کان ٻه ڀيرا سست. سرور تي لوڊ پڻ حادثي کان اڳ جي ڀيٽ ۾ وڌيڪ آهي.
۽ سوال: "هن وقت بنيادي طور تي ڇا ٿي رهيو آهي؟" ۽ هيٺين صورتحال بنيادي سان ٿئي ٿي. ٽرانزيڪشن چارٽ تي توهان ڏسي سگهو ٿا ته اهو بند ٿي ويو آهي ۽ حقيقت ۾ ڪو به ڊگهو ٽرانزيڪشن ناهي. پر حادثي دوران علامتي طور تي نشان جي سائيز وڌي وئي. ۽ ان وقت کان وٺي انهن ۾ گهٽتائي نه آئي آهي. بنياد تي سراسري وقت مستحڪم ٿي چڪو آهي. ۽ جواب اسان لاءِ قابل قبول رفتار تي مناسب طور تي اچي رهيا آهن. آٽو ويڪيوم وڌيڪ فعال ٿي ويو ۽ نشاني سان ڪجهه ڪرڻ شروع ڪيو، ڇاڪاڻ ته ان کي وڌيڪ ڊيٽا ذريعي ڇڪڻ جي ضرورت آهي.
خاص طور تي، اڪائونٽن سان ٽيسٽ پليٽ جي مطابق، جتي اسان بيلنس تبديل ڪريون ٿا: هڪ درخواست لاءِ جوابي وقت لڳي ٿو معمول تي موٽي آيو آهي. پر حقيقت ۾ اهو هڪ اڌ ڀيرا وڌيڪ آهي.
۽ پروسيسر تي لوڊ ٿيڻ کان، اسان ڏسون ٿا ته پروسيسر تي لوڊ حادثي کان اڳ گهربل قيمت ڏانهن واپس نه آيو آهي. ۽ ان جا سبب بلڪل هيٺئين ساڄي گراف ۾ موجود آهن. اهو ڏسي سگهجي ٿو ته يادگيري جو هڪ خاص مقدار اتي ڳولي رهيو آهي. اهو آهي، گهربل لائين ڳولڻ لاء، اسان بيڪار ڊيٽا ذريعي ترتيب ڏيڻ دوران ڊيٽابيس سرور جا وسيلا ضايع ڪندا آهيون. في سيڪنڊ ٽرانزيڪشن جو تعداد مستحڪم ٿي چڪو آهي.
مجموعي طور تي سٺو، پر صورتحال ان کان وڌيڪ خراب آهي. اسان جي ايپليڪيشن جي نتيجي ۾ ڊيٽابيس جي تباهي کي صاف ڪريو جيڪو هن ڊيٽابيس سان ڪم ڪري ٿو.
۽ سمجھڻ لاءِ ته اتي ڇا ٿي رھيو آھي، جيڪڏھن توھان اڳئين رپورٽ تي نه ھو، ھاڻي اچو ته ٿورڙو نظريو وٺون. اندروني عمل جي باري ۾ نظريو. ڪار خلا ڇو ۽ اهو ڇا ڪندو آهي؟
لفظي طور تي مختصر طور سمجھڻ لاء. ڪنهن وقت اسان وٽ هڪ ٽيبل آهي. اسان وٽ ٽيبل ۾ قطارون آهن. اهي سٽون ٿي سگهن ٿيون فعال، زندهه، ۽ جيڪي اسان کي هاڻي ضرورت آهي. اهي تصوير ۾ سائي ۾ نشان لڳل آهن. ۽ اتي ئي مئل لائينون آھن جيڪي اڳي ئي ڪم ڪيون ويون آھن، اپڊيٽ ڪيون ويون آھن، ۽ انھن تي نيون داخلائون ظاهر ٿيون آھن. ۽ اهي نشان لڳل آهن ته اهي هاڻي ڊيٽابيس ڏانهن دلچسپ نه آهن. پر اهي پوسٽ گريس فيچر جي ڪري ٽيبل ۾ آهن.
توهان کي ڪار جي ويڪيوم جي ضرورت ڇو آهي؟ ڪجهه نقطي تي، آٽو ويڪيوم اچي ٿو، ڊيٽابيس تائين رسائي ڪري ٿو ۽ ان کان پڇي ٿو: "مهرباني ڪري مون کي سڀ کان پراڻي ٽرانزيڪشن جي سڃاڻپ ڏيو جيڪا هن وقت ڊيٽابيس ۾ کليل آهي." ڊيٽابيس هن id کي واپس ڏئي ٿو. ۽ آٽو ويڪيوم، ان تي ڀروسو ڪندي، ٽيبل ۾ لائينن ذريعي ترتيب ڏئي ٿو. ۽ جيڪڏهن هو ڏسي ٿو ته ڪجهه لائينون گهڻيون پراڻيون ٽرانزيڪشن ذريعي تبديل ڪيون ويون آهن، ته پوءِ هن کي حق آهي ته انهن کي نشانن جي طور تي نشان لڳائي سگهون جيڪي اسان مستقبل ۾ ٻيهر استعمال ڪري سگهون ٿا اتي نئين ڊيٽا لکڻ سان. اهو هڪ پس منظر وارو عمل آهي.
هن وقت، اسان ڊيٽابيس سان ڪم ڪرڻ جاري رکون ٿا ۽ ٽيبل ۾ ڪجهه تبديليون ڪرڻ جاري رکون ٿا. ۽ انهن لائينن تي، جيڪو اسان ٻيهر استعمال ڪري سگهون ٿا، اسان نئين ڊيٽا لکون ٿا. ۽ اهڙيءَ طرح اسان کي هڪ چڪر ملي ٿو، يعني هر وقت ڪجهه مئل پراڻيون لائينون اتي نظر اچن ٿيون، انهن جي بدران اسان نئين لائين لکون ٿا، جن جي اسان کي ضرورت آهي. ۽ هي هڪ عام حالت آهي PostgreSQL ڪم ڪرڻ لاءِ.
حادثي دوران ڇا ٿيو؟ اهو عمل اتي ڪيئن ٿيو؟
اسان وٽ ڪا نشاني هئي ڪنهن حالت ۾، ڪي زندهه، ڪي مئل لڪير. ڪار جي ويڪيوم اچي وئي آهي. هن ڊيٽابيس کان پڇيو ته اسان جي پراڻي ٽرانزيڪشن ڪهڙي آهي ۽ ان جي آئي ڊي ڪهڙي آهي. مون کي اها آئي ڊي ملي هئي، جيڪا شايد ڪيترائي ڪلاڪ اڳ، شايد ڏهه منٽ اڳ هجي. اهو منحصر آهي ته توهان جي ڊيٽابيس تي ڪيترو وزن آهي. ۽ هو لڪيرن جي ڳولا ۾ ويو ته هو ٻيهر استعمال ٿيل طور نشان لڳائي سگهي. ۽ مون کي اسان جي ٽيبل ۾ اهڙيون لائينون نه مليون.
پر هن وقت اسان ٽيبل سان ڪم جاري رکون ٿا. اسان ان ۾ ڪجهه ڪريون ٿا، ان کي اپڊيٽ ڪريو، ڊيٽا کي تبديل ڪريو. هن وقت ڊيٽابيس کي ڇا ڪرڻ گهرجي؟ هن وٽ موجوده ٽيبل جي آخر ۾ نيون لائينون شامل ڪرڻ کانسواءِ ٻيو ڪو رستو ناهي. ۽ اھڙيءَ طرح اسان جي ٽيبل جي ماپ سوڙ ٿيڻ شروع ٿئي ٿي.
حقيقت ۾، اسان کي ڪم ڪرڻ لاء سائي لائنن جي ضرورت آهي. پر اهڙي مسئلي دوران، اهو ظاهر ٿئي ٿو ته سائي لائينن جو سيڪڙو سڄي ٽيبل تي تمام گهٽ آهي.
۽ جڏهن اسان هڪ سوال تي عمل ڪريون ٿا، ڊيٽابيس کي سڀني لائينن ذريعي وڃڻو پوندو: ڳاڙهي ۽ سائي ٻنهي، گهربل لائن ڳولڻ لاء. ۽ بيڪار ڊيٽا سان ٽيبل کي ڦهلائڻ جو اثر "بلوٽ" سڏيو ويندو آهي، جيڪو پڻ اسان جي ڊسڪ جي جڳهه کي کائي ٿو. ياد رکو، اهو 2 MB هو، اهو 300 MB بڻجي ويو؟ ھاڻي ميگا بائيٽ کي گيگا بائيٽ ۾ تبديل ڪريو ۽ توھان جلدي پنھنجي ڊسڪ وسيلن کي وڃائي ڇڏينداسين.
اسان لاءِ ڪهڙا نتيجا ٿي سگهن ٿا؟
- منهنجي مثال ۾، ٽيبل ۽ انڊيڪس 150 ڀيرا وڌيو. اسان جا ڪجهه گراهڪ وڌيڪ موتمار ڪيس آهن جڏهن اهي صرف ڊسڪ اسپيس کان ٻاهر هلڻ شروع ڪيو.
- ٽيبل جي ماپ پاڻ کي ڪڏهن به گهٽ نه ٿيندي. ڪجھ ڪيسن ۾ آٽو ويڪيوم ميز جي دم کي ڪٽي سگھي ٿو جيڪڏھن رڳو مئل لائينون آھن. پر جيئن ته مسلسل گردش آهي، هڪ سائي لائين آخر ۾ منجمد ٿي سگهي ٿي ۽ اپڊيٽ نه ٿي سگهي ٿي، جڏهن ته ٻين سڀني کي پليٽ جي شروعات ۾ ڪٿي لکيو ويندو. پر اهو هڪ اهڙو ممڪن ناهي ته توهان جي ٽيبل پاڻ ئي سائيز ۾ سڪي ويندي، تنهنڪري توهان کي ان جي اميد نه رکڻ گهرجي.
- ڊيٽابيس کي بيڪار لائينن جي مڪمل گچ ذريعي ترتيب ڏيڻ جي ضرورت آهي. ۽ اسان ڊسڪ وسيلن کي ضايع ڪندا آهيون، اسان پروسيسر وسيلن ۽ بجلي کي ضايع ڪندا آهيون.
- ۽ اهو سڌو سنئون اسان جي ايپليڪيشن تي اثر انداز ٿئي ٿو، ڇاڪاڻ ته جيڪڏهن شروعات ۾ اسان درخواست تي 10 ملي سيڪنڊ خرچ ڪيو، اسان جي ڪوڊ تي 10 ملي سيڪنڊ، پوء حادثي دوران اسان درخواست تي هڪ سيڪنڊ ۽ ڪوڊ تي 10 ملي سيڪنڊ خرچ ڪرڻ شروع ڪيو، يعني هڪ آرڊر. ايپليڪيشن جي ڪارڪردگي ۾ شدت گھٽجي وئي. ۽ جڏهن حادثو حل ڪيو ويو، اسان هڪ درخواست تي 20 مليسيڪنڊ خرچ ڪرڻ شروع ڪيو، ڪوڊ تي 10 مليسيڪنڊ. ان جو مطلب اهو آهي ته اسان اڃا تائين پيداوار ۾ اڌ ڀيرا گهٽجي ويا آهيون. ۽ اهو سڀ ڪجهه هڪ ٽرانزيڪشن جي ڪري آهي جيڪو منجمد ٿي ويو، شايد اسان جي غلطي جي ڪري.
- ۽ سوال: "اسان سڀ ڪجهه واپس ڪيئن حاصل ڪري سگهون ٿا؟" انهي ڪري ته هر شي اسان سان ٺيڪ آهي ۽ درخواستون جلدي جلدي اچن ٿيون جيئن حادثي کان اڳ.
هن مقصد لاء ڪم جو هڪ خاص چڪر آهي جيڪو ڪيو ويندو آهي.
پهرين اسان کي ڳولڻ جي ضرورت آهي مشڪلاتي جدول جيڪي ڦٽيل آهن. اسان سمجھون ٿا ته ڪجھ جدولن ۾ رڪارڊنگ وڌيڪ فعال آھي، ٻين ۾ گھٽ چالو آھي. ۽ ان لاءِ اسين واڌايون استعمال ڪريون ٿا . هن ايڪسٽينشن کي انسٽال ڪرڻ سان، توهان سوال لکي سگهو ٿا جيڪي توهان جي مدد ڪنديون ٽيبلون ڳولڻ ۾ جيڪي ڪافي ڦاٿل آهن.
هڪ دفعو توهان کي اهي ٽيبل مليا آهن، توهان کي انهن کي دٻائڻ جي ضرورت آهي. ان لاءِ اڳ ۾ ئي اوزار موجود آهن. اسان جي ڪمپني ۾ اسان ٽي اوزار استعمال ڪندا آهيون. پهريون آهي بلٽ ان VACUUM FULL. هو ظالم، سخت ۽ بي رحم آهي، پر ڪڏهن ڪڏهن هو تمام مفيد آهي. и - ھي آھن ٽئين پارٽي يوٽيلٽيز ڪمپريسنگ ٽيبل لاءِ. ۽ اهي ڊيٽابيس کي وڌيڪ احتياط سان علاج ڪن ٿا.
اهي استعمال ڪيا ويا آهن ان تي منحصر آهي جيڪو توهان لاء وڌيڪ آسان آهي. پر مان توهان کي ان بابت آخر ۾ ٻڌائيندس. بنيادي شيء اها آهي ته اتي ٽي اوزار آهن. مان چونڊڻ لاء ڪافي آهن.
اسان سڀني شين کي درست ڪرڻ کان پوء ۽ يقيني بڻائي ته سڀ ڪجهه ٺيڪ آهي، اسان کي ڄاڻڻ گهرجي ته مستقبل ۾ هن صورتحال کي ڪيئن روڪيو وڃي:
- اهو ڪافي آساني سان روڪي سگهجي ٿو. توهان کي ماسٽر سرور تي سيشن جي مدت جي نگراني ڪرڻ جي ضرورت آهي. ٽرانزيڪشن جي حالت ۾ بيڪار ۾ خاص طور تي خطرناڪ سيشن. اهي اهي آهن جن صرف هڪ ٽرانزيڪشن کوليو، ڪجهه ڪيو ۽ ڇڏي ويو، يا صرف لڪي ويو، ڪوڊ ۾ گم ٿي ويا.
- ۽ توھان لاءِ، ڊولپرز جي طور تي، اھو ضروري آھي ته توھان جو ڪوڊ ٽيسٽ ڪريو جڏھن اھي حالتون پيدا ٿين. اهو ڪرڻ ڏکيو ناهي. هي هڪ مفيد چيڪ ٿيندو. توهان ڊگهي ٽرانزيڪشن سان لاڳاپيل ”ٻاراڻي“ مسئلن جي وڏي تعداد کان پاسو ڪندا.
انهن گرافن ۾، مان توهان کي ڏيکارڻ چاهيان ٿو ته ڪيئن ڊيٽابيس جي نشاني ۽ رويي ۾ تبديلي آئي جڏهن آئون هن معاملي ۾ VACUUM FULL جي نشاني تي وڃو. هي مون لاء پيداوار نه آهي.
ٽيبل جي سائيز فوري طور تي ان جي عام آپريٽنگ حالت ڏانهن واپس آئي ميگا بائيٽ جي هڪ جوڙو. اهو تمام گهڻو متاثر نه ڪيو سرور لاء اوسط جوابي وقت.
پر خاص طور تي اسان جي امتحان واري نشاني لاءِ، جتي اسان اڪائونٽ بيلنس کي اپڊيٽ ڪيو، اسان ڏسون ٿا ته سائن ۾ ڊيٽا کي اپڊيٽ ڪرڻ جي درخواست لاءِ اوسط جوابي وقت اڳي ايمرجنسي ليول تائين گھٽجي ويو هو. هن درخواست کي مڪمل ڪرڻ لاءِ پروسيسر پاران استعمال ڪيل وسيلا پڻ حادثي کان اڳ واري سطح تي اچي ويا. ۽ هيٺيون ساڄي گراف ڏيکاري ٿو ته هاڻي اسان کي بلڪل اها لڪير ملي ٿي جنهن جي اسان کي فوري ضرورت آهي، بغير مئل لائينن جي ان ڍير مان گذرڻ جي جيڪي ٽيبل کي دٻائڻ کان اڳ موجود هئا. ۽ سراسري درخواست وقت لڳ ڀڳ ساڳئي سطح تي رهي. پر هتي مون وٽ آهي، بلڪه، منهنجي هارڊويئر ۾ هڪ غلطي.
هتي پهرين ڪهاڻي ختم ٿئي ٿي. اهو سڀ کان وڌيڪ عام آهي. ۽ اهو هر ڪنهن سان ٿئي ٿو، بغير ڪنهن ڪلائنٽ جي تجربي کان سواءِ ۽ پروگرامر ڪيترا اهل آهن. جلد يا بعد ۾ اهو ٿئي ٿو.
ٻي ڪهاڻي، جنهن ۾ اسان لوڊ ورهايو ۽ سرور وسيلن کي بهتر ڪيو
- اسان اڳي ئي وڏا ٿي ويا آهيون ۽ سنجيده ماڻهو بڻجي چڪا آهيون. ۽ اسان سمجهون ٿا ته اسان وٽ هڪ نقل آهي ۽ اهو اسان لاءِ سٺو هوندو ته لوڊ کي متوازن ڪريون: ماسٽر ڏانهن لکو، ۽ نقل مان پڙهو. ۽ عام طور تي اها صورتحال پيدا ٿيندي آهي جڏهن اسان ڪجهه رپورٽون يا اي ٽي ايل تيار ڪرڻ چاهيون ٿا. ۽ ڪاروبار هن بابت تمام گهڻو خوش آهي. هو واقعي چاهي ٿو ڪيترن ئي پيچيده تجزين سان مختلف رپورٽون.
- رپورٽن ۾ ڪيترائي ڪلاڪ لڳن ٿا، ڇاڪاڻ ته پيچيده تجزياتي مليس سيڪنڊن ۾ شمار نه ٿي ڪري سگھجي. اسان، بهادر ماڻهن وانگر، ڪوڊ لکندا آهيون. داخل ڪرڻ واري ايپليڪيشن ۾ اسان ماسٽر تي رڪارڊنگ ڪندا آهيون، ۽ رپورٽن کي نقل تي عمل ڪندا آهيون.
- لوڊ ورهائڻ.
- هر شي مڪمل طور تي ڪم ڪري ٿي. اسان عظيم آهيون.
۽ هي صورتحال ڇا نظر اچي ٿي؟ خاص طور تي انهن گرافس تي، مون ٽرانزيڪشن جي مدت لاء نقل کان ٽرانزيڪشن جي مدت پڻ شامل ڪئي. ٻيا سڀئي گراف صرف ماسٽر سرور ڏانهن اشارو ڪن ٿا.
هن وقت تائين، منهنجو رپورٽ بورڊ وڌي چڪو هو. انهن مان وڌيڪ آهن. اسان ڏسون ٿا ته سراسري سرور جو جواب وقت مستحڪم آهي. اسان ڏسون ٿا ته نقل تي اسان وٽ هڪ ڊگهو هلندڙ ٽرانزيڪشن آهي جيڪو 2 ڪلاڪن تائين هلندو آهي. اسان آٽو ويڪيوم جي خاموش آپريشن کي ڏسون ٿا، جيڪو مئل لائنن تي عمل ڪري ٿو. ۽ اسان سان هر شي ٺيڪ آهي.
خاص طور تي، آزمائشي پليٽ جي مطابق، اسان اتي اڪائونٽ بيلنس کي اپڊيٽ ڪرڻ جاري رکون ٿا. ۽ اسان وٽ پڻ درخواستن لاءِ مستحڪم جوابي وقت، مستحڪم وسيلن جي استعمال. اسان وٽ سڀ ڪجهه ٺيڪ آهي.
سڀ ڪجھ ٺيڪ آهي ان وقت تائين جيستائين اهي رپورٽون نقل ڪرڻ سان تڪرار جي ڪري واپس فائر ڪرڻ شروع ڪن. ۽ اهي باقاعده وقفي تي واپس فائر ڪندا آهن.
اسان آن لائن وڃون ٿا ۽ پڙهڻ شروع ڪريون ٿا ته اهو ڇو ٿي رهيو آهي. ۽ اسان هڪ حل ڳوليندا آهيون.
پهريون حل نقل ڪرڻ جي دير کي وڌائڻ آهي. اسان ڄاڻون ٿا ته اسان جي رپورٽ 3 ڪلاڪن تائين هلندي آهي. اسان نقل جي دير کي 3 ڪلاڪن تائين مقرر ڪيو. اسان سڀڪنھن شيء کي شروع ڪري رهيا آهيون، پر اسان اڃا تائين رپورٽن سان مسئلا جاري رکون ٿا ڪڏهن ڪڏهن منسوخ ٿيڻ سان.
اسان چاهيون ٿا ته هر شي ڀرپور هجي. اسان اڳتي وڌون ٿا. ۽ اسان کي انٽرنيٽ تي هڪ سٺي سيٽنگ ملي آهي - hot_standby_feedback. اچو ته ان کي ڦيرايو. Hot_standby_feedback اسان کي اجازت ڏئي ٿو ته آٽو ويڪيوم کي ماسٽر تي رکو. ان ڪري، اسان مڪمل طور تي نقل جي تڪرار کان نجات حاصل ڪندا آهيون. ۽ رپورٽن سان گڏ اسان لاءِ هر شي ڪم ڪري ٿي.
۽ هن وقت ماسٽر سرور سان ڇا ٿي رهيو آهي؟ ۽ اسان ماسٽر سرور سان مڪمل مصيبت ۾ آهيون. هاڻي اسان گراف ڏسي رهيا آهيون جڏهن مون انهن ٻنهي سيٽنگن کي فعال ڪيو آهي. ۽ اسان ڏسون ٿا ته اسان جي نقل تي سيشن ڪنهن به طرح ماسٽر سرور تي صورتحال کي متاثر ڪرڻ شروع ڪيو. هن جو اثر آهي ڇو ته هن آٽو ويڪيوم کي روڪيو، جيڪو مئل لائينن کي صاف ڪري ٿو. اسان جي ٽيبل جي سائيز ٻيهر آسمان ڏانهن وڌي وئي آهي. سراسري سوال جي عمل جو وقت سڄي ڊيٽابيس ۾ پڻ آسمان کي وڌايو ويو. آٽو ويڪيوم ٿورو تنگ ٿي ويا.
خاص طور تي، اسان جي پليٽ مان، اسان ڏسون ٿا ته ان تي ڊيٽا اپڊيٽ پڻ آسمان ڏانهن وڌي وئي. سي پي يو جو استعمال ساڳئي طرح تمام گهڻو وڌي چڪو آهي. اسان وري وڏي تعداد ۾ مئل، بيڪار لائينن مان گذري رهيا آهيون. ۽ هن نشاني لاءِ جوابي وقت ۽ ٽرانزيڪشن جو تعداد گهٽجي ويو آهي.
اهو ڇا ٿيندو جيڪڏهن اسان کي خبر ناهي ته آئون اڳي ڇا ڳالهائي رهيو هوس؟
- اسان مسئلا ڳولڻ شروع ڪريون ٿا. جيڪڏهن اسان پهرين حصي ۾ مسئلن جو سامنا ڪيو، اسان ڄاڻون ٿا ته اهو ٿي سگهي ٿو هڪ ڊگهي ٽرانزيڪشن جي ڪري ۽ ماسٽر ڏانهن وڃو. اسان وٽ ماسٽر تي مسئلو آهي. هن کي ساس ڪري ٿو. اهو گرم ڪري ٿو، ان جي لوڊ اوسط اٽڪل هڪ سئو آهي.
- اتي درخواستون سست آھن، پر اسان اتي ڪو ڊگھي ھلندڙ ٽرانزيڪشن نه ٿا ڏسو. ۽ اسان کي سمجهه ۾ نه ٿو اچي ته معاملو ڇا آهي. اسان کي سمجهه ۾ نه ٿو اچي ته ڪٿي ڏسون.
- اسان سرور جي سامان جي جانچ ڪريون ٿا. ٿي سگهي ٿو اسان جو حملو تباهه ٿي ويو. ٿي سگهي ٿو اسان جي يادگيري جي لٺ سڙي وئي. ها، ڪجهه به ٿي سگهي ٿو. پر نه، سرور نوان آهن، سڀ ڪجھ ٺيڪ ڪم ڪري ٿو.
- هرڪو هلائي رهيو آهي: منتظم، ڊولپر ۽ ڊائريڪٽر. ڪجھ به مدد نه ڪندو آھي.
- ۽ ڪجهه نقطي تي هر شيء اوچتو پاڻ کي درست ڪرڻ شروع ٿئي ٿو.
هن وقت، اسان جي نقل تي درخواست تي عمل ڪيو ويو ۽ ڇڏي ويو. اسان کي رپورٽ ملي. ڪاروبار اڃا خوش آهي. جئين توهان ڏسي سگهو ٿا، اسان جي نشاني ٻيهر وڌي وئي آهي ۽ سڪي وڃڻ وارو ناهي. سيشن سان گڏ گراف تي، مون هن ڊگھي ٽرانزيڪشن جو هڪ ٽڪرو هڪ نقل مان ڇڏي ڏنو ته جيئن توهان اندازو لڳائي سگهو ته اهو ڪيترو وقت وٺندو جيستائين صورتحال مستحڪم ٿيندي.
سيشن ختم ٿي چڪو آهي. ۽ صرف ڪجهه وقت کان پوءِ سرور وڌيڪ يا گهٽ ترتيب ۾ اچي ٿو. ۽ ماسٽر سرور تي درخواستن لاءِ اوسط جوابي وقت معمول تي اچي ٿو. ڇو ته، آخرڪار، آٽو ويڪيوم کي انهن مئل لائينن کي صاف ڪرڻ ۽ نشان لڳائڻ جو موقعو آهي. ۽ هو پنهنجو ڪم ڪرڻ لڳو. ۽ هو ڪيترو جلدي اهو ڪري ٿو، تنهنڪري جلدي اسان کي ترتيب ڏينداسين.
ٽيسٽ ٿيل ٽيبليٽ جي مطابق، جتي اسان اڪائونٽ بيلنس کي اپڊيٽ ڪندا آهيون، اسان بلڪل ساڳي تصوير ڏسون ٿا. سراسري اڪائونٽ جي تازه ڪاري جو وقت به آهستي آهستي معمول تي اچي رهيو آهي. پروسيسر پاران استعمال ڪيل وسيلا پڻ گھٽجي ويا آهن. ۽ في سيڪنڊ ٽرانزيڪشن جو تعداد معمول ڏانهن موٽندو. پر اسان ٻيهر معمول تي واپس آيا آهيون، جيئن ته حادثي کان اڳ هئاسين.
ڪنهن به صورت ۾، اسان ڪارڪردگي جي گهٽتائي حاصل ڪندا آهيون، جيئن پهرين صورت ۾، هڪ اڌ کان ٻه ڀيرا، ۽ ڪڏهن ڪڏهن وڌيڪ.
لڳي ٿو ته اسان سڀ ڪجھ ٺيڪ ڪيو آهي. لوڊ ورهايو. سامان بيڪار نه آهي. اسان پنهنجي ذهنن مطابق درخواستون ورهايون، پر پوءِ به سڀ ڪجهه خراب ٿي ويو.
- hot_standby_feedback کي فعال نه ڪيو؟ ها، خاص طور تي مضبوط سببن کان سواء ان کي چالو ڪرڻ جي سفارش نه ڪئي وئي آهي. ڇاڪاڻ ته هي موڙ سڌو سنئون ماسٽر سرور کي متاثر ڪري ٿو ۽ اتي آٽو ويڪيوم جي آپريشن کي معطل ڪري ٿو. ان کي چالو ڪرڻ سان ڪجھ نقل تي ۽ ان جي باري ۾ وساريو، توھان ماسٽر کي مارڻ ۽ ايپليڪيشن سان وڏيون مسئلا حاصل ڪري سگھو ٿا.
- وڌو وڌو max_standby_streaming_delay؟ ها، رپورٽن لاء اهو سچ آهي. جيڪڏهن توهان وٽ ٽي ڪلاڪ رپورٽ آهي ۽ توهان نٿا چاهيو ته اهو نقلي تڪرارن جي ڪري حادثو ٿئي، پوءِ بس دير وڌايو. هڪ ڊگهي مدي واري رپورٽ ڪڏهن به ڊيٽا جي ضرورت ناهي جيڪا ڊيٽابيس ۾ اچي چڪي آهي. جيڪڏهن توهان وٽ آهي ٽن ڪلاڪن لاءِ، پوءِ توهان ان کي هلائي رهيا آهيو ڪجهه پراڻي ڊيٽا جي مدت لاءِ. ۽ توهان لاءِ، ٽي ڪلاڪ دير هجي يا ڇهن ڪلاڪن جي دير سان ڪو به فرق نه پوندو، پر توهان کي مسلسل رپورٽون ملنديون ۽ انهن جي گرڻ سان ڪو به مسئلو نه ٿيندو.
- قدرتي طور تي، توهان کي replicas تي ڊگهي سيشن کي ڪنٽرول ڪرڻ جي ضرورت آهي، خاص طور تي جيڪڏهن توهان هڪ ريپليڪا تي hot_standby_feedback کي فعال ڪرڻ جو فيصلو ڪيو. ڇاڪاڻ ته ڪجهه به ٿي سگهي ٿو. اسان هي نقل ڊولپر کي ڏنو ته جيئن هو سوالن جي جانچ ڪري سگهي. هن هڪ چريو درخواست لکيو. هن ان کي لانچ ڪيو ۽ چانهه پيئڻ لاءِ روانو ٿيو، ۽ اسان کي قائم ڪيل ماسٽر ملي ويو. يا ٿي سگهي ٿو ته اسان اتي غلط ايپليڪيشن رکون. حالتون مختلف آهن. replicas تي سيشن کي احتياط سان مانيٽر ڪيو وڃي جيئن ماسٽر تي.
- ۽ جيڪڏهن توهان وٽ replicas تي تيز ۽ ڊگهو سوال آهي، ته پوء هن حالت ۾ اهو بهتر آهي ته انهن کي ورهائڻ لاء لوڊ ورهائڻ لاء. هي streaming_delay جي لنڪ آهي. تيزيءَ وارن لاءِ، ھڪڙو نقل آھي ھڪڙي ننڍڙي نقل جي دير سان. ڊگھي ھلندڙ رپورٽنگ جي درخواستن لاءِ، ھڪ ريپليڪا آھي جيڪو 6 ڪلاڪ يا ھڪ ڏينھن ۾ دير ڪري سگھي ٿو. هي هڪ مڪمل طور تي عام صورتحال آهي.
اسان ساڳئي طريقي سان نتيجن کي ختم ڪريون ٿا:
- اسان ڦٽيل ٽيبل ڳوليندا آهيون.
- ۽ اسان ان کي تمام آسان اوزار سان گڏ ڪريون ٿا جيڪو اسان کي مناسب آهي.
ٻي ڪهاڻي هتي ختم ٿئي ٿي. اچو ته ٽئين ڪهاڻي ڏانهن وڃو.
اسان لاءِ پڻ عام آهي جنهن ۾ اسان لڏپلاڻ ڪندا آهيون.
- ڪنهن به سافٽ ويئر جي پيداوار وڌي رهيو آهي. ان لاءِ گهرجون تبديل ٿي رهيون آهن. ڪنهن به صورت ۾، اسان ترقي ڪرڻ چاهيون ٿا. ۽ اهو ٿئي ٿو ته اسان کي جدول ۾ ڊيٽا کي اپڊيٽ ڪرڻ جي ضرورت آهي، يعني نئين ڪارڪردگي لاءِ اسان جي لڏپلاڻ جي لحاظ کان هڪ تازه ڪاري هلائڻ لاءِ جيڪا اسان پنهنجي ترقي جي حصي طور متعارف ڪرائي رهيا آهيون.
- پراڻي ڊيٽا فارميٽ اطمينان بخش نه آهي. اچو ته ھاڻي ٻئي ٽيبل ڏانھن وڃو، جتي مون وٽ انھن اڪائونٽن تي ٽرانزيڪشن آھي. ۽ اچو ته چوندا آهن ته اهي روبل ۾ هئا، ۽ اسان فيصلو ڪيو ته درستگي کي وڌايو ۽ ان کي ڪوپيڪس ۾ ڪيو. ۽ ان لاءِ اسان کي اپڊيٽ ڪرڻ جي ضرورت آهي: فيلڊ کي ضرب ڪريو ٽرانزيڪشن جي رقم سان هڪ سو.
- اڄ جي دنيا ۾، اسان خودڪار ڊيٽابيس ورزن ڪنٽرول اوزار استعمال ڪندا آهيون. اچو ته چوندا آهن . اسان اتي اسان جي لڏپلاڻ کي رجسٽر ڪيو. اسان ان کي اسان جي ٽيسٽ بنياد تي آزمائيندا آهيون. سڀ ڪجھ ٺيڪ آهي. اپڊيٽ ٿي رهي آهي. اهو ڪجهه دير تائين ڪم ڪري ٿو، پر اسان کي تازه ڪاري ڊيٽا ملي ٿي. ۽ اسان هن تي نئين ڪارڪردگي شروع ڪري سگهون ٿا. هر شي کي جانچيو ۽ جانچيو ويو. هر شي جي تصديق ڪئي وئي.
- اسان رٿيل ڪم ڪيو ۽ لڏپلاڻ ڪئي.
هتي توهان جي سامهون پيش ڪيل تازه ڪاري سان لڏپلاڻ آهي. جيئن ته اهي منهنجو اڪائونٽ ٽرانزيڪشن آهن، پليٽ 15 GB هئي. ۽ جيئن ته اسان هر لڪير کي اپڊيٽ ڪيو، اسان تازه ڪاري سان ٽيبل جي سائيز کي ٻيڻو ڪيو، ڇاڪاڻ ته اسان هر لڪير کي ٻيهر لکيو.
لڏپلاڻ دوران، اسان هن پليٽ سان ڪجھ به نه ڪري سگهياسين، ڇاڪاڻ ته ان جي سڀني درخواستن کي قطار ۾ رکيو ويو ۽ انتظار ڪيو ويو جيستائين هي اپڊيٽ مڪمل ٿي وئي. پر هتي آئون توهان جو ڌيان انهن انگن ڏانهن ڇڪائڻ چاهيان ٿو جيڪي عمودي محور تي آهن. اهو آهي، اسان وٽ تقريبا 5 ملي سيڪنڊن جي لڏپلاڻ کان اڳ هڪ سراسري درخواست وقت آهي ۽ پروسيسر لوڊ، ڊسڪ ميموري پڙهڻ لاء بلاڪ عملن جو تعداد 7,5 کان گهٽ آهي.
اسان لڏپلاڻ ڪئي ۽ ٻيهر مسئلا پيدا ٿيا.
لڏپلاڻ ڪامياب ٿي، پر:
- پراڻي ڪارڪردگي هاڻي مڪمل ٿيڻ ۾ گهڻي وقت لڳندي آهي.
- ٽيبل وري سائيز ۾ وڌي وئي.
- سرور تي لوڊ ٻيهر اڳي کان وڌيڪ ٿي ويو.
- ۽، يقينا، اسان اڃا تائين ڪارڪردگي سان گڏ ڪم ڪري رهيا آهيون جيڪو سٺو ڪم ڪيو، اسان ان کي ٿورو بهتر ڪيو آهي.
۽ اهو وري ڦوٽو آهي، جيڪو ٻيهر اسان جي زندگين کي برباد ڪري ٿو.
هتي مان ظاهر ڪريان ٿو ته ٽيبل، پوئين ٻن ڪيسن وانگر، ان جي پوئين سائيز ڏانهن موٽڻ وارو ناهي. سراسري سرور لوڊ ڪافي ٿي لڳي.
۽ جيڪڏهن اسان اڪائونٽن سان ٽيبل ڏانهن رخ ڪريون ٿا، اسان ڏسنداسين ته اوسط درخواست جو وقت هن ميز لاء ٻيڻو ٿي چڪو آهي. پروسيسر تي لوڊ ۽ ميموري ۾ ترتيب ڏنل لائنن جو تعداد 7,5 کان مٿي ٽپو، پر گهٽ هو. ۽ اهو ٽپو 2 ڀيرا پروسيسرز جي صورت ۾، 1,5 ڀيرا بلاڪ آپريشن جي صورت ۾، يعني اسان کي سرور جي ڪارڪردگي ۾ تباهي ملي. ۽ نتيجي طور - اسان جي ايپليڪيشن جي ڪارڪردگي جي تباهي. ساڳئي وقت، ڪالن جو تعداد تقريبن ساڳئي سطح تي رهيو.
۽ هتي بنيادي شيء اهو سمجهڻ آهي ته اهڙي لڏپلاڻ کي صحيح طريقي سان ڪيئن ڪجي. ۽ ان کي ڪرڻ جي ضرورت آهي. اسان اهي لڏپلاڻ ڪافي تسلسل سان ڪندا آهيون.
- اهڙيون وڏيون لڏپلاڻ خود بخود نه ٿينديون آهن. انهن کي هميشه ڪنٽرول هيٺ هجڻ گهرجي.
- هڪ ڄاڻ رکندڙ شخص جي نگراني جي ضرورت آهي. جيڪڏهن توهان وٽ توهان جي ٽيم تي ڊي بي اي آهي، پوء ڊي بي اي کي اهو ڪرڻ ڏيو. هن جو ڪم آهي. جيڪڏهن نه، ته پوءِ سڀ کان وڌيڪ تجربيڪار شخص کي ڏيو، جيڪو ڄاڻي ٿو ته ڊيٽابيس سان ڪيئن ڪم ڪجي.
- هڪ نئون ڊيٽابيس اسڪيما، جيتوڻيڪ اسين هڪ ڪالم کي اپڊيٽ ڪندا آهيون، اسان هميشه مرحلن ۾ تيار ڪندا آهيون، يعني ايپليڪيشن جي نئين ورزن کي رول آئوٽ ڪرڻ کان اڳ ۾:
- نوان شعبا شامل ڪيا ويا آھن جن ۾ اسين تازه ڪاري ڊيٽا کي رڪارڊ ڪنداسين.
- اسان ڊيٽا کي پراڻي فيلڊ مان منتقل ڪريون ٿا نئين فيلڊ ۾ ننڍن حصن ۾. اسان ائين ڇو ڪري رهيا آهيون؟ پهرين، اسان هميشه هن پروسيس جي عمل کي ڪنٽرول ڪندا آهيون. اسان ڄاڻون ٿا ته اسان اڳ ۾ ئي ڪيترائي بيچ منتقل ڪيا آهن ۽ اسان وٽ ڪيترائي بچيا آهن.
- ۽ ٻيو مثبت اثر اهو آهي ته هر اهڙي بيچ جي وچ ۾ اسان ٽرانزيڪشن کي بند ڪريون ٿا، هڪ نئون کوليو، ۽ اهو آٽو ويڪيوم کي پليٽ جي مطابق ڪم ڪرڻ جي اجازت ڏئي ٿو، ٻيهر استعمال لاء ڊيڊ لائنن کي نشان لڳايو.
- لڪيرن لاءِ جيڪي ظاهر ٿينديون جڏهن ايپليڪيشن هلندي آهي (اسان وٽ اڃا تائين پراڻي ايپليڪيشن هلندي آهي)، اسان هڪ ٽريگر شامل ڪندا آهيون جيڪو نئين قيمتن کي نئين فيلڊ ۾ لکي ٿو. اسان جي حالت ۾، هي ضرب آهي هڪ سؤ جي پراڻي قدر.
- جيڪڏهن اسان مڪمل طور تي ضد آهيون ۽ ساڳئي فيلڊ چاهيون ٿا، ته پوء سڀني لڏپلاڻ جي مڪمل ٿيڻ تي ۽ ايپليڪيشن جي نئين ورزن کي رول ڪرڻ کان اڳ، اسان صرف فيلڊن جو نالو تبديل ڪريون ٿا. پراڻن کي ڪجهه ايجاد ڪيل نالو ڏنو ويو آهي، ۽ نوان شعبن کي پراڻن جو نالو ڏنو ويو آهي.
- ۽ صرف ان کان پوء اسان ايپليڪيشن جو هڪ نئون نسخو شروع ڪيو.
۽ ساڳئي وقت اسان کي ڦوٽو نه ملندو ۽ ڪارڪردگي جي لحاظ کان نقصان نه ٿيندو.
ٽين ڪهاڻي هتي ئي ختم ٿئي ٿي.
۽ ھاڻي ٿورڙو وڌيڪ تفصيل انھن اوزارن بابت جن جو ذڪر مون پھرين ڪهاڻيءَ ۾ ڪيو آھي.
بلوٽ ڳولڻ کان پهريان، توهان کي ايڪسٽينشن کي انسٽال ڪرڻ گهرجي .
تنهن ڪري توهان کي سوالن سان گڏ اچڻ جي ضرورت ناهي، اسان اڳ ۾ ئي انهن سوالن کي پنهنجي ڪم ۾ لکيو آهي. توھان انھن کي استعمال ڪري سگھو ٿا. هتي ٻه درخواستون آهن.
- پهريون ڪم ڪرڻ ۾ ڪافي وقت لڳندو آهي، پر اهو توهان کي ٽيبل مان صحيح بلوٽ ويلز ڏيکاريندو.
- ٻيو هڪ تيز ڪم ڪري ٿو ۽ تمام مؤثر آهي جڏهن توهان کي تڪڙو اندازو لڳائڻ جي ضرورت آهي ته ڇا ٽيبل جي مطابق هڪ بلوٽ آهي يا نه. ۽ توهان کي اهو پڻ سمجهڻ گهرجي ته بلوٽ هميشه پوسٽ گريس ٽيبل ۾ موجود آهي. هي ان جي MVCC ماڊل جي هڪ خاصيت آهي.
- ۽ 20٪ بلوٽ اڪثر ڪيسن ۾ ٽيبل لاء عام آهي. اهو آهي، توهان کي پريشان نه ٿيڻ گهرجي ۽ هن ٽيبل کي دٻايو.
اسان معلوم ڪيو ته جدولن جي سڃاڻپ ڪيئن ڪجي جيڪي بيڪار ڊيٽا سان ڀريل آهن.
هاڻي جي باري ۾ ڪيئن bloat کي ٺيڪ ڪرڻ لاء:
- جيڪڏهن اسان وٽ هڪ ننڍڙي ٽيبليٽ ۽ سٺي ڊسڪ آهي، يعني هڪ گيگا بائيٽ تائين جي ٽيبليٽ تي، اهو VACUUM FULL استعمال ڪرڻ بلڪل ممڪن آهي. هو توهان کان ڪجهه سيڪنڊن لاءِ ميز تي رکيل هڪ خاص تالا وٺي ڇڏيندو ۽ ٺيڪ آهي، پر هو سڀ ڪجهه جلدي ۽ سختيءَ سان ڪندو. VACUUM FULL ڇا ڪندو آهي؟ اهو ٽيبل تي هڪ خاص تالا وٺندو آهي ۽ پراڻي جدولن مان زندهه قطارن کي نئين ٽيبل ۾ ٻيهر لکندو آهي. ۽ آخر ۾ هو انهن کي تبديل ڪري ٿو. اهو پراڻن فائلن کي ختم ڪري ٿو ۽ پراڻين کي نئين سان تبديل ڪري ٿو. پر ان جي ڪم جي مدت لاء، ان کي ميز تي هڪ خاص تالا لڳن ٿا. هن جو مطلب آهي ته توهان هن ٽيبل سان ڪجهه به نٿا ڪري سگهو: نه ان تي لکو، نه ان ۾ پڙهو، نه ان کي تبديل ڪريو. ۽ VACUUM FULL ڊيٽا لکڻ لاءِ اضافي ڊسڪ اسپيس جي ضرورت آهي.
- ايندڙ اوزار . ان جي اصول ۾، اهو بلڪل VACUUM FULL سان ملندڙ جلندڙ آهي، ڇاڪاڻ ته اهو پڻ پراڻي فائلن مان ڊيٽا کي نئين فائلن ۾ ٻيهر لکندو آهي ۽ انهن کي ٽيبل ۾ تبديل ڪري ٿو. پر ساڳئي وقت، اهو پنهنجي ڪم جي شروعات ۾ ٽيبل تي هڪ خاص تالا نه وٺندو آهي، پر اهو صرف ان وقت وٺندو آهي جڏهن فائلن کي تبديل ڪرڻ لاء اڳ ۾ ئي تيار ڪيل ڊيٽا آهي. ان جي ڊسڪ ريسورس جون گهرجون VACUUM FULL سان ملندڙ جلندڙ آهن. توهان کي اضافي ڊسڪ اسپيس جي ضرورت آهي، ۽ اهو ڪڏهن ڪڏهن نازڪ هوندو آهي جيڪڏهن توهان وٽ ٽيرا بائيٽ ٽيبل آهن. ۽ اهو ڪافي پروسيسر بکيو آهي ڇاڪاڻ ته اهو فعال طور تي I / O سان ڪم ڪري ٿو.
- ٽيون افاديت آهي . اهو وسيلن سان وڌيڪ محتاط آهي ڇو ته اهو ٿورڙي مختلف اصولن جي مطابق ڪم ڪري ٿو. pgcompacttable جو بنيادي خيال اهو آهي ته اهو سڀني لائيو قطارن کي ٽيبل جي شروعات ڏانهن منتقل ڪري ٿو ٽيبل ۾ تازه ڪاري استعمال ڪندي. ۽ پوءِ اھو ھن ميز تي ھڪڙو خلا ھلي ٿو، ڇاڪاڻتہ اسان ڄاڻون ٿا ته اسان وٽ شروع ۾ زنده قطارون ۽ آخر ۾ مئل قطارون آھن. ۽ خلا پاڻ هن دم کي ڪٽي ٿو، يعني ان کي وڌيڪ ڊسڪ اسپيس جي ضرورت ناهي. ۽ ساڳئي وقت، اهو اڃا تائين وسيلن جي لحاظ کان نچوض ڪري سگهجي ٿو.
اوزار سان گڏ سڀ ڪجهه.
جيڪڏهن توهان ڳوليندا آهيو بلوٽ جو موضوع دلچسپ اندر اندر ڊيلنگ ڪرڻ جي لحاظ کان، هتي ڪجهه مفيد لنڪس آهن:
- - هي منهنجي ساٿي کان هڪ رپورٽ آهي. اهو عام آهي ته پوسٽ گريس جي جڳهه ان جي ڪم ۽ زندگي دوران ڪٿي وڃي ٿي. ۽ بلوٽ بابت ڊيٽابيس جي منتظمين لاءِ هڪ تمام وڏو ۽ تفصيلي ٽيڪنيڪل ٽڪرو آهي.
- - هي اسان جي مخزن جي هڪ لنڪ آهي، جتي اسان ڊيٽابيس جي حالت کي جانچڻ لاءِ مفيد اسڪرپٽ جو هڪ گروپ ذخيرو ڪندا آهيون. اتي توهان bloat ڳولڻ لاء اسڪرپٽ ڳولي سگهو ٿا.
- и اوزارن جا لنڪ جيڪي توهان جي نشانين کي گهٽائڻ ۾ مدد ڪندا.
- - هي منهنجي ساٿي کان هڪ پوسٽ آهي. اتي هو ڪافي سنجيدگيءَ سان ۽ ٽيڪنيڪل طور تي ايڊمنسٽريٽرن جي ويجهو سطح تي بلوٽ جو تفصيل سان تجزيو ڪري ٿو.
مون ڊولپرز لاءِ هڪ خوفناڪ ڪهاڻي ڏيکارڻ جي وڌيڪ ڪوشش ڪئي، ڇاڪاڻ ته اهي اسان جي ڊيٽابيس جا سڌو ڪلائنٽ آهن ۽ انهن کي سمجهڻ گهرجي ته ڪهڙا ۽ ڪهڙا عمل آهن. مون کي اميد آهي ته مان ڪامياب ٿي چڪو آهيان. توهان جي توجه لاء مهرباني!
توهان جا سوال
رپورٽ لاءِ مهرباني! توهان ڳالهايو ته توهان ڪيئن مسئلن جي نشاندهي ڪري سگهو ٿا. انهن کي ڪيئن ڊيڄاري سگهجي ٿو؟ اهو آهي، مون کي هڪ صورتحال هئي جتي درخواستون نه رڳو لڪي رهيون آهن ڇو ته انهن ڪجهه ٻاهرين خدمتن تائين رسائي حاصل ڪئي. اهي صرف ڪجهه جهنگلي شامل هئا. اتي ڪي ننڍڙا، بي ضرر درخواستون هيون، جيڪي هڪ ڏينهن لاءِ لٽڪنديون رهيون، ۽ پوءِ ڪجهه بڪواس ڪرڻ لڳيون. اهو آهي، جيڪو توهان بيان ڪيو آهي ان سان بلڪل ملندڙ جلندڙ آهي. هن کي ڪيئن ٽريڪ ڪرڻ لاء؟ بيٺو ۽ مسلسل ڏسو ته ڪهڙي درخواست بيٺو آهي؟ ان کي ڪيئن روڪي سگهجي ٿو؟
انهي صورت ۾، اهو توهان جي ڪمپني جي منتظمين لاء هڪ ڪم آهي، ضروري ناهي ته DBA لاء.
مان هڪ منتظم آهيان.
PostgreSQL ۾ pg_stat_activity نالي هڪ نظارو آهي، جيڪو ڏنگيل سوالن کي ڏيکاري ٿو. ۽ توهان ڏسي سگهو ٿا ته اهو ڪيترو ڊگهو آهي اتي.
ڇا مون کي اندر اچڻو پوندو ۽ هر 5 منٽن کي ڏسڻو پوندو؟
سيٽ اپ ڪرون ۽ چيڪ ڪريو. جيڪڏهن توهان وٽ ڊگهي مدت جي درخواست آهي، هڪ خط لکو ۽ اهو ئي آهي. اهو آهي، توهان کي پنهنجي اکين سان ڏسڻ جي ضرورت ناهي، اهو خودڪار ٿي سگهي ٿو. توھان کي ھڪڙو خط ملندو، توھان ان تي رد عمل ڪندا. يا توهان خودڪار طريقي سان گول ڪري سگهو ٿا.
ڇا اهڙا واضح سبب آهن ڇو ته ائين ٿئي ٿو؟
مون ڪجهه درج ڪيو آهي. ٻيا وڌيڪ پيچيده مثال. ۽ اتي هڪ ڊگهي وقت لاء هڪ ڳالهه ٻولهه ٿي سگهي ٿو.
رپورٽ لاءِ مهرباني! مون pg_repack افاديت بابت واضح ڪرڻ چاهيو. جيڪڏهن هوء هڪ خاص تالا نه ڪري، پوء ...
هوءَ هڪ خاص تالا لڳائي ٿي.
... پوء مان ممڪن طور تي ڊيٽا وڃائي سگهان ٿو. ڇا منهنجي درخواست کي هن وقت دوران ڪجهه به رڪارڊ نه ڪرڻ گهرجي؟
نه، اهو ٽيبل سان آسانيءَ سان ڪم ڪري ٿو، يعني pg_repack پهريون منتقل ڪري ٿو سڀني لائيو لائينون جيڪي موجود آهن. قدرتي طور، ميز ۾ داخل ٿيڻ جو ڪجهه قسم اتي ٿئي ٿو. هو صرف هن پوني ٽيل کي ٻاهر اڇلائي رهيو آهي.
اهو آهي، هو اصل ۾ آخر ۾ ڪندو آهي؟
آخر ۾، هو انهن فائلن کي مٽائڻ لاءِ هڪ خاص تالا وٺندو آهي.
ڇا اهو VACUUM FULL کان تيز ٿيندو؟
VACUUM FULL، جيئن ئي شروع ٿيو، فوري طور تي هڪ خاص تالا ڪڍيو. ۽ جيستائين هو سڀ ڪجهه نه ڪندو، تيستائين هن کي وڃڻ نه ڏيندو. ۽ pg_repack صرف فائل جي متبادل جي وقت تي هڪ خاص تالا وٺندو آهي. هن وقت توهان اتي نه لکندا، پر ڊيٽا گم نه ٿيندو، سڀ ڪجھ ٺيڪ ٿي ويندو.
سلام! توهان ڪار جي صفائي جي آپريشن بابت ڳالهايو. ڳاڙهي، پيلي ۽ سائي رڪارڊنگ سيلن سان گڏ هڪ گراف هو. اھو آھي، پيلو ھڪڙو - ھن انھن کي نشان لڳايو جيئن ختم ٿيل. ۽ نتيجي طور، انهن ۾ ڪجهه نئون لکي سگهجي ٿو؟
ها. Postgres لائنن کي ختم نٿو ڪري. هن وٽ اهڙي خاصيت آهي. جيڪڏهن اسان هڪ لڪير کي اپڊيٽ ڪيو، اسان پراڻي هڪ کي ختم ٿيل طور نشان لڳايو. ٽرانزيڪشن جو id جنهن هن لڪير کي تبديل ڪيو اتي ظاهر ٿئي ٿو، ۽ اسان هڪ نئين لائن لکون ٿا. ۽ اسان وٽ سيشن آھن جيڪي ممڪن طور تي انھن کي پڙھي سگھن ٿا. ڪنهن زماني ۾ اهي ڪافي پوڙها ٿي ويندا آهن. ۽ جوهر اهو آهي ته آٽو ويڪيوم ڪيئن ڪم ڪري ٿو اهو انهن لائينن مان گذري ٿو ۽ انهن کي غير ضروري طور نشان لڳايو. ۽ توھان اتي ڊيٽا کي مٿي ڪري سگھو ٿا.
مان سمجهان ٿو. پر اهو نه آهي جيڪو سوال بابت آهي. مون ختم نه ڪيو. اچو ته فرض ڪريو اسان وٽ هڪ ٽيبل آهي. ان ۾ variable سائيز جا شعبا آهن. ۽ جيڪڏهن مان ڪا نئين شيءِ داخل ڪرڻ جي ڪوشش ڪريان، ته اهو شايد پراڻي سيل ۾ مناسب نه هجي.
نه، ڪنهن به صورت ۾ سڄي لائن کي اپڊيٽ ڪيو ويندو آهي. Postgres وٽ ٻه ڊيٽا اسٽوريج ماڊل آهن. اهو ڊيٽا جي قسم مان چونڊيندو آهي. اتي ڊيٽا آھي جيڪا سڌو سنئون ٽيبل ۾ محفوظ ڪئي وئي آھي، ۽ اتي پڻ ڊيٽا آھي. اهي ڊيٽا جي وڏي مقدار آهن: متن، json. اهي الڳ الڳ پليٽ ۾ محفوظ آهن. ۽ انهن ٽيبلن جي مطابق، ساڳي ڪهاڻي بلوٽ سان ٿئي ٿي، يعني سڀ ڪجهه ساڳيو آهي. اهي صرف الڳ الڳ درج ٿيل آهن.
رپورٽ لاءِ مهرباني! ڇا مدت کي محدود ڪرڻ لاءِ بيان ٽائم آئوٽ سوالن کي استعمال ڪرڻ قابل قبول آھي؟
تمام قابل قبول. اسان اهو هر جڳهه استعمال ڪندا آهيون. ۽ جيئن ته اسان وٽ پنهنجون خدمتون نه آهن، اسان ريموٽ سپورٽ فراهم ڪندا آهيون، اسان وٽ ڪافي قسم جا گراهڪ آهن. ۽ هرڪو هن سان مڪمل طور تي مطمئن آهي. اهو آهي، اسان وٽ ڪرون نوڪريون آهن جيڪي چيڪ ڪن ٿيون. سيشن جي مدت صرف ڪلائنٽ سان اتفاق ڪيو ويو آهي، جنهن کان اڳ اسان متفق نه آهيون. اهو هڪ منٽ ٿي سگهي ٿو، اهو ٿي سگهي ٿو 10 منٽ. اهو بنياد تي لوڊ ۽ ان جي مقصد تي منحصر آهي. پر اسان سڀ استعمال ڪندا آهيون pg_stat_activity.
رپورٽ لاءِ مهرباني! مان توهان جي رپورٽ کي منهنجي درخواستن تي لاڳو ڪرڻ جي ڪوشش ڪري رهيو آهيان. ۽ اهو لڳي ٿو ته اسان هر جڳهه هڪ ٽرانزيڪشن شروع ڪندا آهيون، ۽ واضح طور تي هر جڳهه تي مڪمل ڪريو. جيڪڏهن ڪجهه استثنا آهي، ته پوء رول بيڪ اڃا به ٿئي ٿي. ۽ پوءِ مان سوچڻ لڳس. آخرڪار، ٽرانزيڪشن واضح طور تي شروع نه ٿي سگھي. اهو شايد ڇوڪري ڏانهن اشارو آهي. جيڪڏهن مان صرف هڪ رڪارڊ کي اپڊيٽ ڪيو، ڇا ٽرانزيڪشن PostgreSQL ۾ شروع ٿيندي ۽ صرف مڪمل ٿيندو جڏهن ڪنيڪشن ختم ٿي ويندو؟
جيڪڏھن توھان ھاڻي ڳالھائي رھيا آھيو ايپليڪيشن ليول بابت، پوءِ اھو منحصر آھي ڊرائيور تي جيڪو توھان استعمال ڪري رھيا آھيو، ORM تي جيڪو استعمال ڪيو پيو وڃي. اتي ڪيترائي سيٽنگون آھن. جيڪڏهن توهان خودڪار ڪمٽ تي فعال ڪيو آهي، پوء هڪ ٽرانزيڪشن اتي شروع ٿئي ٿو ۽ فوري طور تي بند ٿي ويندو.
اهو آهي، اهو فوري طور تي تازه ڪاري کان پوء بند ڪري ٿو؟
اهو سيٽنگن تي منحصر آهي. مون ھڪڙي سيٽنگ جو نالو ڏنو. هي خودڪار ڪم تي آهي. اهو ڪافي عام آهي. جيڪڏهن اهو فعال آهي، پوء ٽرانزيڪشن کوليو ۽ بند ڪيو ويو آهي. جيستائين توهان واضح طور تي چيو ته "ٽرانزيڪشن شروع ڪريو" ۽ "آخر ٽرانزيڪشن"، پر صرف سيشن ۾ هڪ درخواست شروع ڪئي.
سلام! رپورٽ لاءِ مهرباني! اچو ته تصور ڪريون ته اسان وٽ هڪ ڊيٽابيس آهي جيڪو سوز ۽ سوز آهي ۽ پوء سرور تي جاء ختم ٿي ويندي آهي. ڇا ھن صورتحال کي درست ڪرڻ لاءِ ڪي اوزار آھن؟
سرور تي خلا کي صحيح طور تي مانيٽر ڪرڻ جي ضرورت آهي.
مثال طور، DBA چانهه لاء ويو، هڪ تفريح تي هو، وغيره.
جڏهن هڪ فائيل سسٽم ٺاهي وئي آهي، گهٽ ۾ گهٽ ڪجهه قسم جي بيڪ اپ اسپيس ٺاهي وئي آهي جتي ڊيٽا نه لکيل آهي.
ڇا جيڪڏهن اهو مڪمل طور تي صفر کان هيٺ آهي؟
اتي ان کي رزروڊ اسپيس چئبو آهي، يعني ان کي آزاد ڪري سگهجي ٿو ۽ ان تي منحصر آهي ته اها ڪيتري وڏي ٺاهي وئي، توهان کي مفت جاءِ ملي ٿي. ڊفالٽ طور، مون کي خبر ناهي ته ڪيترا آهن. ۽ ٻي صورت ۾، ڊسڪ پهچايو ته جيئن توهان وٽ ڪمرو آهي تعميراتي آپريشن ڪرڻ لاء. توھان ڪجھھ ٽيبل کي ختم ڪري سگھو ٿا جنھن جي توھان کي ضرورت نه آھي.
ڇا ڪي ٻيا اوزار آھن؟
اهو هميشه هٿ سان ٺهيل آهي. ۽ مقامي طور تي اهو واضح ٿئي ٿو ته اتي ڇا ڪرڻ بهتر آهي، ڇاڪاڻ ته ڪجهه ڊيٽا نازڪ آهي ۽ ڪجهه غير نازڪ آهي. ۽ هر ڊيٽابيس ۽ ايپليڪيشن لاءِ جيڪو ان سان ڪم ڪري ٿو، اهو دارومدار تي آهي ڪاروبار. اهو هميشه مقامي طور تي فيصلو ڪيو ويو آهي.
رپورٽ لاءِ مهرباني! مون وٽ ٻه سوال آهن. پهرين، توهان ڏيکاريو سلائڊ جيڪي ڏيکاريا آهن ته جڏهن ٽرانزيڪشن بيٺا آهن، ٻنهي ٽيبل اسپيس سائيز ۽ انڊيڪس سائيز وڌندا آهن. ۽ وڌيڪ رپورٽ تي اتي افاديت جو هڪ گروپ هو جيڪو ٽيبليٽ کي پيڪيج ڪري ٿو. انڊيڪس بابت ڇا؟
انهن کي پڻ پيڪ ڪيو.
پر خلا انڊيڪس تي اثر انداز نٿو ڪري؟
ڪجهه ڪم هڪ انڊيڪس سان. مثال طور، pg_rapack، pgcompacttable. خلا انڊيڪس کي ٻيهر ٺاهي ٿو ۽ انهن کي متاثر ڪري ٿو. VACUUM FULL سان اهو خيال آهي ته هر شي کي اوور رائٽ ڪرڻ، يعني اهو هر ڪنهن سان ڪم ڪري ٿو.
۽ ٻيو سوال. مون کي سمجهه ۾ نه ٿو اچي ته ريپليڪس تي رپورٽون ايترو گهڻو انحصار پاڻ تي ئي آهن. مون کي ائين لڳي رهيو هو ته رپورٽون پڙهيا وڃن ٿا، ۽ نقل لکجن ٿيون.
نقل جي تڪرار جو سبب ڇا آهي؟ اسان وٽ ھڪڙو ماسٽر آھي جنھن تي عمل ٿئي ٿو. اسان وٽ ڪار ويڪيوم ٿي رهي آهي. هڪ autovacuum اصل ۾ ڇا ڪندو آهي؟ هو ڪجهه پراڻيون سٽون ڪڍي رهيو آهي. جيڪڏهن هن وقت اسان وٽ ريپليڪا تي هڪ درخواست آهي جيڪا اهي پراڻيون لائينون پڙهي، ۽ ماسٽر تي هڪ صورتحال پيدا ٿئي ٿي ته آٽو ويڪيوم انهن لائنن کي اوور رائٽنگ لاءِ ممڪن طور نشان لڳايو، پوءِ اسان انهن کي اوور رائٽ ڪري ڇڏيو. ۽ اسان هڪ ڊيٽا پيڪٽ حاصل ڪيو، جڏهن اسان کي انهن لائينن کي ٻيهر لکڻ جي ضرورت آهي جيڪا درخواست کي ريپليڪا تي گهربل آهي، نقل ڪرڻ وارو عمل توهان جي ترتيب ڏنل وقت جي انتظار ۾ ٿيندو. ۽ پوءِ PostgreSQL فيصلو ڪندو ته ان لاءِ وڌيڪ ڇا آهي. ۽ نقل هن لاءِ درخواست کان وڌيڪ اهم آهي، ۽ هو ريپليڪا تي اهي تبديليون ڪرڻ لاءِ درخواست کي شوٽ ڪندو.
اينڊريو، مون وٽ هڪ سوال آهي. اهي شاندار گرافس جيڪي توهان پريزنٽيشن دوران ڏيکاريا، ڇا اهي توهان جي ڪنهن قسم جي افاديت جي ڪم جو نتيجو آهن؟ گراف ڪيئن ٺاهيا ويا؟
هي هڪ خدمت آهي .
ڇا هي هڪ تجارتي پيداوار آهي؟
ها. هي هڪ تجارتي پيداوار آهي.
جو ذريعو: www.habr.com