Dina laporanna, Andrey Borodin bakal nyarioskeun ka anjeun kumaha aranjeunna ngémutan pangalaman skala PgBouncer nalika ngarancang pooler sambungan. , sabab digulung kaluar kana produksi. Salaku tambahan, urang bakal ngabahas naon fungsi puller anu urang hoyong tingali dina versi énggal: penting pikeun urang henteu ngan ukur nyumponan kabutuhan urang, tapi pikeun ngembangkeun komunitas pangguna. .
video:
Halo sadayana! Ngaran abdi Andrew.
Di Yandex, kuring ngembangkeun database open source. Sareng dinten ayeuna urang gaduh topik ngeunaan sambungan pooler sambungan.
Upami anjeun terang kumaha nelepon pooler sambungan dina basa Rusia, teras wartosan kuring. Abdi hoyong pisan mendakan istilah téknis anu saé anu kedah ditetepkeun dina literatur téknis.
Topikna rada pajeulit, sabab dina seueur database pooler sambungan diwangun-di sareng anjeun henteu kedah terang ngeunaan éta. Tangtosna, aya sababaraha setélan dimana waé, tapi dina Postgres éta henteu jalanna. Sareng paralel (dina HighLoad ++ 2019) aya laporan ku Nikolai Samokhvalov ngeunaan nyetél patarosan di Postgres. Na sakumaha Abdi ngartos eta, jalma sumping ka dieu anu geus ngonpigurasi queries maranéhna sampurna, sarta ieu jalma anu Nyanghareupan masalah sistem beuki langka patali jeung jaringan sarta utilization sumberdaya. Sarta di sababaraha tempat bisa jadi rada hese dina harti yén masalah teu atra.
Yandex gaduh Postgres. Seueur jasa Yandex cicing di Yandex.Cloud. Sareng kami gaduh sababaraha petabytes data anu ngahasilkeun sahenteuna sajuta pamundut per detik dina Postgres.
Sarta kami nyadiakeun klaster cukup baku pikeun sakabéh jasa - ieu titik primér utama titik, nu biasa dua réplika (sinkron jeung Asynchronous), cadangan, skala requests bacaan on replica nu.
Unggal titik klaster nyaéta Postgres, anu, salian ti Postgres sareng sistem ngawaskeun, ogé dipasang pooler sambungan. Connection pooler dipaké pikeun Anggar jeung tujuan utamana.
Naon tujuan utama pooler sambungan?
Postgres ngadopsi modél prosés nalika damel sareng database. Ieu ngandung harti yén hiji sambungan hiji prosés, hiji Postgres backend. Sarta di backend ieu aya loba caches béda, nu rada mahal sangkan béda pikeun sambungan béda.
Salaku tambahan, kode Postgres ngagaduhan susunan anu disebut procArray. Ieu ngandung data dasar ngeunaan sambungan jaringan. Sareng ampir sadaya algoritma pamrosésan procArray gaduh pajeulitna linier; aranjeunna ngajalankeun sadaya jaringan sambungan jaringan. Siklus anu lumayan gancang, tapi kalayan sambungan jaringan anu langkung seueur, hal-hal janten langkung mahal. Sareng nalika hal-hal janten langkung mahal, anjeun tiasa mayar harga anu luhur pikeun seueur sambungan jaringan.
Aya 3 pendekatan anu mungkin:
- Dina sisi aplikasi.
- Dina sisi database.
- Sareng antara, nyaéta, sagala jinis kombinasi.
Hanjakalna, pooler anu diwangun ayeuna nuju dikembangkeun. Babaturan urang di PostgreSQL Professional biasana ngalakukeun ieu. Nalika éta bakal muncul hese diprediksi. Sareng kanyataanna, urang gaduh dua solusi pikeun milih arsitek. Ieu mangrupikeun kolam renang sisi aplikasi sareng kolam renang proxy.
Kolam renang sisi aplikasi mangrupikeun cara anu paling gampang. Sareng ampir sadaya supir klien nyayogikeun anjeun cara: nampilkeun jutaan sambungan anjeun dina kode salaku sababaraha belasan sambungan kana pangkalan data.
Masalah anu timbul nyaéta yén dina titik anu anjeun hoyong skala backend, anjeun badé nyebarkeun ka seueur mesin virtual.
Teras anjeun sadar yén anjeun gaduh sababaraha zona kasadiaan, sababaraha pusat data. Sareng pendekatan pooling sisi klien ngakibatkeun angka anu langkung ageung. Anu ageung kirang langkung 10 sambungan. Ieu mangrupikeun ujung anu tiasa dianggo normal.
Lamun urang ngobrol ngeunaan poolers proxy, lajeng aya dua poolers anu bisa ngalakukeun loba hal. Aranjeunna teu ukur poolers. Aranjeunna poolers + fungsionalitas leuwih tiis. Ieu и .
Tapi, hanjakalna, henteu sadayana peryogi fungsionalitas tambahan ieu. Sarta eta ngabalukarkeun kanyataan yén poolers ukur ngarojong sési pooling, i.e. hiji klien asup, hiji klien kaluar kana database.
Ieu henteu cocog pisan pikeun tujuan urang, janten kami nganggo PgBouncer, anu ngalaksanakeun transaksi pooling, nyaéta sambungan server cocog sareng sambungan klien ngan ukur salami transaksi.
Sareng dina beban kerja urang, ieu leres. Tapi aya sababaraha masalah.
Masalahna dimimitian nalika anjeun hoyong mendiagnosis sési, sabab sadaya sambungan anu anjeun asup lokal. Sarerea sumping sareng loopback sareng kumaha waé janten sesah pikeun ngalacak sési.
Tangtu anjeun bisa make application_name_add_host. Ieu mangrupikeun cara di sisi Bouncer pikeun nambihan alamat IP kana application_name. Tapi application_name diatur ku sambungan tambahan.
Dina grafik ieu, dimana garis konéng mangrupa requests nyata, sarta dimana garis biru requests nu ngapung kana database. Sareng bédana ieu mangrupikeun pamasangan application_name, anu diperyogikeun ngan ukur pikeun ngalacak, tapi éta henteu gratis.
Salaku tambahan, dina Bouncer anjeun moal tiasa ngawatesan hiji kolam renang, nyaéta jumlah sambungan database per pangguna khusus, per database khusus.
Ieu ngakibatkeun naon? Anjeun gaduh jasa dimuat ditulis dina C ++ jeung tempat caket dieu layanan leutik dina titik nu teu ngalakukeun nanaon dahsyat jeung database, tapi supir na mana gélo. Ieu muka 20 sambungan jeung sagalana sejenna bakal antosan. Malah kode anjeun normal.
Kami, tangtosna, nyerat patch leutik pikeun Bouncer anu nambihan setélan ieu, nyaéta ngawatesan klien ka kolam renang.
Ieu bakal mungkin pikeun ngalakukeun ieu di sisi Postgres, nyaéta, ngawatesan peran dina database ku jumlah sambungan.
Tapi lajeng anjeun leungit kamampuhan pikeun ngarti naha anjeun teu boga sambungan kana server. PgBouncer henteu ngalungkeun kasalahan sambungan, éta salawasna ngabalikeun inpormasi anu sami. Sareng anjeun teu tiasa ngartos: panginten kecap konci anjeun parantos robih, panginten pangkalan data leungit, panginten aya anu salah. Tapi teu aya diagnosis. Lamun sési teu bisa ngadegkeun, anjeun moal nyaho naha eta teu bisa ngadegkeun.
Dina titik anu tangtu, anjeun ningali grafik aplikasi sareng ningali yén aplikasina henteu jalan.
Tingali di luhur sareng tingali yén Bouncer nyaéta single-threaded. Ieu titik balik dina kahirupan jasa. Anjeun nyadar yén anjeun Nyiapkeun pikeun skala database dina sataun satengah, jeung anjeun kudu skala pooler nu.
Kami parantos nyimpulkeun yén urang peryogi langkung PgBouncers.
Bouncer parantos ditambal sakedik.
Sareng aranjeunna ngajantenkeun sababaraha Bouncer tiasa diangkat ku ngagunakeun deui port TCP. Sareng sistem operasi otomatis mindahkeun sambungan TCP anu asup antara aranjeunna nganggo round-robin.
Ieu transparan pikeun klien, hartina sigana anjeun gaduh hiji Bouncer, tapi anjeun gaduh fragméntasi sambungan dianggurkeun antara ngajalankeun Bouncer.
Sareng dina waktos anu tangtu anjeun tiasa perhatikeun yén 3 Bouncer ieu masing-masing ngahakan inti ku 100%. Anjeun peryogi sababaraha Bouncer. Naha?
Kusabab anjeun gaduh TLS. Anjeun gaduh sambungan énkripsi. Tur upami Anjeun salah tolok ukur Postgres kalawan jeung tanpa TLS, anjeun bakal manggihan yén jumlah sambungan ngadegkeun turun ku ampir dua ordo gedena jeung enkripsi diaktipkeun, sabab TLS sasalaman meakeun sumberdaya CPU.
Sareng di luhur anjeun tiasa ningali sababaraha fungsi kriptografi anu dieksekusi nalika aya gelombang sambungan anu asup. Kusabab primér urang tiasa ngalih antara zona kasadiaan, gelombang sambungan asup mangrupikeun kaayaan anu cukup umum. Hartina, pikeun sababaraha alesan primér heubeul teu sadia, sakabéh beban dikirim ka puseur data sejen. Aranjeunna sadayana bakal datang pikeun ngucapkeun salam ka TLS dina waktos anu sami.
Sareng sajumlah ageung sasalaman TLS tiasa henteu deui ngucapkeun salam ka Bouncer, tapi bakal nyéépkeun tikorona. Alatan waktu béak, gelombang sambungan asup bisa jadi undamped. Upami anjeun nyobian deui ka dasarna tanpa mundur eksponensial, aranjeunna moal datang deui-deui dina gelombang anu koheren.
Ieu conto 16 PgBouncers anu ngamuat 16 inti dina 100%.
Urang sumping ka cascade PgBouncer. Ieu mangrupikeun konfigurasi pangsaéna anu tiasa dihontal dina beban kami sareng Bouncer. Bouncer éksternal kami dianggo pikeun sasalaman TCP, sareng Bouncer internal dianggo pikeun pooling nyata, supados henteu ngabitukeun sambungan éksternal teuing.
Dina konfigurasi ieu, balikan deui lancar tiasa. Anjeun tiasa ngamimitian deui sadayana 18 Bouncer ieu hiji-hiji. Tapi ngajaga konfigurasi sapertos ieu rada sesah. Sysadmins, DevOps, sareng jalma-jalma anu leres-leres nanggungjawaban kana server ieu moal bagja pisan sareng susunan ieu.
Éta sigana yén sadaya perbaikan urang tiasa diwanohkeun kana open source, tapi Bouncer henteu didukung pisan. Contona, kamampuhan pikeun ngajalankeun sababaraha PgBouncers on hiji port ieu komitmen sabulan katukang. Aya paménta tarik sareng fitur ieu sababaraha taun ka pengker.
Atawa conto sejen. Dina Postgres, anjeun tiasa ngabatalkeun pamundut anu nuju lumangsung ku ngirim rusiah ka sambungan anu béda tanpa auténtikasi anu teu perlu. Tapi sababaraha klien ngan saukur ngirim reset TCP, nyaéta aranjeunna megatkeun sambungan jaringan. Naon anu bakal dilakukeun ku Bouncer? Anjeunna moal ngalakukeun nanaon. Bakal neruskeun ngaéksekusi pamundut. Upami anjeun nampi sajumlah ageung sambungan anu parantos nyiptakeun pangkalan data kalayan pamundut anu alit, maka ngan saukur ngahapus sambungan tina Bouncer moal cekap; anjeun ogé kedah ngalengkepan pamundut anu dijalankeun dina pangkalan data.
Ieu parantos ditambal sareng masalah ieu henteu acan dihijikeun kana hulu Bouncer.
Sarta sangkan datang ka kacindekan yen urang kudu pooler sambungan sorangan, nu bakal dimekarkeun, patched, nu masalah bisa gancang dilereskeun jeung nu, tangtosna, kudu multi-threaded.
Urang nyetél multithreading salaku tugas utama. Urang kedah tiasa ngadamel gelombang sambungan TLS anu asup ogé.
Jang ngalampahkeun ieu, urang kudu ngamekarkeun perpustakaan misah disebut Machinarium, nu dirancang pikeun ngajelaskeun kaayaan mesin tina sambungan jaringan sakumaha kode sequential. Upami anjeun ningali kode sumber libpq, anjeun bakal ningali sababaraha telepon anu rumit anu tiasa ngabalikeun hasil sareng ucapkeun, "Telepon kuring engké. Ayeuna kuring gaduh IO pikeun ayeuna, tapi nalika IO ngaleungit kuring bakal ngagaduhan beban dina prosésor. Sareng ieu mangrupikeun skéma multi-level. Komunikasi jaringan biasana digambarkeun ku mesin kaayaan. Seueur aturan sapertos "Upami sateuacana nampi header pakét ukuran N, ayeuna kuring ngantosan N bait," "Upami kuring ngirim pakét SYNC, ayeuna kuring ngantosan pakét kalayan metadata hasil." hasilna mangrupakeun rada hese, kode counterintuitive, saolah-olah Maze ieu dirobah jadi scan garis. Kami ngajantenkeun éta sanés mesin kaayaan, programmer ngajelaskeun jalur utama interaksi dina bentuk kode imperatif biasa. Ngan dina kode imperatif ieu anjeun kedah nyelapkeun tempat dimana urutan palaksanaan kedah diganggu ku ngantosan data tina jaringan, ngalangkungan kontéks palaksanaan ka coroutine anu sanés (benang héjo). Pendekatan ieu sami sareng kanyataan yén urang nyerat jalur anu paling dipiharep dina maze sakaligus, teras tambahkeun cabangna.
Hasilna, urang boga hiji thread nu teu TCP narima tur round-robin ngalirkeun sambungan TPC ka loba pagawe.
Dina hal ieu, unggal sambungan klien salawasna dijalankeun dina hiji prosésor. Sareng ieu ngamungkinkeun anjeun ngajantenkeun cache-friendly.
Jeung sajaba ti éta, kami geus rada ningkat kumpulan pakét leutik kana hiji pakét badag guna ngagentos sistem TCP tumpukan.
Sajaba ti éta, kami geus ningkat pooling transactional dina harti yén Odyssey, nalika ngonpigurasi, bisa ngirim BATAL sarta ROLLBACK dina acara gagalna sambungan jaringan, ie lamun teu aya anu ngantosan pamundut a, Odyssey bakal ngabejaan database teu coba mun minuhan pamundut nu bisa runtah sumberdaya berharga.
Jeung sabisana, urang tetep sambungan ka klien sarua. Ieu ngahindarkeun kedah pasang deui application_name_add_host. Upami ieu mungkin, maka urang henteu kedah ngareset parameter anu dipikabutuh pikeun diagnostik.
Kami damel pikeun kapentingan Yandex.Cloud. Tur upami Anjeun salah make junun PostgreSQL sarta geus dipasang pooler sambungan, Anjeun bisa nyieun réplikasi logis kaluar, nyaéta, ninggalkeun kami, upami anjeun hoyong, ngagunakeun réplikasi logis. Bouncer moal ngirim aliran réplikasi logis luar.
Ieu conto nyetel réplikasi logis.
Salaku tambahan, urang gaduh dukungan pikeun réplikasi fisik ka luar. Dina Awan, tangtosna, ieu teu mungkin, sabab lajeng kluster bakal masihan anjeun teuing informasi ngeunaan dirina. Tapi dina pamasangan Anjeun, lamun perlu réplikasi fisik ngaliwatan pooler sambungan di Odyssey, ieu mungkin.
Odyssey gaduh monitoring anu cocog sareng PgBouncer. Kami gaduh konsol anu sami anu ngajalankeun ampir sadaya paréntah anu sami. Upami aya anu leungit, kirimkeun pamundut tarik, atanapi sahenteuna masalah dina GitHub, sareng kami bakal ngalengkepan paréntah anu diperyogikeun. Tapi kami parantos ngagaduhan pungsi utama konsol PgBouncer.
Sareng, tangtosna, urang gaduh kasalahan diteruskeun. Kami bakal mulangkeun kasalahan anu dilaporkeun ku pangkalan data. Anjeun bakal nampa informasi ngeunaan naha anjeun teu kaasup dina database, na teu ngan nu teu kaasup kana eta.
Fitur ieu ditumpurkeun upami anjeun peryogi 100% kasaluyuan sareng PgBouncer. Urang tiasa kalakuanana sami sareng Bouncer, ngan ukur dina sisi anu aman.
rarancang
Sababaraha kecap ngeunaan kode sumber Odyssey.
Contona, aya paréntah "Reureuh / neruskeun". Aranjeunna biasana dianggo pikeun ngapdet pangkalan data. Upami anjeun kedah ngapdet Postgres, teras anjeun tiasa ngareureuhkeun dina pooler sambungan, ngalakukeun pg_upgrade, teras teraskeun deui. Sareng ti sisi klien éta bakal katingali saolah-olah pangkalan data ngan saukur ngalambatkeun. Fungsi ieu dibawa ka urang ku jalma-jalma ti komunitas. Manehna teu beku acan, tapi geura-giru sagalana bakal. (Geus beku)
- geus beku
Salaku tambahan, salah sahiji fitur anyar dina PgBouncer nyaéta dukungan pikeun Auténtikasi SCRAM, anu ogé dibawa ka urang ku jalma anu henteu damel di Yandex.Cloud. Duanana mangrupikeun fungsionalitas anu rumit sareng penting.
Kituna, abdi hoyong ngabejaan Anjeun naon Odyssey dijieunna tina, bisi anjeun ogé rék nulis kode saeutik ayeuna.
Anjeun gaduh basis sumber Odyssey, anu ngandelkeun dua perpustakaan utama. Perpustakaan Kiwi mangrupikeun palaksanaan protokol pesen Postgres. Nyaéta, proto asli 3 tina Postgres mangrupikeun pesen standar anu tiasa ditukeurkeun di payun sareng tungtung. Éta dilaksanakeun di perpustakaan Kiwi.
Perpustakaan Machinarium mangrupakeun perpustakaan palaksanaan thread. A sempalan leutik Machinarium ieu ditulis dina basa assembly. Tapi entong hariwang, ngan aya 15 jalur.
Arsitéktur Odyssey. Aya mesin utama anu ngajalankeun coroutines. Mesin ieu implements narima sambungan TCP asup tur ngadistribusikaeun aranjeunna diantara pagawe.
Pawang pikeun sababaraha klien tiasa dianggo dina hiji pagawe. Utas utama ogé ngajalankeun konsol sareng ngolah tugas crone pikeun ngahapus sambungan anu henteu diperyogikeun deui di kolam renang.
Odyssey diuji ngagunakeun standar Postgres test suite. Urang ngan ngajalankeun install-pariksa ngaliwatan Bouncer tur ngaliwatan Odyssey, urang meunang null div. Aya sababaraha tés anu patali jeung pormat tanggal nu teu lulus persis sarua di Bouncer na di Odyssey.
Salaku tambahan, aya seueur supir anu gaduh tés sorangan. Sarta kami nganggo tés maranéhna pikeun nguji Odyssey.
Sajaba ti éta, alatan konfigurasi cascade urang, urang kudu nguji rupa bundles: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey guna mastikeun yén lamun Odyssey réngsé nepi di salah sahiji bagian dina cascade, éta ogé masih jalan. sakumaha urang nyangka.
Rakean
Kami nganggo Odyssey dina produksi. Sareng éta henteu adil upami kuring nyarios yén sadayana tiasa dianggo. Henteu, éta, enya, tapi henteu salawasna. Contona, dina produksi sagalana ngan digawé, lajeng babaturan urang ti PostgreSQL Profesional sumping sarta ngomong yén urang kungsi bocor memori. Éta leres-leres, kami ngalereskeunana. Tapi éta basajan.
Teras kami mendakan yén pooler sambungan ngagaduhan sambungan TLS anu asup sareng sambungan TLS anu kaluar. Jeung sambungan merlukeun sertipikat klien tur sertipikat server.
Bouncer na Odyssey sertipikat server anu reread ku pcache maranéhna, tapi sertipikat klien teu perlu reread ti pcache, sabab scalable Odyssey kami pamustunganana ngajalankeun kana kinerja sistem maca sertipikat ieu. Ieu sumping salaku kejutan ka kami, sabab teu nyandak anjeunna lila nolak. Mimitina éta skala linier, tapi sanggeus 20 asup sambungan simultaneous masalah ieu némbongkeun sorangan.
Métode Auténtikasi Pluggable nyaéta kamampuan pikeun ngabuktoskeun kaaslianana nganggo alat Lunux anu diwangun. Dina PgBouncer éta dilaksanakeun ku cara anu aya benang anu misah pikeun ngadagoan réspon ti PAM sareng aya utas PgBouncer utama anu nyayogikeun sambungan ayeuna sareng tiasa naroskeun aranjeunna cicing dina benang PAM.
Kami henteu ngalaksanakeun ieu pikeun hiji alesan anu sederhana. Urang boga loba threads. Naha urang peryogi ieu?
Ieu pamustunganana bisa nyieun masalah dina éta lamun boga auténtikasi PAM jeung auténtikasi non-PAM, lajeng gelombang badag auténtikasi PAM nyata bisa reureuh auténtikasi non-PAM. Ieu mangrupikeun salah sahiji hal anu teu acan kami perbaiki. Tapi upami anjeun hoyong ngalereskeun éta, anjeun tiasa ngalakukeun ieu.
rake sejen éta urang boga hiji thread nu narima sagala sambungan asup. Teras aranjeunna dialihkeun ka kolam renang karyawan, dimana sasalaman TLS bakal dilaksanakeun.
Intina, upami anjeun gaduh gelombang koheren 20 sambungan jaringan, aranjeunna sadayana bakal ditampi. Sareng di sisi klien libpq bakal ngamimitian ngalaporkeun timeouts. Sacara standar sigana 000 detik.
Upami aranjeunna sadayana henteu tiasa lebet kana pangkalan data dina waktos anu sami, maka aranjeunna henteu tiasa ngalebetkeun pangkalan data, sabab sadayana ieu tiasa katutupan ku cobaan deui non-eksponensial.
Kami dugi ka kacindekan yén kami nyalin skéma ti PgBouncer di dieu kalayan kanyataan yén kami parantos ngabatalkeun jumlah sambungan TCP anu kami tampi.
Lamun urang nempo yén kami narima sambungan, Tapi aranjeunna pamustunganana teu boga waktu pikeun sasalaman, urang nempatkeun aranjeunna dina antrian ambéh maranéhanana teu runtah sumberdaya CPU. Ieu ngakibatkeun kanyataan yén sasalaman simultaneous bisa jadi teu dipigawé pikeun sakabéh sambungan nu geus anjog. Tapi sahenteuna batur bakal ngasupkeun database, sanajan beban rada beurat.
Roadmap
Naon anu anjeun hoyong tingali di masa depan di Odyssey? Naon anu urang siap pikeun ngembangkeun diri sareng naon anu urang ngarepkeun ti masarakat?
Nepi ka Agustus 2019.
Ieu kumaha peta jalan Odyssey dina bulan Agustus:
- Kami hoyong SCRAM sareng auténtikasi PAM.
- Kami hoyong neraskeun pamundut bacaan ka sayaga.
- Abdi hoyong balikan deui online.
- Jeung kamampuhan pikeun reureuhan on server.
Satengah tina peta jalan ieu parantos réngsé, sanés ku urang. Sareng ieu saé. Janten hayu urang bahas naon anu tetep sareng tambahkeun deui.
? Kami gaduh réplika anu ngan saukur bakal memanaskeun hawa tanpa ngalaksanakeun pamundut. Urang kudu aranjeunna nyadiakeun failover na switchover. Bisi masalah di salah sahiji puseur data, abdi hoyong ngeusian aranjeunna kalayan sababaraha karya mangpaat. Kusabab urang teu bisa ngonpigurasikeun prosesor sentral sarua, memori sarua béda, sabab disebutkeun réplikasi moal jalan.
Sacara prinsip, dina Postgres, mimitian ti 10, kasebut nyaéta dimungkinkeun pikeun nangtukeun session_attrs nalika nyambungkeun. Anjeun tiasa daptar sadaya host database dina sambungan jeung nyebutkeun naha anjeun bade database: nulis atawa maca wungkul. Sareng supir nyalira bakal milih host anu munggaran dina daptar anu paling dipikaresep ku anjeunna, anu nyumponan sarat session_attrs.
Tapi masalah sareng pendekatan ieu nya éta teu ngadalikeun lag réplikasi. Anjeun bisa jadi kudu sababaraha réplika nu geus katinggaleun balik pikeun jumlah unacceptable waktu pikeun layanan anjeun. Dina raraga ngaktifkeun palaksanaan pinuh-diulas queries dibaca dina réplika, urang dasarna kudu ngarojong pangabisa Odyssey pikeun henteu ngajalankeun lamun eta teu bisa dibaca.
Odyssey kudu indit ka database ti jaman ka jaman jeung ménta jarak réplikasi ti primér. Tur upami eta geus ngahontal nilai wates, teu ngameunangkeun requests anyar kana database, ngabejaan klien nu eta perlu ulang initiate sambungan na, jigana, pilih host sejen pikeun ngaéksekusi requests. Ieu bakal ngidinan database pikeun gancang balikkeun lag réplikasi sarta balik deui ka ngabales ku pamundut a.
Hésé pikeun masihan pigura waktos pikeun palaksanaan, sabab éta open source. Tapi, abdi miharep, moal 2,5 taun kawas kolega kuring ti PgBouncer. Ieu mangrupikeun fitur anu kuring hoyong tingali dina Odyssey.
. Ayeuna anjeun tiasa ngadamel pernyataan anu disusun ku dua cara. Kahiji, anjeun tiasa ngaéksekusi paréntah SQL, nyaéta "disiapkeun". Pikeun ngartos paréntah SQL ieu, urang kedah diajar ngartos SQL di sisi Bouncer. Ieu bakal jadi hiji overkill, sabab overkill, saprak urang kudu sakabeh parser. Urang teu bisa parse unggal paréntah SQL.
Tapi aya pernyataan anu disiapkeun dina tingkat protokol pesen dina proto3. Sareng ieu mangrupikeun tempat nalika inpormasi yén pernyataan anu disusun dilakukeun dina bentuk terstruktur. Sarta kami bisa ngarojong pamahaman yén dina sababaraha sambungan server klien nanya ka nyieun pernyataan disusun. Sareng upami transaksi ditutup, urang tetep kedah ngajaga konektipitas antara server sareng klien.
Tapi di dieu aya béda dina dialog, sabab aya nu nyebutkeun yén anjeun kudu ngarti jenis pernyataan disusun klien dijieun tur babagi sambungan server antara sakabeh klien nu dijieun sambungan server ieu, i.e., anu dijieun pernyataan disusun misalna.
Andres Freund ngomong yén lamun klien datang ka anjeun anu geus dijieun pernyataan disiapkeun dina sambungan server sejen, lajeng nyieun eta pikeun anjeunna. Tapi sigana saeutik salah mun ngaéksekusi queries dina database tinimbang klien, tapi ti sudut pandang pamekar anu nulis protokol pikeun interacting jeung database, éta bakal merenah lamun anjeunna ngan dibéré sambungan jaringan nu. aya patarosan anu disiapkeun sapertos kitu.
Sareng hiji deui fitur anu kedah urang laksanakeun. Urang ayeuna gaduh monitoring cocog sareng PgBouncer. Urang tiasa mulangkeun rata-rata waktos palaksanaan query. Tapi waktos rata-rata suhu rata-rata di rumah sakit: aya anu tiis, aya anu haneut - rata-rata, sadayana séhat. Éta henteu leres.
Urang kudu nerapkeun rojongan pikeun percentiles, nu bakal nunjukkeun yén aya queries slow nu wasting sumberdaya sarta nyieun monitoring leuwih ditarima.
Anu paling penting nyaéta kuring hoyong versi 1.0 (Vérsi 1.1 parantos dileupaskeun). Kanyataan yén Odyssey ayeuna dina versi 1.0rc, nyaéta calon pelepasan. Sareng sadaya masalah anu kuring didaptarkeun dibenerkeun kalayan versi anu sami, kecuali bocor mémori.
Naon hartosna versi 1.0 pikeun urang? Kami ngaluncurkeun Odyssey ka pangkalan kami. Éta parantos dijalankeun dina pangkalan data urang, tapi nalika dugi ka 1 pamundut per detik, maka urang tiasa nyarios yén ieu mangrupikeun versi pelepasan sareng ieu mangrupikeun vérsi anu tiasa disebat 000.
Sababaraha jalma di komunitas naroskeun yén versi 1.0 kalebet pause sareng SCRAM. Tapi ieu bakal hartosna yén urang kedah ngagulung versi salajengna pikeun produksi, sabab SCRAM atanapi pause henteu acan tiwas. Tapi, paling dipikaresep, masalah ieu bakal direngsekeun cukup gancang.
Abdi ngantosan pamundut tarik anjeun. Abdi ogé hoyong ngadangu masalah naon anjeun gaduh sareng Bouncer. Hayu urang bahas aranjeunna. Panginten urang tiasa ngalaksanakeun sababaraha fungsi anu anjeun peryogikeun.
Ieu tungtung bagian abdi, abdi hoyong ngadangukeun anjeun. Hatur nuhun!
patarosan
Mun kuring nyetél sorangan application_name, eta bakal diteruskeun neuleu, kaasup dina pooling urus di Odyssey?
Odyssey atanapi Bouncer?
Dina Odyssey. Dina Bouncer ieu dialungkeun.
Urang bakal ngalakukeun hiji set.
Tur upami sambungan nyata kuring jumps on sambungan séjén, éta bakal dikirimkeun?
Kami bakal ngadamel set sadaya parameter anu didaptarkeun dina daptar. Abdi henteu tiasa terang upami application_name aya dina daptar ieu. Jigana kuring nempo manehna aya. Urang bakal nyetél sadaya parameter anu sami. Kalayan hiji pamundut, set bakal ngalakukeun sadayana anu dipasang ku klien nalika ngamimitian.
Hatur nuhun, Andrey, pikeun laporan! laporan alus! Abdi bungah yén Odyssey ngembang langkung gancang sareng langkung gancang unggal menit. Abdi hoyong neraskeun sapertos kieu. Kami parantos naroskeun anjeun gaduh sambungan multi-sumber data supados Odyssey tiasa nyambung ka database anu béda sakaligus, nyaéta budak master, teras otomatis nyambung ka master anyar saatos failover.
Sumuhun, abdi sigana apal ieu diskusi. Ayeuna aya sababaraha gudang. Tapi euweuh switching antara aranjeunna. Di sisi urang, urang kedah polling server yén éta téh masih hirup tur ngartos yen failover geus lumangsung, anu bakal nelepon pg_recovery. Kuring boga cara baku ngartos yen urang teu datang ka master. Sareng urang kedah ngartos kumaha waé tina kasalahan atanapi naon? Nyaéta, gagasan téh metot, keur dibahas. Tulis deui komentar. Upami anjeun ngagaduhan pagawé anu terang C, maka éta saé.
Isu skala sakuliah réplika ogé dipikaresep ku urang, sabab urang hayang nyieun nyoko klaster replicated sasederhana mungkin pikeun pamekar aplikasi. Tapi di dieu kuring hoyong langkung seueur koméntar, nyaéta kumaha cara ngalakukeunana, kumaha ngalakukeunana saé.
Patarosan ogé ngeunaan réplika. Tétéla anjeun gaduh master sareng sababaraha réplika. Sarta eta jelas yén maranéhna balik ka replica kirang sering ti master pikeun sambungan, sabab bisa mibanda béda. Anjeun nyarios yén bédana data tiasa sapertos kitu moal nyugemakeun bisnis anjeun sareng anjeun moal angkat ka dinya dugi ka diulang. Dina waktos anu sami, upami anjeun lami henteu angkat ka dinya, teras ngamimitian angkat, maka data anu diperyogikeun moal langsung sayogi. Hartina, lamun urang terus buka master, lajeng cache nu aya warmed up, tapi dina replika cache lags saeutik.
Sumuhun leres. Pcache moal gaduh blok data anu anjeun pikahoyong, cache nyata moal gaduh inpormasi ngeunaan tabel anu anjeun pikahoyong, rencanana moal aya patarosan anu diparaké, moal aya nanaon.
Jeung lamun anjeun boga sababaraha jenis klaster, jeung anjeun tambahkeun hiji replica anyar aya, lajeng bari dimimitian, sagalana goréng di dinya, ie naek cache na.
Kuring meunang ide. Pendekatan anu bener bakal ngajalankeun perséntase leutik queries dina replica kahiji, nu bakal haneut nepi cache nu. Sacara kasar, urang ngagaduhan syarat yén urang kedah katinggaleun master henteu langkung ti 10 detik. Sareng kaayaan ieu henteu kalebet dina hiji gelombang, tapi lancar pikeun sababaraha klien.
Sumuhun, nambahan beurat.
Ieu mangrupakeun ide nu sae. Tapi mimitina urang kedah ngalaksanakeun shutdown ieu. Kahiji urang kudu mareuman, lajeng urang bakal mikir ngeunaan kumaha carana ngahurungkeun. Ieu mangrupikeun fitur anu saé pikeun ngaktifkeun lancar.
Nginx gaduh pilihan ieu slowly start dina klaster pikeun server. Sarta anjeunna laun naek beban.
Leres, ide anu saé, urang badé nyobian éta nalika urang ngaraosan éta.
sumber: www.habr.com