O'z hisobotida Andrey Borodin sizga ulanish hovuzini loyihalashda PgBouncer-ni masshtablash tajribasini qanday hisobga olganliklarini aytib beradi. , ular uni ishlab chiqarishga chiqarganlarida. Bundan tashqari, biz tortuvchining qanday funktsiyalarini yangi versiyalarda ko'rishni xohlayotganimizni muhokama qilamiz: bu biz uchun nafaqat ehtiyojlarimizni qondirish, balki foydalanuvchilar hamjamiyatini rivojlantirish uchun muhimdir. .
Video:
Hammaga salom! Meni ismim Andrey.
Yandex-da men ochiq kodli ma'lumotlar bazalarini ishlab chiqaman. Va bugun bizda ulanish hovuzi ulanishlari haqida mavzu bor.
Agar siz rus tilida ulanish hovuzchisiga qanday qo'ng'iroq qilishni bilsangiz, menga ayting. Men, albatta, texnik adabiyotda o'rnatilishi kerak bo'lgan yaxshi texnik atama topmoqchiman.
Mavzu juda murakkab, chunki ko'pgina ma'lumotlar bazalarida ulanish pulchisi o'rnatilgan va siz bu haqda bilishingiz shart emas. Albatta, hamma joyda ba'zi sozlamalar mavjud, ammo Postgresda u shunday ishlamaydi. Va parallel ravishda (HighLoad++ 2019 da) Nikolay Samoxvalovning Postgres-da so'rovlarni o'rnatish haqida hisoboti mavjud. Va tushunganimdek, bu erga o'z so'rovlarini mukammal tarzda sozlagan odamlar kelishgan va bular tarmoq va resurslardan foydalanish bilan bog'liq kamroq tizim muammolariga duch kelgan odamlardir. Va ba'zi joylarda muammolar aniq emas, degan ma'noda juda qiyin bo'lishi mumkin.
Yandex-da Postgres mavjud. Yandex.Cloud-da ko'plab Yandex xizmatlari yashaydi. Va bizda Postgres-da soniyada kamida million so'rovni yaratadigan bir necha petabayt ma'lumotlar mavjud.
Va biz barcha xizmatlar uchun juda standart klasterni taqdim etamiz - bu tugunning asosiy asosiy tugunidir, odatiy ikkita replika (sinxron va asinxron), zaxira nusxasi, replikada o'qish so'rovlarini masshtablash.
Har bir klaster tuguni Postgres bo'lib, unga Postgres va monitoring tizimlaridan tashqari ulanish puli ham o'rnatilgan. Ulanish hovuzi fextavonie uchun va uning asosiy maqsadi uchun ishlatiladi.
Pouler ulanishining asosiy maqsadi nima?
Postgres ma'lumotlar bazasi bilan ishlashda jarayon modelini qabul qiladi. Bu bitta ulanish bitta jarayon, bitta Postgres backend ekanligini anglatadi. Va bu backendda juda ko'p turli xil keshlar mavjud bo'lib, ularni turli ulanishlar uchun har xil qilish juda qimmat.
Bundan tashqari, Postgres kodida procArray deb nomlangan massiv mavjud. U tarmoq ulanishlari haqida asosiy ma'lumotlarni o'z ichiga oladi. Va deyarli barcha procArray ishlov berish algoritmlari chiziqli murakkablikka ega; ular tarmoq ulanishlarining butun massivida ishlaydi. Bu juda tez sikl, lekin ko'proq kiruvchi tarmoq ulanishlari bilan narsalar biroz qimmatroq bo'ladi. Va narsalar biroz qimmatlashganda, siz ko'plab tarmoq ulanishlari uchun juda yuqori narxni to'lashingiz mumkin.
3 ta mumkin bo'lgan yondashuv mavjud:
- Ilova tomonida.
- Ma'lumotlar bazasi tomonida.
- Va o'rtasida, ya'ni barcha turdagi kombinatsiyalar.
Afsuski, o'rnatilgan hovuzchi hozirda ishlab chiqilmoqda. PostgreSQL Professional-dagi do'stlarimiz buni ko'pincha qilishadi. Qachon paydo bo'lishini oldindan aytish qiyin. Va aslida, bizda me'mor tanlash uchun ikkita echim bor. Bular dastur tomonidagi hovuz va proksi-pullardir.
Ilova tomonidagi hovuz eng oson yo'lidir. Va deyarli barcha mijoz drayverlari sizga shunday yo'lni taqdim etadi: millionlab ulanishlaringizni kodda ma'lumotlar bazasiga bir necha o'nlab ulanishlar sifatida taqdim eting.
Muammo shundaki, ma'lum bir nuqtada siz backendni kengaytirmoqchi bo'lsangiz, uni ko'plab virtual mashinalarga joylashtirmoqchisiz.
Keyin sizda yana bir nechta mavjudlik zonalari, bir nechta ma'lumotlar markazlari borligini tushunasiz. Mijozlarni birlashtirish yondashuvi esa katta raqamlarga olib keladi. Katta bo'lganlar 10 000 ga yaqin ulanishlardir. Bu normal ishlashi mumkin bo'lgan chekka.
Agar biz proksi-serverlar haqida gapiradigan bo'lsak, unda ko'p narsalarni qila oladigan ikkita hovuzchi bor. Ular nafaqat hovuzchilar. Ular hovuzchilar + yanada ajoyib funksionallik. Bu и .
Ammo, afsuski, hamma ham bu qo'shimcha funktsiyaga muhtoj emas. Va bu shuni anglatadiki, hovuzchilar faqat sessiyalarni birlashtirishni qo'llab-quvvatlaydi, ya'ni bitta kiruvchi mijoz, bitta chiquvchi mijoz ma'lumotlar bazasiga.
Bu bizning maqsadlarimiz uchun unchalik mos emas, shuning uchun biz tranzaktsiyalarni birlashtirishni amalga oshiradigan PgBouncer-dan foydalanamiz, ya'ni server ulanishlari faqat tranzaktsiya davomiyligi uchun mijoz ulanishlariga mos keladi.
Va bizning ish yukimizda bu haqiqatdir. Ammo bir nechta muammolar mavjud.
Muammolar seansga tashxis qo'ymoqchi bo'lganingizda boshlanadi, chunki sizning barcha kiruvchi ulanishlaringiz mahalliydir. Har bir inson loopback bilan keldi va qandaydir tarzda sessiyani kuzatish qiyin bo'ladi.
Albatta application_name_add_host dan foydalanishingiz mumkin. Bu application_name ga IP-manzilni qo'shishning Bouncer tomonidagi usul. Lekin application_name qo'shimcha ulanish orqali o'rnatiladi.
Ushbu grafikda sariq chiziq haqiqiy so'rovlar va ko'k chiziq ma'lumotlar bazasiga uchadigan so'rovlardir. Va bu farq aynan application_name-ning o'rnatilishi bo'lib, u faqat kuzatish uchun kerak bo'ladi, lekin u mutlaqo bepul emas.
Bundan tashqari, Bouncer-da siz bitta hovuzni, ya'ni ma'lum bir foydalanuvchi uchun ma'lumotlar bazasiga ulanishlar sonini cheklay olmaysiz.
Bu nimaga olib keladi? Sizda C++ da yozilgan yuklangan xizmat va yaqin joyda maʼlumotlar bazasi bilan hech qanday dahshatli ish qilmaydigan tugundagi kichik xizmat bor, lekin uning drayveri aqldan ozadi. U 20 000 ta ulanishni ochadi va qolgan hamma narsa kutadi. Hatto sizning kodingiz ham normal.
Biz, albatta, Bouncer uchun kichik yamoq yozdik, bu sozlamani qo'shdi, ya'ni mijozlarni hovuzga chekladi.
Buni Postgres tomonida qilish mumkin edi, ya'ni ma'lumotlar bazasidagi rollarni ulanishlar soni bilan cheklash.
Ammo keyin siz nima uchun serverga ulanishingiz yo'qligini tushunish qobiliyatini yo'qotasiz. PgBouncer ulanish xatosini yaratmaydi, u har doim bir xil ma'lumotni qaytaradi. Va siz tushunolmaysiz: ehtimol sizning parolingiz o'zgargan, ehtimol ma'lumotlar bazasi yo'qolgan, ehtimol biror narsa noto'g'ri. Ammo tashxis yo'q. Agar sessiya o'rnatilmasa, nima uchun uni o'rnatib bo'lmasligini bilmay qolasiz.
Muayyan nuqtada siz dastur grafiklariga qaraysiz va dastur ishlamayotganini ko'rasiz.
Yuqoriga qarang va Bouncer bitta ipli ekanligini ko'ring. Bu xizmat hayotidagi burilish nuqtasi. Siz bir yarim yil ichida ma'lumotlar bazasini kengaytirishga tayyorlanayotganingizni tushunasiz va siz hovuzni kengaytirishingiz kerak.
Biz ko'proq PgBouncers kerak degan xulosaga keldik.
Bouncer biroz yamalgan.
Va ular buni shunday qildilarki, TCP portidan qayta foydalanish orqali bir nechta Bouncerlar ko'tarilishi mumkin edi. Operatsion tizim esa avtomatik ravishda ular orasidagi kiruvchi TCP ulanishlarini round-robin yordamida uzatadi.
Bu mijozlar uchun shaffof, ya'ni sizda bitta Bouncer borga o'xshaydi, lekin sizda ishlaydigan Bouncers o'rtasida bo'sh ulanishlar mavjud.
Va ma'lum bir lahzada siz ushbu 3 ta Bouncerning har biri o'z yadrosini 100% ga yeyishini sezishingiz mumkin. Sizga bir nechta Bouncer kerak. Nega?
Chunki sizda TLS bor. Sizda shifrlangan ulanish mavjud. Agar siz Postgres-ni TLS bilan va TLSsiz taqqoslasangiz, shifrlash yoqilgan bo'lsa, o'rnatilgan ulanishlar soni deyarli ikki darajaga kamayishini bilib olasiz, chunki TLS qo'l siqish protsessor resurslarini sarflaydi.
Va yuqori qismida siz kiruvchi ulanishlar to'lqini mavjud bo'lganda bajariladigan bir nechta kriptografik funktsiyalarni ko'rishingiz mumkin. Bizning asosiy mavjudlik zonalari o'rtasida almashishi mumkinligi sababli, kiruvchi ulanishlar to'lqini juda odatiy holatdir. Ya'ni, negadir eski birlamchi mavjud emas edi, butun yuk boshqa ma'lumotlar markaziga yuborildi. Ularning barchasi bir vaqtning o'zida TLS bilan salomlashish uchun kelishadi.
Va ko'p miqdordagi TLS qo'l siqishlari endi Bouncer bilan salomlashmasligi mumkin, lekin uning tomog'ini siqib chiqaradi. Vaqt tugashi sababli, kiruvchi ulanishlar to'lqini o'chirilishi mumkin. Agar siz eksponensial orqaga qaytishsiz bazaga qayta urinsangiz, ular izchil to'lqinda qayta-qayta kelmaydi.
Mana 16 yadroni 16% yuklaydigan 100 ta PgBouncers misoli.
Biz PgBouncer kaskadiga keldik. Bu Bouncer bilan yuklaganimizda erishish mumkin bo'lgan eng yaxshi konfiguratsiya. Bizning tashqi Bouncerlarimiz TCP qo'l siqish uchun ishlatiladi va ichki Bouncers tashqi ulanishlarni juda ko'p qismlarga ajratmaslik uchun haqiqiy birlashtirish uchun ishlatiladi.
Ushbu konfiguratsiyada muammosiz qayta ishga tushirish mumkin. Siz ushbu 18 ta Bouncerni birma-bir qayta ishga tushirishingiz mumkin. Ammo bunday konfiguratsiyani saqlash juda qiyin. Sysadmins, DevOps va ushbu server uchun aslida mas'ul bo'lgan odamlar bu tartibdan unchalik mamnun bo'lmaydi.
Bizning barcha yaxshilanishlarimiz ochiq manbaga ko'tarilishi mumkindek tuyuladi, ammo Bouncer unchalik yaxshi qo'llab-quvvatlanmaydi. Misol uchun, bitta portda bir nechta PgBouncers-ni ishga tushirish qobiliyati bir oy oldin amalga oshirilgan. Bir necha yil oldin ushbu xususiyat bilan tortishish so'rovi mavjud edi.
Yoki yana bir misol. Postgres-da siz keraksiz autentifikatsiyasiz sirni boshqa ulanishga yuborish orqali amalga oshirilayotgan so'rovni bekor qilishingiz mumkin. Ammo ba'zi mijozlar oddiygina TCP resetini yuboradilar, ya'ni ular tarmoq ulanishini buzadilar. Bouncer nima qiladi? U hech narsa qilmaydi. U so'rovni bajarishda davom etadi. Agar siz kichik so'rovlar bilan ma'lumotlar bazasini yaratgan juda ko'p ulanishlarni olgan bo'lsangiz, shunchaki Bouncer-dan ulanishni uzishning o'zi etarli bo'lmaydi, shuningdek, ma'lumotlar bazasida ishlaydigan so'rovlarni bajarishingiz kerak.
Bu tuzatildi va bu muammo hali Bouncerning yuqori oqimiga birlashtirilmagan.
Shunday qilib, biz ishlab chiqiladigan, yamalgan, muammolar tezda tuzatilishi mumkin bo'lgan va, albatta, ko'p tarmoqli bo'lishi kerak bo'lgan o'z ulanish pulimiz kerak degan xulosaga keldik.
Biz asosiy vazifa sifatida multithreadingni qo'ydik. Biz kiruvchi TLS ulanishlari to'lqinini yaxshi boshqarishimiz kerak.
Buning uchun biz Machinarium deb nomlangan alohida kutubxonani ishlab chiqishimiz kerak edi, u tarmoq ulanishining mashina holatlarini ketma-ket kod sifatida tasvirlash uchun mo'ljallangan. Agar siz libpq manba kodiga qarasangiz, sizga natijani qaytarishi mumkin bo'lgan juda murakkab qo'ng'iroqlarni ko'rasiz va "Menga keyinroq qo'ng'iroq qiling. Hozirda menda IO bor, lekin IO yo'qolganda protsessorga yuk bo'ladi." Va bu ko'p darajali sxema. Tarmoq aloqasi odatda davlat mashinasi tomonidan tavsiflanadi. "Agar men ilgari N o'lchamdagi paket sarlavhasini olgan bo'lsam, endi N baytni kutyapman", "Agar men SYNC paketini yuborgan bo'lsam, endi natija metama'lumotlari bo'lgan paketni kutaman" kabi ko'plab qoidalar. Natijada, labirint chiziqli skanerlashga aylantirilgandek, juda qiyin, ziddiyatli koddir. Biz buni shunday qildikki, davlat mashinasi o'rniga dasturchi o'zaro ta'sirning asosiy yo'lini oddiy imperativ kod shaklida tasvirlaydi. Shunchaki, ushbu imperativ kodga siz tarmoqdan ma'lumotlarni kutish, ijro kontekstini boshqa koroutinga (yashil ip) o'tkazish orqali bajarish ketma-ketligi to'xtatilishi kerak bo'lgan joylarni kiritishingiz kerak. Ushbu yondashuv biz labirintda eng kutilgan yo'lni ketma-ket yozib, keyin unga novdalar qo'shishimizga o'xshaydi.
Natijada, bizda TCP-ni qabul qiladigan va TPC ulanishini ko'plab ishchilarga o'tkazadigan bitta ip bor.
Bunday holda, har bir mijoz ulanishi doimo bitta protsessorda ishlaydi. Va bu sizga uni keshga qulay qilish imkonini beradi.
Bundan tashqari, tizim TCP stekini bo'shatish uchun biz kichik paketlarni bitta katta paketga yig'ishni biroz yaxshiladik.
Bundan tashqari, biz tranzaksiyalarni birlashtirishni yaxshiladik, chunki Odyssey konfiguratsiya qilinganida tarmoqqa ulanishda xatolik yuz berganda CANCEL va ROLLBACK yuborishi mumkin, ya'ni hech kim so'rovni kutmasa, Odyssey ma'lumotlar bazasiga buni qilishga urinmaslikni aytadi. qimmatbaho resurslarni isrof qilishi mumkin bo'lgan so'rovni bajarish.
Va iloji bo'lsa, biz bir xil mijoz bilan aloqani saqlab turamiz. Bu application_name_add_host-ni qayta o'rnatishdan qochadi. Agar bu mumkin bo'lsa, diagnostika uchun zarur bo'lgan parametrlarni qo'shimcha ravishda tiklashimiz shart emas.
Biz Yandex.Cloud manfaati uchun ishlaymiz. Va agar siz boshqariladigan PostgreSQL-dan foydalansangiz va ulanish hovuzchisi o'rnatilgan bo'lsa, siz mantiqiy replikatsiyani tashqi ko'rinishda yaratishingiz mumkin, ya'ni, agar xohlasangiz, mantiqiy replikatsiya yordamida bizni qoldiring. Bouncer mantiqiy replikatsiya oqimini tashqariga chiqarmaydi.
Bu mantiqiy replikatsiyani o'rnatishga misol.
Bundan tashqari, biz tashqi tomondan jismoniy replikatsiyani qo'llab-quvvatlaymiz. Bulutda, albatta, bu mumkin emas, chunki u holda klaster sizga o'zi haqida juda ko'p ma'lumot beradi. Ammo o'rnatishlaringizda, agar sizga Odyssey-dagi ulanish hovuzchisi orqali jismoniy replikatsiya kerak bo'lsa, bu mumkin.
Odyssey PgBouncer bilan to'liq mos keladigan monitoringga ega. Bizda deyarli bir xil buyruqlarni bajaradigan bir xil konsol mavjud. Agar biror narsa etishmayotgan bo'lsa, GitHub-da tortishish so'rovini yoki hech bo'lmaganda muammoni yuboring va biz kerakli buyruqlarni bajaramiz. Ammo bizda PgBouncer konsolining asosiy funksiyalari allaqachon mavjud.
Va, albatta, bizda xatolarni yo'naltirish bor. Biz ma'lumotlar bazasi tomonidan xabar qilingan xatoni qaytaramiz. Siz nima uchun ma'lumotlar bazasiga kiritilmaganligingiz haqida ma'lumot olasiz va nafaqat siz unga kiritilmagansiz.
PgBouncer bilan 100% moslik kerak bo'lsa, bu xususiyat o'chirib qo'yiladi. Biz xavfsiz tomonda bo'lish uchun Bouncer kabi o'zimizni tutishimiz mumkin.
Rivojlanish
Odyssey manba kodi haqida bir necha so'z.
Masalan, "To'xtatib turish / Davom etish" buyruqlari mavjud. Ular odatda ma'lumotlar bazasini yangilash uchun ishlatiladi. Agar siz Postgres-ni yangilashingiz kerak bo'lsa, u holda uni ulanish hovuzida to'xtatib qo'yishingiz, pg_upgrade-ni bajarishingiz va keyin davom ettirishingiz mumkin. Va mijoz tomonidan ma'lumotlar bazasi shunchaki sekinlashayotganga o'xshaydi. Bu funksiya bizga jamiyatdagi odamlar tomonidan olib kelingan. U hali muzlagani yo'q, lekin tez orada hamma narsa bo'ladi. (Allaqachon muzlatilgan)
- allaqachon muzlatilgan
Bundan tashqari, PgBouncer-ning yangi xususiyatlaridan biri bu SCRAM autentifikatsiyasini qo'llab-quvvatlash bo'lib, uni bizga Yandex.Cloud-da ishlamaydigan shaxs ham keltirgan. Ikkalasi ham murakkab funksional va muhim.
Shuning uchun, agar siz ham hozir bir oz kod yozmoqchi bo'lsangiz, Odyssey nimadan iboratligini aytmoqchiman.
Sizda ikkita asosiy kutubxonaga asoslangan Odyssey manba bazasi mavjud. Kivi kutubxonasi Postgres xabar protokolining amalga oshirilishidir. Ya'ni, Postgres-ning mahalliy proto 3 - bu front-end va back-endlar almashishi mumkin bo'lgan standart xabarlar. Ular Kivi kutubxonasida amalga oshiriladi.
Machinarium kutubxonasi ipni amalga oshirish kutubxonasidir. Ushbu Machinariumning kichik bir qismi assembler tilida yozilgan. Lekin vahima qo'ymang, bor yo'g'i 15 qator bor.
Odyssey arxitekturasi. Korutinlar ishlaydigan asosiy mashina mavjud. Ushbu mashina kiruvchi TCP ulanishlarini qabul qilishni va ularni ishchilar o'rtasida taqsimlashni amalga oshiradi.
Bir nechta mijozlar uchun ishlov beruvchi bitta ishchi ichida ishlashi mumkin. Asosiy ip, shuningdek, konsolni boshqaradi va hovuzda endi kerak bo'lmagan ulanishlarni o'chirish uchun kron vazifalarini qayta ishlaydi.
Odyssey standart Postgres test to'plami yordamida sinovdan o'tkaziladi. Biz shunchaki Bouncer va Odyssey orqali o'rnatish-tekshirishni bajaramiz, biz null div olamiz. Bouncer va Odyssey-da bir xil o'tmaydigan sana formatlash bilan bog'liq bir nechta testlar mavjud.
Bundan tashqari, o'z sinovlariga ega bo'lgan ko'plab haydovchilar mavjud. Va biz Odysseyni sinab ko'rish uchun ularning testlaridan foydalanamiz.
Bundan tashqari, kaskad konfiguratsiyasimiz tufayli biz turli xil to'plamlarni sinab ko'rishimiz kerak: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, agar Odyssey kaskadning biron bir qismiga kirgan bo'lsa, u ham ishlayotganiga ishonch hosil qilish uchun biz kutganimizdek.
Rake
Biz ishlab chiqarishda Odyssey-dan foydalanamiz. Va agar hamma narsa ishlaydi, desam adolatdan bo'lmaydi. Yo'q, ya'ni, ha, lekin har doim emas. Misol uchun, ishlab chiqarishda hamma narsa shunchaki ishladi, keyin PostgreSQL Professional-dan do'stlarimiz kelib, bizda xotira oqishi borligini aytishdi. Ular haqiqatan ham shunday edi, biz ularni tuzatdik. Lekin bu oddiy edi.
Keyin biz ulanish hovuzchisi kiruvchi TLS ulanishlari va chiquvchi TLS ulanishlariga ega ekanligini aniqladik. Va ulanishlar mijoz sertifikatlari va server sertifikatlarini talab qiladi.
Bouncer va Odyssey server sertifikatlari pcache tomonidan qayta o'qiladi, ammo mijoz sertifikatlari pcache'dan qayta o'qilishi shart emas, chunki bizning kengaytiriladigan Odyssey oxir-oqibatda ushbu sertifikatni o'qish tizimining ishlashiga ta'sir qiladi. Bu biz uchun kutilmagan bo'ldi, chunki unga qarshilik ko'rsatish ko'p vaqt talab qilmadi. Avvaliga u chiziqli ravishda kengaydi, ammo 20 000 ta kiruvchi bir vaqtning o'zida ulanishdan keyin bu muammo o'zini ko'rsatdi.
Pluggable autentifikatsiya usuli - bu o'rnatilgan Lunux vositalari yordamida autentifikatsiya qilish qobiliyati. PgBouncer-da u shunday amalga oshiriladiki, PAM-dan javob kutish uchun alohida oqim mavjud va joriy ulanishga xizmat ko'rsatadigan va ulardan PAM oqimida yashashni so'rashi mumkin bo'lgan asosiy PgBouncer ipi mavjud.
Biz buni bitta oddiy sababga ko'ra amalga oshirmadik. Bizda juda ko'p iplar bor. Nega bizga bu kerak?
Bu oxir-oqibat muammolarni keltirib chiqarishi mumkin, chunki sizda PAM autentifikatsiyasi va PAM bo'lmagan autentifikatsiya mavjud bo'lsa, PAM autentifikatsiyasining katta to'lqini PAM bo'lmagan autentifikatsiyani sezilarli darajada kechiktirishi mumkin. Bu biz tuzatmagan narsalardan biridir. Ammo agar siz uni tuzatmoqchi bo'lsangiz, buni qilishingiz mumkin.
Yana bir rake shundaki, bizda barcha kiruvchi ulanishlarni qabul qiladigan bitta ip bor. Va keyin ular ishchilar hovuziga o'tkaziladi, u erda TLS qo'l siqish bo'lib o'tadi.
Xulosa qilib aytganda, agar sizda 20 000 ta tarmoq ulanishining izchil to'lqini bo'lsa, ularning barchasi qabul qilinadi. Va mijoz tomonida libpq vaqt tugashi haqida xabar berishni boshlaydi. Odatiy bo'lib, u 3 soniya kabi ko'rinadi.
Agar ularning barchasi bir vaqtning o'zida ma'lumotlar bazasiga kira olmasalar, ular ma'lumotlar bazasiga kira olmaydilar, chunki bularning barchasi eksponensial bo'lmagan qayta urinish bilan qoplanishi mumkin.
Biz PgBouncer-dan sxemani bu erda ko'chirib oldik, chunki biz qabul qiladigan TCP ulanishlar sonini qisqartirdik.
Agar biz ulanishlarni qabul qilayotganimizni ko'rsak, lekin ular oxir-oqibat qo'l siqish uchun vaqtlari yo'q, biz ularni CPU resurslarini isrof qilmasliklari uchun navbatga qo'yamiz. Bu kelgan barcha ulanishlar uchun bir vaqtning o'zida qo'l siqish amalga oshirilmasligiga olib keladi. Ammo hech bo'lmaganda kimdir ma'lumotlar bazasiga kiradi, hatto yuk juda og'ir bo'lsa ham.
nima bo'ladi?
Odisseyda kelajakda nimani ko'rishni xohlaysiz? Biz o'zimizni rivojlantirishga nima tayyormiz va jamiyatdan nimani kutamiz?
2019 yil avgust holatiga ko'ra.
Avgust oyida Odyssey yo'l xaritasi shunday ko'rinishga ega edi:
- Biz SCRAM va PAM autentifikatsiyasini xohladik.
- Biz oʻqish soʻrovlarini kutish rejimiga yoʻnaltirmoqchi edik.
- Men onlayn qayta ishga tushirishni xohlayman.
- Va serverda pauza qilish imkoniyati.
Ushbu yo'l xaritasining yarmi biz tomonimizdan emas, balki yakunlandi. Va u yaxshi. Shunday qilib, keling, nima qolganini muhokama qilamiz va yana qo'shamiz.
? Bizda so'rovlarni bajarmasdan havoni isitadigan nusxalar mavjud. Biz ularni o'zgartirish va almashtirishni ta'minlash uchun kerak. Agar ma'lumotlar markazlaridan birida muammolar yuzaga kelsa, men ularni foydali ish bilan band qilmoqchiman. Chunki biz bir xil markaziy protsessorlarni, bir xil xotirani boshqacha sozlay olmaymiz, chunki aks holda replikatsiya ishlamaydi.
Printsipial jihatdan Postgres-da 10 dan boshlab ulanishda session_attrs-ni belgilash mumkin. Ulanishdagi barcha ma'lumotlar bazasi xostlarini sanab o'tishingiz va nima uchun ma'lumotlar bazasiga borganingizni aytishingiz mumkin: yozish yoki faqat o'qish. Va haydovchining o'zi ro'yxatdagi birinchi xostni tanlaydi, bu esa session_attrs talablariga javob beradi.
Ammo bu yondashuv bilan bog'liq muammo shundaki, u replikatsiya kechikishini nazorat qilmaydi. Sizning xizmatingiz uchun qabul qilib bo'lmaydigan vaqt uchun orqada qolgan ba'zi nusxalar bo'lishi mumkin. Replikada o'qish so'rovlarini to'liq funksiyali bajarish uchun biz Odyssey-ni o'qib bo'lmaganda ishlamaslik qobiliyatini qo'llab-quvvatlashimiz kerak.
Odyssey vaqti-vaqti bilan ma'lumotlar bazasiga borib, birlamchidan replikatsiya masofasini so'rashi kerak. Va agar u chegara qiymatiga yetgan bo'lsa, ma'lumotlar bazasiga yangi so'rovlarga ruxsat bermang, mijozga ulanishlarni qayta boshlashi kerakligini ayting va, ehtimol, so'rovlarni bajarish uchun boshqa xostni tanlang. Bu ma'lumotlar bazasiga replikatsiya kechikishini tezda tiklashga va so'rov bilan javob berish uchun yana qaytishga imkon beradi.
Amalga oshirish uchun muddat berish qiyin, chunki u ochiq manba. Ammo, umid qilamanki, PgBouncer'dagi hamkasblarim kabi 2,5 yil emas. Bu men Odisseyda ko'rishni xohlagan xususiyatdir.
. Endi siz ikkita usulda tayyorlangan bayonotni yaratishingiz mumkin. Birinchidan, siz SQL buyrug'ini bajarishingiz mumkin, ya'ni "tayyorlangan". Ushbu SQL buyrug'ini tushunish uchun biz Bouncer tomonida SQLni tushunishni o'rganishimiz kerak. Bu ortiqcha bo'ladi, chunki bu ortiqcha, chunki bizga butun tahlilchi kerak. Biz har bir SQL buyrug'ini tahlil qila olmaymiz.
Ammo proto3 da xabar protokoli darajasida tayyorlangan bayonot mavjud. Va bu erda tayyorlangan bayonot yaratilayotganligi haqidagi ma'lumotlar tuzilgan shaklda keladi. Va biz ba'zi server ulanishlarida mijoz tayyorlangan bayonotlarni yaratishni so'rashini tushunishimiz mumkin. Agar tranzaktsiya yopilgan bo'lsa ham, biz server va mijoz o'rtasidagi aloqani saqlab turishimiz kerak.
Ammo bu erda dialogda nomuvofiqlik paydo bo'ladi, chunki kimdir mijoz qanday tayyorlangan bayonotlarni yaratganini tushunishingiz va ushbu server ulanishini yaratgan barcha mijozlar o'rtasida server ulanishini bo'lishishingiz kerakligini aytadi, ya'ni bunday tayyorlangan bayonotni kim yaratgan.
Andres Freundning aytishicha, agar sizga boshqa server ulanishida bunday tayyorlangan bayonotni yaratgan mijoz kelsa, u uchun uni yarating. Ammo mijoz o'rniga ma'lumotlar bazasida so'rovlarni bajarish biroz noto'g'ri ko'rinadi, ammo ma'lumotlar bazasi bilan o'zaro ishlash protokolini yozuvchi ishlab chiquvchi nuqtai nazaridan, agar unga oddiygina tarmoq ulanishi berilsa, qulay bo'lar edi. shunday tayyorlangan so'rov mavjud.
Va biz amalga oshirishimiz kerak bo'lgan yana bir xususiyat. Endi bizda PgBouncer bilan mos monitoring mavjud. Biz so'rovning o'rtacha bajarilish vaqtini qaytarishimiz mumkin. Ammo o'rtacha vaqt - shifoxonadagi o'rtacha harorat: ba'zilari sovuq, ba'zilari issiq - o'rtacha, har bir kishi sog'lom. Bu yolg'on.
Resurslarni behuda sarflaydigan va monitoringni maqbulroq qiladigan sekin so'rovlar mavjudligini ko'rsatadigan foizlarni qo'llab-quvvatlashimiz kerak.
Eng muhimi, men 1.0 versiyasini xohlayman (1.1-versiya allaqachon chiqarilgan). Gap shundaki, Odyssey hozirda 1.0rc versiyasida, ya'ni nashrga nomzod. Va men sanab o'tgan barcha muammolar, xotiraning oqishi bundan mustasno, aynan bir xil versiyada tuzatildi.
1.0 versiyasi biz uchun nimani anglatadi? Biz Odisseyni bazalarimizga tarqatmoqdamiz. U allaqachon bizning ma'lumotlar bazalarimizda ishlamoqda, lekin u soniyada 1 so'rovlar nuqtasiga yetganda, bu reliz versiyasi va bu 000 deb nomlanishi mumkin bo'lgan versiya deb aytishimiz mumkin.
Jamiyatdagi bir nechta odamlar 1.0 versiyasi pauza va SCRAMni o'z ichiga olishini so'rashdi. Ammo bu biz keyingi versiyani ishlab chiqarishga chiqarishimiz kerakligini anglatadi, chunki na SCRAM, na pauza hali o'ldirilmagan. Ammo, ehtimol, bu muammo juda tez hal qilinadi.
Men sizning taklifingizni kutaman. Bouncer bilan qanday muammolaringiz borligini ham eshitmoqchiman. Keling, ularni muhokama qilaylik. Ehtimol, biz sizga kerak bo'lgan ba'zi funktsiyalarni amalga oshirishimiz mumkin.
Bu mening qismim tugadi, men sizni tinglamoqchiman. Rahmat!
Sizning savollaringiz
Agar men o'zimning application_nameimni o'rnatsam, u to'g'ri yo'naltiriladimi, shu jumladan Odyssey-da tranzaksiyalarni birlashtirishda?
Odyssey yoki Bouncer?
Odisseyda. Bouncerda u tashlanadi.
Biz to'plam qilamiz.
Va agar mening haqiqiy aloqam boshqa ulanishlarga o'tsa, u uzatiladimi?
Biz ro'yxatda keltirilgan barcha parametrlar to'plamini qilamiz. Bu ro'yxatda application_name bor yoki yo'qligini ayta olmayman. Men uni o'sha erda ko'rgan deb o'ylayman. Biz bir xil parametrlarni o'rnatamiz. Bitta so'rov bilan to'plam ishga tushirish paytida mijoz tomonidan o'rnatilgan hamma narsani bajaradi.
Rahmat, Andrey, hisobot uchun! Yaxshi hisobot! Odyssey har daqiqada tezroq va tez rivojlanayotganidan xursandman. Men shunday davom etmoqchiman. Odyssey bir vaqtning o'zida turli xil ma'lumotlar bazalariga, ya'ni asosiy qulga ulanishi va so'ng uzilishdan keyin avtomatik ravishda yangi masterga ulanishi uchun biz sizdan ko'p ma'lumot manbalariga ulanishni so'ragan edik.
Ha, men bu munozarani eslayman. Endi bir nechta omborlar mavjud. Ammo ular o'rtasida hech qanday almashish yo'q. Bizning tomonimizdan, biz serverdan uning hali ham tirikligini so'rashimiz va pg_recovery-ga qo'ng'iroq qiladigan uzilish sodir bo'lganligini tushunishimiz kerak. Biz ustaga kelmaganimizni tushunishning standart usuli bor. Va xatolardan qandaydir tarzda tushunishimiz kerakmi yoki nima? Ya'ni, g'oya qiziq, muhokama qilinmoqda. Ko'proq sharhlar yozing. Agar sizda C tilini biladigan ishchilaringiz bo'lsa, bu juda yaxshi.
Replikalar bo'yicha masshtablash masalasi ham bizni qiziqtiradi, chunki biz replikatsiya qilingan klasterlarni qabul qilishni dastur ishlab chiquvchilari uchun imkon qadar sodda qilishni xohlaymiz. Lekin bu erda men ko'proq sharhlar istardim, ya'ni buni aniq qanday qilish kerak, qanday qilib yaxshi qilish kerak.
Savol replikalar haqida ham. Ma'lum bo'lishicha, sizda usta va bir nechta nusxalar bor. Va ular ulanishlar uchun ustaga qaraganda replikaga kamroq borishlari aniq, chunki ularda farqlar bo'lishi mumkin. Siz ma'lumotlardagi farq shunday bo'lishi mumkinki, u sizning biznesingizni qoniqtirmaydi va u takrorlanmaguncha u erga bormaysiz deb aytdingiz. Shu bilan birga, agar siz u erga uzoq vaqt bormagan bo'lsangiz va keyin borishni boshlagan bo'lsangiz, kerakli ma'lumotlar darhol mavjud bo'lmaydi. Ya'ni, agar biz doimo ustaga borsak, u erda kesh isitiladi, lekin replikatsiyada kesh biroz orqada qoladi.
Ha, bu haqiqat. Pcache siz xohlagan ma'lumotlar bloklariga ega bo'lmaydi, haqiqiy keshda siz xohlagan jadvallar haqida ma'lumot bo'lmaydi, rejalarda tahlil qilingan so'rovlar bo'lmaydi, umuman hech narsa bo'lmaydi.
Va sizda qandaydir klaster mavjud bo'lsa va u erda yangi nusxa qo'shsangiz, u ishga tushganda, unda hamma narsa yomon, ya'ni keshini oshiradi.
Men fikr oldim. To'g'ri yondashuv birinchi navbatda replikada so'rovlarning kichik foizini ishga tushirish bo'ladi, bu esa keshni isitadi. Taxminan aytganda, bizda ustadan 10 soniyadan ko'p bo'lmagan orqada qolish sharti bor. Va bu holat bitta to'lqinga kiritilmagan, ammo ba'zi mijozlar uchun muammosiz.
Ha, vaznni oshiring.
Bu yaxshi fikr. Lekin birinchi navbatda biz ushbu o'chirishni amalga oshirishimiz kerak. Avval biz o'chirishimiz kerak, keyin esa qanday yoqish haqida o'ylaymiz. Bu muammosiz yoqish uchun ajoyib xususiyatdir.
Nginx-da bunday imkoniyat mavjud slowly start server uchun klasterda. Va u asta-sekin yukni oshiradi.
Ha, ajoyib g'oya, biz buni amalga oshirganimizda sinab ko'ramiz.
Manba: www.habr.com