Ing laporan kasebut, Andrey Borodin bakal menehi pitutur marang kowe carane nggatekake pengalaman skala PgBouncer nalika ngrancang pooler sambungan. , nalika padha mbalek metu menyang produksi. Kajaba iku, kita bakal ngrembug apa fungsi penarik sing pengin dideleng ing versi anyar: penting kanggo kita ora mung nyukupi kabutuhan, nanging uga ngembangake komunitas pangguna. .
Video:
Halo kabeh! Jenengku Andrew.
Ing Yandex, aku ngembangake database open source. Lan dina iki kita duwe topik babagan sambungan pooler sambungan.
Yen sampeyan ngerti carane nelpon pooler sambungan ing basa Rusia, banjur ngomong. Aku pancene pengin nemokake istilah teknis sing apik sing kudu ditetepake ing literatur teknis.
Topik iki cukup rumit, amarga ing akeh database pooler sambungan dibangun lan sampeyan ora perlu ngerti babagan iki. Mesthi, ana sawetara setelan ing endi wae, nanging ing Postgres ora bisa kaya ngono. Lan sejajar (ing HighLoad ++ 2019) ana laporan dening Nikolai Samokhvalov babagan nyetel pitakon ing Postgres. Lan aku ngerti, wong teka ing kene sing wis ngatur pitakon kanthi sampurna, lan iki minangka wong sing ngadhepi masalah sistem sing luwih langka sing ana gandhengane karo panggunaan jaringan lan sumber daya. Lan ing sawetara panggonan bisa uga angel banget amarga masalah kasebut ora jelas.
Yandex duwe Postgres. Akeh layanan Yandex manggon ing Yandex.Cloud. Lan kita duwe sawetara petabyte data sing ngasilake paling ora yuta panjalukan saben detik ing Postgres.
Lan kita nyedhiyakake kluster sing cukup standar kanggo kabeh layanan - iki minangka simpul utami utama simpul, rong replika biasa (sinkron lan asinkron), serep, skala panjalukan maca ing replika.
Saben simpul kluster yaiku Postgres, sing, saliyane Postgres lan sistem pemantauan, pooler sambungan uga dipasang. Pooler sambungan digunakake kanggo pager lan kanggo tujuan utama.
Apa tujuan utama pooler sambungan?
Postgres nganggo model proses nalika nggarap database. Iki tegese siji sambungan iku siji proses, siji Postgres backend. Lan ing backend iki ana akeh caches beda, kang cukup larang kanggo nggawe beda kanggo sambungan beda.
Kajaba iku, kode Postgres duwe array sing diarani procArray. Isine data dhasar babagan sambungan jaringan. Lan meh kabeh algoritma pangolahan procArray duwe kerumitan linier; padha mbukak kabeh sambungan jaringan. Iki minangka siklus sing cepet banget, nanging kanthi sambungan jaringan sing luwih akeh, regane dadi luwih larang. Lan nalika dadi luwih larang, sampeyan bisa mbayar rega sing dhuwur banget kanggo akeh sambungan jaringan.
Ana 3 pendekatan sing bisa ditindakake:
- Ing sisih aplikasi.
- Ing sisih database.
- Lan ing antarane, yaiku, kabeh jinis kombinasi.
Sayange, pooler sing dibangun saiki lagi dikembangake. Kanca-kanca ing PostgreSQL Professional biasane nindakake iki. Nalika bakal katon angel diprediksi. Lan nyatane, kita duwe rong solusi sing bisa dipilih dening arsitek. Iki minangka kolam renang sisih aplikasi lan kolam proxy.
Kolam sisih aplikasi minangka cara paling gampang. Lan meh kabeh driver klien nyedhiyakake sampeyan kanthi cara: saiki mayuta-yuta sambungan sampeyan ing kode minangka sawetara rolas sambungan menyang database.
Masalah sing muncul yaiku ing titik tartamtu sampeyan pengin skala backend, sampeyan pengin nyebarake menyang akeh mesin virtual.
Banjur sampeyan ngerti yen sampeyan duwe sawetara zona kasedhiyan, sawetara pusat data. Lan pendekatan pooling sisih klien ndadékaké kanggo nomer luwih. Sing gedhe kira-kira 10 sambungan. Iki minangka pinggiran sing bisa digunakake kanthi normal.
Yen kita ngomong babagan poolers proxy, banjur ana loro poolers sing bisa nindakake akeh perkara. Padha ora mung poolers. Padha poolers + fungsi liyane kelangan. Iki и .
Nanging, sayangé, ora saben wong mbutuhake fungsi tambahan iki. Lan ndadékaké kasunyatan sing poolers mung ndhukung sesi pooling, IE siji klien mlebu, siji klien metu menyang database.
Iki ora cocog banget kanggo tujuan kita, mula kita nggunakake PgBouncer, sing ngetrapake pooling transaksi, yaiku sambungan server cocog karo sambungan klien mung sajrone transaksi.
Lan ing beban kerja kita, iki bener. Nanging ana sawetara masalah.
Masalah diwiwiti nalika sampeyan pengin diagnosa sesi, amarga kabeh sambungan mlebu sampeyan lokal. Saben uwong teka karo loopback lan piye wae dadi angel kanggo nglacak sesi.
Mesthi sampeyan bisa nggunakake application_name_add_host. Iki minangka cara ing sisih Bouncer kanggo nambah alamat IP menyang application_name. Nanging application_name disetel dening sambungan tambahan.
Ing grafik iki, ing ngendi garis kuning minangka panjaluk nyata, lan ing ngendi garis biru minangka panjaluk sing mabur menyang database. Lan prabédan iki sabenere instalasi saka application_name, kang mung perlu kanggo nelusuri, nanging ora free ing kabeh.
Kajaba iku, ing Bouncer sampeyan ora bisa matesi siji blumbang, IE nomer sambungan database saben pangguna tartamtu, saben database tartamtu.
Iki ndadékaké kanggo apa? Sampeyan duwe layanan dimuat ditulis ing C ++ lan nang endi wae toko layanan cilik ing simpul sing ora nindakake apa-apa elek karo database, nanging driver dadi edan. Mbukak 20 sambungan lan kabeh liyane bakal ngenteni. Malah kode sampeyan normal.
Kita, mesthi, nulis tembelan cilik kanggo Bouncer sing nambahake setelan iki, yaiku mbatesi klien menyang blumbang.
Sampeyan bisa nindakake iki ing sisih Postgres, yaiku, mbatesi peran ing database kanthi jumlah sambungan.
Nanging sampeyan bakal kelangan kemampuan kanggo ngerti kenapa sampeyan ora duwe sambungan menyang server. PgBouncer ora uncalan kesalahan sambungan, tansah ngasilake informasi sing padha. Lan sampeyan ora bisa ngerti: bisa uga sandhi sampeyan wis diganti, bisa uga database ilang, bisa uga ana sing salah. Nanging ora ana diagnosis. Yen sesi ora bisa ditetepake, sampeyan ora bakal ngerti kenapa ora bisa ditetepake.
Ing titik tartamtu, sampeyan ndeleng grafik aplikasi lan ndeleng manawa aplikasi kasebut ora bisa digunakake.
Deleng ing ndhuwur lan deleng manawa Bouncer nganggo benang siji. Iki minangka titik balik ing urip layanan. Sampeyan ngerti yen sampeyan lagi nyiapake ukuran database sajrone setaun setengah, lan sampeyan kudu nggawe skala pooler.
We wis teka menyang kesimpulan sing kita kudu luwih PgBouncers.
Bouncer wis ditambal dicokot.
Lan dheweke nggawe supaya sawetara Bouncer bisa diunggahake kanthi nggunakake port TCP maneh. Lan sistem operasi kanthi otomatis nransfer sambungan TCP sing mlebu ing antarane nggunakake round-robin.
Iki transparan kanggo klien, tegese sampeyan duwe Bouncer, nanging sampeyan duwe fragmentasi sambungan sing ora aktif ing antarane Bouncer sing mlaku.
Lan ing wektu tartamtu sampeyan bisa uga sok dong mirsani sing 3 Bouncer iki saben mangan nganti 100% inti. Sampeyan butuh sawetara Bouncer. Kenging punapa?
Amarga sampeyan duwe TLS. Sampeyan duwe sambungan ndhelik. Lan yen sampeyan benchmark Postgres karo lan tanpa TLS, sampeyan bakal nemokake sing nomer sambungan diadegaké irungnya dening meh rong urutan gedhene karo enkripsi aktif, amarga TLS jabat tangan nganggo sumber daya CPU.
Lan ing sisih ndhuwur sampeyan bisa ndeleng sawetara fungsi kriptografi sing ditindakake nalika ana gelombang sambungan sing mlebu. Wiwit utami kita bisa ngalih ing antarane zona kasedhiyan, gelombang sambungan mlebu minangka kahanan sing cukup khas. Yaiku, sakperangan alesan utami lawas ora kasedhiya, kabeh beban dikirim menyang pusat data liyane. Kabeh bakal teka kanggo ngucapake salam marang TLS bebarengan.
Lan akeh salaman TLS bisa uga ora ngucapake salam marang Bouncer, nanging bakal nyeret tenggorokan. Amarga wektu entek, gelombang sambungan sing mlebu bisa uga ora bisa diredam. Yen sampeyan nyoba maneh menyang pangkalan tanpa mundur eksponensial, dheweke ora bakal teka maneh lan maneh ing gelombang sing koheren.
Iki minangka conto 16 PgBouncers sing ngemot 16 intine kanthi 100%.
Kita teka ing cascade PgBouncer. Iki minangka konfigurasi paling apik sing bisa digayuh ing beban kita karo Bouncer. Bouncer eksternal kita digunakake kanggo jabat tangan TCP, lan Bouncer internal digunakake kanggo pooling nyata, supaya ora fragment sambungan eksternal banget.
Ing konfigurasi iki, restart lancar bisa. Sampeyan bisa miwiti maneh kabeh 18 Bouncer iki siji-siji. Nanging njaga konfigurasi kasebut cukup angel. Sysadmins, DevOps, lan wong sing tanggung jawab kanggo server iki ora bakal seneng banget karo pengaturan iki.
Kayane kabeh dandan kita bisa dipromosekake dadi open source, nanging Bouncer ora didhukung kanthi apik. Contone, kemampuan kanggo mbukak sawetara PgBouncers ing siji port wis dileksanakake sasi kepungkur. Ana panjalukan narik karo fitur iki sawetara taun kepungkur.
Utawa siji conto liyane. Ing Postgres, sampeyan bisa mbatalake panjalukan sing lagi ditindakake kanthi ngirim rahasia menyang sambungan sing beda tanpa otentikasi sing ora perlu. Nanging sawetara klien mung ngirim TCP reset, IE break sambungan jaringan. Apa sing bakal ditindakake Bouncer? Dheweke ora bakal nindakake apa-apa. Bakal terus nglakokake panjaluk kasebut. Yen sampeyan wis nampa akeh sambungan sing nggawe database kanthi panjaluk cilik, mula mung medhot sambungan saka Bouncer ora bakal cukup; sampeyan uga kudu ngrampungake panjaluk sing mlaku ing database kasebut.
Iki wis ditambal lan masalah iki durung digabung menyang hulu Bouncer.
Lan kita teka menyang kesimpulan sing kita kudu pooler sambungan dhewe, kang bakal dikembangaké, patched, kang masalah bisa cepet didandani lan kang, mesthi, kudu multi-Utas.
Kita nyetel multithreading minangka tugas utama. Kita kudu bisa nangani gelombang sambungan TLS sing mlebu kanthi apik.
Kanggo nindakake iki, kita kudu ngembangake perpustakaan kapisah sing disebut Machinarium, sing dirancang kanggo njlèntrèhaké negara mesin sambungan jaringan minangka kode urutan. Yen sampeyan ndeleng kode sumber libpq, sampeyan bakal weruh sawetara telpon sing rumit sing bisa ngasilake asil lan ujar, "Telpon aku mengko. Saiki aku duwe IO saiki, nanging nalika IO ilang, aku bakal duwe beban ing prosesor. Lan iki minangka skema multi-level. Komunikasi jaringan biasane diterangake dening mesin negara. Akeh aturan kaya "Yen sadurunge aku nampa header paket ukuran N, saiki aku ngenteni bita N," "Yen aku ngirim paket SYNC, saiki aku ngenteni paket kanthi metadata asil." Asil punika rodo angel, counterintuitive kode, kaya mbingungake padha diowahi kanggo baris scan. We digawe supaya tinimbang mesin negara, programmer njlèntrèhaké path utama interaksi ing wangun kode imperatif biasa. Mung ing kode imperatif iki sampeyan kudu nglebokake panggonan ing ngendi urutan eksekusi kudu diganggu kanthi ngenteni data saka jaringan, ngliwati konteks eksekusi menyang coroutine liyane (utas ijo). Pendekatan iki padha karo kasunyatan sing kita nulis path paling samesthine ing mbingungake ing saurutan, lan banjur nambah cabang menyang.
Akibaté, kita duwe siji thread sing TCP nampa lan round-robin liwat sambungan TPC kanggo akeh buruh.
Ing kasus iki, saben sambungan klien tansah mlaku ing siji prosesor. Lan iki ngidini sampeyan nggawe cache-friendly.
Kajaba iku, kita wis rada nambah koleksi paket cilik dadi siji paket gedhe kanggo ngredhakaké tumpukan TCP sistem.
Kajaba iku, kita wis nambah pooling transaksional ing pangertèn sing Odyssey, nalika diatur, bisa ngirim CANCEL lan ROLLBACK ing acara saka Gagal sambungan jaringan, IE yen ora ana sing nunggu panjalukan, Odyssey bakal marang database ora nyoba kanggo nepaki panjalukan sing bisa mbuang sumber daya larang regane.
Lan yen bisa, kita tetep sambungan menyang klien sing padha. Iki supaya ora nginstal maneh application_name_add_host. Yen bisa, mula kita ora kudu ngreset paramèter sing dibutuhake kanggo diagnostik.
Kita kerja kanggo kepentingan Yandex.Cloud. Lan yen sampeyan nggunakake ngatur PostgreSQL lan duwe pooler sambungan diinstal, sampeyan bisa nggawe réplikasi logis metu, IE ninggalake kita, yen pengin, nggunakake réplikasi logis. Bouncer ora bakal ngeculake aliran replikasi logis ing njaba.
Iki minangka conto nyetel replikasi logis.
Kajaba iku, kita duwe dhukungan kanggo replikasi fisik ing njaba. Ing Cloud, mesthine, iki ora mungkin, amarga kluster kasebut bakal menehi sampeyan akeh informasi babagan awake dhewe. Nanging ing panginstalan, yen sampeyan perlu replikasi fisik liwat pooler sambungan ing Odyssey, iki bisa.
Odyssey nduweni pemantauan sing kompatibel karo PgBouncer. We duwe console padha sing nganggo meh kabeh printah padha. Yen ana sing ilang, kirim panjaluk tarik, utawa paling ora ana masalah ing GitHub, lan kita bakal ngrampungake prentah sing dibutuhake. Nanging kita wis duwe fungsi utama konsol PgBouncer.
Lan, mesthi, kita duwe kesalahan nerusake. Kita bakal ngasilake kesalahan sing dilaporake dening database. Sampeyan bakal nampa informasi bab apa sing ora klebu ing database, lan ora mung sing ora klebu ing.
Fitur iki dipateni yen sampeyan butuh 100% kompatibilitas karo PgBouncer. Kita bisa tumindak kanthi cara sing padha karo Bouncer, mung supaya bisa aman.
Pangembangan saka
Sawetara tembung babagan kode sumber Odyssey.
Contone, ana printah "Ngaso / Resume". Biasane digunakake kanggo nganyari database. Yen sampeyan kudu nganyari Postgres, sampeyan bisa ngaso ing pooler sambungan, nindakake pg_upgrade, banjur nerusake. Lan saka sisih klien bakal katon kaya database mung alon-alon. Fungsi iki digawa menyang kita dening wong saka masyarakat. Dheweke durung beku, nanging rauh kabeh bakal dadi. (Wis beku)
- wis beku
Kajaba iku, salah sawijining fitur anyar ing PgBouncer yaiku dhukungan kanggo Otentikasi SCRAM, sing uga digawa menyang kita dening wong sing ora kerja ing Yandex.Cloud. Loro-lorone minangka fungsi sing kompleks lan penting.
Mulane, aku arep ngomong apa Odyssey digawe, yen sampeyan uga pengin nulis kode cilik saiki.
Sampeyan duwe basis sumber Odyssey, sing gumantung ing rong perpustakaan utama. Pustaka Kiwi minangka implementasi protokol pesen Postgres. Yaiku, proto asli 3 saka Postgres minangka pesen standar sing bisa diganti ing ngarep lan mburi. Padha dileksanakake ing perpustakaan Kiwi.
Pustaka Machinarium minangka perpustakaan implementasi benang. A fragmen cilik saka Machinarium iki ditulis ing basa assembly. Nanging aja kuwatir, mung ana 15 baris.
arsitektur Odyssey. Ana mesin utama sing coroutines mlaku. Mesin iki ngetrapake sambungan TCP sing mlebu lan disebarake ing antarane para pekerja.
A handler kanggo sawetara klien bisa digunakake ing siji buruh. Utas utama uga nganggo konsol lan ngolah tugas crone kanggo mbusak sambungan sing ora dibutuhake maneh ing blumbang.
Odyssey dites nggunakake Suite test Postgres standar. Kita mung mbukak install-check liwat Bouncer lan liwat Odyssey, kita entuk div null. Ana sawetara tes related kanggo format tanggal sing ora pass persis padha ing Bouncer lan ing Odyssey.
Kajaba iku, ana akeh pembalap sing duwe tes dhewe. Lan kita nggunakake tes kanggo nyoba Odyssey.
Kajaba iku, amarga konfigurasi kaskade, kita kudu nyoba macem-macem bundel: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey kanggo mesthekake yen Odyssey rampung ing samubarang bagean ing cascade, uga isih bisa digunakake. kaya sing dikarepake.
Rake
Kita nggunakake Odyssey ing produksi. Lan ora adil yen aku ujar manawa kabeh bisa digunakake. Ora, ya, nanging ora mesthi. Contone, ing produksi kabeh mung makarya, banjur kanca-kanca saka PostgreSQL Professional teka lan ngandika yen kita wis bocor memori. Padha tenan, kita mbenerake. Nanging prasaja.
Banjur kita nemokake manawa pooler sambungan duwe sambungan TLS mlebu lan sambungan TLS metu. Lan sambungan mbutuhake sertifikat klien lan sertifikat server.
Sertifikat server Bouncer lan Odyssey diwaca maneh dening pcache, nanging sertifikat klien ora perlu diwaca maneh saka pcache, amarga Odyssey sing bisa diukur pungkasane mlaku menyang kinerja sistem maca sertifikat iki. Iki teka minangka surprise kanggo kita, amarga iku ora njupuk dawa kanggo nolak. Ing kawitan scaled linearly, nanging sawise 20 mlebu sambungan simultaneous masalah iki nuduhake dhewe.
Metode Otentikasi Pluggable yaiku kemampuan kanggo keasliane nggunakake alat Lunux sing dibangun. Ing PgBouncer dileksanakake kanthi cara sing ana thread kapisah kanggo ngenteni respon saka PAM lan ana utas PgBouncer utama sing nglayani sambungan saiki lan bisa njaluk supaya manggon ing thread PAM.
Kita ora ngleksanakake iki kanggo siji alesan prasaja. Kita duwe akeh benang. Napa kita butuh iki?
Iki pungkasane bisa nggawe masalah yen sampeyan duwe otentikasi PAM lan otentikasi non-PAM, mula gelombang otentikasi PAM sing gedhe bisa nundha otentikasi non-PAM. Iki minangka salah sawijining perkara sing durung didandani. Nanging yen sampeyan pengin ndandani, sampeyan bisa nindakake iki.
Rake liyane yaiku kita duwe siji benang sing nampa kabeh sambungan sing mlebu. Banjur ditransfer menyang blumbang buruh, ing ngendi salaman TLS bakal ditindakake.
Ing ngisor iki, yen sampeyan duwe gelombang koheren 20 sambungan jaringan, kabeh bakal ditampa. Lan ing sisih klien libpq bakal miwiti nglaporake wektu entek. Kanthi gawan misale jek 000 detik.
Yen kabeh ora bisa mlebu ing basis data bebarengan, mula ora bisa mlebu ing basis data, amarga kabeh iki bisa ditutupi kanthi nyoba maneh non-eksponensial.
Kita teka ing kesimpulan yen kita nyalin skema saka PgBouncer ing kene kanthi kasunyatan manawa kita wis nyuda jumlah sambungan TCP sing kita tampa.
Yen kita weruh yen kita nampa sambungan, nanging pungkasanipun ora duwe wektu kanggo salaman, kita sijine wong ing antrian supaya padha ora sampah sumber CPU. Iki ndadékaké kanggo kasunyatan sing jabat tangan simultaneous bisa uga ora dileksanakake kanggo kabeh sambungan sing wis teka. Nanging paling ora ana sing bakal mlebu database, sanajan bebane cukup abot.
roadmap
Apa sampeyan pengin ndeleng ing mangsa ngarep ing Odyssey? Apa sing kita siap kanggo ngembangake awake dhewe lan apa sing dikarepake saka masyarakat?
Ing Agustus 2019.
Iki minangka peta dalan Odyssey ing wulan Agustus:
- Kita pengin otentikasi SCRAM lan PAM.
- We wanted kanggo nerusake panjalukan maca kanggo siyaga.
- Aku pengin miwiti maneh online.
- Lan kemampuan kanggo ngaso ing server.
Setengah saka roadmap iki wis rampung, lan ora dening kita. Lan iki apik. Dadi ayo ngrembug apa sing isih ana lan nambah liyane.
? Kita duwe replika sing mung bakal panas udhara tanpa nglakokaké panjalukan. We kudu wong kanggo nyedhiyani failover lan switchover. Ing cilik saka masalah ing salah siji saka pusat data, Aku kaya kanggo Occupy karo sawetara karya migunani. Amarga kita ora bisa ngatur prosesor tengah padha, memori padha beda, amarga digunakake réplikasi ora bisa.
Ing asas, ing Postgres, miwiti saka 10, iku bisa kanggo nemtokake session_attrs nalika nyambungake. Sampeyan bisa dhaptar kabeh host database ing sambungan lan ngomong apa sing arep kanggo database: nulis utawa maca mung. Lan pembalap dhewe bakal milih host pisanan ing dhaptar sing paling disenengi, sing nyukupi syarat session_attrs.
Nanging masalah karo pendekatan iki ora ngontrol lag réplikasi. Sampeyan bisa uga duwe sawetara tiron sing wis ketinggalan kanggo wektu sing ora bisa ditampa kanggo layanan sampeyan. Kanggo ngaktifake eksekusi pitakon maca kanthi lengkap ing replika, kita kudu ndhukung kemampuan Odyssey supaya ora mbukak nalika ora bisa diwaca.
Odyssey kudu pindhah menyang database saka wektu kanggo wektu lan takon kanggo replikasi kadohan saka utami. Lan yen wis tekan nilai watesan, ora ngidini panjalukan anyar menyang database, marang klien sing perlu kanggo miwiti maneh sambungan lan, bisa, pilih host liyane kanggo nglakokaké panjalukan. Iki bakal ngidini database cepet mulihake lag réplikasi lan bali maneh kanggo nanggapi karo panjalukan.
Iku angel kanggo menehi pigura wektu kanggo implementasine, amarga iku open source. Nanging, muga-muga, ora 2,5 taun kaya kanca-kanca saka PgBouncer. Iki minangka fitur sing pengin dakdeleng ing Odyssey.
. Saiki sampeyan bisa nggawe statement sing disiapake kanthi rong cara. Pisanan, sampeyan bisa nglakokake perintah SQL, yaiku "siap". Supaya ngerti printah SQL iki, kita kudu sinau kanggo ngerti SQL ing sisih Bouncer. Iki bakal dadi overkill, amarga overkill, amarga kita butuh kabeh parser. Kita ora bisa ngurai saben printah SQL.
Nanging ana statement sing disiapake ing tingkat protokol pesen ing proto3. Lan iki minangka papan nalika informasi sing disiapake statement digawe ing wangun sing wis kabentuk. Lan kita bisa ndhukung pangerten sing ing sawetara sambungan server klien takon kanggo nggawe statements disiapake. Lan sanajan transaksi ditutup, kita isih kudu njaga konektivitas antarane server lan klien.
Nanging ing kene ana bedane ing dialog, amarga ana wong sing ujar manawa sampeyan kudu ngerti apa jenis pernyataan sing disiapake klien digawe lan nuduhake sambungan server antarane kabeh klien sing nggawe sambungan server iki, yaiku, sing nggawe pernyataan sing disiapake.
Andres Freund ngandika yen klien teka kanggo sampeyan sing wis nggawe statement disiapake kuwi ing sambungan server liyane, banjur nggawe kanggo wong. Nanging misale jek rada salah kanggo nglakokake pitakon ing database tinimbang klien, nanging saka sudut pandang pangembang sing nulis protokol kanggo sesambungan karo database, bakal trep yen dheweke mung diwenehi sambungan jaringan. ana pitakon sing disiapake.
Lan siji fitur liyane sing kudu kita tindakake. Saiki kita duwe pemantauan sing kompatibel karo PgBouncer. Kita bisa ngasilake rata-rata wektu eksekusi query. Nanging wektu rata-rata yaiku suhu rata-rata ing rumah sakit: ana sing adhem, ana sing anget - rata-rata, kabeh wong sehat. Iku ora bener.
Kita kudu ngetrapake dhukungan kanggo persentil sing bakal nuduhake yen ana pitakon alon sing mbuang sumber daya lan nggawe pemantauan luwih bisa ditampa.
Sing paling penting yaiku aku pengin versi 1.0 (Versi 1.1 wis dirilis). Kasunyatane yaiku Odyssey saiki ana ing versi 1.0rc, yaiku calon rilis. Lan kabeh masalah sing dakkandhakake diatasi kanthi versi sing padha, kajaba bocor memori.
Apa tegese versi 1.0 kanggo kita? Kita ngluncurake Odyssey menyang pangkalan kita. Wis mlaku ing basis data kita, nanging nalika tekan 1 panjalukan saben detik, mula kita bisa ngomong yen iki versi rilis lan iki versi sing bisa diarani 000.
Sawetara wong ing komunitas takon manawa versi 1.0 kalebu ngaso lan SCRAM. Nanging iki tegese kita kudu muter versi sabanjure kanggo produksi, amarga SCRAM utawa ngaso durung matèni. Nanging, paling kamungkinan, masalah iki bakal ditanggulangi cukup cepet.
Aku ngenteni panjaluk tarik sampeyan. Aku uga pengin krungu apa masalah sampeyan duwe Bouncer. Ayo padha rembugan. Mungkin kita bisa ngetrapake sawetara fungsi sing sampeyan butuhake.
Iki pungkasan saka bagean, aku pengin ngrungokake sampeyan. Matur nuwun!
Pitakonan
Yen aku nyetel application_name dhewe, bakal diterusake kanthi bener, kalebu ing pooling transaksi ing Odyssey?
Odyssey utawa Bouncer?
Ing Odyssey. Ing Bouncer dibuwang.
Kita bakal nggawe set.
Lan yen sambungan nyata saya mlumpat ing sambungan liyane, bakal ditularake?
Kita bakal nggawe set kabeh paramèter sing kadhaptar ing dhaptar. Aku ora ngerti yen application_name ana ing dhaptar iki. Aku wis weruh dheweke ana. Kita bakal nyetel kabeh paramèter sing padha. Kanthi siji panyuwunan, set bakal nindakake kabeh sing wis diinstal dening klien nalika wiwitan.
Matur nuwun, Andrey, kanggo laporan! Laporan apik! Aku bungah sing Odyssey berkembang luwih cepet lan luwih cepet saben menit. Aku pengin terus kaya iki. Kita wis takon sampeyan duwe sambungan multi-sumber data supaya Odyssey bisa nyambung menyang database beda bebarengan, IE master abdi, lan banjur otomatis nyambung menyang master anyar sawise failover.
Ya kayane aku ngelingi diskusi iki. Saiki ana sawetara panyimpenan. Nanging ora ana owah-owahan ing antarane. Ing sisih kita, kita kudu polling server sing isih urip lan ngerti sing failover wis kedaden, sing bakal nelpon pg_recovery. Aku duwe cara standar pangerten sing kita ora teka master. Lan kita kudu ngerti piye wae saka kesalahane utawa apa? Tegese, gagasan iku menarik, lagi dibahas. Tulis komentar liyane. Yen sampeyan duwe buruh sing ngerti C, iku apik.
Masalah skala ing replika uga menarik kanggo kita, amarga kita pengin nggawe adopsi kluster sing ditiru kanthi gampang kanggo pangembang aplikasi. Nanging ing kene aku pengin komentar liyane, yaiku persis carane nindakake, carane nindakake kanthi apik.
Pitakonan uga babagan replika. Pranyata sampeyan duwe master lan sawetara replika. Lan iku cetha sing padha pindhah menyang tiron kurang asring saka master kanggo sambungan, amarga padha duwe beda. Sampeyan ujar manawa prabédan ing data kasebut bisa uga ora bakal gawe marem bisnis sampeyan lan sampeyan ora bakal pindhah menyang kono nganti ditiru. Ing wektu sing padha, yen sampeyan ora lunga menyang kono nganti suwe, banjur wiwit lunga, mula data sing dibutuhake ora bakal kasedhiya. Sing, yen kita terus-terusan menyang master, banjur cache ana warmed munggah, nanging ing tiron cache lags sethitik.
Ya bener. Pcache ora bakal duwe pamblokiran data sing dikarepake, cache nyata ora bakal duwe informasi babagan tabel sing dikarepake, rencana kasebut ora bakal ana pitakon, ora bakal ana apa-apa.
Lan nalika sampeyan duwe sawetara jenis kluster, lan sampeyan nambah tiron anyar ana, banjur nalika iku wiwit, kabeh iku ala, IE mundhak cache sawijining.
Aku entuk ide. Pendekatan sing bener yaiku nglakokake persentase cilik pitakon ing replika dhisik, sing bakal dadi panas ing cache. Secara kasar, kita duwe syarat yen kita kudu ketinggalan master ora luwih saka 10 detik. Lan kondisi iki ora kalebu ing siji gelombang, nanging lancar kanggo sawetara klien.
Ya, nambah bobot.
Iki minangka ide sing apik. Nanging pisanan kita kudu ngleksanakake shutdown iki. Kaping pisanan, kita kudu mateni, banjur mikir babagan cara ngaktifake. Iki minangka fitur sing apik kanggo ngaktifake kanthi lancar.
Nginx duwe pilihan iki slowly start ing kluster kanggo server. Lan mboko sithik nambah beban.
Ya, ide sing apik, kita bakal nyoba nalika entuk.
Source: www.habr.com