اپنی رپورٹ میں، آندرے بوروڈن آپ کو بتائیں گے کہ کنکشن پولر کو ڈیزائن کرتے وقت انہوں نے پی جی باؤنسر کو اسکیل کرنے کے تجربے کو کیسے مدنظر رکھا۔ ، جیسا کہ انہوں نے اسے پیداوار میں شامل کیا۔ اس کے علاوہ، ہم اس بات پر تبادلہ خیال کریں گے کہ ہم نئے ورژن میں پلر کے کون سے افعال دیکھنا چاہیں گے: یہ ہمارے لیے نہ صرف اپنی ضروریات کو پورا کرنا، بلکہ صارف برادری کو تیار کرنا بھی اہم ہے۔ .
ویڈیو:
سب کو سلام! میرا نام اینڈریو ہے۔
Yandex میں، میں اوپن سورس ڈیٹا بیس تیار کرتا ہوں۔ اور آج ہمارے پاس کنکشن پولر کنکشن کے بارے میں ایک موضوع ہے۔
اگر آپ جانتے ہیں کہ کنکشن پولر کو روسی میں کس طرح کال کرنا ہے، تو مجھے بتائیں۔ میں واقعی میں ایک اچھی تکنیکی اصطلاح تلاش کرنا چاہتا ہوں جو تکنیکی ادب میں قائم کی جانی چاہئے۔
موضوع کافی پیچیدہ ہے، کیونکہ بہت سے ڈیٹا بیس میں کنکشن پولر بلٹ ان ہوتا ہے اور آپ کو اس کے بارے میں جاننے کی بھی ضرورت نہیں ہوتی۔ یقینا، ہر جگہ کچھ ترتیبات موجود ہیں، لیکن پوسٹگریس میں یہ اس طرح کام نہیں کرتا ہے۔ اور متوازی طور پر (HighLoad++ 2019 پر) Nikolai Samokhvalov کی پوسٹگریس میں سوالات ترتیب دینے کے بارے میں ایک رپورٹ ہے۔ اور جیسا کہ میں سمجھتا ہوں، وہ لوگ یہاں آئے جنہوں نے پہلے ہی اپنے سوالات کو مکمل طور پر ترتیب دے رکھا تھا، اور یہ وہ لوگ ہیں جنہیں نیٹ ورک اور وسائل کے استعمال سے متعلق سسٹم کے زیادہ نایاب مسائل کا سامنا ہے۔ اور بعض جگہوں پر یہ اس لحاظ سے کافی مشکل ہو سکتا ہے کہ مسائل واضح نہیں ہیں۔
Yandex میں Postgres ہے۔ Yandex کی بہت سی سروسز Yandex.Cloud میں رہتی ہیں۔ اور ہمارے پاس کئی پیٹا بائٹس ڈیٹا ہیں جو پوسٹگریس میں فی سیکنڈ کم از کم دس لاکھ درخواستیں تیار کرتے ہیں۔
اور ہم تمام خدمات کے لیے کافی معیاری کلسٹر فراہم کرتے ہیں - یہ نوڈ کا بنیادی بنیادی نوڈ ہے، معمول کی دو نقلیں (مطابقت پذیر اور غیر مطابقت پذیر)، بیک اپ، ریپلیکا پر پڑھنے کی درخواستوں کی اسکیلنگ۔
ہر کلسٹر نوڈ پوسٹگریس ہے، جس پر پوسٹگریس اور مانیٹرنگ سسٹم کے علاوہ، کنکشن پولر بھی نصب ہے۔ کنکشن پولر کو باڑ لگانے اور اس کے بنیادی مقصد کے لیے استعمال کیا جاتا ہے۔
کنکشن پولر کا بنیادی مقصد کیا ہے؟
پوسٹگریس ڈیٹا بیس کے ساتھ کام کرتے وقت ایک پروسیس ماڈل اپناتا ہے۔ اس کا مطلب ہے کہ ایک کنکشن ایک عمل ہے، ایک پوسٹگریس پسدید۔ اور اس پسدید میں بہت سارے مختلف کیچز ہیں، جو مختلف کنکشنز کے لیے مختلف بنانا کافی مہنگے ہیں۔
مزید برآں، پوسٹگریس کوڈ میں ایک صف ہے جسے procArray کہتے ہیں۔ یہ نیٹ ورک کنکشن کے بارے میں بنیادی ڈیٹا پر مشتمل ہے۔ اور تقریباً تمام procArray پروسیسنگ الگورتھم میں لکیری پیچیدگی ہوتی ہے؛ وہ نیٹ ورک کنکشن کی پوری صف پر چلتے ہیں۔ یہ ایک بہت تیز سائیکل ہے، لیکن زیادہ آنے والے نیٹ ورک کنکشن کے ساتھ چیزیں تھوڑی زیادہ مہنگی ہو جاتی ہیں۔ اور جب چیزیں تھوڑی زیادہ مہنگی ہوجاتی ہیں، تو آپ بہت سارے نیٹ ورک کنکشن کے لیے بہت زیادہ قیمت ادا کر سکتے ہیں۔
3 ممکنہ نقطہ نظر ہیں:
- درخواست کی طرف۔
- ڈیٹا بیس کی طرف۔
- اور درمیان، یعنی تمام قسم کے مجموعے۔
بدقسمتی سے، بلٹ ان پولر فی الحال ترقی کے تحت ہے۔ PostgreSQL Professional میں ہمارے دوست زیادہ تر یہ کرتے ہیں۔ یہ کب ظاہر ہوگا اس کا اندازہ لگانا مشکل ہے۔ اور حقیقت میں، ہمارے پاس معمار کے لیے دو حل ہیں جن میں سے انتخاب کرنا ہے۔ یہ ایپلیکیشن سائیڈ پول اور پراکسی پول ہیں۔
ایپلیکیشن سائیڈ پول سب سے آسان طریقہ ہے۔ اور تقریباً تمام کلائنٹ ڈرائیورز آپ کو ایک طریقہ فراہم کرتے ہیں: آپ کے لاکھوں کنکشنز کو کوڈ میں ڈیٹا بیس کے کئی درجن کنکشن کے طور پر پیش کرتے ہیں۔
جو مسئلہ پیدا ہوتا ہے وہ یہ ہے کہ ایک خاص مقام پر آپ بیک اینڈ کو پیمانہ کرنا چاہتے ہیں، آپ اسے بہت سی ورچوئل مشینوں پر تعینات کرنا چاہتے ہیں۔
تب آپ کو احساس ہوگا کہ آپ کے پاس دستیابی کے کئی اور زونز، کئی ڈیٹا سینٹرز ہیں۔ اور کلائنٹ سائیڈ پولنگ اپروچ بڑی تعداد کی طرف لے جاتا ہے۔ بڑے والے تقریباً 10 کنکشن ہیں۔ یہ وہ کنارے ہے جو عام طور پر کام کر سکتا ہے۔
اگر ہم پراکسی پولرز کی بات کریں، تو دو پولرز ہیں جو بہت کچھ کر سکتے ہیں۔ وہ نہ صرف پولرز ہیں۔ وہ پولرز + زیادہ ٹھنڈی فعالیت ہیں۔ یہ и .
لیکن، بدقسمتی سے، ہر ایک کو اس اضافی فعالیت کی ضرورت نہیں ہے۔ اور یہ اس حقیقت کی طرف لے جاتا ہے کہ پولرز صرف سیشن پولنگ کی حمایت کرتے ہیں، یعنی ایک آنے والا کلائنٹ، ایک ڈیٹا بیس میں جانے والا کلائنٹ۔
یہ ہمارے مقاصد کے لیے بہت موزوں نہیں ہے، اس لیے ہم PgBouncer استعمال کرتے ہیں، جو ٹرانزیکشن پولنگ کو لاگو کرتا ہے، یعنی سرور کے کنکشنز صرف لین دین کی مدت کے لیے کلائنٹ کنکشنز سے مماثل ہوتے ہیں۔
اور ہمارے کام کے بوجھ میں، یہ سچ ہے۔ لیکن چند مسائل ہیں۔.
مسائل اس وقت شروع ہوتے ہیں جب آپ سیشن کی تشخیص کرنا چاہتے ہیں، کیونکہ آپ کے آنے والے تمام کنکشن مقامی ہیں۔ ہر کوئی لوپ بیک کے ساتھ آیا اور کسی نہ کسی طرح سیشن کا پتہ لگانا مشکل ہو جاتا ہے۔
یقینا آپ application_name_add_host استعمال کرسکتے ہیں۔ یہ ایپلیکیشن_نام میں آئی پی ایڈریس شامل کرنے کا باؤنسر کی طرف ایک طریقہ ہے۔ لیکن application_name ایک اضافی کنکشن کے ذریعہ سیٹ کیا گیا ہے۔
اس گراف پر، جہاں پیلی لکیر حقیقی درخواستیں ہیں، اور جہاں نیلی لائن وہ درخواستیں ہیں جو ڈیٹا بیس میں اڑتی ہیں۔ اور یہ فرق بالکل ایپلی کیشن_نام کی تنصیب کا ہے، جس کی ضرورت صرف ٹریسنگ کے لیے ہے، لیکن یہ بالکل مفت نہیں ہے۔
اس کے علاوہ، باؤنسر میں آپ ایک پول کو محدود نہیں کر سکتے، یعنی فی مخصوص صارف، فی مخصوص ڈیٹا بیس کے ڈیٹا بیس کنکشنز کی تعداد۔
اس سے کیا ہوتا ہے؟ آپ کے پاس C++ میں لکھی ہوئی ایک بھری ہوئی سروس ہے اور کہیں قریب ایک نوڈ پر ایک چھوٹی سی سروس ہے جو ڈیٹا بیس کے ساتھ کوئی خوفناک کام نہیں کرتی ہے، لیکن اس کا ڈرائیور پاگل ہو جاتا ہے۔ یہ 20 کنکشن کھولتا ہے اور باقی سب کچھ انتظار کرے گا۔ یہاں تک کہ آپ کا کوڈ نارمل ہے۔
ہم نے، یقیناً، باؤنسر کے لیے ایک چھوٹا سا پیچ لکھا جس نے اس ترتیب کو شامل کیا، یعنی کلائنٹس کو پول تک محدود کرنا۔
پوسٹگریس سائیڈ پر ایسا کرنا ممکن ہو گا، یعنی ڈیٹا بیس میں کنکشن کی تعداد کے حساب سے رولز کو محدود کریں۔
لیکن پھر آپ یہ سمجھنے کی صلاحیت کھو دیتے ہیں کہ آپ کا سرور سے کوئی رابطہ کیوں نہیں ہے۔ پی جی باؤنسر کنکشن کی غلطی نہیں پھینکتا ہے، یہ ہمیشہ وہی معلومات واپس کرتا ہے۔ اور آپ سمجھ نہیں سکتے: ہو سکتا ہے آپ کا پاس ورڈ بدل گیا ہو، ہو سکتا ہے ڈیٹا بیس ابھی گم ہو گیا ہو، ہو سکتا ہے کچھ گڑبڑ ہو۔ لیکن کوئی تشخیص نہیں ہے۔ اگر ایک سیشن قائم نہیں کیا جا سکتا ہے، تو آپ نہیں جانتے کہ یہ کیوں قائم نہیں کیا جا سکتا.
ایک خاص مقام پر، آپ ایپلیکیشن گرافس کو دیکھتے ہیں اور دیکھتے ہیں کہ ایپلیکیشن کام نہیں کر رہی ہے۔
اوپر دیکھیں اور دیکھیں کہ باؤنسر سنگل تھریڈڈ ہے۔ یہ سروس کی زندگی میں ایک اہم موڑ ہے۔ آپ کو احساس ہے کہ آپ ڈیڑھ سال میں ڈیٹا بیس کی پیمائش کرنے کی تیاری کر رہے تھے، اور آپ کو پولر کو پیمانہ کرنے کی ضرورت ہے۔
ہم اس نتیجے پر پہنچے ہیں کہ ہمیں مزید PgBouncers کی ضرورت ہے۔
باؤنسر کو تھوڑا سا تھپتھپا دیا گیا ہے۔
اور انہوں نے اسے بنایا تاکہ TCP پورٹ کو دوبارہ استعمال کر کے کئی باؤنسر بنائے جا سکیں۔ اور آپریٹنگ سسٹم راؤنڈ رابن کا استعمال کرتے ہوئے ان کے درمیان آنے والے TCP کنکشنز کو خود بخود منتقل کرتا ہے۔
یہ کلائنٹس کے لیے شفاف ہے، یعنی ایسا لگتا ہے کہ آپ کے پاس ایک باؤنسر ہے، لیکن آپ کے پاس چلانے والے باؤنسرز کے درمیان بیکار کنکشنز ہیں۔
اور ایک خاص لمحے میں آپ محسوس کر سکتے ہیں کہ یہ 3 باؤنسر ہر ایک اپنا بنیادی حصہ 100% کھا جاتا ہے۔ آپ کو کچھ باؤنسر کی ضرورت ہے۔ کیوں؟
کیونکہ آپ کے پاس TLS ہے۔ آپ کے پاس ایک مرموز کنکشن ہے۔ اور اگر آپ TLS کے ساتھ اور اس کے بغیر پوسٹگریس کو بینچ مارک کرتے ہیں، تو آپ کو معلوم ہوگا کہ انکرپشن فعال ہونے کے ساتھ قائم کردہ کنکشنز کی تعداد میں تقریباً دو آرڈرز کی کمی واقع ہوتی ہے، کیونکہ TLS ہینڈ شیک CPU وسائل استعمال کرتا ہے۔
اور سب سے اوپر آپ کچھ خفیہ نگاری کے فنکشن دیکھ سکتے ہیں جو آنے والے رابطوں کی لہر کے وقت انجام پاتے ہیں۔ چونکہ ہمارا پرائمری دستیابی والے علاقوں کے درمیان تبدیل ہو سکتا ہے، اس لیے آنے والے رابطوں کی لہر کافی عام صورت حال ہے۔ یعنی کسی وجہ سے پرانا پرائمری دستیاب نہیں تھا، سارا لوڈ دوسرے ڈیٹا سینٹر کو بھیج دیا گیا۔ وہ سب ایک ہی وقت میں TLS کو ہیلو کہنے آئیں گے۔
اور TLS مصافحہ کی ایک بڑی تعداد اب باؤنسر کو ہیلو نہیں کہہ سکتی، لیکن اس کا گلا دبا دے گی۔ وقت ختم ہونے کی وجہ سے، آنے والے رابطوں کی لہر بے داغ ہو سکتی ہے۔ اگر آپ ایکسپونینشنل بیک آف کے بغیر بنیاد پر دوبارہ کوشش کرتے ہیں، تو وہ ایک مربوط لہر میں بار بار نہیں آئیں گے۔
یہاں 16 PgBouncers کی ایک مثال ہے جو 16% پر 100 کور لوڈ کرتے ہیں۔
ہم جھرن PgBouncer پر آئے۔ یہ بہترین ترتیب ہے جو باؤنسر کے ساتھ ہمارے بوجھ پر حاصل کی جا سکتی ہے۔ ہمارے بیرونی باؤنسرز TCP ہینڈ شیک کے لیے استعمال کیے جاتے ہیں، اور اندرونی باؤنسر حقیقی پولنگ کے لیے استعمال کیے جاتے ہیں، تاکہ بیرونی کنکشنز کو بہت زیادہ ٹکڑے نہ کیا جائے۔
اس ترتیب میں، ایک ہموار دوبارہ شروع ممکن ہے. آپ ان تمام 18 باؤنسر کو ایک ایک کرکے دوبارہ شروع کر سکتے ہیں۔ لیکن اس طرح کی ترتیب کو برقرار رکھنا کافی مشکل ہے۔ Sysadmins، DevOps، اور وہ لوگ جو اصل میں اس سرور کے ذمہ دار ہیں اس انتظام سے زیادہ خوش نہیں ہوں گے۔
ایسا لگتا ہے کہ ہماری تمام اصلاحات کو اوپن سورس میں فروغ دیا جا سکتا ہے، لیکن باؤنسر کو زیادہ تعاون حاصل نہیں ہے۔ مثال کے طور پر، ایک پورٹ پر کئی PgBouncers چلانے کی صلاحیت ایک ماہ پہلے کی گئی تھی۔ کئی سال پہلے اس خصوصیت کے ساتھ ایک پل کی درخواست تھی۔
یا ایک اور مثال۔ پوسٹگریس میں، آپ غیر ضروری تصدیق کے بغیر راز کو مختلف کنکشن پر بھیج کر پیشرفت کی درخواست کو منسوخ کر سکتے ہیں۔ لیکن کچھ کلائنٹس صرف TCP ری سیٹ بھیجتے ہیں، یعنی وہ نیٹ ورک کنکشن توڑ دیتے ہیں۔ باؤنسر کیا کرے گا؟ وہ کچھ نہیں کرے گا۔ یہ درخواست پر عمل درآمد جاری رکھے گا۔ اگر آپ کو کنکشنز کی ایک بڑی تعداد موصول ہوئی ہے جس نے چھوٹی درخواستوں کے ساتھ ڈیٹا بیس بنایا ہے، تو صرف باؤنسر سے کنکشن منقطع کرنا کافی نہیں ہوگا؛ آپ کو ان درخواستوں کو بھی مکمل کرنا ہوگا جو ڈیٹا بیس میں چل رہی ہیں۔
یہ پیچ کیا گیا ہے اور یہ مسئلہ ابھی تک باؤنسر کے اپ اسٹریم میں ضم نہیں ہوا ہے۔
اور اس طرح ہم اس نتیجے پر پہنچے کہ ہمیں اپنے کنکشن پولر کی ضرورت ہے، جسے تیار کیا جائے گا، پیچ کیا جائے گا، جس میں مسائل کو فوری طور پر درست کیا جا سکتا ہے اور جو یقیناً کثیر جہتی ہونا چاہیے۔
ہم نے ملٹی تھریڈنگ کو بنیادی کام کے طور پر سیٹ کیا۔ ہمیں آنے والے TLS کنکشن کی لہر کو اچھی طرح سے ہینڈل کرنے کے قابل ہونے کی ضرورت ہے۔
ایسا کرنے کے لیے، ہمیں مشینیریم نامی ایک علیحدہ لائبریری تیار کرنی پڑی، جو نیٹ ورک کنکشن کی مشینی حالتوں کو ترتیب وار کوڈ کے طور پر بیان کرنے کے لیے بنائی گئی ہے۔ اگر آپ libpq سورس کوڈ کو دیکھیں گے تو آپ کو کچھ پیچیدہ کالیں نظر آئیں گی جو آپ کو نتیجہ دے سکتی ہیں اور کہہ سکتی ہیں، "مجھے بعد میں کال کریں۔ ابھی میرے پاس ابھی کے لیے IO ہے، لیکن جب IO چلا جائے گا تو میرے پروسیسر پر بوجھ پڑے گا۔ اور یہ ایک کثیر سطحی اسکیم ہے۔ نیٹ ورک مواصلات عام طور پر ریاستی مشین کے ذریعہ بیان کیا جاتا ہے۔ بہت سارے اصول جیسے "اگر مجھے پہلے N سائز کا پیکٹ ہیڈر موصول ہوا تھا، اب میں N بائٹس کا انتظار کر رہا ہوں،" "اگر میں نے SYNC پیکٹ بھیجا ہے، تو اب میں نتیجہ کے میٹا ڈیٹا والے پیکٹ کا انتظار کر رہا ہوں۔" نتیجہ ایک مشکل، متضاد کوڈ ہے، گویا بھولبلییا کو لائن اسکین میں تبدیل کر دیا گیا ہے۔ ہم نے اسے اس لیے بنایا ہے کہ ریاستی مشین کے بجائے، پروگرامر عام ضروری کوڈ کی شکل میں تعامل کے مرکزی راستے کو بیان کرتا ہے۔ یہ صرف اتنا ہے کہ اس لازمی کوڈ میں آپ کو ایسی جگہیں داخل کرنے کی ضرورت ہے جہاں نیٹ ورک سے ڈیٹا کا انتظار کرتے ہوئے، عملدرآمد کے سیاق و سباق کو کسی اور کورٹین (گرین تھریڈ) میں منتقل کر کے عمل درآمد کی ترتیب میں خلل ڈالنے کی ضرورت ہے۔ یہ نقطہ نظر اس حقیقت سے ملتا جلتا ہے کہ ہم بھولبلییا میں ایک قطار میں سب سے زیادہ متوقع راستہ لکھتے ہیں، اور پھر اس میں شاخیں شامل کرتے ہیں۔
نتیجے کے طور پر، ہمارے پاس ایک تھریڈ ہے جو TCP قبول کرتا ہے اور راؤنڈ رابن بہت سے کارکنوں کو TPC کنکشن منتقل کرتا ہے۔
اس صورت میں، ہر کلائنٹ کنکشن ہمیشہ ایک پروسیسر پر چلتا ہے۔ اور یہ آپ کو اسے کیش فرینڈلی بنانے کی اجازت دیتا ہے۔
اور اس کے علاوہ، ہم نے چھوٹے پیکٹوں کو ایک بڑے پیکٹ میں جمع کرنے میں قدرے بہتری لائی ہے تاکہ سسٹم TCP اسٹیک سے نجات مل سکے۔
اس کے علاوہ، ہم نے ٹرانزیکشنل پولنگ کو اس لحاظ سے بہتر بنایا ہے کہ Odyssey، جب کنفیگر ہو جائے، نیٹ ورک کنکشن کی ناکامی کی صورت میں CANCEL اور ROLLBACK بھیج سکتا ہے، یعنی اگر کوئی درخواست کا انتظار نہیں کر رہا ہے، Odyssey ڈیٹا بیس سے کہے گا کہ وہ کوشش نہ کرے۔ درخواست کو پورا کریں جس سے قیمتی وسائل ضائع ہو سکتے ہیں۔
اور جب بھی ممکن ہو، ہم ایک ہی کلائنٹ سے رابطے رکھتے ہیں۔ یہ application_name_add_host کو دوبارہ انسٹال کرنے سے گریز کرتا ہے۔ اگر یہ ممکن ہے، تو ہمیں اضافی طور پر ان پیرامیٹرز کو دوبارہ ترتیب دینے کی ضرورت نہیں ہے جو تشخیص کے لیے درکار ہیں۔
ہم Yandex.Cloud کے مفاد میں کام کرتے ہیں۔ اور اگر آپ نظم شدہ PostgreSQL استعمال کرتے ہیں اور آپ کے پاس کنکشن پولر نصب ہے، تو آپ منطقی نقل تیار کر سکتے ہیں، یعنی، اگر آپ چاہیں، منطقی نقل کا استعمال کرتے ہوئے، ہمیں چھوڑ دیں۔ باؤنسر منطقی نقل کے بہاؤ کو باہر نہیں چھوڑے گا۔
یہ منطقی نقل ترتیب دینے کی ایک مثال ہے۔
اس کے علاوہ، ہمارے پاس ظاہری شکل میں جسمانی نقل کے لیے تعاون ہے۔ کلاؤڈ میں، یقینا، یہ ناممکن ہے، کیونکہ پھر کلسٹر آپ کو اپنے بارے میں بہت زیادہ معلومات دے گا۔ لیکن آپ کی تنصیبات میں، اگر آپ کو اوڈیسی میں کنکشن پولر کے ذریعے جسمانی نقل کی ضرورت ہے، تو یہ ممکن ہے۔
Odyssey PgBouncer کے ساتھ مکمل طور پر ہم آہنگ نگرانی رکھتا ہے۔ ہمارے پاس وہی کنسول ہے جو تقریباً تمام ایک جیسی کمانڈز چلاتا ہے۔ اگر کچھ غائب ہے تو، پل کی درخواست بھیجیں، یا کم از کم GitHub پر کوئی مسئلہ، اور ہم ضروری کمانڈز کو مکمل کریں گے۔ لیکن ہمارے پاس پہلے سے ہی PgBouncer کنسول کی اہم فعالیت موجود ہے۔
اور، یقینا، ہمارے پاس فارورڈنگ میں غلطی ہے۔ ہم ڈیٹا بیس کی طرف سے رپورٹ کی گئی غلطی واپس کر دیں گے۔ آپ اس بارے میں معلومات حاصل کریں گے کہ آپ ڈیٹا بیس میں کیوں شامل نہیں ہیں، اور صرف یہ نہیں کہ آپ اس میں شامل نہیں ہیں۔
اگر آپ کو PgBouncer کے ساتھ 100% مطابقت درکار ہے تو یہ خصوصیت غیر فعال ہے۔ ہم باؤنسر کی طرح برتاؤ کر سکتے ہیں، صرف محفوظ طرف رہنے کے لیے۔
ترقی
اوڈیسی سورس کوڈ کے بارے میں چند الفاظ۔
مثال کے طور پر، "Pause / Resume" کمانڈز موجود ہیں۔ وہ عام طور پر ڈیٹا بیس کو اپ ڈیٹ کرنے کے لیے استعمال ہوتے ہیں۔ اگر آپ کو پوسٹگریس کو اپ ڈیٹ کرنے کی ضرورت ہے، تو آپ اسے کنکشن پولر میں روک سکتے ہیں، pg_upgrade کر سکتے ہیں، پھر دوبارہ شروع کر سکتے ہیں۔ اور کلائنٹ کی طرف سے ایسا نظر آئے گا جیسے ڈیٹا بیس سست ہو رہا ہو۔ یہ فعالیت کمیونٹی کے لوگوں کے ذریعہ ہمارے پاس لائی گئی۔ وہ ابھی منجمد نہیں ہوئی ہے، لیکن جلد ہی سب کچھ ہو جائے گا۔ (پہلے ہی منجمد)
- پہلے ہی منجمد
اس کے علاوہ، PgBouncer میں نئی خصوصیات میں سے ایک SCRAM توثیق کے لیے سپورٹ ہے، جسے ہمارے پاس ایک ایسے شخص نے بھی لایا ہے جو Yandex.Cloud میں کام نہیں کرتا ہے۔ دونوں پیچیدہ فعالیت اور اہم ہیں۔
لہذا، میں آپ کو بتانا چاہوں گا کہ اوڈیسی کس چیز سے بنی ہے، اگر آپ بھی ابھی تھوڑا کوڈ لکھنا چاہتے ہیں۔
آپ کے پاس اوڈیسی سورس بیس ہے، جو دو اہم لائبریریوں پر انحصار کرتا ہے۔ کیوی لائبریری پوسٹگریس میسج پروٹوکول کا نفاذ ہے۔ یعنی پوسٹگریس کا مقامی پروٹو 3 معیاری پیغامات ہیں جن کا فرنٹ اینڈ اور بیک اینڈز تبادلہ کر سکتے ہیں۔ وہ کیوی لائبریری میں لاگو ہوتے ہیں۔
مشینیریم لائبریری تھریڈ پر عمل درآمد کی لائبریری ہے۔ اس مشینیریم کا ایک چھوٹا سا حصہ اسمبلی زبان میں لکھا گیا ہے۔ لیکن گھبرائیں نہیں، صرف 15 لائنیں ہیں۔
اوڈیسی فن تعمیر۔ ایک مین مشین ہے جس پر کوروٹینز چل رہی ہیں۔ یہ مشین آنے والے TCP کنکشن کو قبول کرنے اور انہیں کارکنوں میں تقسیم کرنے کا عمل کرتی ہے۔
کئی کلائنٹس کے لیے ایک ہینڈلر ایک کارکن کے اندر کام کر سکتا ہے۔ مرکزی دھاگہ کنسول کو بھی چلاتا ہے اور ان کنکشنز کو حذف کرنے کے لیے کرون کاموں کی پروسیسنگ کرتا ہے جن کی پول میں مزید ضرورت نہیں ہے۔
معیاری پوسٹگریس ٹیسٹ سوٹ کا استعمال کرتے ہوئے اوڈیسی کی جانچ کی جاتی ہے۔ ہم صرف باؤنسر کے ذریعے انسٹال چیک چلاتے ہیں اور اوڈیسی کے ذریعے، ہمیں ایک null div ملتا ہے۔ ڈیٹ فارمیٹنگ سے متعلق کئی ٹیسٹ ہیں جو باؤنسر اور اوڈیسی میں بالکل ایک جیسے نہیں گزرتے ہیں۔
اس کے علاوہ، بہت سے ڈرائیور ہیں جن کی اپنی جانچ ہوتی ہے۔ اور ہم اوڈیسی کو جانچنے کے لیے ان کے ٹیسٹ استعمال کرتے ہیں۔
اس کے علاوہ، ہماری جھرن کی ترتیب کی وجہ سے، ہمیں مختلف بنڈلز کی جانچ کرنی ہوگی: Postgres + Odyssey، PgBouncer + Odyssey، Odyssey + Odyssey تاکہ یہ یقینی بنایا جا سکے کہ اگر Odyssey جھرن کے کسی بھی حصے میں ختم ہوا ہے، تو یہ اب بھی کام کرتا ہے۔ جیسا کہ ہم توقع کرتے ہیں.
ریک
ہم پیداوار میں اوڈیسی کا استعمال کرتے ہیں۔ اور یہ مناسب نہیں ہوگا اگر میں کہوں کہ سب کچھ کام کرتا ہے۔ نہیں، یہ ہے، ہاں، لیکن ہمیشہ نہیں۔ مثال کے طور پر، پروڈکشن میں سب کچھ کام کرتا ہے، پھر PostgreSQL پروفیشنل سے ہمارے دوست آئے اور کہا کہ ہمارے پاس میموری لیک ہو گئی ہے۔ وہ واقعی تھے، ہم نے انہیں درست کیا۔ لیکن یہ سادہ تھا.
پھر ہم نے دریافت کیا کہ کنکشن پولر میں آنے والے TLS کنکشن اور باہر جانے والے TLS کنکشن ہیں۔ اور کنکشن کلائنٹ سرٹیفکیٹ اور سرور سرٹیفکیٹ کی ضرورت ہے.
Bouncer اور Odyssey سرور سرٹیفکیٹس کو ان کے pcache کے ذریعے دوبارہ پڑھا جاتا ہے، لیکن کلائنٹ کے سرٹیفکیٹس کو pcache سے دوبارہ پڑھنے کی ضرورت نہیں ہے، کیونکہ ہماری توسیع پذیر Odyssey بالآخر اس سرٹیفکیٹ کو پڑھنے کے سسٹم کی کارکردگی پر چلتی ہے۔ یہ ہمارے لیے حیران کن تھا، کیونکہ اسے مزاحمت کرنے میں زیادہ وقت نہیں لگا۔ پہلے تو یہ لکیری طور پر پیمانہ ہوا، لیکن 20،000 آنے والے بیک وقت کنکشن کے بعد یہ مسئلہ خود ظاہر ہوا۔
پلگ ایبل توثیق کا طریقہ بلٹ ان Lunux ٹولز کا استعمال کرکے تصدیق کرنے کی صلاحیت ہے۔ پی جی باؤنسر میں اسے اس طرح لاگو کیا جاتا ہے کہ پی اے ایم کے جواب کا انتظار کرنے کے لیے ایک الگ تھریڈ ہوتا ہے اور ایک اہم پی جی باؤنسر تھریڈ ہوتا ہے جو موجودہ کنکشن کی خدمت کرتا ہے اور انہیں پی اے ایم تھریڈ میں رہنے کے لیے کہہ سکتا ہے۔
ہم نے اسے ایک سادہ وجہ سے نافذ نہیں کیا۔ ہمارے پاس بہت سارے دھاگے ہیں۔ ہمیں اس کی ضرورت کیوں ہے؟
یہ بالآخر اس میں مسائل پیدا کر سکتا ہے کہ اگر آپ کے پاس PAM کی توثیق اور غیر PAM توثیق ہے، تو PAM کی توثیق کی ایک بڑی لہر نان PAM توثیق میں نمایاں طور پر تاخیر کر سکتی ہے۔ یہ ان چیزوں میں سے ایک ہے جسے ہم نے طے نہیں کیا ہے۔ لیکن اگر آپ اسے ٹھیک کرنا چاہتے ہیں، تو آپ یہ کر سکتے ہیں۔
ایک اور ریک یہ تھا کہ ہمارے پاس ایک دھاگہ ہے جو آنے والے تمام رابطوں کو قبول کرتا ہے۔ اور پھر انہیں ورکر پول میں منتقل کر دیا جاتا ہے، جہاں TLS ہینڈ شیک ہو گا۔
پایان لائن، اگر آپ کے پاس 20 نیٹ ورک کنکشنز کی مربوط لہر ہے، تو وہ سب کو قبول کر لیا جائے گا۔ اور کلائنٹ کی طرف libpq ٹائم آؤٹ کی اطلاع دینا شروع کر دے گا۔ پہلے سے طے شدہ طور پر یہ 000 سیکنڈ لگتا ہے۔
اگر وہ سب ایک ہی وقت میں ڈیٹا بیس میں داخل نہیں ہوسکتے ہیں، تو وہ ڈیٹا بیس میں داخل نہیں ہوسکتے ہیں، کیونکہ یہ سب کچھ غیر کفایتی دوبارہ کوشش کے ذریعے احاطہ کیا جاسکتا ہے۔
ہم اس نتیجے پر پہنچے ہیں کہ ہم نے PgBouncer سے اسکیم کو یہاں اس حقیقت کے ساتھ نقل کیا ہے کہ ہم نے TCP کنکشنز کی تعداد کو تھروٹلنگ کر رکھا ہے جسے ہم قبول کرتے ہیں۔
اگر ہم دیکھتے ہیں کہ ہم کنکشن قبول کر رہے ہیں، لیکن آخر کار ان کے پاس مصافحہ کرنے کا وقت نہیں ہے، تو ہم انہیں ایک قطار میں لگا دیتے ہیں تاکہ وہ CPU کے وسائل کو ضائع نہ کریں۔ یہ اس حقیقت کی طرف جاتا ہے کہ بیک وقت مصافحہ ان تمام رابطوں کے لیے نہیں کیا جا سکتا جو پہنچ چکے ہیں۔ لیکن کم از کم کوئی ڈیٹا بیس میں داخل ہو گا، چاہے بوجھ کافی زیادہ ہو۔
روڈ میپ
آپ مستقبل میں اوڈیسی میں کیا دیکھنا چاہیں گے؟ ہم خود کو ترقی دینے کے لیے کیا تیار ہیں اور ہم کمیونٹی سے کیا توقع رکھتے ہیں؟
اگست 2019 تک۔
اگست میں اوڈیسی روڈ میپ کی طرح نظر آیا:
- ہم SCRAM اور PAM کی توثیق چاہتے تھے۔
- ہم پڑھنے کی درخواستوں کو اسٹینڈ بائی پر آگے بڑھانا چاہتے تھے۔
- میں آن لائن دوبارہ شروع کرنا چاہتا ہوں۔
- اور سرور پر توقف کرنے کی صلاحیت۔
اس روڈ میپ کا آدھا حصہ مکمل ہو چکا ہے، ہم نے نہیں۔ اور یہ اچھی بات ہے۔ تو آئیے اس پر تبادلہ خیال کریں کہ کیا باقی ہے اور مزید شامل کریں۔
? ہمارے پاس نقلیں ہیں جو درخواستوں پر عمل کیے بغیر ہوا کو گرم کریں گی۔ ہمیں ان کی ضرورت ہے کہ وہ فیل اوور اور سوئچ اوور فراہم کریں۔ ڈیٹا سینٹرز میں سے کسی ایک میں مسائل کی صورت میں، میں ان پر کچھ مفید کام کرنا چاہوں گا۔ کیونکہ ہم ایک ہی مرکزی پروسیسرز، ایک ہی میموری کو مختلف طریقے سے ترتیب نہیں دے سکتے ہیں، کیونکہ دوسری صورت میں نقل کام نہیں کرے گی۔
اصولی طور پر، پوسٹگریس میں، 10 سے شروع ہو کر، رابطہ کرتے وقت session_attrs کی وضاحت ممکن ہے۔ آپ کنکشن میں تمام ڈیٹابیس میزبانوں کی فہرست بنا سکتے ہیں اور کہہ سکتے ہیں کہ آپ ڈیٹا بیس پر کیوں جا رہے ہیں: صرف لکھیں یا پڑھیں۔ اور ڈرائیور خود فہرست میں سب سے پہلے میزبان کو منتخب کرے گا جو اسے سب سے زیادہ پسند ہے، جو سیشن_اٹارس کی ضروریات کو پورا کرتا ہے۔
لیکن اس نقطہ نظر کے ساتھ مسئلہ یہ ہے کہ یہ نقل کے وقفے کو کنٹرول نہیں کرتا ہے۔ آپ کے پاس کچھ نقل ہو سکتی ہے جو آپ کی خدمت کے لیے ناقابل قبول وقت کے لیے پیچھے رہ گئی ہے۔ نقل پر پڑھنے والے سوالات کی مکمل خصوصیات والے عمل کو فعال کرنے کے لیے، ہمیں بنیادی طور پر Odyssey کی اس قابلیت کو سپورٹ کرنے کی ضرورت ہے کہ جب اسے پڑھا نہیں جا سکتا ہے تو اسے نہ چلایا جائے۔
اوڈیسی کو وقتاً فوقتاً ڈیٹا بیس پر جانا چاہیے اور پرائمری سے نقل کی دوری کے لیے پوچھنا چاہیے۔ اور اگر یہ حد کی قدر کو پہنچ گیا ہے تو، ڈیٹا بیس میں نئی درخواستوں کی اجازت نہ دیں، کلائنٹ کو بتائیں کہ اسے کنکشن دوبارہ شروع کرنے کی ضرورت ہے اور، ممکنہ طور پر، درخواستوں کو انجام دینے کے لیے کسی دوسرے میزبان کو منتخب کریں۔ اس سے ڈیٹا بیس کو نقل کے وقفے کو تیزی سے بحال کرنے اور درخواست کے ساتھ جواب دینے کے لیے دوبارہ واپس آنے کی اجازت ملے گی۔
نفاذ کے لیے ٹائم فریم دینا مشکل ہے، کیونکہ یہ اوپن سورس ہے۔ لیکن، مجھے امید ہے کہ PgBouncer سے میرے ساتھیوں کی طرح 2,5 سال نہیں۔ یہ وہ خصوصیت ہے جسے میں اوڈیسی میں دیکھنا چاہوں گا۔
. اب آپ دو طریقوں سے تیار شدہ بیان بنا سکتے ہیں۔ سب سے پہلے، آپ ایس کیو ایل کمانڈ پر عمل کر سکتے ہیں، یعنی "تیار"۔ اس SQL کمانڈ کو سمجھنے کے لیے، ہمیں باؤنسر سائیڈ پر SQL کو سمجھنا سیکھنا ہوگا۔ یہ اوور کِل ہو گا، کیونکہ یہ اوور کِل ہے، کیونکہ ہمیں پورے پارسر کی ضرورت ہے۔ ہم ہر SQL کمانڈ کو پارس نہیں کر سکتے۔
لیکن پروٹو 3 پر میسج پروٹوکول کی سطح پر ایک تیار بیان موجود ہے۔ اور یہ وہ جگہ ہے جب وہ معلومات جو ایک تیار شدہ بیان تیار کیا جا رہا ہے ایک منظم شکل میں آتا ہے۔ اور ہم اس تفہیم کی حمایت کر سکتے ہیں کہ کچھ سرور کنکشن پر کلائنٹ نے تیار کردہ بیانات بنانے کو کہا۔ اور یہاں تک کہ اگر لین دین بند ہے، تب بھی ہمیں سرور اور کلائنٹ کے درمیان رابطہ برقرار رکھنے کی ضرورت ہے۔
لیکن یہاں مکالمے میں تضاد پیدا ہوتا ہے، کیونکہ کوئی کہتا ہے کہ آپ کو یہ سمجھنے کی ضرورت ہے کہ کلائنٹ نے کس قسم کے تیار کردہ بیانات بنائے ہیں اور اس سرور کنکشن کو تخلیق کرنے والے تمام کلائنٹس کے درمیان سرور کنکشن کا اشتراک کریں، یعنی جنہوں نے اس طرح کا تیار کردہ بیان بنایا ہے۔
اینڈریس فرینڈ نے کہا کہ اگر کوئی کلائنٹ آپ کے پاس آتا ہے جس نے پہلے ہی کسی دوسرے سرور کنکشن میں اس طرح کا تیار کردہ بیان تیار کیا ہے، تو اسے اس کے لیے بنائیں۔ لیکن کلائنٹ کے بجائے ڈیٹا بیس میں سوالات کو انجام دینا قدرے غلط معلوم ہوتا ہے، لیکن ڈیٹا بیس کے ساتھ بات چیت کے لیے پروٹوکول لکھنے والے ڈویلپر کے نقطہ نظر سے، یہ آسان ہوگا اگر اسے صرف ایک نیٹ ورک کنکشن دیا جائے جس میں اس طرح ایک تیار سوال ہے.
اور ایک اور خصوصیت جو ہمیں لاگو کرنے کی ضرورت ہے۔ اب ہمارے پاس پی جی باؤنسر کے ساتھ ہم آہنگ نگرانی ہے۔ ہم استفسار پر عمل درآمد کا اوسط وقت واپس کر سکتے ہیں۔ لیکن اوسط وقت ہسپتال میں اوسط درجہ حرارت ہے: کچھ سرد ہیں، کچھ گرم ہیں - اوسط، ہر کوئی صحت مند ہے. یہ سچ نہیں ہے.
ہمیں پرسنٹائلز کے لیے سپورٹ کو نافذ کرنے کی ضرورت ہے جو اس بات کی نشاندہی کرے گی کہ سست سوالات ہیں جو وسائل کو ضائع کر رہے ہیں اور نگرانی کو مزید قابل قبول بناتے ہیں۔
سب سے اہم بات یہ ہے کہ مجھے ورژن 1.0 چاہیے (ورژن 1.1 پہلے ہی ریلیز ہو چکا ہے)۔ حقیقت یہ ہے کہ اوڈیسی اب ورژن 1.0rc میں ہے، یعنی ریلیز امیدوار۔ اور تمام مسائل جو میں نے درج کیے ہیں بالکل اسی ورژن کے ساتھ طے کیے گئے تھے، سوائے میموری لیک کے۔
ہمارے لیے ورژن 1.0 کا کیا مطلب ہوگا؟ ہم اوڈیسی کو اپنے اڈوں پر لے جا رہے ہیں۔ یہ ہمارے ڈیٹا بیس پر پہلے سے ہی چل رہا ہے، لیکن جب یہ فی سیکنڈ 1 درخواستوں تک پہنچ جاتا ہے، تو ہم کہہ سکتے ہیں کہ یہ ریلیز ورژن ہے اور یہ ایک ایسا ورژن ہے جسے 000 کہا جا سکتا ہے۔
کمیونٹی کے کئی لوگوں نے کہا ہے کہ ورژن 1.0 میں توقف اور SCRAM شامل ہیں۔ لیکن اس کا مطلب یہ ہوگا کہ ہمیں اگلے ورژن کو پروڈکشن میں لانے کی ضرورت ہوگی، کیونکہ نہ تو SCRAM اور نہ ہی توقف ابھی تک مارا گیا ہے۔ لیکن، زیادہ تر امکان ہے، یہ مسئلہ بہت جلد حل ہو جائے گا.
میں آپ کی درخواست کا انتظار کر رہا ہوں۔ میں یہ بھی سننا چاہوں گا کہ آپ کو باؤنسر کے ساتھ کیا مسائل ہیں۔ آئیے ان پر بحث کرتے ہیں۔ ہو سکتا ہے کہ ہم کچھ ایسے فنکشنز کو نافذ کر سکیں جن کی آپ کو ضرورت ہے۔
یہ میرے حصے کا اختتام ہے، میں آپ کو سننا چاہتا ہوں۔ شکریہ!
آپ کے سوالات
اگر میں خود اپنا application_name سیٹ کرتا ہوں، تو کیا اسے درست طریقے سے فارورڈ کیا جائے گا، بشمول Odyssey میں ٹرانزیکشن پولنگ میں؟
اوڈیسی یا باؤنسر؟
اوڈیسی میں۔ باؤنسر میں اسے پھینکا جاتا ہے۔
ہم ایک سیٹ کریں گے۔
اور اگر میرا حقیقی کنکشن دوسرے کنکشن پر چھلانگ لگاتا ہے، تو کیا یہ منتقل ہو جائے گا؟
ہم تمام پیرامیٹرز کا ایک سیٹ بنائیں گے جو فہرست میں درج ہیں۔ میں یہ نہیں بتا سکتا کہ آیا application_name اس فہرست میں ہے۔ مجھے لگتا ہے کہ میں نے اسے وہاں دیکھا ہے۔ ہم تمام ایک جیسے پیرامیٹرز مرتب کریں گے۔ ایک درخواست کے ساتھ، سیٹ وہ سب کچھ کرے گا جو سٹارٹ اپ کے دوران کلائنٹ کے ذریعے انسٹال کیا گیا تھا۔
آپ کا شکریہ، اینڈری، رپورٹ کے لیے! اچھی رپورٹ! مجھے خوشی ہے کہ اوڈیسی ہر منٹ میں تیزی سے ترقی کر رہی ہے۔ میں اسی طرح جاری رکھنا چاہتا ہوں۔ ہم نے پہلے ہی آپ سے ملٹی ڈیٹا سورس کنکشن رکھنے کو کہا ہے تاکہ Odyssey بیک وقت مختلف ڈیٹا بیسز سے منسلک ہو سکے، یعنی ایک ماسٹر غلام، اور پھر فیل اوور کے بعد خود بخود ایک نئے ماسٹر سے جڑ جائے۔
ہاں، لگتا ہے مجھے یہ بحث یاد ہے۔ اب وہاں کئی ذخیرہ ہیں۔ لیکن ان کے درمیان کوئی تبدیلی نہیں ہے۔ ہماری طرف، ہمیں سرور پر رائے شماری کرنی چاہیے کہ یہ ابھی تک زندہ ہے اور سمجھیں کہ ایک فیل اوور ہوا ہے، جو pg_recovery کو کال کرے گا۔ میرے پاس سمجھنے کا ایک معیاری طریقہ ہے کہ ہم آقا کے پاس نہیں آئے۔ اور غلطیوں سے ہمیں کسی طرح سمجھنا چاہیے یا کیا؟ یعنی خیال دلچسپ ہے، اس پر بحث ہو رہی ہے۔ مزید تبصرے لکھیں۔ اگر آپ کے پاس ایسے کارکن ہیں جو C جانتے ہیں، تو یہ عام طور پر بہت اچھا ہے۔
نقلوں میں اسکیلنگ کا مسئلہ بھی ہمارے لیے دلچسپی کا باعث ہے، کیونکہ ہم ایپلیکیشن ڈویلپرز کے لیے نقل شدہ کلسٹرز کو اپنانے کو جتنا ممکن ہو آسان بنانا چاہتے ہیں۔ لیکن یہاں میں مزید تبصرے چاہوں گا، یعنی بالکل یہ کیسے کرنا ہے، اسے اچھی طرح سے کیسے کرنا ہے۔
سوال نقل کے بارے میں بھی ہے۔ یہ پتہ چلتا ہے کہ آپ کے پاس ایک ماسٹر اور کئی نقلیں ہیں۔ اور یہ واضح ہے کہ وہ کنکشن کے لیے ماسٹر کے مقابلے میں کم کثرت سے نقل پر جاتے ہیں، کیونکہ ان میں اختلافات ہو سکتے ہیں۔ آپ نے کہا کہ ڈیٹا میں فرق ایسا ہو سکتا ہے کہ اس سے آپ کے کاروبار کی تسکین نہیں ہو گی اور جب تک اسے نقل نہیں کیا جائے گا آپ وہاں نہیں جائیں گے۔ ساتھ ہی، اگر آپ کافی دیر تک وہاں نہیں گئے، اور پھر جانا شروع کر دیا، تو جو ڈیٹا درکار ہے وہ فوری طور پر دستیاب نہیں ہوگا۔ یعنی اگر ہم مسلسل آقا کے پاس جائیں تو وہاں کی کیش گرم ہو جاتی ہے، لیکن نقل میں کیش تھوڑا سا پیچھے رہ جاتا ہے۔
جی ہاں یہ سچ ہے. pcache میں وہ ڈیٹا بلاکس نہیں ہوں گے جو آپ چاہتے ہیں، اصلی کیشے میں آپ کے مطلوبہ ٹیبلز کے بارے میں معلومات نہیں ہوں گی، پلانز میں تجزیہ کردہ سوالات نہیں ہوں گے، کچھ بھی نہیں ہوگا۔
اور جب آپ کے پاس کسی قسم کا کلسٹر ہوتا ہے، اور آپ وہاں ایک نیا ریپلیکا شامل کرتے ہیں، تو جب یہ شروع ہوتا ہے، اس میں سب کچھ خراب ہوتا ہے، یعنی اس کا ذخیرہ بڑھاتا ہے۔
مجھے خیال آیا۔ صحیح نقطہ نظر یہ ہوگا کہ پہلے نقل پر سوالات کا ایک چھوٹا فیصد چلایا جائے ، جو کیشے کو گرم کرے گا۔ موٹے الفاظ میں، ہماری شرط ہے کہ ہمیں ماسٹر سے 10 سیکنڈ سے زیادہ پیچھے نہیں رہنا چاہیے۔ اور یہ حالت ایک لہر میں شامل نہیں ہے، لیکن کچھ گاہکوں کے لئے آسانی سے.
ہاں وزن بڑھائیں۔
یہ ایک اچھا خیال ہے۔ لیکن پہلے ہمیں اس بند کو نافذ کرنے کی ضرورت ہے۔ پہلے ہمیں آف کرنے کی ضرورت ہے، اور پھر ہم سوچیں گے کہ کیسے آن کیا جائے۔ آسانی سے فعال کرنے کے لیے یہ ایک بہترین خصوصیت ہے۔
Nginx کے پاس یہ آپشن ہے۔ slowly start سرور کے لیے ایک کلسٹر میں۔ اور وہ آہستہ آہستہ بوجھ بڑھاتا ہے۔
جی ہاں، بہت اچھا خیال، جب ہم اس تک پہنچیں گے تو ہم اسے آزمائیں گے۔
ماخذ: www.habr.com