هن جي ڳالهين ۾، اينڊري بوروڊن توهان کي ٻڌائيندو ته ڪنيڪشن پولر کي ڊزائين ڪرڻ وقت انهن پي جي بائونسر اسڪيلنگ جي تجربي کي ڪيئن سمجهيو. ، ڪيئن انهن ان کي پيداوار ۾ ٻاهر ڪڍيو. ان کان علاوه، اسان بحث ڪنداسين ته پولر جا ڪهڙا ڪم اسان نئين نسخن ۾ ڏسڻ چاهيندا: اهو اسان لاء ضروري آهي ته نه رڳو اسان جي ضرورتن کي پورو ڪرڻ، پر صارف جي ڪميونٽي کي ترقي ڪرڻ لاء. .
وڊيو:
هيلو سڀ! منهنجو نالو اينڊريو آهي.
Yandex تي، مان ترقي ڪري رهيو آهيان اوپن سورس ڊيٽابيس. ۽ اڄ اسان وٽ هڪ موضوع آهي ڪنيڪشن پولر ڪنيڪشن بابت.
جيڪڏھن توھان ڄاڻو ٿا ته ڪھڙي ريت ڪنيڪشن پولر کي روسي ۾، پوء مون کي ٻڌايو. مان واقعي هڪ سٺو ٽيڪنيڪل اصطلاح ڳولڻ چاهيان ٿو جيڪو فني ادب ۾ قائم ڪيو وڃي.
موضوع ڪافي پيچيده آهي، ڇاڪاڻ ته ڪيترن ئي ڊيٽابيس ۾ ڪنيڪشن پولر ٺهيل آهي ۽ توهان کي ان بابت ڄاڻڻ جي به ضرورت ناهي. ڪجهه سيٽنگون، يقينا، هر جڳهه آهن، پر پوسٽ گريس ۾ اهو ڪم نٿو ڪري. ۽ متوازي (HighLoad++ 2019 تي) پوسٽ گريس ۾ سوالن کي ترتيب ڏيڻ تي نڪولائي سموخولوف جي رپورٽ آهي. ۽ مان سمجهان ٿو ته اهي ماڻهو هتي آيا آهن جيڪي اڳ ۾ ئي درخواستن کي مڪمل طور تي ترتيب ڏئي چڪا آهن، ۽ اهي ماڻهو آهن جيڪي نيٽ ورڪ، وسيلن جي استعمال سان لاڳاپيل نادر سسٽم مسئلن سان منهن ڏيڻ وارا آهن. ۽ ڪجهه هنڌن تي اهو ڪافي ڏکيو ٿي سگهي ٿو ان معنى ۾ ته مسئلا واضح نه آهن.
Yandex ۾ Postgres آهي. ڪيتريون ئي Yandex خدمتون Yandex.Cloud ۾ رهن ٿيون. ۽ اسان وٽ ڊيٽا جا ڪيترائي پيٽابيٽس آهن جيڪي پوسٽ گريس ۾ في سيڪنڊ ۾ گهٽ ۾ گهٽ هڪ ملين درخواستون ٺاهيندا آهن.
۽ اسان سڀني خدمتن لاءِ عام طور تي عام ڪلستر مهيا ڪندا آهيون - هي نوڊ جو بنيادي بنيادي نوڊ آهي، عام طور تي ٻه ريپليڪس (هم وقت ساز ۽ هم وقت ساز)، بيڪ اپ، ريپليڪا تي پڙهڻ جي درخواستن جو اسڪيلنگ.
هر ڪلستر نوڊ پوسٽ گريس آهي، جنهن تي، پوسٽ گريس ۽ مانيٽرنگ سسٽم کان علاوه، هڪ ڪنيڪشن پولر پڻ نصب ٿيل آهي. ڪنيڪشن پولر کي باهه ڏيڻ ۽ ان جي بنيادي مقصد لاء استعمال ڪيو ويندو آهي.
ڪنيڪشن پولر جو بنيادي مقصد ڇا آهي؟
Postgres هڪ ڊيٽابيس سان ڪم ڪرڻ لاء هڪ پروسيس ماڊل اختيار ڪري ٿو. هن جو مطلب اهو آهي ته هڪ ڪنيڪشن هڪ عمل آهي، هڪ پوسٽ گريس پس منظر. ۽ ھن پسمنظر ۾ ڪيترائي مختلف ڪيش آھن، جيڪي مختلف ڪنيڪشن لاءِ مختلف ڪرڻ لاءِ ڪافي قيمتي آھن.
انهي سان گڏ، پوسٽ گريس ڪوڊ ۾ هڪ صف آهي جنهن کي procArray سڏيو ويندو آهي. اهو نيٽ ورڪ ڪنيڪشن بابت بنيادي ڊيٽا تي مشتمل آهي. ۽ لڳ ڀڳ سڀ procArray پروسيسنگ الگورٿمس ۾ لڪير جي پيچيدگي آهي، اهي نيٽ ورڪ ڪنيڪشن جي پوري صف ذريعي هلن ٿا. اهو هڪ تمام تيز چڪر آهي، پر وڌيڪ ايندڙ نيٽ ورڪ ڪنيڪشن سان، شيون ڪجهه وڌيڪ قيمتي ٿي وڃن ٿيون. ۽ جڏهن شيون ٿورو وڌيڪ مهانگو ٿي وڃن ٿيون، ته توهان نيٽ ورڪ ڪنيڪشن جي وڏي تعداد لاءِ تمام وڏي قيمت ادا ڪندا.
اتي 3 ممڪن طريقا آهن:
- درخواست جي پاسي تي.
- ڊيٽابيس جي پاسي تي.
- ۽ وچ ۾، اهو آهي، سڀ ممڪن مجموعا.
بدقسمتي سان، تعمير ٿيل پولر هن وقت ترقي هيٺ آهي. PostgreSQL Professional تي دوست گهڻو ڪري اهو ڪندا آهن. جڏهن اهو ظاهر ٿيندو ته اڳڪٿي ڪرڻ ڏکيو آهي. ۽ حقيقت ۾، اسان وٽ هڪ معمار جي چونڊ لاء ٻه حل آهن. اهي ايپليڪيشن-سائيڊ پول ۽ پراکسي پول آهن.
ايپليڪيشن-سائيڊ پول تمام آسان طريقو آهي. ۽ تقريبن سڀئي ڪلائنٽ ڊرائيور توهان کي هڪ طريقو مهيا ڪن ٿا: ڪوڊ ۾ توهان جي لکين ڪنيڪشن جي نمائندگي ڪرڻ لاءِ جيئن ته ڊيٽابيس سان ڪي درجن کن ڪنيڪشن.
حقيقت سان مسئلو آهي ته هڪ خاص نقطي تي توهان پس منظر کي ماپڻ چاهيو ٿا، توهان ان کي ڪيترن ئي ورچوئل مشينن تي لڳائڻ چاهيو ٿا.
پوءِ توھان اڃا تائين سمجھو ٿا ته توھان وٽ ڪيترائي وڌيڪ دستياب زون آھن ، ڪيترائي ڊيٽا مرڪز. ۽ ڪلائنٽ سائڊ پولنگ جو طريقو وڏي انگن اکرن ڏانهن وٺي ٿو. وڏا آهن اٽڪل 10 ڪنيڪشن. هي هڪ ڪنڊ آهي جيڪو سٺو ڪم ڪري سگهي ٿو.
جيڪڏهن اسان پراکسي پولرز جي باري ۾ ڳالهايون ٿا، ته اتي ٻه پولرز آهن جيڪي گهڻو ڪجهه ڪري سگهن ٿا. اهي نه رڳو پولر آهن. اهي پولر آهن + وڌيڪ ٿڌي ڪارڪردگي. هي и .
پر، بدقسمتي سان، هرڪو هن اضافي ڪارڪردگي جي ضرورت ناهي. ۽ اهو حقيقت ڏانهن وٺي ٿو ته پولرز صرف سيشن پولنگ جي حمايت ڪن ٿا، يعني هڪ ايندڙ ڪلائنٽ، ڊيٽابيس ڏانهن هڪ ٻاهر نڪرندڙ ڪلائنٽ.
اهو اسان جي ڪمن لاءِ بلڪل موزون ناهي، تنهن ڪري اسان استعمال ڪريون ٿا PgBouncer، جيڪو ٽرانزيڪشن پولنگ کي لاڳو ڪري ٿو، يعني سرور ڪنيڪشن صرف ٽرانزيڪشن جي مدت لاءِ ڪلائنٽ ڪنيڪشن سان ميپ ٿيل آهن.
۽ اسان جي لوڊ تي - اهو سچ آهي. پر اتي ڪيترائي مسئلا آهن.
مسئلا تڏهن شروع ٿين ٿا جڏهن توهان هڪ سيشن جي تشخيص ڪرڻ چاهيو ٿا، ڇاڪاڻ ته سڀ ايندڙ ڪنيڪشن مقامي آهن. هرڪو لوپ بيڪ سان آيو ۽ ڪنهن نه ڪنهن طرح سيشن کي ٽريڪ ڪرڻ ڏکيو ٿي پيو.
يقينا توهان استعمال ڪري سگهو ٿا application_name_add_host. هي آهي بائونسر طرف جو طريقو هڪ IP پتي کي شامل ڪرڻ لاءِ application_name. پر application_name هڪ اضافي ڪنيڪشن ذريعي مقرر ڪيو ويو آهي.
ھن چارٽ تي، جتي پيلي لڪير حقيقي درخواستون آھن، ۽ جتي نيري لڪير درخواستون آھن جيڪي ڊيٽابيس ۾ پرواز ڪن ٿيون. ۽ اهو فرق بلڪل Application_name جي سيٽنگ جو آهي، جيڪو صرف ٽريڪنگ لاءِ گهربل آهي، پر اهو بلڪل مفت ناهي.
اضافي طور تي، باؤنسر هڪ پول کي محدود نٿو ڪري سگهي، يعني ڊيٽابيس ڪنيڪشن جو تعداد في صارف، في ڊيٽابيس.
هي ڪهڙي طرف وٺي ٿو؟ توهان وٽ هڪ لوڊ ٿيل سروس آهي جيڪا C ++ ۾ لکيل آهي ۽ ويجھي ڪنهن نوڊ تي هڪ ننڍڙي خدمت جيڪا بيس سان ڪجهه به غلط نه ڪندي آهي، پر ان جو ڊرائيور چريو ٿي ويندو آهي. اهو 20 ڪنيڪشن کوليندو آهي ۽ باقي سڀ ڪجهه انتظار ڪندو. جيتوڻيڪ توهان جو ڪوڊ صحيح آهي.
يقينن، اسان Bouncer لاءِ هڪ ننڍڙو پيچ لکيو جنهن هن سيٽنگ کي شامل ڪيو، يعني ڪلائنٽ کي پول تائين محدود ڪرڻ.
اهو ممڪن ٿيندو ته پوسٽ گريس جي پاسي تي، يعني ڊيٽابيس ۾ ڪردارن کي ڪنيڪشن جي تعداد تائين محدود ڪريو.
پر پوءِ توھان سمجھڻ جي صلاحيت وڃائي ويٺا آھيو ته توھان جو سرور سان ڪو رابطو ڇو نه آھي. PgBouncer ڪنيڪشن جي غلطي نه ٿو اڇلائي، اهو هميشه ساڳئي معلومات موٽائي ٿو. ۽ توهان سمجهي نٿا سگهو: ٿي سگهي ٿو توهان جو پاسورڊ تبديل ٿي ويو آهي، ٿي سگهي ٿو ڊيٽابيس صرف هيٺ ٿي ويو، ٿي سگهي ٿو ڪجهه غلط آهي. پر ڪا به تشخيص نه آهي. جيڪڏهن سيشن قائم نه ٿي سگهي، توهان کي خبر ناهي ته اهو ڇو نه ٿو ڪري سگهجي.
هڪ خاص نقطي تي، توهان اپليڪيشن جي گرافس کي ڏسو ۽ ڏسو ته ايپليڪيشن ڪم نه ڪري رهي آهي.
مٿي تي ڏسو ۽ ڏسو ته Bouncer اڪيلو ڌاڳو آهي. هي خدمت جي زندگي ۾ هڪ موڙ آهي. توھان سمجھو ٿا ته توھان تيار ڪري رھيا ھئا ڊيٽابيس کي ماپڻ لاءِ سال ۽ اڌ ۾، ۽ توھان کي ضرورت آھي پولر کي ماپڻ جي.
اسان ان نتيجي تي پهتا آهيون ته اسان کي وڌيڪ PgBouncers جي ضرورت آهي.
باؤنسر کي ٿورڙو پيچ ڪيو ويو آهي.
۽ انهن اهو ٺاهيو ته جيئن TCP بندرگاهه جي ٻيهر استعمال سان ڪيترائي بائونسر اٿاريا وڃن. ۽ اڳ ۾ ئي آپريٽنگ سسٽم خودڪار طريقي سان منتقل ڪري ٿو ايندڙ TCP ڪنيڪشن انهن جي وچ ۾ گول-روبينوم ذريعي.
هي ڪلائنٽ لاءِ شفاف آهي، يعني اهو لڳي ٿو ته توهان وٽ هڪ بائونسر آهي، پر توهان وٽ بيڪار ڪنيڪشن جو ٽڪراءُ آهي هلندڙ بائونسر جي وچ ۾.
۽ ڪجهه نقطي تي، توهان محسوس ڪري سگهون ٿا ته اهي 3 باؤنسر هر هڪ پنهنجي بنيادي کي 100٪ کائيندا آهن. توھان کي ضرورت آھي ڪافي ڪجھ بائونسر. ڇو؟
ڇو ته توهان وٽ TLS آهي. توھان وٽ ھڪڙو ڳجھو ڪنيڪشن آھي. ۽ جيڪڏهن توهان TLS سان ۽ بغير پوسٽ گريس کي بينچ مارڪ ڪيو ٿا، توهان کي معلوم ٿيندو ته قائم ڪيل ڪنيڪشن جو تعداد تقريباً ٻن آرڊرن جي شدت سان گهٽجي ٿو انڪريپشن سان، ڇاڪاڻ ته TLS هٿ ملائڻ CPU وسيلن کي استعمال ڪري ٿو.
۽ مٿي ۾، توهان ڏسي سگهو ٿا ڪافي ڪجهه cryptographic افعال جيڪي ايندڙ ڪنيڪشن جي موج دوران جاري ڪيا ويا آهن. جيئن ته اسان جي پرائمري دستيابي زونن جي وچ ۾ مٽائي سگھي ٿي، ايندڙ رابطن جي ھڪڙي موج ھڪڙي عام صورتحال آھي. اهو آهي، ڪجهه سببن لاء، پراڻي پرائمري دستياب نه هئي، سڄو لوڊ ٻئي ڊيٽا سينٽر ڏانهن موڪليو ويو. اهي سڀ هڪ ئي وقت TLS کي هيلو چوڻ لاءِ ايندا.
۽ TLS هٿ ملائڻ جو وڏو تعداد شايد اڳ ۾ ئي بائونسر کي سلام نه ڪري، پر هن جي ڳلي کي دٻائي. ايندڙ ڪنيڪشن جي هڪ لهر وقت ختم ٿيڻ جي ڪري اڻڄاتل ٿي سگهي ٿي. جيڪڏهن توهان وٽ بي بنياد تي ٻيهر ڪوشش ڪئي وئي آهي بغير ڪنهن exponential backoff جي، اهي واپس نه ايندا ۽ هڪ مربوط موج ۾.
هتي 16 PgBouncers جو هڪ مثال آهي جيڪو 16 ڪور تي 100٪ لوڊ ڪري ٿو.
اسان cascading PgBouncer تي پهچي ويا آهيون. هي بهترين ترتيب آهي جيڪو اسان حاصل ڪري سگهون ٿا اسان جي باؤنسر لوڊ تي. اسان جا خارجي بائونسر TCP ھٿ شيڪ لاءِ ڪم ڪن ٿا، ۽ اندروني باؤنسر حقيقي پولنگ لاءِ ڪم ڪن ٿا، انھيءَ لاءِ ته ٻاهرين ڪنيڪشن کي گھڻو ٽڪرا ٽڪرا نه ڪيو وڃي.
هن ترتيب ۾، هڪ نرم ٻيهر شروع ڪرڻ ممڪن آهي. توهان انهن سڀني 18 بائونسر کي هڪ هڪ ڪري ٻيهر شروع ڪري سگهو ٿا. پر اهڙي ترتيب کي برقرار رکڻ تمام ڏکيو آهي. سسٽم منتظمين، DevOps، ۽ ماڻهو جيڪي واقعي هن سرور جا ذميوار آهن هن اسڪيم سان تمام گهڻو خوش نه ٿيندا.
اهو لڳي ٿو ته اسان جي سڀني سڌارن کي اوپن سورس ۾ ترقي ڪري سگهجي ٿو، پر بائونسر تمام سٺو سپورٽ نٿو ڪري. مثال طور، ساڳئي بندرگاهن تي ڪيترن ئي PgBouncers کي هلائڻ جي صلاحيت هڪ مهينو اڳ ڪئي وئي هئي. ھن خصوصيت سان ھڪڙي ڇڪڻ جي درخواست ڪجھ سال اڳ ھئي.
يا هڪ وڌيڪ مثال. Postgres ۾، توهان اضافي تصديق جي بغير ڪنهن ٻئي ڪنيڪشن ڏانهن راز موڪلڻ ذريعي هلندڙ درخواست کي منسوخ ڪري سگهو ٿا. پر ڪجهه گراهڪ صرف هڪ TCP-ري سيٽ موڪليندا آهن، يعني اهي نيٽ ورڪ ڪنيڪشن ٽوڙيندا آهن. بائونسر ان سان ڇا ڪندو؟ هو ڪجهه به نه ڪندو. اهو درخواست تي عمل ڪرڻ جاري رکندو. جيڪڏهن توهان ڪنيڪشن جو هڪ وڏو تعداد حاصل ڪيو آهي جنهن جو بنياد ننڍين درخواستن سان رکيل آهي، ته پوءِ صرف بائونسر کان ڪنيڪشن ختم ڪرڻ ڪافي نه هوندو، توهان کي انهن درخواستن کي به مڪمل ڪرڻو پوندو جيڪي ڊيٽابيس ۾ هلندڙ آهن.
اهو پيچ ڪيو ويو آهي ۽ مسئلو اڃا تائين بائونسر جي اپ اسٽريم ۾ ضم نه ڪيو ويو آهي.
۽ تنهنڪري اسان ان نتيجي تي پهتاسين ته اسان کي پنهنجي ڪنيڪشن پولر جي ضرورت آهي، جيڪا ترقي ڪئي ويندي، پيچ ٿيل، جنهن ۾ اهو ممڪن ٿيندو ته جلدي مسئلن کي حل ڪرڻ ۽ جيڪو، يقينا، گهڻن موضوعن وارو هجڻ گهرجي.
اسان ملٽي ٿريڊنگ کي بنيادي ڪم طور مقرر ڪيو. اسان کي ايندڙ TLS ڪنيڪشن جي موج کي چڱي طرح سنڀالڻ جي قابل ٿيڻو پوندو.
ائين ڪرڻ لاءِ، اسان کي مشينريم نالي هڪ الڳ لائبريري ٺاهڻي هئي، جيڪا هڪ نيٽ ورڪ ڪنيڪشن جي مشين رياستن کي سيريل ڪوڊ طور بيان ڪرڻ لاءِ ٺهيل آهي. جيڪڏهن توهان libpq سورس ڪوڊ تي نظر وجهو ٿا، توهان کي ڪافي پيچيده ڪالون نظر اينديون جيڪي توهان کي نتيجو ڏئي سگهن ٿيون ۽ چوندا آهن، "مون کي ٿوري دير کان پوء ڪال ڪريو. ھاڻي مون وٽ ھاڻي IO آھي، پر جڏھن IO گذري ٿو، مون وٽ پروسيسر تي لوڊ آھي. ۽ هي هڪ گهڻ سطحي اسڪيم آهي. نيٽ ورڪ رابطي عام طور تي بيان ڪيو ويندو آهي رياست مشين طرفان. ڪيترائي ضابطا جيئن ته "جيڪڏهن مون کي اڳ ۾ هڪ پيڪٽ هيڊر حاصل ڪيو ويو آهي N سائيز، پوء هاڻي مان انتظار ڪري رهيو آهيان N بائيٽس"، "جيڪڏهن مون هڪ SYNC پيڪٽ موڪليو، ته هاڻي مان نتيجو ميٽا ڊيٽا سان گڏ هڪ پيڪٽ جو انتظار ڪري رهيو آهيان." اهو هڪ بلڪه ڏکيو انسداد بدعنواني ڪوڊ نڪرندو آهي، ڄڻ ته بھولبلييا کي هڪ لائن اسڪين ۾ تبديل ڪيو ويو آهي. اسان ان کي ٺاهيو ته رياستي مشين جي بدران، پروگرامر عام لازمي ڪوڊ جي صورت ۾ مکيه رابطي واري رستي کي بيان ڪري ٿو. بس هن لازمي ڪوڊ ۾، توهان کي انهن هنڌن کي داخل ڪرڻ جي ضرورت آهي جتي عملدرآمد جي ترتيب کي مداخلت ڪرڻ جي ضرورت آهي نيٽ ورڪ مان ڊيٽا جي انتظار ۾، عملدرآمد جي حوالي سان ٻئي ڪورين (سائي موضوع) ڏانهن منتقل ڪندي. اهو طريقو انهي حقيقت سان ملندڙ جلندڙ آهي ته اسان هڪ قطار ۾ سڀ کان وڌيڪ متوقع رستو لکون ٿا، ۽ پوء ان ۾ شاخون شامل ڪريو.
نتيجي طور، اسان وٽ ھڪڙو ٿريڊ آھي جيڪو TCP قبول ڪري ٿو ۽ راؤنڊ-رابن ڪيترن ئي ڪارڪنن کي TPC ڪنيڪشن پاس ڪري ٿو.
انهي حالت ۾، هر ڪلائنٽ ڪنيڪشن هميشه هڪ پروسيسر تي هلندو آهي. ۽ هي توهان کي اجازت ڏئي ٿو ته ان کي ڪيش-دوست بڻائڻ.
۽ ان کان علاوه، اسان ٿورڙو بهتر ڪيو آهي ننڍڙن پيڪٽن جي مجموعن کي هڪ وڏي پئڪيٽ ۾ ترتيب ڏيڻ لاءِ سسٽم TCP اسٽيڪ کي آف لوڊ ڪرڻ لاءِ.
ان کان علاوه، اسان ٽرانزيڪشن پولنگ کي ان لحاظ کان بهتر ڪيو آهي ته Odyssey، جڏهن ترتيب ڏنل هجي، نيٽ ورڪ ڪنيڪشن جي ناڪامي جي صورت ۾ CANCEL ۽ ROLLBACK موڪلي سگهي ٿي، يعني جيڪڏهن ڪو به درخواست جو انتظار نه ڪري رهيو آهي، Odyssey ڊيٽابيس کي ٻڌائيندو ته پوري ڪرڻ جي ڪوشش نه ڪئي وڃي. درخواست جيڪا قيمتي وسيلن کي ضايع ڪري سگهي ٿي.
۽ جڏهن به ممڪن هجي، اسان ساڳئي ڪلائنٽ سان ڪنيڪشن رکون ٿا. هي ايپليڪيشن_نام_add_host کي ٻيهر انسٽال ڪرڻ کان پاسو ڪري ٿو. جيڪڏهن ممڪن هجي، ته پوءِ اسان وٽ پيٽرول جي اضافي ريٽ نه آهي جيڪي تشخيص لاءِ گهربل آهن.
اسان Yandex.Cloud جي مفاد ۾ ڪم ڪريون ٿا. ۽ جيڪڏھن توھان استعمال ڪري رھيا آھيو منظم PostgreSQL ۽ توھان وٽ ھڪڙو ڪنيڪشن پولر نصب آھي، توھان ٺاھي سگھوٿا منطقي نقل ٻاھران، يعني جيڪڏھن توھان چاھيو، اسان کي ڇڏي ڏيو، منطقي نقل استعمال ڪندي. منطقي نقل جي وهڪري کان ٻاهر Bouncer نه ڏيندو.
هي منطقي نقل قائم ڪرڻ جو هڪ مثال آهي.
ان کان علاوه، اسان وٽ فزيڪل نقل لاءِ مدد آهي ٻاهران. Cloud ۾، يقينا، اهو ناممڪن آهي، ڇو ته پوء ڪلستر توهان کي پنهنجي باري ۾ تمام گهڻو معلومات ڏيندو. پر توهان جي تنصيب ۾، جيڪڏهن توهان کي اوڊيسي ۾ ڪنيڪشن پولر ذريعي جسماني نقل جي ضرورت آهي، اهو ممڪن آهي.
Odyssey PgBouncer سان مڪمل طور تي مطابقت رکندڙ نگراني ڪئي آهي. اسان وٽ ساڳيو ڪنسول آهي جيڪو لڳ ڀڳ سڀني ساڳين حڪمن تي عمل ڪري ٿو. جيڪڏهن ڪجهه غائب آهي، هڪ پل جي درخواست موڪليو، يا گهٽ ۾ گهٽ هڪ مسئلو GitHub تي، اسان ضروري حڪمن کي مڪمل ڪنداسين. پر اسان وٽ اڳ ۾ ئي PgBouncer ڪنسول جي مکيه ڪارڪردگي آهي.
۽ يقينا اسان وٽ غلطي آهي اڳتي وڌڻ. اسان بنيادي طرفان رپورٽ ڪيل غلطي واپس ڪنداسين. توهان کي اها ڄاڻ ملندي ته توهان بنيادي ڇو نه آهيو، نه رڳو اهو ته توهان ان ۾ نه آهيو.
ھي خصوصيت غير فعال آھي جيڪڏھن توھان کي ضرورت آھي 100٪ PgBouncer سان مطابقت. اسان Bouncer وانگر عمل ڪري سگهون ٿا، صرف صورت ۾.
ترقي
Odyssey سورس ڪوڊ بابت ڪجھ لفظ.
مثال طور، اتي آهن "Pause / Resume" حڪم. اهي عام طور تي ڊيٽابيس کي تازه ڪاري ڪرڻ لاء استعمال ٿيندا آهن. جيڪڏهن توهان پوسٽ گريس کي اپڊيٽ ڪرڻ جي ضرورت آهي، توهان ان کي ڪنيڪشن پولر ۾ روڪي سگهو ٿا، هڪ ڪريو pg_upgrade، پوء ٻيهر شروع ڪريو. ۽ ڪلائنٽ جي پاسي کان، اهو ڏسڻ ۾ ايندو ته ڊيٽابيس صرف سست ٿي رهيو هو. هي ڪارڪردگي اسان کي ڪميونٽي جي ماڻهن طرفان آندو ويو آهي. هوءَ اڃا مري نه وئي آهي، پر جلد ئي سڀ ڪجهه ٿي ويندو. (اڳ ۾ ئي مري ويو)
- اڳ ئي مري ويو
ان کان علاوه، PgBouncer ۾ نئين خاصيتن مان هڪ آهي SCRAM تصديق جي حمايت، جيڪو پڻ اسان وٽ آندو ويو آهي هڪ شخص جيڪو Yandex.Cloud ۾ ڪم نٿو ڪري. ٻئي پيچيده ڪارڪردگي ۽ اهم آهن.
تنهن ڪري، مان توهان کي ٻڌائڻ چاهيان ٿو ته Odyssey ڇا مان ٺهيل آهي، جيڪڏهن توهان پڻ ڪجهه ڪوڊ لکڻ چاهيو ٿا.
توهان وٽ اصل اوڊيسي جو بنياد آهي، جيڪو ٻن مکيه لائبريرين تي ڀاڙي ٿو. ڪيوي لائبريري پوسٽ گريس ميسيج پروٽوڪول جو نفاذ آهي. اھو آھي، پوسٽ گريس جو اصلي پروٽو 3 معياري پيغام آھي جيڪو فرنٽ اينڊ ۽ پس منظر تبديل ڪري سگھن ٿا. اهي Kiwi لائبريري ۾ لاڳو آهن.
مشينريم لائبريري هڪ ٿريڊ پليل لائبريري آهي. هن مشينري جو هڪ ننڍڙو ٽڪرو assembler ۾ لکيل آهي. پر پريشان نه ڪريو، صرف 15 لائينون آھن.
اوڊيسي فن تعمير. اتي هڪ مکيه مشين آهي cooutines ڊوڙندو. هي مشين ايندڙ TCP ڪنيڪشن کي قبول ڪرڻ ۽ ڪارڪنن ۾ ورهائڻ کي لاڳو ڪري ٿي.
هڪ ڪم ڪندڙ اندر، ڪيترن ئي گراهڪن لاء هڪ سنڀاليندڙ ڪم ڪري سگهي ٿو. ۽ پڻ مکيه سلسلي ۾، ڪنسولز ۽ ڪنيڪشن کي ختم ڪرڻ لاء ڪرون ڪمن جي پروسيسنگ جيڪي هاڻي پول ۾ گهربل نه آهن گھمائي رهيا آهن.
Odyssey معياري پوسٽ گريس ٽيسٽ سوٽ استعمال ڪندي آزمايو ويو آهي. اسان صرف هلون ٿا انسٽال چيڪ بائونسر ذريعي ۽ اوڊيسي جي ذريعي، اسان حاصل ڪيو هڪ null div. تاريخ جي فارميٽنگ سان لاڳاپيل ڪيترائي تجربا آهن جيڪي بائونسر ۽ اوڊيسي ۾ بلڪل ساڳيا ناڪام ٿين ٿا.
ان کان سواء، ڪيترائي ڊرائيور آھن جن کي پنھنجي جاچ پڙتال آھي. ۽ اسان اوڊيسي کي جانچڻ لاءِ انهن جا تجربا استعمال ڪندا آهيون.
انهي سان گڏ، اسان جي cascading ترتيب جي ڪري، اسان کي مختلف بنڊلن کي جانچڻو پوندو: Postgres + Odyssey، PgBouncer + Odyssey، Odyssey + Odyssey انهي ڳالهه کي يقيني بڻائڻ لاءِ ته جيڪڏهن اوڊيسي ڪاسڪيڊ جي ڪنهن به حصي ۾ آهي، اهو اڃا به ڪم ڪري ٿو توقع جي مطابق. .
ريڪ
اسان پيداوار ۾ Odyssey استعمال ڪندا آهيون. ۽ اهو صحيح نه ٿيندو جيڪڏهن مان چوان ته سڀ ڪجهه صرف ڪم ڪري ٿو. نه، يعني ها، پر هميشه نه. مثال طور، پيداوار ۾ سڀ ڪجھ ڪم ڪيو، پوء اسان جا دوست PostgreSQL Professional کان آيا ۽ چيو ته اسان وٽ ميموري ليک آهي. اهي واقعي هئا، اسان انهن کي درست ڪيو. پر اهو سادو هو.
پوءِ اسان ڏٺو ته ڪنيڪشن پولر وٽ ايندڙ TLS ڪنيڪشن ۽ ٻاھرين TLS ڪنيڪشن آھن. ۽ ڪنيڪشن کي ڪلائنٽ سرٽيفڪيٽ ۽ سرور سرٽيفڪيٽ جي ضرورت آهي.
Bouncer ۽ Odyssey سرور سرٽيفڪيٽ pcache ذريعي ٻيهر پڙهيا ويندا آهن، پر ڪلائنٽ سرٽيفڪيٽن کي pcache مان ٻيهر پڙهڻ جي ضرورت ناهي، ڇو ته اسان جي اسپيبلبل Odyssey آخرڪار هن سرٽيفڪيٽ کي پڙهڻ جي سسٽم جي ڪارڪردگي تي منحصر آهي. اها ڳالهه اسان لاءِ حيران ڪندڙ ڳالهه هئي، ڇاڪاڻ ته هن فوري طور تي آرام نه ڪيو. شروعات ۾، ان کي لڪير سان ماپ ڪيو ويو، ۽ 20 ايندڙ ايندڙ هڪ ئي وقت ڪنيڪشن کان پوء، اهو مسئلو پاڻ کي ظاهر ڪيو.
پلگ ايبل تصديق جو طريقو بلٽ ان لينڪس ٽولز سان تصديق ڪرڻ جي صلاحيت آهي. PgBouncer ۾، اهو اهڙي طرح لاڳو ڪيو ويو آهي ته اتي هڪ الڳ موضوع آهي PAM کان جواب جي انتظار ۾ ۽ هڪ مکيه PgBouncer سلسلي آهي جيڪو موجوده ڪنيڪشن جي خدمت ڪري ٿو ۽ انهن کي PAM سلسلي ۾ رهڻ لاء پڇي سگهي ٿو.
اسان هڪ سادي سبب لاء هن تي عمل نه ڪيو. اسان وٽ ڪيترائي وهڪرو آهن. اسان کي ان جي ضرورت ڇو آهي؟
نتيجي طور، اهو مسئلو پيدا ڪري سگھي ٿو ته جيڪڏھن توھان وٽ آھي PAM جي تصديق ۽ غير PAM جي تصديق، پوء PAM جي تصديق جي ھڪڙي وڏي لهر غير PAM جي تصديق کي دير ڪري سگھي ٿي. اهو انهن شين مان هڪ آهي جنهن کي اسان مقرر نه ڪيو آهي. پر جيڪڏھن توھان ان کي درست ڪرڻ چاھيو ٿا، توھان ھي ڪري سگھو ٿا.
هڪ ٻيو ريڪ حقيقت سان هو ته اسان وٽ هڪ موضوع آهي جيڪو سڀني ايندڙ ڪنيڪشن کي قبول ڪري ٿو. ۽ پوءِ اهي ڪم ڪندڙ تلاءَ ڏانهن منتقل ڪيا ويندا آهن، جتي TLS هٿ ملائي ويندي.
نتيجي طور، جيڪڏهن توهان وٽ 20 نيٽ ورڪ ڪنيڪشن جي هڪ همعصر لهر آهي، اهي سڀئي قبول ڪيا ويندا. ۽ ڪلائنٽ جي پاسي، libpq رپورٽنگ ٽائم آئوٽ شروع ڪندو. ڊفالٽ طور، اهو 000 سيڪنڊن وانگر آهي.
جيڪڏهن اهي سڀ هڪ ئي وقت بنياد ۾ داخل نٿا ٿي سگهن، ته پوءِ اهي بنيادي ۾ داخل نه ٿا ٿي سگهن، ڇاڪاڻ ته اهو سڀ ڪجهه هڪ غير متوقع ٻيهر ڪوشش سان ڍڪي سگهجي ٿو.
اسان هتي PgBouncer اسڪيم کي نقل ڪري ختم ڪيو ته جيئن اسان قبول ڪريون ٿا TCP ڪنيڪشن جي تعداد کي ڇڪايو.
جيڪڏهن اسان ڏسون ٿا ته اسان ڪنيڪشن قبول ڪري رهيا آهيون، پر انهن وٽ آخر ۾ هٿ ملائڻ جو وقت ناهي، اسان انهن کي قطار ۾ رکون ٿا ته جيئن اهي سي پي يو وسيلن کي استعمال نه ڪن. اهو حقيقت ڏانهن وٺي ٿو ته هڪ ئي وقت ۾ هٿ ملائڻ ممڪن نه آهي سڀني ڪنيڪشن لاء جيڪي پهچي ويا آهن. پر گهٽ ۾ گهٽ ڪو ماڻهو ڊيٽابيس ۾ داخل ٿيندو، جيتوڻيڪ لوڊ ڪافي مضبوط آهي.
روڊ ميپ
اوڊيسي ۾ توهان مستقبل ۾ ڇا ڏسڻ چاهيندا؟ ڇا اسان پاڻ کي ترقي ڪرڻ لاء تيار آهيون ۽ اسان کي ڪميونٽي کان ڇا اميد آهي؟
آگسٽ 2019 لاء.
اھو اھو آھي جيڪو Odyssey روڊ ميپ آگسٽ ۾ نظر آيو:
- اسان چاهيون ٿا SCRAM ۽ PAM جي تصديق.
- اسان پڙهڻ جي درخواستن کي اسٽينڊ بائي ڏانهن اڳتي وڌائڻ چاهيون ٿا.
- مان آن لائن ٻيهر شروع ڪرڻ چاهيان ٿو.
- ۽ سرور تي روڪڻ جي صلاحيت.
هن روڊ ميپ جو اڌ ڪم ڪيو ويو آهي، ۽ اسان طرفان نه. ۽ هي سٺو آهي. تنهن ڪري اچو ته بحث ڪريون ته ڇا بچيو آهي ۽ وڌيڪ شامل ڪريو.
؟ اسان وٽ نقل آهن جيڪي، درخواستن کي پورو ڪرڻ کان سواء، صرف هوا کي گرم ڪندا. اسان کي انهن جي ضرورت آهي ناڪامي ۽ سوئچ اوور مهيا ڪرڻ لاءِ. ڊيٽا سينٽرن مان هڪ ۾ مسئلن جي صورت ۾، آئون انهن کي ڪجهه مفيد ڪم سان قبضو ڪرڻ چاهيندس. ڇاڪاڻ ته اسان ساڳيا مرڪزي پروسيسرز کي ترتيب نه ٿا ڏئي سگهون، ساڳي ميموري مختلف طريقي سان، ڇاڪاڻ ته نقل ٻي صورت ۾ ڪم نه ڪندي.
اصول ۾، پوسٽ گريس ۾، 10 کان شروع ٿيندڙ، اهو ممڪن آهي سيشن_attrs بيان ڪرڻ جڏهن ڳنڍڻ. توھان ڪنيڪشن ۾ سڀني ڊيٽابيس ھوسٽن کي لسٽ ڪري سگھو ٿا ۽ چئو ڇو توھان ڊيٽابيس ڏانھن وڃي رھيا آھيو: صرف لکو يا پڙھو. ۽ ڊرائيور پاڻ کي لسٽ تي پهريون ميزبان چونڊيندو جيڪو اهو بهترين پسند ڪندو، جيڪو سيشن_attrs جي گهرجن کي پورو ڪري ٿو.
پر هن طريقي سان مسئلو اهو آهي ته اهو نقل جي وقف کي ڪنٽرول نٿو ڪري. توهان وٽ شايد ڪجهه قسم جي نقل آهي جيڪا توهان جي خدمت لاء ناقابل قبول وقت جي پويان آهي. ھڪڙي ريپليڪا تي پڙھڻ جي درخواستن جي مڪمل خصوصيت تي عمل ڪرڻ لاء، حقيقت ۾، اسان کي اوڊيسي ۾ مدد ڪرڻ جي ضرورت آھي ڪم نه ڪرڻ جي صلاحيت جڏھن پڙھڻ ناممڪن آھي.
اوڊيسي کي وقت بوقت ڊيٽابيس ڏانهن وڃڻو پوندو آهي ۽ پرائمري کان نقل جي فاصلي لاءِ پڇڻو پوندو آهي. ۽ جيڪڏهن اهو حد تائين پهچي ويو آهي، ڊيٽابيس ۾ نئين درخواستون نه ڏيو، ڪلائنٽ کي ٻڌايو ته توهان کي ڪنيڪشن ٻيهر شروع ڪرڻ جي ضرورت آهي، ۽ ممڪن آهي، درخواستن تي عمل ڪرڻ لاء هڪ ٻيو ميزبان چونڊيو. هي ڊيٽابيس کي اجازت ڏيندو ته جلدي ريپليڪشن ليگ کي بحال ڪري ۽ سوال سان جواب ڏيڻ لاءِ ٻيهر واپس اچي.
ان تي عملدرآمد جي تاريخن جو نالو ڏيڻ ڏکيو آهي، ڇاڪاڻ ته اهو کليل ذريعو آهي. پر، مون کي اميد آهي، نه 2,5 سال PgBouncer کان ساٿين وانگر. اها خاصيت آهي جيڪا مان اوڊيسي ۾ ڏسڻ چاهيندس.
. هاڻي توهان ٻن طريقن سان تيار ڪيل بيان ٺاهي سگهو ٿا. پهرين، توهان هڪ SQL حڪم جاري ڪري سگهو ٿا، يعني "تيار". ھن SQL ڪمانڊ کي سمجھڻ لاءِ، اسان کي سکڻو پوندو ته باؤنسر پاسي تي SQL کي ڪيئن سمجھجي. اهو اوورڪِل هوندو ڇو ته اهو اوور ڪل آهي ڇو ته اسان کي پوري پارسر جي ضرورت آهي. اسان هر SQL حڪم کي پارس نٿا ڪري سگھون.
پر پروٽو 3 تي پيغام پروٽوڪول جي سطح تي تيار ڪيل بيان آهي. ۽ اھو اھو جڳھ آھي جڏھن معلومات جيڪا تيار ڪيل بيان ٺاھي رھي آھي ھڪڙي منظم شڪل ۾ اچي ٿي. ۽ اسان سمجھڻ جي حمايت ڪري سگھون ٿا ته ڪجھ سرور ڪنيڪشن تي ڪلائنٽ تيار ڪيل بيان تيار ڪرڻ لاء چيو. ۽ جيتوڻيڪ ٽرانزيڪشن بند ٿي وئي آهي، اسان کي اڃا تائين سرور ۽ ڪلائنٽ سان ڳنڍيل رکڻ جي ضرورت آهي.
پر هتي ڳالهه ٻولهه ۾ اختلاف پيدا ٿئي ٿو، ڇاڪاڻ ته ڪو چوي ٿو ته توهان کي سمجهڻ جي ضرورت آهي ته ڪلائنٽ ڪهڙا تيار ڪيل بيان ٺاهيا آهن ۽ انهن سڀني ڪلائنٽ جي وچ ۾ سرور ڪنيڪشن شيئر ڪن ٿا جن هي سرور ڪنيڪشن ٺاهيو آهي، يعني جن اهڙو تيار ڪيل بيان ٺاهيو آهي.
Andres Freund چيو ته جيڪڏهن ڪو ڪلائنٽ توهان وٽ آيو آهي جيڪو اڳ ۾ ئي ڪنهن ٻئي سرور ڪنيڪشن ۾ اهڙي تيار ڪيل بيان ٺاهي چڪو آهي، پوء ان لاء ٺاهيو. پر اهو لڳي ٿو ته ڪلائنٽ جي بدران ڊيٽابيس ۾ سوالن تي عمل ڪرڻ ٿورو غلط آهي، پر هڪ ڊولپر جي نقطي نظر کان جيڪو ڊيٽابيس سان رابطي لاء پروٽوڪول لکي ٿو، اهو آسان ٿيندو جيڪڏهن هن کي صرف نيٽ ورڪ ڪنيڪشن ڏنو وڃي. جنهن ۾ اهڙي تيار ڪيل درخواست آهي.
۽ هڪ وڌيڪ خصوصيت جيڪا اسان کي لاڳو ڪرڻ جي ضرورت آهي. اسان وٽ ھاڻي PgBouncer سان مطابقت رکي ٿي. اسان سراسري سوال جي عمل جو وقت واپس ڪري سگھون ٿا. پر سراسري وقت اسپتال ۾ سراسري درجه حرارت آهي: ڪو ماڻهو ٿڌو آهي، ڪو گرم آهي - سراسري طور تي هرڪو صحتمند آهي. اهو سچ نه آهي.
اسان کي فيصد لاءِ سپورٽ لاڳو ڪرڻ جي ضرورت آهي، جنهن مان ظاهر ٿئي ٿو ته سستي درخواستون آهن جيڪي وسيلن کي استعمال ڪن ٿيون ۽ نگراني کي وڌيڪ قابل قبول بڻائين ٿيون.
سڀ کان اهم شيء اها آهي ته مون کي ورجن 1.0 چاهيو (نسخ 1.1 اڳ ۾ ئي جاري ڪيو ويو آهي). حقيقت اها آهي ته هاڻي اوڊيسي نسخو 1.0rc ۾ آهي، يعني اميدوار ڇڏڻ. ۽ سڀئي ريڪ جيڪي مون درج ڪيا آهن بلڪل ساڳي نسخي سان مقرر ڪيا ويا، سواء ميموري لڪ جي.
ڇا ٿيندو نسخو 1.0 اسان لاءِ مطلب؟ اسان اوڊيسي کي اسان جي بنيادن ڏانهن ڇڪي رهيا آهيون. اهو اڳ ۾ ئي اسان جي ڊيٽابيس تي هلندڙ آهي، پر جڏهن اهو في سيڪنڊ 1 درخواستن جي نقطي تي پهچي ٿو، تڏهن اسان چئي سگهون ٿا ته هي هڪ رليز ورزن آهي ۽ هي هڪ نسخو آهي جنهن کي 000 چئي سگهجي ٿو.
ڪميونٽي جي ڪيترن ئي ماڻهن ورزن 1.0 ۾ وڌيڪ توقف ۽ SCRAM لاءِ چيو آهي. پر هن جو مطلب اهو ٿيندو ته اسان کي ايندڙ ورزن کي پيداوار ۾ آڻڻ جي ضرورت پوندي، ڇاڪاڻ ته نه ته SCRAM ۽ نه ئي رڪاوٽ اڃا تائين ضم ڪيو ويو آهي. پر، گهڻو ڪري، هن مسئلي کي تڪڙو تڪڙو حل ڪيو ويندو.
مان توهان جي موڪل جي درخواست جو انتظار ڪري رهيو آهيان. ۽ مان پڻ ٻڌڻ چاهيان ٿو ته توهان کي بائونسر سان ڪهڙا مسئلا آهن. اچو ته انهن تي بحث ڪريون. ٿي سگهي ٿو ته اسان ڪجهه فنڪشن لاڳو ڪري سگهون ٿا جيڪي توهان جي ضرورت آهي.
هي منهنجو حصو ختم ڪري ٿو، مان توهان کان ٻڌڻ چاهيان ٿو. تنهنجي مهرباني!
توهان جا سوال
جيڪڏهن آئون پنهنجو پنهنجو application_name رکان، ڇا اهو صحيح طور تي اڇلايو ويندو، بشمول اوڊيسي ۾ ٽرانزيڪشن پولنگ ۾؟
اوڊيسي يا بائونسر؟
اوڊيسي ۾. بائونسر اڇلايو ويو آهي.
اسان هڪ سيٽ ٺاهينداسين.
۽ جيڪڏهن منهنجو حقيقي ڪنيڪشن ٻين ڪنيڪشن تي هٽايو ويندو، ڇا اهو منتقل ڪيو ويندو؟
اسان سڀني ماپن جو هڪ سيٽ ٺاهينداسين جيڪي درج ٿيل آهن. مان نه ٿو ٻڌائي سگهان ته ڇا application_name هن لسٽ ۾ آهي. اهو لڳي ٿو ته هن کيس اتي ڏٺو. اسان سڀ ساڳيا پيٽرول سيٽ ڪنداسين. ھڪڙي گذارش سان، سيٽ سڀ ڪجھ ڪندو جيڪو ڪلائنٽ پاران شروعاتي دوران نصب ڪيو ويو آھي.
رپورٽ لاء Andrey جي مهرباني! سٺي رپورٽ! مون کي خوشي آهي ته اوڊيسي هر منٽ تيزي سان ترقي ڪري رهي آهي. مان ائين ئي جاري رکڻ چاهيان ٿو. اسان اڳ ۾ ئي توهان کان پڇيو آهي ته هڪ گھڻائي ڊيٽا-ذريعو ڪنيڪشن آهي ته جيئن اوڊيسي هڪ ئي وقت مختلف ڊيٽابيس سان ڳنڍي سگهي، يعني غلام ماسٽر، ۽ پوء خودڪار طريقي سان نئين ماسٽر سان ڳنڍڻ کان پوء ناڪام ٿيڻ کان پوء.
ها، مون کي اهو بحث ياد اچي ٿو. هاڻي اتي ڪيترائي ذخيرا آهن. پر انهن جي وچ ۾ ڪوبه ڦيرڦار ناهي. اسان جي پاسي، اسان کي سرور کان سوال ڪرڻ گهرجي ته اهو اڃا تائين جيئرو آهي ۽ سمجھو ته هڪ ناڪام ٿي چڪو آهي، جيڪو سڏيندو pg_recovery. مون وٽ هڪ معياري طريقو آهي ته اسان کي سمجهه ۾ نه آيو هو ماسٽر ڏانهن. ۽ اسان کي ڪنهن نه ڪنهن طرح غلطين مان سمجهڻ گهرجي يا ڪيئن؟ اهو آهي، خيال دلچسپ آهي، ان تي بحث ڪيو پيو وڃي. وڌيڪ تبصرو لکو. جيڪڏهن توهان وٽ ڪم ڪندڙ هٿ آهن جيڪي ڄاڻن ٿا سي، پوء اهو عام طور تي شاندار آهي.
replicas جي وچ ۾ ماپڻ جو مسئلو پڻ اسان لاءِ دلچسپيءَ جو آهي، ڇاڪاڻ ته اسان چاهيون ٿا ته نقل ڪيل ڪلسٽرن کي اپنائڻ کي جيترو ممڪن ٿي سگهي ايپليڪيشن ڊولپرز لاءِ. پر هتي آئون وڌيڪ رايا چاهيندس، اهو آهي، اهو ڪيئن ڪجي، اهو ڪيئن ڪجي.
سوال نقلن بابت پڻ آهي. اهو ظاهر ٿيو ته توهان وٽ هڪ ماسٽر ۽ ڪيترائي نقل آهن. ۽ اهو واضح آهي ته اهي ڪنيڪشن لاء ماسٽر جي ڀيٽ ۾ گهٽ اڪثر نقل ڏانهن ويندا آهن، ڇاڪاڻ ته انهن ۾ فرق ٿي سگهي ٿو. توهان چيو ته ڊيٽا ۾ فرق ٿي سگهي ٿو ته توهان جو ڪاروبار مطمئن نه ٿيندو ۽ توهان اتي نه ويندا جيستائين اهو نقل نه ڪيو وڃي. ساڳئي وقت، جيڪڏهن توهان گهڻي وقت تائين اتي نه وڃو، ۽ پوء وڃڻ شروع ڪيو، ته پوء توهان کي گهربل ڊيٽا فوري طور تي دستياب نه هوندي. اهو آهي، جيڪڏهن اسان مسلسل ماسٽر ڏانهن وڃون ٿا، پوء ڪيش اتي گرم ٿي ويندو آهي، ۽ ڪيش نقل ۾ ٿورو پوئتي آهي.
ها اهو سچ آهي. pcache ۾ ڪو به ڊيٽا بلاڪ نه هوندو جيڪو توهان چاهيو ٿا، حقيقي ڪيش ۾ ٽيبل جي باري ۾ ڪا به ڄاڻ نه هوندي جيڪا توهان چاهيو ٿا، منصوبن ۾ ڪو به پارس ڪيل سوال نه هوندو، ڪجهه به نه.
۽ جڏهن توهان وٽ ڪجهه قسم جو ڪلستر هوندو آهي، ۽ توهان اتي هڪ نئين نقل شامل ڪندا آهيو، پوء جڏهن اهو شروع ٿئي ٿو، ان ۾ سڀ ڪجهه خراب آهي، يعني اهو ان جي ڪيش کي وڌائي ٿو.
مون کي خيال آيو. صحيح طريقو اهو هوندو ته سوالن جو هڪ ننڍڙو سيڪڙو ريپليڪا تي پهريون ڀيرو هلائڻ، جيڪو ڪيش کي گرم ڪري ڇڏيندو. عام طور تي ڳالهائڻ، اسان وٽ شرط آهي ته اسان کي ماسٽر جي پويان 10 سيڪنڊن کان وڌيڪ نه هجڻ گهرجي. ۽ اها حالت هڪ موج ۾ شامل نه ٿيڻ گهرجي، پر ڪجهه گراهڪن لاء آسانيء سان.
ها، وزن وڌايو.
هي هڪ سٺو خيال آهي. پر پهرين توهان کي هن بند کي لاڳو ڪرڻ جي ضرورت آهي. پهرين اسان کي بند ڪرڻ جي ضرورت آهي، ۽ پوء اسان کي ڪيئن چالو ڪرڻ جي باري ۾ سوچيو. هي هڪ بهترين خصوصيت آهي آساني سان آن ڪرڻ لاءِ.
nginx وٽ هي اختيار آهي slowly start سرور لاء ڪلستر ۾. ۽ هو آهستي آهستي لوڊ ٺاهي ٿو.
ها، عظيم خيال، اسان ان کي ڪوشش ڪنداسين جڏهن اسان انهي کي حاصل ڪنداسين.
جو ذريعو: www.habr.com