د هغه په خبرو کې، انډری بوروډین به تاسو ته ووایي چې څنګه دوی د پی جی باونسر اندازه کولو تجربه په پام کې نیولې کله چې د ارتباط پولر ډیزاین کوي ، دوی دا څنګه په تولید کې راوباسي. سربیره پردې ، موږ به پدې اړه بحث وکړو چې د پولر کومې دندې چې موږ غواړو په نوي نسخو کې وګورو: دا زموږ لپاره نه یوازې زموږ اړتیاو پوښلو لپاره مهم دي ، بلکه د کارونکي ټولنې پراختیا لپاره. .
ویډیو:
سلام و ټولو ته! زما نوم اندریو دی.
په Yandex کې، زه د خلاصې سرچینې ډیټابیسونو ته وده ورکوم. او نن ورځ موږ د کنکشن پولر اړیکو په اړه موضوع لرو.
که تاسو پوهیږئ چې څنګه په روسیه کې د ارتباط پولر ته زنګ ووهئ ، نو ما ته ووایاست. زه واقعیا غواړم یو ښه تخنیکي اصطلاح ومومئ چې باید په تخنیکي ادب کې رامینځته شي.
موضوع خورا پیچلې ده ، ځکه چې په ډیری ډیټابیسونو کې د پیوستون پولر جوړ شوی او تاسو حتی اړتیا نلرئ پدې اړه پوه شئ. ځینې ترتیبات، البته، هرچیرې دي، مګر په Postgres کې دا کار نه کوي. او په موازي ډول (په HighLoad++ 2019 کې) په پوسټګریس کې د پوښتنو ترتیب کولو په اړه د نیکولای سموخوالوف لخوا راپور شتون لري. او زه پوهیږم چې هغه خلک دلته راغلي دي چې دمخه یې غوښتنې په سمه توګه تنظیم کړي دي، او دا هغه خلک دي چې د شبکې، د سرچینو کارولو پورې اړوند د نادر سیسټم ستونزو سره مخ دي. او په ځینو ځایونو کې دا خورا ستونزمن کیدی شي پدې معنی چې ستونزې څرګندې ندي.
Yandex Postgres لري. ډیری Yandex خدمتونه په Yandex.Cloud کې ژوند کوي. او موږ ډیری پیټابایټ ډیټا لرو چې په پوسټګریس کې په هره ثانیه کې لږترلږه یو ملیون غوښتنې رامینځته کوي.
او موږ د ټولو خدماتو لپاره په کافي اندازه عادي کلستر چمتو کوو - دا د نوډ اصلي اصلي نوډ دی، معمول دوه نقلونه (همغږي او غیر متمرکز)، بیک اپ، په نقل کې د لوستلو غوښتنو اندازه کول.
هر کلستر نوډ پوسټګریس دی ، په کوم کې چې د پوسټګریس او نظارت سیسټمونو سربیره ، د پیوستون پولر هم نصب شوی. د کنکشن پولر د کټارو لپاره او د دې اصلي هدف لپاره کارول کیږي.
د پیوستون پولر اصلي موخه څه ده؟
پوسټګریس د ډیټابیس سره کار کولو لپاره د پروسې ماډل غوره کوي. دا پدې مانا ده چې یو اړیکه یوه پروسه ده، یو پوسټګریس پس منظر. او پدې پس منظر کې ډیری مختلف کیچونه شتون لري ، کوم چې د مختلف ارتباطاتو لپاره مختلف کولو لپاره خورا ګران دي.
همچنان ، د پوسټګریس کوډ کې یو سري شتون لري چې د پروکار په نوم یادیږي. دا د شبکې اړیکو په اړه لومړني معلومات لري. او نږدې ټول procArray پروسس کولو الګوریتمونه خطي پیچلتیا لري ، دوی د شبکې اتصالاتو ټول صف څخه تیریږي. دا یو ډیر ګړندی دوره ده، مګر د ډیرو راتلونکو شبکو اړیکو سره، شیان یو څه ډیر ګران کیږي. او کله چې شیان یو څه ډیر ګران شي ، نو تاسو د ډیری شبکې اتصالاتو لپاره خورا لوړ نرخ تادیه کوئ.
درې ممکنه لارې شتون لري:
- د غوښتنلیک په اړخ کې.
- د ډیټابیس اړخ ته.
- او تر منځ، دا ټول ممکنه ترکیبونه دي.
له بده مرغه، جوړ شوی پولر اوس مهال د پراختیا په حال کې دی. په PostgreSQL پروفیشنل کې ملګري ډیری دا کار کوي. دا به کله ښکاره شي اټکل کول ستونزمن دي. او په حقیقت کې، موږ د معمار د انتخاب لپاره دوه حلونه لرو. دا د غوښتنلیک اړخ حوض او پراکسي پول دي.
د غوښتنلیک اړخ حوض ترټولو اسانه لاره ده. او نږدې ټول پیرودونکي ډرایورونه تاسو ته یوه لاره درکوي: په کوډ کې ستاسو د ملیونونو اتصالونو نمایندګي وکړئ لکه څنګه چې ډیټابیس ته لسګونه اړیکې.
د دې حقیقت سره ستونزه شتون لري چې په یو ټاکلي وخت کې تاسو غواړئ د شالید اندازه اندازه کړئ ، تاسو غواړئ دا ډیری مجازی ماشینونو ته ځای په ځای کړئ.
بیا تاسو لاهم پوهیږئ چې تاسو د شتون ډیری نور زونونه لرئ ، ډیری ډیټا مرکزونه. او د پیرودونکي اړخ پولینګ چلند لوی شمیر ته لار هواروي. لوی یې شاوخوا 10 اړیکې لري. دا یوه څنډه ده چې کولی شي ښه کار وکړي.
که موږ د پراکسي پولرونو په اړه وغږیږو، نو دوه پولرونه شتون لري چې کولی شي ډیر شیان ترسره کړي. دوی نه یوازې پولرونه دي. دوی پولرونه دي + ډیر ښه فعالیت. دا и .
مګر، له بده مرغه، هرڅوک دې اضافي فعالیت ته اړتیا نلري. او دا د دې حقیقت لامل کیږي چې پولر یوازې د سیشن پولینګ ملاتړ کوي ، د بیلګې په توګه یو راتلونکی پیرودونکي ، ډیټابیس ته یو وتلی پیرودونکي.
دا زموږ د دندو لپاره خورا مناسب نه دی، نو موږ د PgBouncer کاروو، کوم چې د لیږد پولینګ پلي کوي، د بیلګې په توګه د سرور اړیکې یوازې د لیږد د مودې لپاره د مراجعینو اړیکو ته نقشه شوي.
او زموږ په بار کې - دا ریښتیا ده. مګر یو شمیر ستونزې شتون لري.
ستونزې هغه وخت پیل کیږي کله چې تاسو غواړئ د ناستې تشخیص وکړئ، ځکه چې ټولې راتلونکی اړیکې محلي دي. هرڅوک د لوپ بیک سره راغلی او یو څه د ناستې تعقیب ستونزمن کیږي.
البته تاسو کولی شئ application_name_add_host وکاروئ. دا غوښتنلیک_نوم ته د IP پته اضافه کولو لپاره د باونسر اړخ لاره ده. مګر application_name د اضافي پیوستون لخوا تنظیم شوی.
په دې چارټ کې، چیرې چې ژیړ کرښه ریښتینې غوښتنې دي، او چیرې چې نیلي کرښه هغه غوښتنې دي چې ډیټابیس ته ځي. او دا توپیر دقیقا د application_name ترتیب دی ، کوم چې یوازې د تعقیب لپاره اړین دی ، مګر دا په بشپړ ډول وړیا ندی.
برسېره پردې، باونسر نشي کولی یو حوض محدود کړي، د بیلګې په توګه د هر کاروونکي ډیټابیس اړیکو شمیر، په هر ډیټابیس کې.
دا څه لامل کیږي؟ تاسو یو بار شوی خدمت لرئ چې په C ++ کې لیکل شوی او بل چیرې نږدې په نوډ کې یو کوچنی خدمت شتون لري چې د بیس سره هیڅ غلط نه کوي ، مګر د هغې چلوونکی لیونی کیږي. دا 20 اړیکې خلاصوي او نور هرڅه به انتظار وکړي. حتی ستاسو کوډ سم دی.
البته، موږ د باونسر لپاره یو کوچنی پیچ لیکلی چې دا ترتیب یې اضافه کړی، د بیلګې په توګه حوض ته د مراجعینو محدودول.
دا به ممکنه وي چې دا د پوسټګریس اړخ کې ترسره کړئ، د بیلګې په توګه په ډیټابیس کې رولونه د اړیکو شمیر ته محدود کړئ.
مګر بیا تاسو د پوهیدو وړتیا له لاسه ورکوئ چې ولې تاسو له سرور سره هیڅ اړیکه نلرئ. PgBouncer د پیوستون تېروتنه نه کوي، دا تل ورته معلومات بیرته راولي. او تاسو نه پوهیږئ: شاید ستاسو پټنوم بدل شوی وي، شاید ډیټابیس یوازې ښکته شوی وي، شاید یو څه غلط وي. مګر هیڅ تشخیص شتون نلري. که غونډه جوړه نشي، تاسو به نه پوهیږئ چې دا ولې نشي ترسره کیدی.
په یو ټاکلي وخت کې، تاسو د غوښتنلیک ګرافونو ته ګورئ او وګورئ چې غوښتنلیک کار نه کوي.
په پورتنۍ برخه کې وګورئ او وګورئ چې باونسر یو اړخیز دی. دا د خدمت په ژوند کې یو مهم ټکی دی. تاسو پوهیږئ چې تاسو په یو نیم کال کې د ډیټابیس اندازه کولو لپاره چمتووالی نیولی و، او تاسو اړتیا لرئ چې پولر اندازه کړئ.
موږ دې پایلې ته رسیدلي یو چې موږ نورو PgBouncers ته اړتیا لرو.
توپ اچوونکی یو څه پیچلی شوی دی.
او دوی یې جوړ کړل ترڅو د TCP بندر له بیا کارولو سره څو باونسرونه راپورته شي. او دمخه عملیاتي سیسټم په اوتومات ډول د راؤنډ-روبینوم لخوا د دوی ترمینځ راتلونکي TCP اړیکې لیږدوي.
دا د پیرودونکو لپاره شفاف دی، د بیلګې په توګه داسې ښکاري چې تاسو یو باونسر لرئ، مګر تاسو د چلولو باونسرونو ترمنځ د بې کاره اړیکو ټوټه ټوټه لرئ.
او په ځینو وختونو کې، تاسو شاید وګورئ چې دا 3 توپ اچوونکي هر یو خپل اصلي 100٪ خوري. تاسو یو څو توپ اچوونکو ته اړتیا لرئ. ولې؟
ځکه چې تاسو TLS لرئ. تاسو یو کوډ شوی پیوستون لرئ. او که تاسو د TLS سره او پرته پوسټګریس بنچمارک کړئ ، نو تاسو به ومومئ چې د تاسیس شوي ارتباطاتو شمیر د کوډ کولو فعال شوي سره نږدې دوه آرډرونو شدت سره راټیټیږي ، ځکه چې د TLS لاسي شیک د CPU سرچینې مصرفوي.
او په پورتنۍ برخه کې، تاسو کولی شئ یو څو کریپټوګرافیک فعالیتونه وګورئ چې د راتلونکو اړیکو څپې په جریان کې اجرا کیږي. له هغه ځایه چې زموږ لومړني کولی شي د شتون زونونو ترمینځ تیر شي ، د راتلونکو اړیکو څپې خورا عادي حالت دی. دا د ځینو دلیلونو لپاره، زوړ ابتدايي شتون نلري، ټول بار د معلوماتو مرکز ته لیږل شوی و. دوی ټول به په ورته وخت کې TLS ته سلام ووایی.
او د TLS لاسوندونو لوی شمیر ممکن دمخه باونسر ته ښه راغلاست ونکړي ، مګر د هغه ستوني راوباسي. د راتلونکو اړیکو څپې ممکن د وخت پای ته رسیدو له امله بې برخې شي. که تاسو د اضطراري بیک آف پرته اډې ته بیا هڅه وکړئ ، نو دوی به په یو همغږي څپې کې بیرته نه راځي.
دلته د 16 PgBouncers یوه بیلګه ده چې 16 کورونه په 100٪ باروي.
موږ د کاسکیډینګ PgBouncer ته رسیدلي یو. دا غوره ترتیب دی چې موږ کولی شو زموږ د باونسر بار کې ترلاسه کړو. زموږ بهرني باونسرونه د TCP لاسي صیب لپاره خدمت کوي ، او داخلي باونسر د ریښتیني پولینګ لپاره خدمت کوي ، ترڅو بهرنۍ اړیکې په پراخه کچه ټوټه نشي.
په دې ترتیب کې، یو نرم بیا پیل ممکن دی. تاسو کولی شئ دا ټول 18 باونسرونه یو له بل سره بیا پیل کړئ. مګر د داسې ترتیب ساتل خورا ستونزمن دي. د سیسټم مدیران، DevOps، او هغه خلک چې واقعیا د دې سرور لپاره مسؤل دي د دې سکیم سره به ډیر خوښ نه وي.
داسې ښکاري چې زموږ ټول پرمختګونه په خلاصې سرچینې کې وده کولی شي، مګر باونسر ډیر ښه ملاتړ نه کوي. د مثال په توګه، په ورته بندر کې د ډیری PgBouncers چلولو وړتیا یوه میاشت دمخه ژمنه شوې وه. د دې خصوصیت سره د پلولو غوښتنه څو کاله دمخه وه.
یا یو بل مثال. په پوسټګریس کې، تاسو کولی شئ د اضافي تصدیق پرته بل ارتباط ته د پټ لیږلو له لارې روانه غوښتنه لغوه کړئ. مګر ځینې پیرودونکي په ساده ډول د TCP ریسیټ لیږي ، د بیلګې په توګه دوی د شبکې اتصال ماتوي. باونسر به له دې سره څه وکړي؟ هغه به هیڅ ونه کړي. دا به د غوښتنې اجرا کولو ته دوام ورکړي. که تاسو لوی شمیر اړیکې ترلاسه کړې وي چې اساس یې د کوچنیو غوښتنو سره ایښودلی وي ، نو په ساده ډول د باونسر څخه د اتصال قطع کول به کافي نه وي ، تاسو لاهم اړتیا لرئ هغه غوښتنې بشپړې کړئ چې په ډیټابیس کې روانې دي.
دا پیچل شوی او مسله لاهم د باونسر په جریان کې نه ده یوځای شوې.
او له همدې امله موږ دې پایلې ته ورسیدو چې موږ خپل د پیوستون پولر ته اړتیا لرو، کوم چې به پراختیا ومومي، پیچل شي، په کوم کې چې دا به ممکنه وي چې ژر تر ژره ستونزې حل کړي او البته، باید څو اړخیز وي.
موږ ملټي ټریډینګ د اصلي دندې په توګه تنظیم کوو. موږ اړتیا لرو چې د راتلوونکي TLS اړیکو څپې په ښه توګه اداره کړو.
د دې کولو لپاره، موږ باید د ماشیناریوم په نوم یو جلا کتابتون جوړ کړو، کوم چې د شبکې ارتباط د ماشین حالت د سریال کوډ په توګه تشریح کولو لپاره ډیزاین شوی. که تاسو د libpq سرچینې کوډ ته ګورئ ، تاسو به خورا پیچلي تلیفونونه وګورئ چې کولی شي تاسو ته پایله درکړي او ووایی ، "ما لږ وروسته زنګ ووهئ. همدا اوس زه د اوس لپاره IO لرم ، مګر کله چې IO تیریږي ، زه پروسیسر باندې بار لرم. او دا یو څو اړخیز سکیم دی. د شبکې تعامل معمولا د دولتي ماشین لخوا تشریح کیږي. ډیری قواعد لکه "که ما دمخه د اندازې N د کڅوړې سرلیک ترلاسه کړ، نو اوس زه د N بایټس په تمه یم"، "که ما د SYNC پاکټ لیږلی وي، نو اوس زه د پایلې میټاډاټا سره د پاکټ په تمه یم." دا یو ډیر ستونزمن ضد رواني کوډ وګرځید، لکه څنګه چې بھولبلییا په لاین سکین بدله شوې وه. موږ دا جوړ کړل چې د دولتي ماشین پرځای، پروګرامر د عادي اړین کوډ په بڼه د اصلي متقابل عمل لاره تشریح کوي. یوازې پدې لازمي کوډ کې ، تاسو اړتیا لرئ هغه ځایونه دننه کړئ چیرې چې د اعدام لړۍ باید د شبکې څخه ډیټا ته په انتظار کولو سره مداخله وکړي ، د اجرا کولو شرایط بل کورټین (شنه تار) ته لیږدوي. دا طریقه د حقیقت سره ورته ده چې موږ په مزی کې ترټولو تمه شوې لاره په قطار کې لیکو، او بیا یې څانګې اضافه کوو.
د پایلې په توګه، موږ یو تار لرو چې د TCP منلو وړ ګرځوي او راؤنډ رابین ډیری کارمندانو ته د TPC پیوستون لیږدوي.
پدې حالت کې ، د هر پیرودونکي اړیکې تل په یو پروسیسر چلیږي. او دا تاسو ته اجازه درکوي چې دا د کیچ دوستانه کړي.
او سربیره پردې ، موږ د سیسټم TCP سټیک آفلوډ کولو لپاره په یوه لوی پاکټ کې د کوچنیو کڅوړو راټولول یو څه ښه کړي دي.
برسېره پردې، موږ د راکړې ورکړې پولینګ په دې معنی کې ښه کړی چې Odyssey، کله چې تنظیم شوی وي، کولی شي د شبکې اتصال ناکامۍ په صورت کې CANCEL او ROLLBACK واستوي، د بیلګې په توګه که هیڅوک د غوښتنې په تمه نه وي، اوډیسي به ډیټابیس ته ووایي چې د پوره کولو هڅه مه کوه. هغه غوښتنه چې کولی شي قیمتي سرچینې ضایع کړي.
او هرکله چې امکان ولري ، موږ ورته پیرودونکي سره اړیکې ساتو. دا د غوښتنلیک_نوم_add_host بیا نصبولو څخه مخنیوی کوي. که امکان ولري، نو بیا موږ د پیرامیټونو اضافي بیا تنظیم نه لرو چې د تشخیص لپاره اړین دي.
موږ د Yandex.Cloud په ګټو کې کار کوو. او که تاسو اداره شوي PostgreSQL کاروئ او تاسو د پیوستون پولر نصب کړی وي ، تاسو کولی شئ منطقي نقل بهر ته رامینځته کړئ ، د مثال په توګه موږ پریږدئ که تاسو وغواړئ ، د منطقي نقل په کارولو سره. د منطقي نقل له جریان څخه بهر باونسر به نه ورکوي.
دا د منطقي نقل ترتیب کولو یوه بیلګه ده.
سربیره پردې ، موږ د فزیکي عکس العمل لپاره ملاتړ لرو. په کلاوډ کې، البته، دا ناممکن دی، ځکه چې بیا کلستر به تاسو ته د خپل ځان په اړه ډیر معلومات درکړي. مګر ستاسو په تاسیساتو کې، که تاسو په اوډیسي کې د ارتباط پولر له لارې فزیکي نقل ته اړتیا لرئ، دا ممکنه ده.
اوډیسي د PgBouncer سره په بشپړ ډول مناسب نظارت لري. موږ ورته کنسول لرو چې نږدې ټول ورته حکمونه اجرا کوي. که یو څه ورک وي، د پلټ غوښتنه واستوئ، یا لږترلږه په GitHub کې یوه مسله، موږ به اړین امرونه بشپړ کړو. مګر موږ دمخه د PgBouncer کنسول اصلي فعالیت لرو.
او البته موږ تېروتنه لرو. موږ به د اډې لخوا راپور شوي غلطۍ بیرته راستانه کړو. تاسو به معلومات ترلاسه کړئ چې تاسو ولې په اډه کې نه یاست، نه یوازې دا چې تاسو په دې کې نه یاست.
دا خصوصیت غیر فعال دی که تاسو د PgBouncer سره 100٪ مطابقت ته اړتیا لرئ. موږ کولی شو د باونسر په څیر چلند وکړو، یوازې په قضیه کې.
پرمختیا
د اوډیسي سرچینې کوډ په اړه یو څو ټکي.
د مثال په توګه، د "Pause / Resume" کمانډونه شتون لري. دوی معمولا د ډیټابیس تازه کولو لپاره کارول کیږي. که تاسو د پوسټګریس لوړولو ته اړتیا لرئ، تاسو کولی شئ دا د ارتباط پولر کې ودروئ، pg_upgrade وکړئ، بیا پیل کړئ. او د پیرودونکي اړخ څخه ، دا به داسې ښکاري چې ډیټابیس یوازې ورو و. دا فعالیت موږ ته د ټولنې د خلکو لخوا راوړل شوی. هغه تر اوسه نه ده مړه شوې، خو ډېر ژر به هر څه شي. (مخکې مړ شوی)
- دمخه مړ شوی
سربیره پردې ، په PgBouncer کې یو له نویو ځانګړتیاو څخه د SCRAM تصدیق ملاتړ دی ، کوم چې موږ ته د هغه چا لخوا هم راوړل شوی چې په Yandex.Cloud کې کار نه کوي. دواړه پیچلي فعالیت او مهم دي.
له همدې امله ، زه غواړم تاسو ته ووایم چې اوډیسي له څه شی څخه جوړ شوی ، په هغه صورت کې چې تاسو همدا اوس یو څه کوډ ولیکئ.
تاسو د اوډیسي اصلي اډه لرئ، کوم چې په دوو اصلي کتابتونونو تکیه کوي. د کیوي کتابتون د پوسټګریس پیغام پروتوکول پلي کول دي. دا دی، د پوسټګریس اصلي پروټو 3 معیاري پیغامونه دي چې مخکني او شاته یې تبادله کولی شي. دوی د کیوي کتابتون کې پلي شوي.
د ماشینریوم کتابتون د تار پلي کولو کتابتون دی. د دې ماشینریوم یوه کوچنۍ ټوټه په جمع کولو کې لیکل شوې ده. مګر اندیښنه مه کوئ، یوازې 15 کرښې شتون لري.
د اوډیسي معمارۍ. یو اصلي ماشین شتون لري چې کوروټین چلوي. دا ماشین د راتلونکو TCP پیوستونونو منلو او د کارمندانو ترمنځ ویش پلي کوي.
د یو کارګر دننه، د څو پیرودونکو لپاره یو سمبالونکی کار کولی شي. او همدارنګه په اصلي تار کې ، کنسول او د کرون دندو پروسس کول د ارتباطاتو لرې کولو لپاره چې نور په حوض کې ورته اړتیا نلري سپن کیږي.
اوډیسي د معیاري پوسټګریس ټیسټ سویټ په کارولو سره ازمول شوی. موږ یوازې د باونسر له لارې انسټال چیک چلوو او د اوډیسي له لارې، موږ یو ناپاک div ترلاسه کوو. د نیټې فارمیټینګ پورې اړوند ډیری ازموینې شتون لري چې په باونسر او اوډیسي کې ورته ورته ناکامیږي.
سربیره پردې ، ډیری موټر چلونکي شتون لري چې خپله ازموینه لري. او موږ د دوی ازموینې د اوډیسي ازموینې لپاره کاروو.
همچنان ، زموږ د کاسکیډینګ ترتیب له امله ، موږ باید مختلف بنډلونه و ازمویو: Postgres + Odyssey ، PgBouncer + Odyssey ، Odyssey + Odyssey د دې لپاره چې ډاډ ترلاسه شي که اوډیسي د کاسکیډ په هره برخه کې وي ، دا لاهم د تمې سره سم کار کوي. .
ریک
موږ په تولید کې Odyssey کاروو. او دا به عادلانه نه وي که زه وایم چې هرڅه یوازې کار کوي. نه، یعني هو، مګر تل نه. د مثال په توګه ، په تولید کې هرڅه یوازې کار کوي ، بیا زموږ ملګري د PostgreSQL پروفیشنل څخه راغلل او ویې ویل چې موږ د حافظې لیک درلود. دوی واقعیا وو ، موږ یې تنظیم کړل. خو دا ساده وه.
بیا موږ وموندله چې د پیوستون پولر راتلونکی TLS اتصالونه او د وتلو TLS اړیکې لري. او اړیکې د مراجعینو سندونو او سرور سندونو ته اړتیا لري.
د باونسر او اوډیسي سرور سندونه د pcache لخوا بیا لوستل کیږي ، مګر د پیرودونکي سندونه د pcache څخه بیا لوستلو ته اړتیا نلري ، ځکه چې زموږ د توزیع وړ اوډیسي په پای کې د دې سند لوستلو سیسټم فعالیت پورې اړه لري. دا زموږ لپاره حیرانتیا وه، ځکه چې هغه سمدستي آرام نه و. په لومړي سر کې دا په خطي توګه اندازه شوې، او د 20 راتلونکو یوځل اړیکو وروسته، دا ستونزه پخپله ښکاره شوه.
د پلګ ایبل تصدیق کولو میتود د جوړ شوي لیونکس وسیلو سره د تصدیق کولو وړتیا ده. په PgBouncer کې، دا په داسې ډول پلي کیږي چې د PAM څخه د ځواب په انتظار کې یو جلا تار شتون لري او یو اصلي PgBouncer تار شتون لري چې اوسني پیوستون ته خدمت کوي او کولی شي له دوی څخه وغواړي چې د PAM تار کې ژوند وکړي.
موږ دا د یو ساده دلیل لپاره پلي نه کړل. موږ ډیری جریانونه لرو. ولې موږ ورته اړتیا لرو؟
د پایلې په توګه ، دا کولی شي پدې کې ستونزې رامینځته کړي که تاسو د PAM تصدیق او غیر PAM تصدیق ولرئ ، نو د PAM تصدیق لوی څپې کولی شي د پام وړ غیر PAM تصدیق وځنډوي. دا یو له هغو شیانو څخه دی چې موږ یې نه دی ټاکلی. مګر که تاسو غواړئ دا سم کړئ، تاسو کولی شئ دا کار وکړئ.
بل ریک د دې حقیقت سره و چې موږ یو تار لرو چې ټول راتلونکي اړیکې مني. او بیا دوی د کارګر حوض ته لیږدول کیږي، چیرې چې د TLS لاسونه به ترسره شي.
د پایلې په توګه، که تاسو د 20 شبکې اتصالونو یو همغږي څپې ولرئ، دوی به ټول ومنل شي. او د پیرودونکي اړخ کې ، libpq به د راپور ورکولو مهال ویش پیل کړي. په ډیفالټ ډول، دا د 000 ثانیو په څیر دی.
که دوی ټول نشي کولی په ورته وخت کې اډې ته ننوځي، نو دوی نشي کولی اډې ته ننوځي، ځکه چې دا ټول د غیر اضطراري بیاکتنې لخوا پوښل کیدی شي.
موږ دلته د PgBouncer سکیم کاپي کول پای ته ورسوو ترڅو موږ د TCP اتصالونو شمیر چې موږ یې منو.
که موږ وګورو چې موږ اړیکې منو ، مګر دوی په پای کې د لاس ورکولو لپاره وخت نلري ، موږ یې په کتار کې واچوو ترڅو دوی د CPU سرچینې مصرف نکړي. دا د دې حقیقت لامل کیږي چې یوځل لاسونه د ټولو اړیکو لپاره چې رسیدلي ندي ترسره کیدی شي. مګر لږترلږه یو څوک به ډیټابیس ته ننوځي ، حتی که بار خورا قوي وي.
نقشه
تاسو په راتلونکي کې په اوډیسي کې څه لیدل غواړئ؟ موږ د خپل ځان د پرمختګ لپاره څه چمتو کوو او له ټولنې څخه څه تمه لرو؟
د اګست 2019 لپاره.
دا هغه څه دي چې د اوډیسي سړک نقشه په اګست کې ښکاري:
- موږ د SCRAM او PAM تصدیق غواړو.
- موږ غوښتل چې د لوستلو غوښتنې د سټنډرډ لپاره وړاندې کړو.
- زه غواړم آنلاین بیا پیل کړم.
- او په سرور کې د بندولو وړتیا.
د دې سړک نیمایي برخه ترسره شوې، او زموږ لخوا نه ده. او دا ښه دی. نو راځئ چې بحث وکړو چې څه پاتې دي او نور اضافه کړئ.
؟ موږ نقلونه لرو چې د غوښتنو پوره کولو پرته به په ساده ډول هوا تودوخه کړي. موږ دوی ته اړتیا لرو چې ناکام او سویچ اوور چمتو کړو. د معلوماتو په یوه مرکز کې د ستونزو په صورت کې، زه غواړم دوی د یو څه ګټور کار سره اشغال کړم. ځکه چې موږ نشو کولی ورته مرکزي پروسیسرونه، ورته حافظه په بل ډول تنظیم کړو، ځکه چې نقل کول به بل کار ونه کړي.
په اصولو کې، په پوسټګریس کې، د 10 څخه پیل کیږي، دا ممکنه ده چې د نښلولو پر مهال سیشن_attrs مشخص کړئ. تاسو کولی شئ په اړیکه کې د ډیټابیس ټول کوربه لیست کړئ او ووایاست چې تاسو ولې ډیټابیس ته ځئ: یوازې ولیکئ یا ولولئ. او پخپله ډرایور به په لیست کې لومړی کوربه غوره کړي چې دا غوره خوښوي، کوم چې د سیشن_attrs اړتیاوې پوره کوي.
مګر د دې طریقې سره ستونزه دا ده چې دا د نقل کولو ځنډ کنټرول نه کوي. تاسو ممکن یو ډول نقل ولرئ چې ستاسو د خدمت لپاره د نه منلو وړ وخت لخوا شاته وي. د دې لپاره چې په نقل کې د لوستلو غوښتنو بشپړ مشخص اجرا کولو لپاره ، په حقیقت کې ، موږ اړتیا لرو په اوډیسي کې د دې وړتیا ملاتړ وکړو چې کار ونه کړي کله چې لوستل ناممکن وي.
اوډیسي باید وخت په وخت ډیټابیس ته لاړ شي او له لومړني څخه د نقل فاصلې غوښتنه وکړي. او که دا حد ته رسیدلی وي، ډیټابیس ته نوې غوښتنې مه پریږدئ، پیرودونکي ته ووایاست چې تاسو اړتیا لرئ د اړیکو بیا پیلولو ته اړتیا ولرئ او احتمالا، د غوښتنو اجرا کولو لپاره بل کوربه غوره کړئ. دا به ډیټابیس ته اجازه ورکړي چې ژر تر ژره د نقل کولو ځنډ بیرته راولي او د پوښتنې سره ځواب ویلو لپاره بیرته راستون شي.
د تطبیق نیټې نومول ستونزمن کار دی، ځکه چې دا خلاص سرچینه ده. مګر، زه هیله لرم چې د PgBouncer د همکارانو په څیر 2,5 کاله نه وي. دا هغه ځانګړتیا ده چې زه غواړم په اوډیسي کې وګورم.
. اوس تاسو کولی شئ په دوه لارو چمتو شوی بیان جوړ کړئ. لومړی، تاسو کولی شئ د SQL کمانډ اجرا کړئ، یعنې "تیار شوی". د دې SQL کمانډ د پوهیدو لپاره، موږ باید د باونسر اړخ کې د SQL د پوهیدو څرنګوالی زده کړو. دا به ډیر کیل وي ځکه چې دا خورا ډیر دی ځکه چې موږ ټول پارسر ته اړتیا لرو. موږ نشو کولی هر SQL کمانډ تجزیه کړو.
مګر په پروټو 3 کې د پیغام پروتوکول په کچه چمتو شوی بیان شتون لري. او دا هغه ځای دی کله چې هغه معلومات چې چمتو شوي بیان رامینځته کیږي په منظم شکل کې راځي. او موږ کولی شو د دې پوهیدو ملاتړ وکړو چې په ځینې سرور پیوستون کې پیرودونکي د چمتو شوي بیاناتو رامینځته کولو غوښتنه کړې. او حتی که معامله بنده وي، موږ لاهم اړتیا لرو چې سرور او پیرودونکي وصل وساتو.
مګر دلته په خبرو اترو کې توپیر شتون لري، ځکه چې یو څوک وايي چې تاسو اړتیا لرئ پوه شئ چې کوم چمتو شوي بیانونه پیرودونکي رامینځته کړي او د ټولو پیرودونکو ترمنځ د سرور اړیکه شریکه کړئ چې دا سرور اړیکه رامینځته کړې، د بیلګې په توګه، چا چې دا ډول چمتو شوی بیان رامینځته کړی.
اندریس فروینډ وویل که چیرې یو پیرودونکی تاسو ته راشي چې دمخه یې په بل سرور اتصال کې ورته چمتو شوی بیان رامینځته کړی وي ، نو د هغه لپاره یې جوړ کړئ. مګر داسې بریښي چې د پیرودونکي پرځای په ډیټابیس کې د پوښتنو پلي کول یو څه غلط دي ، مګر د پراختیا کونکي له نظره چې د ډیټابیس سره د تعامل لپاره پروتوکول لیکي ، نو دا به اسانه وي که هغه ته په ساده ډول د شبکې اتصال ورکړل شي. چې ورته چمتو شوې غوښتنه لري.
او یو بل ځانګړتیا چې موږ یې پلي کولو ته اړتیا لرو. موږ اوس د PgBouncer سره مطابقت لرونکی څارنه لرو. موږ کولی شو د پوښتنې اوسط وخت بیرته راګرځوو. مګر اوسط وخت په روغتون کې د تودوخې اوسط دی: یو څوک سړه دی، څوک ګرم دی - په اوسط ډول هرڅوک روغ دی. دا رښتیا نه ده.
موږ اړتیا لرو چې د فیصدو لپاره ملاتړ پلي کړو، کوم چې دا په ګوته کوي چې ورو غوښتنې شتون لري چې سرچینې مصرفوي او څارنه به د منلو وړ وي.
ترټولو مهمه خبره دا ده چې زه نسخه 1.0 غواړم (نسخه 1.1 لا دمخه خپور شوی). حقیقت دا دی چې اوس اوډیسي په 1.0rc نسخه کې دی، یعنی د کاندید خوشې کول. او ټول ریک چې ما لیست کړی په سمه توګه د ورته نسخې سره تنظیم شوی و ، پرته د حافظې لیک پرته.
1.0 نسخه به زموږ لپاره څه معنی ولري؟ موږ اوډیسي خپلو اډو ته رسوو. دا لا دمخه زموږ په ډیټابیسونو کې روان دی، مګر کله چې دا په هر ثانیه کې د 1 غوښتنو ته ورسیږي، نو موږ کولی شو ووایو چې دا د خوشې کولو نسخه ده او دا یوه نسخه ده چې د 000 په نوم یادیږي.
په ټولنه کې ډیری خلکو په 1.0 نسخه کې د ډیر وقفې او SCRAM غوښتنه کړې. مګر دا به پدې معنی وي چې موږ به اړتیا ولرو چې راتلونکی نسخه تولید ته واړوو ، ځکه چې نه SCRAM او نه هم وقفه تراوسه سره یوځای شوي ندي. مګر، ډیری احتمال، دا مسله به په چټکۍ سره حل شي.
زه ستاسو د غوښتنې په تمه یم. او زه غواړم دا هم واورم چې تاسو د باونسر سره کومې ستونزې لرئ. راځئ چې پرې بحث وکړو. شاید موږ کولی شو ځینې دندې پلي کړو چې تاسو ورته اړتیا لرئ.
دا زما برخه پای ته رسوي، زه غواړم له تاسو څخه واورم. له تاسو مننه!
پوښتنې
که زه خپل غوښتنلیک_نوم ورکړم، ایا دا به په سمه توګه وغورځول شي، په شمول په اوډیسي کې د لیږد پولینګ کې؟
اوډیسي یا باونسر؟
په اوډیسي کې. توپ وهونکی وغورځول شو.
موږ به یوه جوړه جوړه کړو.
او که زما ریښتیني اړیکه د نورو ارتباطاتو څخه تیریږي ، ایا دا به لیږدول کیږي؟
موږ به د ټولو پیرامیټونو یو سیټ جوړ کړو چې لیست شوي دي. زه نشم ویلای چې د غوښتنلیک_نوم په دې لیست کې دی که نه. داسې ښکاري چې هغه هلته لیدلی و. موږ به ټول ورته پیرامیټونه تنظیم کړو. د یوې غوښتنې سره، سیټ به هر هغه څه وکړي چې د پیل کولو پرمهال د پیرودونکي لخوا نصب شوي.
د راپور لپاره اندری مننه! ښه راپور! زه خوښ یم چې اوډیسي هره دقیقه ګړندی او ګړندی وده کوي. زه غواړم همداسې دوام ورکړم. موږ دمخه له تاسو څخه غوښتنه کړې چې د څو ډیټا سرچینې اتصال ولرئ ترڅو اوډیسي کولی شي په ورته وخت کې مختلف ډیټابیسونو سره وصل شي ، د بیلګې په توګه د غلام ماسټر ، او بیا د ناکامۍ وروسته په اوتومات ډول نوي ماسټر سره وصل شي.
هو، داسې ښکاري چې زه دا بحث په یاد لرم. اوس ډیری ذخیره شتون لري. مګر د دوی ترمنځ هیڅ بدلون نشته. زموږ په خوا کې، موږ باید د سرور څخه پوښتنه وکړو چې دا لاهم ژوندی دی او پوهیږو چې یو ناکامي پیښه شوې، څوک به pg_recovery ته زنګ ووهي. زه یو معیاري لاره لرم چې پوه شم چې موږ ماسټر ته نه یو راغلی. او موږ باید د تیروتنو څخه یو څه پوه شو که څنګه؟ دا، نظر په زړه پورې دی، دا بحث کیږي. نور نظرونه ولیکئ. که تاسو کاري لاسونه لرئ چې C پیژني، نو دا عموما په زړه پورې دی.
د نقلونو په اوږدو کې د اندازه کولو مسله هم زموږ لپاره د علاقې وړ ده ، ځکه چې موږ غواړو د غوښتنلیک پراختیا کونکو لپاره د امکان تر حده د نقل شوي کلسترونو منل ساده کړو. مګر دلته زه نور نظرونه غواړم، دا دا دی چې دا څنګه وکړو، دا څنګه ښه کړو.
پوښتنه د نقلونو په اړه هم ده. دا معلومه شوه چې تاسو یو ماسټر او څو نقلونه لرئ. او دا روښانه ده چې دوی د اړیکو لپاره ماسټر ته لږ ځله نقل ته ځي، ځکه چې دوی ممکن توپیر ولري. تاسو وویل چې په ډیټا کې توپیر ممکن داسې وي چې ستاسو سوداګرۍ به مطمین نه وي او تاسو به هلته نه ځئ تر هغه چې دا تکرار نشي. په ورته وخت کې ، که تاسو د اوږدې مودې لپاره هلته نه و تللي ، او بیا لاړشئ ، نو هغه معلومات چې تاسو ورته اړتیا لرئ سمدلاسه شتون نلري. دا دی، که موږ په دوامداره توګه ماسټر ته لاړ شو، نو بیا هلته کیچ ګرمیږي، او کیچ په نقل کې یو څه شاته دی.
هو دا رښتیا ده. په pcache کې به د ډیټا بلاکونه شتون ونلري چې تاسو یې غواړئ، په ریښتینې کیچ کې به د میزونو په اړه هیڅ معلومات شتون ونلري چې تاسو یې غواړئ، په پالنونو کې به هیڅ پارس شوي پوښتنې نه وي، هیڅ شی نه وي.
او کله چې تاسو یو ډول کلستر ولرئ، او تاسو هلته یو نوی نقل اضافه کړئ، نو کله چې دا پیل کیږي، هر څه په کې خراب دي، د بیلګې په توګه دا خپل زیرمه وده کوي.
ما نظر ترلاسه کړ. سمه لاره به دا وي چې لومړی په نقل کې د پوښتنو کوچنۍ سلنه پرمخ بوځي، کوم چې کیچ ګرموي. په لنډه توګه، موږ یو شرط لرو چې موږ باید د ماسټر شاته 10 ثانیو څخه زیات نه یو. او دا حالت باید په یوه څپې کې شامل نه وي، مګر د ځینو مراجعینو لپاره په اسانۍ سره.
هو، وزن زیات کړئ.
دا یو ښه نظر دی. مګر لومړی تاسو اړتیا لرئ دا بند پلي کړئ. لومړی موږ باید بند کړو، او بیا به موږ د دې په اړه فکر وکړو چې څنګه فعال کړو. دا یو ښه خصوصیت دی چې په اسانۍ سره فعال شي.
nginx دا اختیار لري slowly start د سرور لپاره په کلستر کې. او هغه په تدریجي ډول بار جوړوي.
هو، عالي نظر، موږ به دا هڅه وکړو کله چې موږ دې ته ورسیږو.
سرچینه: www.habr.com