Андрей Бородин илтгэлдээ холболтын нэгтгэгчийг зохион бүтээхдээ PgBouncer-ийн масштабыг нэмэгдүүлэх туршлагыг хэрхэн харгалзан үзсэн тухай танд хэлэх болно. , тэд үүнийг үйлдвэрлэлд нэвтрүүлэх үед. Нэмж дурдахад бид чирэгчийн ямар функцийг шинэ хувилбараар харахыг хүсч байгаагаа ярилцах болно: энэ нь зөвхөн бидний хэрэгцээг хангах төдийгүй хэрэглэгчийн нийгэмлэгийг хөгжүүлэхэд чухал ач холбогдолтой юм. .
Видео:
Сайн уу! Намайг Эндрю гэдэг.
Yandex-д би нээлттэй эхийн мэдээллийн санг хөгжүүлдэг. Мөн өнөөдөр бид холболтын цуглуулагч холболтын тухай сэдэвтэй байна.
Хэрэв та холболтын пүүзерийг орос хэлээр яаж дуудхаа мэддэг бол надад хэлээрэй. Техникийн ном зохиолд бий болох ёстой сайн техникийн нэр томъёог олохыг би үнэхээр хүсч байна.
Энэ сэдэв нь нэлээд төвөгтэй, учир нь олон мэдээллийн санд холболтын нэгтгэгч суурилуулсан бөгөөд та энэ талаар мэдэх шаардлагагүй болно. Мэдээжийн хэрэг, хаа сайгүй зарим тохиргоо байдаг, гэхдээ Postgres дээр энэ нь тийм биш юм. Үүний зэрэгцээ (HighLoad++ 2019 дээр) Postgres дээр асуулга тохируулах тухай Николай Самохваловын илтгэл бий. Миний ойлгож байгаагаар асуултуудаа аль хэдийн төгс тохируулсан хүмүүс энд ирсэн бөгөөд эдгээр нь сүлжээ, нөөцийн ашиглалттай холбоотой илүү ховор системийн асуудалтай тулгардаг хүмүүс юм. Мөн зарим газар асуудал нь тодорхойгүй байна гэдэг утгаараа нэлээд хэцүү байж болох юм.
Yandex-д Postgres байдаг. Yandex.Cloud дээр олон Yandex үйлчилгээнүүд амьдардаг. Бид Postgres-д секундэд дор хаяж сая хүсэлт гаргадаг хэд хэдэн петабайт өгөгдөлтэй.
Мөн бид бүх үйлчилгээнд нэлээд стандарт кластер өгдөг - энэ бол зангилааны үндсэн үндсэн зангилаа, ердийн хоёр хуулбар (синхрон ба асинхрон), хуулбар, хуулбар дээрх унших хүсэлтийг масштаблах явдал юм.
Кластерын зангилаа бүр нь Postgres бөгөөд үүнд Postgres болон хяналтын системээс гадна холболтын нэгтгэгч суурилуулсан болно. Холболтын нэгдлүүдийг хашаа барихад ашигладаг бөгөөд үндсэн зориулалтаар нь ашигладаг.
Холболт цуглуулагчийн гол зорилго юу вэ?
Postgres мэдээллийн сантай ажиллахдаа процессын загварыг ашигладаг. Энэ нь нэг холболт нь нэг процесс, нэг Postgres backend гэсэн үг юм. Мөн энэ арын хэсэгт маш олон төрлийн кэш байдаг бөгөөд өөр өөр холболтыг өөр өөр болгоход нэлээд үнэтэй байдаг.
Нэмж дурдахад Postgres код нь procArray нэртэй массивтай байдаг. Энэ нь сүлжээний холболтын талаархи үндсэн мэдээллийг агуулдаг. Бараг бүх procArray боловсруулах алгоритмууд нь шугаман нарийн төвөгтэй байдаг бөгөөд тэдгээр нь сүлжээний холболтын бүх массивыг хамардаг. Энэ нь маш хурдан мөчлөг боловч илүү олон ирж буй сүлжээний холболтууд нь бага зэрэг илүү үнэтэй болдог. Мөн бүх зүйл арай илүү үнэтэй болох үед та маш олон сүлжээний холболтыг маш өндөр үнээр төлж болно.
3 боломжит арга байдаг:
- Хэрэглээний тал дээр.
- Өгөгдлийн сангийн тал дээр.
- Мөн хооронд, өөрөөр хэлбэл бүх төрлийн хослолууд.
Харамсалтай нь, угсарсан бассейн одоо боловсруулагдаж байна. PostgreSQL Professional дахь манай найзууд үүнийг ихэвчлэн хийдэг. Хэзээ гарч ирэхийг таамаглахад хэцүү байдаг. Үнэн хэрэгтээ, архитектор сонгох хоёр шийдэл бидэнд бий. Эдгээр нь програмын талын сан болон прокси сан юм.
Хэрэглээний хажуугийн усан сан бол хамгийн хялбар арга юм. Бараг бүх клиент драйверууд танд нэг арга замыг санал болгодог: өөрийн сая сая холболтыг өгөгдлийн санд хэдэн арван холболт болгон кодоор харуулах.
Асуудал нь тодорхой үед та арын хэсгийг томруулж, олон виртуал машинд байрлуулахыг хүсч байгаа явдал юм.
Дараа нь та хэд хэдэн боломжит бүс, хэд хэдэн дата төвтэй гэдгээ ойлгосон. Үйлчлүүлэгчийг нэгтгэх арга нь илүү олон тоо гарахад хүргэдэг. Том нь 10 орчим холболт юм. Энэ бол хэвийн ажиллах боломжтой ирмэг юм.
Хэрэв бид прокси нэгдлүүдийн талаар ярих юм бол маш олон зүйлийг хийж чадах хоёр плёндер байдаг. Тэд зөвхөн бассейн тоглогчид биш. Тэдгээр нь нэгдлүүд + илүү гайхалтай функцууд юм. Энэ и .
Гэвч харамсалтай нь хүн бүр энэ нэмэлт функцийг шаарддаггүй. Мөн энэ нь нэгтгэгчид зөвхөн сеанс нэгтгэхийг дэмждэг, өөрөөр хэлбэл нэг ирж буй үйлчлүүлэгч, нэг гарч буй үйлчлүүлэгч нь мэдээллийн санд хүргэдэг.
Энэ нь бидний зорилгод тийм ч тохиромжтой биш тул бид гүйлгээний нэгтгэлийг хэрэгжүүлдэг PgBouncer-ийг ашигладаг, өөрөөр хэлбэл серверийн холболтыг зөвхөн гүйлгээний хугацаанд үйлчлүүлэгчийн холболттой тааруулдаг.
Мөн бидний ажлын ачаалалд энэ нь үнэн юм. Гэхдээ хэд хэдэн асуудал байна.
Таны ирж буй бүх холболтууд нь орон нутгийнх учраас сессийг оношлохыг хүсэх үед асуудал эхэлдэг. Бүгд л давталттай ирсэн бөгөөд ямар нэгэн байдлаар сессийг хянахад хэцүү болно.
Мэдээж хэрэг та application_name_add_host ашиглаж болно. Энэ бол Bouncer тал дээр application_name-д IP хаяг нэмэх арга юм. Гэхдээ application_name нэмэлт холболтоор тохируулагдсан.
Энэ график дээр шар шугам нь бодит хүсэлт, цэнхэр шугам нь мэдээллийн сан руу ниссэн хүсэлтүүд байна. Мөн энэ ялгаа нь зөвхөн мөрдөхөд шаардлагатай application_name-ийн суулгац юм, гэхдээ энэ нь огт үнэ төлбөргүй биш юм.
Нэмж дурдахад, Bouncer-д та нэг сан, тухайлбал тодорхой хэрэглэгч, тодорхой мэдээллийн санд өгөгдлийн сангийн холболтын тоог хязгаарлаж болохгүй.
Энэ нь юунд хүргэдэг вэ? Танд C++ хэл дээр бичигдсэн ачаалагдсан үйлчилгээ байгаа бөгөөд ойролцоо хаа нэгтээ өгөгдлийн санд ямар ч муу зүйл хийдэггүй зангилааны жижиг үйлчилгээ байгаа ч драйвер нь галзуурдаг. Энэ нь 20 холболтыг нээж, бусад бүх зүйл хүлээх болно. Таны код хүртэл хэвийн байна.
Бид мэдээж Bouncer-д зориулж жижиг засвар бичсэн бөгөөд энэ тохиргоог нэмсэн, өөрөөр хэлбэл үйлчлүүлэгчдийг усан санд хязгаарласан.
Үүнийг Postgres тал дээр хийх боломжтой, өөрөөр хэлбэл өгөгдлийн сан дахь үүргүүдийг холболтын тоогоор хязгаарлах боломжтой.
Гэхдээ дараа нь та яагаад сервертэй холбогдоогүй байгаагаа ойлгох чадвараа алддаг. PgBouncer нь холболтын алдаа гаргадаггүй, үргэлж ижил мэдээллийг буцаадаг. Та ойлгохгүй байна: магадгүй таны нууц үг өөрчлөгдсөн, магадгүй мэдээллийн сан алдагдсан, ямар нэг зүйл буруу байж магадгүй юм. Гэхдээ онош байхгүй. Хэрэв хуралдааныг байгуулж чадахгүй бол яагаад үүнийг байгуулж чадахгүй байгааг та мэдэхгүй.
Тодорхой цэг дээр та програмын графикуудыг хараад програм ажиллахгүй байгааг харна.
Дээд талаас нь хараад Bouncer нь нэг урсгалтай болохыг хараарай. Энэ бол үйлчилгээний амьдралын эргэлтийн цэг юм. Та нэг жил хагасын дараа мэдээллийн санг өргөжүүлэхээр бэлтгэж байгаагаа ойлгож байгаа бөгөөд та сан хөмрөгчийг өргөжүүлэх хэрэгтэй.
Бидэнд илүү олон PgBouncer хэрэгтэй гэсэн дүгнэлтэд хүрсэн.
Bouncer-г бага зэрэг засварласан.
Мөн тэд TCP портыг дахин ашиглах замаар хэд хэдэн Bouncer-ийг өсгөх боломжтой болгосон. Үйлдлийн систем нь ирж буй TCP холболтыг автоматаар round-robin ашиглан хооронд нь шилжүүлдэг.
Энэ нь үйлчлүүлэгчдэд ил тод байдаг бөгөөд энэ нь танд нэг Bouncer байгаа юм шиг харагдаж байгаа хэдий ч танд ажиллаж байгаа Bouncers-ийн хооронд сул холболтууд хуваагдсан байна.
Тодорхой мөчид та эдгээр 3 Bouncer тус бүр өөрийн үндсэн цөмийг 100% идэж байгааг анзаарч магадгүй юм. Танд нэлээд хэдэн Bouncer хэрэгтэй. Яагаад?
Учир нь танд TLS байгаа. Та шифрлэгдсэн холболттой байна. Хэрэв та Postgres-ийг TLS-тэй болон TLS-гүй харьцуулж үзвэл, TLS-ийн гар барих нь CPU-ийн нөөцийг зарцуулдаг тул шифрлэлт идэвхжсэн үед тогтсон холболтын тоо бараг хоёр дарааллаар буурч байгааг олж мэдэх болно.
Дээд талд та орж ирж буй холболтын давалгаа гарах үед гүйцэтгэгддэг хэд хэдэн криптограф функцуудыг харж болно. Манай анхдагч нь боломжийн бүсийн хооронд шилжих боломжтой тул ирж буй холболтын давалгаа нь нэлээд ердийн нөхцөл байдал юм. Өөрөөр хэлбэл, ямар нэг шалтгаанаар хуучин анхдагч боломжгүй байсан тул ачааллыг бүхэлд нь өөр мэдээллийн төв рүү илгээсэн. Тэд бүгд нэгэн зэрэг TLS-тэй мэндлэх гэж ирнэ.
Мөн олон тооны TLS гар барих нь Bouncer-тэй мэндлэхээ больж, хоолойг нь шахах болно. Хугацаа хэтэрсэн тул ирж буй холболтын долгион унтрахгүй болно. Хэрэв та экспоненциал ухралтгүйгээр суурь руу дахин оролдвол тэд уялдаатай долгионоор дахин дахин ирэхгүй.
16 цөмийг 16% ачаалдаг 100 PgBouncer-ийн жишээ энд байна.
Бид каскад PgBouncer дээр ирлээ. Энэ бол Bouncer-ийн тусламжтайгаар бидний ачаалалд хүрч болох хамгийн сайн тохиргоо юм. Манай гадаад Bouncer-уудыг TCP гар барихад ашигладаг бол дотоод Bouncer-уудыг жинхэнэ нэгтгэхэд ашигладаг бөгөөд ингэснээр гадаад холболтыг хэт их хуваахгүй.
Энэ тохиргоонд гөлгөр дахин эхлүүлэх боломжтой. Та эдгээр бүх 18 Bouncer-ийг нэг нэгээр нь дахин эхлүүлж болно. Гэхдээ ийм тохиргоог хадгалах нь нэлээд хэцүү байдаг. Системийн админууд, DevOps болон энэ серверийг хариуцдаг хүмүүс энэ зохицуулалтад тийм ч таатай биш байх болно.
Бидний бүх сайжруулалтыг нээлттэй эх сурвалж болгон сурталчилж болох юм шиг санагдаж байгаа ч Bouncer тийм ч сайн дэмжигдээгүй байна. Жишээлбэл, нэг порт дээр хэд хэдэн PgBouncers ажиллуулах чадварыг сарын өмнө хийсэн. Хэдэн жилийн өмнө энэ функцтэй татах хүсэлт байсан.
Эсвэл өөр нэг жишээ. Postgres дээр та нууцыг шаардлагагүй баталгаажуулалтгүйгээр өөр холболт руу илгээж байгаа хүсэлтийг цуцалж болно. Гэхдээ зарим үйлчлүүлэгчид зүгээр л TCP тохиргоог илгээдэг, өөрөөр хэлбэл сүлжээний холболтыг тасалдаг. Bouncer юу хийх вэ? Тэр юу ч хийхгүй. Энэ нь хүсэлтийг үргэлжлүүлэн биелүүлэх болно. Хэрэв та жижиг хүсэлт бүхий мэдээллийн сан үүсгэсэн асар олон тооны холболтыг хүлээн авсан бол Bouncer-ээс холболтыг салгах нь хангалтгүй бөгөөд та мэдээллийн санд ажиллаж байгаа хүсэлтийг бөглөх хэрэгтэй.
Үүнийг засварласан бөгөөд энэ асуудлыг Bouncer-ийн дээд хэсэгт хараахан нэгтгээгүй байна.
Тиймээс бид өөрсдийн холболтын нэгтгэгч хэрэгтэй гэсэн дүгнэлтэд хүрсэн бөгөөд үүнийг боловсруулж, нөхөж, асуудлыг хурдан засч залруулах боломжтой, мэдээжийн хэрэг олон урсгалтай байх ёстой.
Бид multithreading-ийг гол ажил болгон тавьсан. Бид ирж буй TLS холболтын давалгааг сайн зохицуулах чадвартай байх хэрэгтэй.
Үүний тулд бид сүлжээний холболтын машины төлөвийг дараалсан код болгон дүрслэх зорилготой Machinarium нэртэй тусдаа номын сан боловсруулах шаардлагатай болсон. Хэрэв та libpq-ийн эх кодыг харвал үр дүнгээ өгч болохуйц нэлээд төвөгтэй дуудлага гарч ирэх бөгөөд "Дараа залгана уу. Яг одоо надад IO байгаа, гэхдээ IO алга болох үед би процессорыг ачаалах болно." Мөн энэ бол олон түвшний схем юм. Сүлжээний холбоог ихэвчлэн төлөвийн машинаар тодорхойлдог. "Хэрэв би өмнө нь N хэмжээтэй пакетийн толгой хэсгийг хүлээн авсан бол одоо N байт хүлээж байна", "Хэрэв би SYNC пакет илгээсэн бол одоо би үр дүнгийн мета өгөгдөл бүхий пакетыг хүлээж байна" гэх мэт олон дүрэм байдаг. Үр дүн нь төөрдөг байшинг шугаман сканнер болгон хувиргасан мэт нэлээд хэцүү, үл ойлгогдох код юм. Бид үүнийг төрийн машины оронд программист харилцан үйлчлэлийн үндсэн замыг энгийн императив код хэлбэрээр дүрслэхээр хийсэн. Энэ зайлшгүй кодонд та сүлжээнээс өгөгдөл хүлээж, гүйцэтгэх контекстийг өөр корутин (ногоон утас) руу дамжуулах замаар гүйцэтгэлийн дарааллыг тасалдуулах шаардлагатай газруудыг оруулах хэрэгтэй. Энэ арга нь бид төөрдөг байшинд хамгийн их хүлээгдэж буй замыг дараалан бичиж, дараа нь мөчрүүдийг нэмдэгтэй төстэй юм.
Үүний үр дүнд бид TCP-г хүлээн зөвшөөрч, TPC холболтыг олон ажилчдад дамжуулдаг нэг урсгалтай болсон.
Энэ тохиолдолд үйлчлүүлэгчийн холболт бүр үргэлж нэг процессор дээр ажилладаг. Мөн энэ нь кэшэд ээлтэй болгох боломжийг танд олгоно.
Нэмж дурдахад бид системийн TCP стекийг хөнгөвчлөхийн тулд жижиг пакетуудыг нэг том пакет болгон цуглуулах ажлыг бага зэрэг сайжруулсан.
Нэмж дурдахад бид Odyssey-г тохируулснаар сүлжээний холболт эвдэрсэн тохиолдолд CANCEL болон ROLLBACK илгээх боломжтой, өөрөөр хэлбэл хэн ч хүсэлт хүлээхгүй бол Odyssey мэдээллийн санд оролдохгүй байхыг хэлэх болно гэсэн утгаараа бид гүйлгээний нэгтгэлийг сайжруулсан. үнэт нөөцийг дэмий үрэх хүсэлтийг биелүүлэх.
Боломжтой бол бид нэг үйлчлүүлэгчтэй холбоо тогтоодог. Энэ нь application_name_add_host-г дахин суулгах шаардлагагүй болно. Хэрэв энэ боломжтой бол бид оношлогоонд шаардлагатай параметрүүдийг дахин тохируулах шаардлагагүй болно.
Бид Yandex.Cloud-ийн ашиг сонирхолд нийцүүлэн ажилладаг. Хэрэв та удирддаг PostgreSQL ашигладаг бөгөөд холболтын нэгтгэгч суулгасан бол логик хуулбарыг гадагшаа гаргах боломжтой, өөрөөр хэлбэл, хэрэв хүсвэл логик хуулбарыг ашиглан биднийг орхиж болно. Bouncer нь логик хуулбарлах урсгалыг гадагш гаргахгүй.
Энэ бол логик хуулбарыг тохируулах жишээ юм.
Нэмж дурдахад бид гаднах биет хуулбарыг дэмждэг. Үүлэн дээр энэ нь мэдээжийн хэрэг боломжгүй, учир нь кластер танд өөрийнхөө тухай хэт их мэдээлэл өгөх болно. Гэхдээ таны суулгацуудад Odyssey дахь холболтын нэгтгэгчээр дамжуулан физик хуулбарлах шаардлагатай бол энэ нь боломжтой юм.
Odyssey нь PgBouncer-тэй бүрэн нийцтэй хяналттай. Бид бараг бүх ижил командуудыг ажиллуулдаг ижил консолтой. Хэрэв ямар нэг зүйл дутуу байвал татах хүсэлт, эсвэл ядаж GitHub дээр асуудал гаргавал бид шаардлагатай командуудыг гүйцэтгэнэ. Гэхдээ бид PgBouncer консолын үндсэн функцтэй болсон.
Мэдээжийн хэрэг, бид алдаа дамжуулалттай байдаг. Бид мэдээллийн сангаас мэдээлсэн алдааг буцаах болно. Та яагаад мэдээллийн санд хамрагдаагүй тухай мэдээлэл авах болно, зөвхөн таныг энэ санд оруулаагүй болно.
Хэрэв танд PgBouncer-тэй 100% нийцтэй байх шаардлагатай бол энэ функц идэвхгүй болно. Бид аюулгүй талдаа байхын тулд Bouncer-тэй адилхан биеэ авч явж чадна.
Хөгжил
Odyssey эх кодын талаар хэдэн үг хэлье.
Жишээлбэл, "Түр зогсоох / Үргэлжлүүлэх" командууд байдаг. Тэдгээрийг ихэвчлэн мэдээллийн санг шинэчлэхэд ашигладаг. Хэрэв та Postgres-ийг шинэчлэх шаардлагатай бол холболтын нэгтгэгч дээр түр зогсоож, pg_upgrade хийж, үргэлжлүүлж болно. Үйлчлүүлэгчийн талаас өгөгдлийн сан зүгээр л удааширч байгаа мэт харагдах болно. Энэ функцийг олон нийтийн хүмүүс бидэнд авчирсан. Тэр хараахан хөлдөөгүй байгаа ч удахгүй бүх зүйл болно. (Аль хэдийн хөлдсөн)
- аль хэдийн хөлдсөн
Нэмж дурдахад PgBouncer-ийн шинэ боломжуудын нэг бол SCRAM Authentication-ийн дэмжлэг бөгөөд үүнийг Yandex.Cloud дээр ажилладаггүй хүн бидэнд авчирсан. Аль аль нь нарийн төвөгтэй ажиллагаатай бөгөөд чухал ач холбогдолтой.
Тиймээс одоо та ч бас жаахан код бичмээр байвал Одиссей юунаас бүтдэгийг хэлмээр байна.
Та хоёр үндсэн номын санд тулгуурласан Odyssey эх сурвалжийн баазтай. Киви номын сан нь Postgres мессежийн протоколын хэрэгжилт юм. Өөрөөр хэлбэл, Postgres-ийн эх прото 3 нь урд болон арын төгсгөлүүд солилцож болох стандарт мессежүүд юм. Тэд Киви номын санд хэрэгждэг.
Machinarium номын сан нь урсгалыг хэрэгжүүлэх номын сан юм. Энэхүү машинриумын жижиг хэсэг нь ассемблер хэлээр бичигдсэн байдаг. Гэхдээ бүү сандар, ердөө 15 мөр байна.
Одиссей архитектур. Корутин ажиллаж байгаа үндсэн машин байдаг. Энэ машин нь ирж буй TCP холболтыг хүлээн авч, ажилчдын дунд түгээдэг.
Хэд хэдэн үйлчлүүлэгчдэд зориулсан зохицуулагч нэг ажилчин дотор ажиллах боломжтой. Үндсэн утас нь консолыг ажиллуулж, санд хэрэггүй болсон холболтуудыг устгах крон даалгавруудыг боловсруулдаг.
Odyssey-ийг стандарт Postgres тестийн багц ашиглан туршиж үздэг. Бид зүгээр л Bouncer болон Odyssey-ээр дамжуулан install-check-ийг ажиллуулснаар бид null div авдаг. Огнооны форматтай холбоотой хэд хэдэн тестүүд Bouncer болон Odyssey-д яг адилхан давдаггүй.
Үүнээс гадна өөрийн гэсэн шалгалттай олон жолооч байдаг. Мөн бид Одиссейг шалгахын тулд тэдний тестийг ашигладаг.
Нэмж дурдахад, бидний каскадын тохиргооноос шалтгаалан бид янз бүрийн багцуудыг туршиж үзэх хэрэгтэй: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey нь каскадын аль нэг хэсэгт орсон бол энэ нь бас ажилладаг хэвээр байгаа гэдэгт итгэлтэй байх болно. бидний хүлээж байгаачлан.
Тармуур
Бид Odyssey-г үйлдвэрлэлд ашигладаг. Хэрэв би бүх зүйл зүгээр л ажилладаг гэж хэлбэл шударга бус байх болно. Үгүй ээ, тийм ээ, гэхдээ үргэлж биш. Жишээлбэл, үйлдвэрлэлд бүх зүйл зүгээр л ажиллаж байсан, дараа нь PostgreSQL Professional-аас манай найзууд ирээд санах ой алдагдаж байна гэж хэлсэн. Тэд үнэхээр байсан, бид тэдгээрийг зассан. Гэхдээ энэ нь энгийн байсан.
Дараа нь бид холболтын нэгтгэгч нь ирж буй TLS холболтууд болон гарч буй TLS холболтуудтай болохыг олж мэдсэн. Мөн холболтууд нь үйлчлүүлэгчийн гэрчилгээ болон серверийн гэрчилгээ шаарддаг.
Bouncer болон Odyssey серверийн гэрчилгээг pcache-ээр нь дахин уншдаг боловч үйлчлүүлэгчийн гэрчилгээг pcache-ээс дахин унших шаардлагагүй, учир нь бидний өргөтгөх боломжтой Odyssey нь эцсийн дүндээ энэ гэрчилгээг унших системийн гүйцэтгэлд ордог. Энэ нь бидний хувьд гэнэтийн зүйл болсон, учир нь түүнийг эсэргүүцэхэд удаан хугацаа зарцуулаагүй. Эхэндээ энэ нь шугаман масштабтай байсан боловч 20 нэгэн зэрэг орж ирсэн холболтын дараа энэ асуудал гарч ирэв.
Pluggable Authentication Method нь суулгасан Lunux хэрэгслийг ашиглан баталгаажуулах чадвар юм. PgBouncer-д энэ нь PAM-аас хариу хүлээх тусдаа хэлхээтэй байх ба одоогийн холболтод үйлчилдэг үндсэн PgBouncer урсгалтай байхаар хэрэгжсэн бөгөөд тэднээс PAM хэлхээнд амьдрахыг хүсэх боломжтой.
Энгийн нэг шалтгаанаар бид үүнийг хэрэгжүүлээгүй. Бидэнд маш олон утас бий. Энэ яагаад бидэнд хэрэгтэй байна вэ?
Энэ нь эцэстээ асуудал үүсгэж болзошгүй тул хэрэв танд PAM баталгаажуулалт болон PAM бус нэвтрэлт танилт байгаа бол PAM баталгаажуулалтын том давалгаа нь PAM бус нэвтрэлт танилтыг ихээхэн удаашруулж болзошгүй. Энэ бол бидний засаагүй зүйлсийн нэг юм. Гэхдээ хэрэв та үүнийг засахыг хүсч байвал үүнийг хийж чадна.
Өөр нэг тармуур нь бидэнд ирж буй бүх холболтыг хүлээн зөвшөөрдөг нэг утастай байсан. Дараа нь тэдгээрийг TLS-ийн гар барих ёслол болох ажилчдын цөөрөмд шилжүүлнэ.
Эцэст нь хэлэхэд, хэрэв та 20 сүлжээний холболттой уялдаа холбоотой долгионтой бол тэдгээрийг бүгдийг нь хүлээн авах болно. Үйлчлүүлэгч тал дээр libpq нь завсарлагааны талаар мэдээлж эхэлнэ. Анхдагчаар энэ нь 000 секунд байх шиг байна.
Хэрэв тэд бүгд өгөгдлийн санд нэгэн зэрэг нэвтэрч чадахгүй бол мэдээллийн санд нэвтэрч чадахгүй, учир нь энэ бүгдийг экспоненциал бус дахин оролдлого хийх боломжтой.
Бид PgBouncer-ийн схемийг эндээс хуулж авсан, бидний хүлээн зөвшөөрч буй TCP холболтын тоог багасгасан гэсэн дүгнэлтэд хүрсэн.
Хэрэв бид холболтыг хүлээн авч байгаа боловч эцсийн дүндээ гар барих цаг байхгүй бол бид CPU-ийн нөөцийг үрэхгүйн тулд дараалалд оруулдаг. Энэ нь ирсэн бүх холболтын хувьд нэгэн зэрэг гар барих боломжгүй болоход хүргэдэг. Гэхдээ ачаалал нэлээд хүнд байсан ч ядаж хэн нэгэн мэдээллийн сан руу орох болно.
заалтуудын
Та Одиссейд ирээдүйд юу үзэхийг хүсч байна вэ? Бид өөрсдийгөө хөгжүүлэхэд юу бэлэн байна, олон нийтээс юу хүлээж байна вэ?
2019 оны наймдугаар сарын байдлаар.
XNUMX-р сард Одиссей замын зураг иймэрхүү харагдаж байв.
- Бид SCRAM болон PAM баталгаажуулалтыг хүссэн.
- Бид унших хүсэлтийг зогсолт руу шилжүүлэхийг хүссэн.
- Би онлайнаар дахин эхлүүлэхийг хүсч байна.
- Мөн сервер дээр түр зогсоох чадвар.
Энэ замын зураглалын тал хувь нь хийгдсэн болохоос манайх биш. Мөн энэ сайн байна. Тиймээс юу үлдэх талаар ярилцаж, нэмж оруулцгаая.
? Бидэнд хүсэлтийг биелүүлэхгүйгээр агаарыг халаах хуулбарууд бий. Ачаалал болон шилжүүлэлтийг хангахын тулд бидэнд хэрэгтэй. Дата төвүүдийн аль нэгэнд асуудал гарсан тохиолдолд би тэдэнд хэрэгтэй ажил хийхийг хүсч байна. Учир нь бид ижил төв процессор, ижил санах ойг өөрөөр тохируулах боломжгүй, эс тэгвээс хуулбарлах нь ажиллахгүй.
Зарчмын хувьд Postgres-д 10-аас эхлэн холболт хийхдээ session_attrs-г зааж өгөх боломжтой. Та холболтод байгаа бүх өгөгдлийн сангийн хостуудыг жагсааж, яагаад мэдээллийн сан руу орох гэж байгаагаа хэлж болно: бичих эсвэл зөвхөн унших. Жолооч өөрөө хамгийн их таалагдсан жагсаалтын эхний хостыг сонгох бөгөөд энэ нь session_attrs-ийн шаардлагыг хангасан байна.
Гэхдээ энэ аргын асуудал нь хуулбарлах хоцролтыг хянадаггүй явдал юм. Таны үйлчилгээнд хүлээн зөвшөөрөгдөөгүй хугацаагаар хоцрогдсон хуулбар байж магадгүй. Хуулбар дээр унших асуулгыг бүрэн гүйцэд гүйцэтгэхийг идэвхжүүлэхийн тулд бид үндсэндээ Odyssey-г унших боломжгүй үед ажиллахгүй байх чадварыг дэмжих хэрэгтэй.
Odyssey нь мэдээллийн сан руу үе үе очиж, анхдагчаас хуулбарлах зайг асуух ёстой. Хэрэв энэ нь хязгаарт хүрсэн бол өгөгдлийн санд шинэ хүсэлт оруулахыг бүү зөвшөөр, үйлчлүүлэгчид холболтыг дахин эхлүүлэх шаардлагатайг хэлж, хүсэлтийг гүйцэтгэх өөр хост сонгох боломжтой. Энэ нь мэдээллийн санд хуулбарлах хоцролтыг хурдан сэргээж, хүсэлтэд хариу өгөхийн тулд дахин буцаж ирэх боломжийг олгоно.
Энэ нь нээлттэй эх сурвалж учраас хэрэгжүүлэх хугацааг зааж өгөхөд хэцүү байдаг. Гэхдээ PgBouncer-ийн хамт олон шиг 2,5 жил биш гэж найдаж байна. Энэ бол миний Одиссей киноноос харахыг хүсч буй онцлог юм.
. Одоо та бэлтгэсэн мэдэгдлийг хоёр аргаар үүсгэж болно. Эхлээд та SQL командыг ажиллуулж болно, тухайлбал "бэлтгэсэн". Энэхүү SQL командыг ойлгохын тулд бид Bouncer талын SQL-г ойлгож сурах хэрэгтэй. Бидэнд бүхэлд нь задлан шинжлэгч хэрэгтэй байгаа тул энэ нь хэтрүүлсэн байх болно. Бид SQL команд бүрийг задлан шинжилж чадахгүй.
Гэхдээ proto3 дээр мессежийн протоколын түвшинд бэлтгэсэн мэдэгдэл байдаг. Энэ бол бэлтгэсэн мэдэгдлийг үүсгэж байгаа мэдээлэл нь бүтэцлэгдсэн хэлбэрээр ирдэг газар юм. Зарим серверийн холболт дээр үйлчлүүлэгч бэлтгэсэн мэдэгдлийг үүсгэхийг хүссэн гэсэн ойлголтыг бид дэмжиж чадна. Гүйлгээ хаалттай байсан ч бид сервер болон үйлчлүүлэгчийн хоорондын холболтыг хадгалах шаардлагатай хэвээр байна.
Гэхдээ энд харилцан ярианы зөрүү гарч байна, учир нь хэн нэгэн үйлчлүүлэгч ямар төрлийн бэлтгэсэн мэдэгдлүүд үүсгэснийг ойлгох хэрэгтэй бөгөөд энэ серверийн холболтыг үүсгэсэн бүх үйлчлүүлэгчид, өөрөөр хэлбэл ийм бэлтгэсэн мэдэгдлийг үүсгэсэн серверийн холболтыг хуваалцах хэрэгтэй гэж хэлсэн.
Андрес Фрейнд хэлэхдээ, хэрэв өөр сервер холболт дээр ийм бэлтгэсэн мэдэгдлийг үүсгэсэн үйлчлүүлэгч танд ирвэл түүнд зориулж үүсгэ. Гэхдээ хүсэлтийг үйлчлүүлэгчийн оронд мэдээллийн санд гүйцэтгэх нь бага зэрэг буруу юм шиг санагддаг, гэхдээ мэдээллийн сантай харилцах протоколыг бичдэг хөгжүүлэгчийн үүднээс түүнд зүгээр л сүлжээний холболт өгвөл тохиромжтой байх болно. ийм бэлдсэн хүсэлт байна.
Мөн бидний хэрэгжүүлэх шаардлагатай бас нэг онцлог шинж чанар. Бид одоо PgBouncer-тэй нийцтэй хяналттай болсон. Бид асуулгын гүйцэтгэлийн дундаж хугацааг буцаах боломжтой. Гэхдээ дундаж хугацаа нь эмнэлгийн дундаж температур юм: зарим нь хүйтэн, зарим нь дулаан байдаг - дунджаар хүн бүр эрүүл байдаг. Энэ үнэн биш.
Бид нөөцийг дэмий үрж буй асуулга удаашралтай байгааг харуулж, хяналтыг илүү хүлээн зөвшөөрөхүйц болгох хувь хэмжээг дэмжих шаардлагатай байна.
Хамгийн гол нь би 1.0 хувилбарыг хүсч байна (1.1 хувилбар аль хэдийн гарсан). Үнэн хэрэгтээ Odyssey одоо 1.0rc хувилбартай, өөрөөр хэлбэл нэр дэвшигчийг гаргасан байна. Санах ой алдагдахаас бусад тохиолдолд миний жагсаасан бүх асуудлыг яг ижил хувилбараар зассан.
1.0 хувилбар нь бидний хувьд юу гэсэн үг вэ? Бид Odyssey-г бааздаа хүргэж байна. Энэ нь манай мэдээллийн сан дээр аль хэдийн ажиллаж байгаа боловч секундэд 1 хүсэлт гаргах цэгт хүрэх үед энэ нь хувилбарын хувилбар бөгөөд үүнийг 000 гэж нэрлэж болох хувилбар гэж хэлж болно.
Нийгэмд байгаа хэд хэдэн хүмүүс 1.0 хувилбарт түр зогсоох болон SCRAM-г оруулахыг хүссэн. Гэхдээ энэ нь бид дараагийн хувилбарыг үйлдвэрлэлд нэвтрүүлэх шаардлагатай болно гэсэн үг юм, учир нь SCRAM болон түр зогсолтын аль нь ч устгагдаагүй байна. Гэхдээ энэ асуудал нэлээд хурдан шийдэгдэх байх.
Би таны татах хүсэлтийг хүлээж байна. Би бас таныг Bouncer-тэй холбоотой ямар асуудалтай байгааг сонсмоор байна. Тэднийг ярилцъя. Магадгүй бид танд хэрэгтэй зарим функцийг хэрэгжүүлж болох юм.
Энэ бол миний хэсэг дуусч байна, би чамайг сонсмоор байна. Баярлалаа!
Асуултууд
Хэрэв би өөрийн application_name-г тохируулсан бол үүнийг Odyssey дахь гүйлгээний нэгдлүүдийг оруулаад зөв дамжуулах уу?
Odyssey эсвэл Bouncer?
Одиссейд. Bouncer-д энэ нь шиддэг.
Бид багц хийнэ.
Хэрэв миний жинхэнэ холболт бусад холболтууд дээр үсрэх юм бол энэ нь дамжих уу?
Бид жагсаалтад орсон бүх параметрийн багцыг хийх болно. Энэ жагсаалтад application_name байгаа эсэхийг би хэлж чадахгүй байна. Би түүнийг тэнд харсан гэж бодож байна. Бид бүгд ижил параметрүүдийг тохируулах болно. Нэг хүсэлтээр уг багц нь эхлүүлэх явцад үйлчлүүлэгчийн суулгасан бүх зүйлийг хийх болно.
Мэдээлэл өгсөн Андрей, баярлалаа! Сайн тайлан! Одиссей минут тутамд илүү хурдацтай хөгжиж байгаад баяртай байна. Би ингээд үргэлжлүүлмээр байна. Odyssey-ийг өөр өөр мэдээллийн сантай, тухайлбал мастер боолтой зэрэг холбож, дараа нь бүтэлгүйтсэний дараа автоматаар шинэ мастерт холбогдохын тулд бид танаас олон мэдээллийн эх сурвалжтай холболт хийхийг аль хэдийн хүссэн.
Тийм ээ, би энэ хэлэлцүүлгийг санаж байх шиг байна. Одоо хэд хэдэн агуулах бий. Гэхдээ тэдний хооронд ямар ч өөрчлөлт байхгүй. Манай талаас бид серверийг амьд байгаа эсэхийг нь асууж, pg_recovery руу залгах алдаа гарсан гэдгийг ойлгох ёстой. Бид мастер дээр ирээгүй гэдгийг ойлгох стандарт арга надад бий. Бид алдаанаасаа ямар нэгэн байдлаар ойлгох ёстой юу эсвэл юу? Энэ нь санаа нь сонирхолтой, яригдаж байгаа гэсэн үг. Илүү олон сэтгэгдэл бичээрэй. Хэрэв танд С-г мэддэг ажилчид байгаа бол энэ нь маш сайн хэрэг.
Хуулбарласан кластеруудыг ашиглахыг програм хөгжүүлэгчдэд аль болох хялбар болгохыг хүсч байгаа тул хуулбарыг өргөжүүлэх асуудал бидний сонирхлыг татдаг. Гэхдээ энд би илүү их сэтгэгдлийг хүсч байна, өөрөөр хэлбэл яг яаж хийх, яаж сайн хийх вэ.
Асуулт нь хуулбаруудын тухай юм. Танд мастер, хэд хэдэн хуулбар байгаа нь харагдаж байна. Тэдгээр нь хоорондоо ялгаатай байж болох тул тэд мастер руу холболт хийхээс илүү хуулбар руу бага очдог нь тодорхой байна. Мэдээллийн зөрүү нь таны бизнест нийцэхгүй байж магадгүй бөгөөд үүнийг хуулбарлах хүртэл тийшээ явахгүй гэж та хэлсэн. Үүний зэрэгцээ, хэрэв та тэнд удаан хугацаагаар очоогүй, дараа нь явж эхэлсэн бол шаардлагатай мэдээлэл тэр даруй гарахгүй. Өөрөөр хэлбэл, хэрэв бид мастер руу байнга очдог бол тэнд байгаа кэш дулаарч, хуулбар дээр кэш бага зэрэг хоцордог.
Тийм ээ энэ нь үнэн. Pcache нь таны хүссэн өгөгдлийн блокгүй, жинхэнэ кэш нь таны хүссэн хүснэгтүүдийн талаарх мэдээлэлгүй, төлөвлөгөөнд задлан шинжлэгдсэн асуулга байхгүй, юу ч байхгүй болно.
Хэрэв танд ямар нэгэн кластер байгаа бол та тэнд шинэ хуулбар нэмбэл, түүнийг эхлүүлэх үед бүх зүйл муу байна, өөрөөр хэлбэл кэшээ нэмэгдүүлнэ.
Би санаа авсан. Зөв арга бол эхлээд хуулбар дээр асуулгын багахан хувийг ажиллуулах бөгөөд энэ нь кэшийг халаах болно. Бүдүүлэгээр хэлэхэд бид мастераас 10 секундээс илүүгүй хоцрох ёстой гэсэн нөхцөлтэй. Мөн энэ нөхцөл байдал нэг долгионд ороогүй боловч зарим үйлчлүүлэгчдэд жигд байдаг.
Тийм ээ, жингээ нэмэгдүүлээрэй.
Энэ бол сайн санаа юм. Гэхдээ эхлээд энэ хаалтыг хэрэгжүүлэх хэрэгтэй. Эхлээд бид унтраах хэрэгтэй, дараа нь хэрхэн асаах талаар бодох болно. Энэ нь саадгүй идэвхжүүлэх гайхалтай боломж юм.
Nginx-д ийм сонголт бий slowly start серверт зориулсан кластерт. Тэгээд тэр ачааллыг аажмаар нэмэгдүүлдэг.
Тийм ээ, гайхалтай санаа, бид үүнийг ойртсон үедээ туршиж үзэх болно.
Эх сурвалж: www.habr.com