Katika ripoti yake, Andrey Borodin atakuambia jinsi walivyozingatia uzoefu wa kuongeza PgBouncer wakati wa kuunda kiboreshaji cha unganisho. , walipokuwa wakiiingiza katika uzalishaji. Kwa kuongezea, tutajadili ni kazi gani za kivuta tungependa kuona katika matoleo mapya: ni muhimu kwetu sio kukidhi mahitaji yetu tu, bali pia kukuza jamii ya watumiaji. .
Video:
Salaam wote! Jina langu ni Andrew.
Katika Yandex, ninaendeleza hifadhidata za chanzo wazi. Na leo tuna mada kuhusu miunganisho ya viunganishi vya uunganisho.
Ikiwa unajua jinsi ya kupiga simu ya unganisho kwa Kirusi, basi niambie. Ninataka sana kupata neno zuri la kiufundi ambalo linapaswa kuanzishwa katika fasihi ya kiufundi.
Mada hiyo ni ngumu sana, kwa sababu katika hifadhidata nyingi kiboreshaji cha unganisho kimejengwa ndani na hauitaji hata kujua juu yake. Bila shaka, kuna baadhi ya mipangilio kila mahali, lakini katika Postgres haifanyi kazi kwa njia hiyo. Na sambamba (kwenye HighLoad++ 2019) kuna ripoti ya Nikolai Samokhvalov kuhusu kuanzisha maswali katika Postgres. Na kama ninavyoelewa, watu walikuja hapa ambao tayari walikuwa wamesanidi maswali yao kikamilifu, na hawa ni watu ambao wanakabiliwa na shida nadra zaidi za mfumo zinazohusiana na mtandao na utumiaji wa rasilimali. Na katika baadhi ya maeneo inaweza kuwa vigumu kabisa kwa maana kwamba matatizo si dhahiri.
Yandex ina Postgres. Huduma nyingi za Yandex zinaishi katika Yandex.Cloud. Na tuna petabytes kadhaa za data ambazo hutoa angalau maombi milioni kwa sekunde katika Postgres.
Na tunatoa nguzo ya kawaida kwa huduma zote - hii ndiyo nodi kuu ya msingi ya nodi, replicas mbili za kawaida (synchronous na asynchronous), chelezo, kuongeza maombi ya kusoma kwenye nakala.
Kila nodi ya nguzo ni Postgres, ambayo, pamoja na Postgres na mifumo ya ufuatiliaji, pooler ya uunganisho pia imewekwa. Pooler ya uunganisho hutumiwa kwa uzio na kwa kusudi lake kuu.
Kusudi kuu la kiboreshaji cha unganisho ni nini?
Postgres inachukua mfano wa mchakato wakati wa kufanya kazi na hifadhidata. Hii inamaanisha kuwa muunganisho mmoja ni mchakato mmoja, nyuma ya nyuma ya Postgres. Na katika backend hii kuna mengi ya cache tofauti, ambayo ni ghali kabisa kufanya tofauti kwa uhusiano tofauti.
Kwa kuongeza, nambari ya Postgres ina safu inayoitwa procArray. Ina data ya msingi kuhusu miunganisho ya mtandao. Na karibu algorithms zote za usindikaji za procArray zina ugumu wa mstari; zinaendesha safu nzima ya miunganisho ya mtandao. Ni mzunguko wa haraka sana, lakini kwa miunganisho ya mtandao inayoingia mambo yanakuwa ghali zaidi. Na wakati mambo yanapozidi kuwa ghali, unaweza kuishia kulipa bei ya juu sana kwa miunganisho mingi ya mtandao.
Kuna njia 3 zinazowezekana:
- Kwa upande wa maombi.
- Kwa upande wa hifadhidata.
- Na kati, yaani, kila aina ya mchanganyiko.
Kwa bahati mbaya, pooler iliyojengwa kwa sasa iko chini ya maendeleo. Marafiki wetu katika PostgreSQL Professional hufanya hivi zaidi. Wakati itaonekana ni vigumu kutabiri. Na kwa kweli, tuna suluhisho mbili kwa mbunifu kuchagua. Hizi ni dimbwi la upande wa maombi na bwawa la wakala.
Dimbwi la upande wa maombi ndio njia rahisi zaidi. Na karibu viendeshi vyote vya mteja hukupa njia: wasilisha mamilioni ya miunganisho yako kwa nambari kama miunganisho kadhaa kwenye hifadhidata.
Shida inayotokea ni kwamba kwa wakati fulani unataka kuongeza hali ya nyuma, unataka kuipeleka kwa mashine nyingi za kawaida.
Kisha unatambua kuwa una kanda kadhaa zaidi za upatikanaji, vituo kadhaa vya data. Na mbinu ya kuunganisha upande wa mteja husababisha idadi kubwa zaidi. Kubwa ni karibu viunganisho 10. Hii ni makali ambayo inaweza kufanya kazi kwa kawaida.
Ikiwa tunazungumza juu ya washiriki wa wakala, basi kuna washiriki wawili ambao wanaweza kufanya mambo mengi. Wao si tu washiriki. Wao ni poolers + utendaji baridi zaidi. Hii ΠΈ .
Lakini, kwa bahati mbaya, si kila mtu anahitaji utendaji huu wa ziada. Na inaongoza kwa ukweli kwamba washiriki wanaweza kusaidia tu ujumuishaji wa kipindi, yaani, mteja mmoja anayeingia, mteja mmoja anayetoka kwenye hifadhidata.
Hii haifai sana kwa madhumuni yetu, kwa hivyo tunatumia PgBouncer, ambayo hutekelezea shughuli za pamoja, yaani, miunganisho ya seva inalinganishwa na miunganisho ya mteja kwa muda wa muamala pekee.
Na katika mzigo wetu wa kazi, hii ni kweli. Lakini kuna matatizo machache.
Matatizo huanza unapotaka kutambua kikao, kwa sababu miunganisho yako yote inayoingia ni ya ndani. Kila mtu alikuja na kitanzi na kwa namna fulani inakuwa vigumu kufuatilia kikao.
Bila shaka unaweza kutumia application_name_add_host. Hii ni njia kwa upande wa Bouncer ya kuongeza anwani ya IP kwa application_name. Lakini application_name imewekwa na muunganisho wa ziada.
Kwenye grafu hii, ambapo mstari wa njano ni maombi halisi, na ambapo mstari wa bluu ni maombi ambayo huruka kwenye hifadhidata. Na tofauti hii ni usanidi wa application_name, ambayo inahitajika tu kwa ufuatiliaji, lakini sio bure hata kidogo.
Kwa kuongeza, katika Bouncer huwezi kuweka kikomo cha hifadhi moja, yaani, idadi ya miunganisho ya hifadhidata kwa kila mtumiaji maalum, kwa hifadhidata maalum.
Je, hii inaongoza kwa nini? Una huduma iliyopakiwa iliyoandikwa katika C ++ na mahali fulani karibu na huduma ndogo kwenye nodi ambayo haifanyi chochote kibaya na hifadhidata, lakini dereva wake huenda wazimu. Inafungua miunganisho 20 na kila kitu kingine kitasubiri. Hata nambari yako ni ya kawaida.
Sisi, bila shaka, tuliandika kiraka kidogo cha Bouncer ambacho kiliongeza mpangilio huu, yaani, kuwawekea kikomo wateja kwenye bwawa.
Itawezekana kufanya hivi kwa upande wa Postgres, yaani, kupunguza majukumu katika hifadhidata kwa idadi ya miunganisho.
Lakini basi unapoteza uwezo wa kuelewa kwa nini huna miunganisho kwenye seva. PgBouncer haitupi hitilafu ya muunganisho, inarudisha habari sawa kila wakati. Na huwezi kuelewa: labda nenosiri lako limebadilika, labda hifadhidata imepotea, labda kuna kitu kibaya. Lakini hakuna utambuzi. Ikiwa kikao hakiwezi kuanzishwa, hutajua kwa nini hakiwezi kuanzishwa.
Kwa wakati fulani, unatazama grafu za maombi na kuona kwamba programu haifanyi kazi.
Angalia sehemu ya juu na uone kuwa Bouncer ina uzi mmoja. Hii ni hatua ya kugeuka katika maisha ya huduma. Unagundua kuwa ulikuwa unajiandaa kuongeza hifadhidata kwa mwaka mmoja na nusu, na unahitaji kuongeza kiboreshaji.
Tumefikia hitimisho kwamba tunahitaji PgBouncers zaidi.
Bouncer imewekewa viraka kidogo.
Na walifanya hivyo ili Bouncers kadhaa ziweze kukuzwa kwa kutumia tena bandari ya TCP. Na mfumo wa uendeshaji huhamisha moja kwa moja miunganisho inayoingia ya TCP kati yao kwa kutumia duru-robin.
Hili ni wazi kwa wateja, kumaanisha kwamba inaonekana kama una Kidhibiti kimoja, lakini una mgawanyiko wa miunganisho isiyo na kazi kati ya kuendesha Viboreshaji.
Na kwa wakati fulani unaweza kugundua kuwa hawa Wachezaji 3 kila mmoja hula msingi wake kwa 100%. Unahitaji Bouncers chache kabisa. Kwa nini?
Kwa sababu una TLS. Una muunganisho uliosimbwa kwa njia fiche. Na ukilinganisha Postgres na TLS na bila TLS, utapata kwamba idadi ya miunganisho imara inashuka kwa karibu oda mbili za ukubwa na usimbaji fiche umewezeshwa, kwa sababu kupeana mkono kwa TLS hutumia rasilimali za CPU.
Na hapo juu unaweza kuona kazi chache za kriptografia ambazo hutekelezwa wakati kuna wimbi la miunganisho inayoingia. Kwa kuwa msingi wetu unaweza kubadilisha kati ya maeneo ya upatikanaji, wimbi la miunganisho inayoingia ni hali ya kawaida kabisa. Hiyo ni, kwa sababu fulani msingi wa zamani haukupatikana, mzigo wote ulitumwa kwenye kituo kingine cha data. Watakuja wote kusalimia TLS kwa wakati mmoja.
Na idadi kubwa ya TLS handshake inaweza isimsalimie Bouncer tena, lakini itabana koo lake. Kwa sababu ya kuisha kwa muda, wimbi la miunganisho inayoingia linaweza kuwa laini. Ukijaribu tena kwenye msingi bila kurudi nyuma kwa kasi, hazitakuja tena na tena katika wimbi thabiti.
Hapa kuna mfano wa PgBouncers 16 zinazopakia cores 16 kwa 100%.
Tulikuja kwenye mteremko wa PgBouncer. Huu ndio usanidi bora zaidi ambao unaweza kupatikana kwenye mzigo wetu na Bouncer. Viboreshaji vyetu vya nje vinatumika kwa kupeana mkono kwa TCP, na Vibakuzi vya ndani vinatumika kwa kuunganisha halisi, ili kutogawanya miunganisho ya nje sana.
Katika usanidi huu, kuanzisha upya laini kunawezekana. Unaweza kuanzisha upya Bouncers hizi zote 18 moja baada ya nyingine. Lakini kudumisha usanidi kama huo ni ngumu sana. Sysadmins, DevOps, na watu ambao wanawajibika kwa seva hii hawatafurahiya sana mpangilio huu.
Inaweza kuonekana kuwa uboreshaji wetu wote unaweza kukuzwa hadi chanzo huria, lakini Bouncer haitumiki vyema. Kwa mfano, uwezo wa kuendesha PgBouncers kadhaa kwenye bandari moja ulifanyika mwezi mmoja uliopita. Kulikuwa na ombi la kuvuta kipengele hiki miaka kadhaa iliyopita.
Au mfano mmoja zaidi. Katika Postgres, unaweza kughairi ombi linaloendelea kwa kutuma siri kwa muunganisho tofauti bila uthibitishaji usio wa lazima. Lakini wateja wengine hutuma tu uwekaji upya wa TCP, i.e. wanavunja muunganisho wa mtandao. Bouncer atafanya nini? Hatafanya lolote. Itaendelea kutekeleza ombi. Ikiwa umepokea idadi kubwa ya miunganisho ambayo imeunda hifadhidata na maombi madogo, basi kukataza tu muunganisho kutoka kwa Bouncer hakutakuwa na kutosha; unahitaji pia kukamilisha maombi hayo ambayo yanaendeshwa kwenye hifadhidata.
Hili limebanwa na tatizo hili bado halijaunganishwa kwenye mkondo wa juu wa Bouncer.
Na kwa hivyo tulifikia hitimisho kwamba tunahitaji pooler yetu ya uunganisho, ambayo itaendelezwa, iliyowekwa viraka, ambayo matatizo yanaweza kusahihishwa haraka na ambayo, bila shaka, lazima yawe na nyuzi nyingi.
Tunaweka multithreading kama kazi kuu. Tunahitaji kuweza kushughulikia wimbi la miunganisho inayoingia ya TLS vizuri.
Ili kufanya hivyo, ilibidi tutengeneze maktaba tofauti inayoitwa Machinarium, ambayo imeundwa kuelezea hali ya mashine ya muunganisho wa mtandao kama nambari ya mfuatano. Ukiangalia msimbo wa chanzo wa libpq, utaona simu kadhaa changamano ambazo zinaweza kukurudishia matokeo na kusema, βNipigie baadaye. Hivi sasa nina IO kwa sasa, lakini IO ikiondoka nitakuwa na mzigo kwenye processor. Na huu ni mpango wa ngazi nyingi. Mawasiliano ya mtandao kawaida huelezewa na mashine ya serikali. Sheria nyingi kama vile "Ikiwa hapo awali nilipokea kichwa cha pakiti cha ukubwa wa N, sasa nasubiri N ka," "Ikiwa nilituma pakiti ya SYNC, sasa ninangoja pakiti iliyo na metadata ya matokeo." Matokeo yake ni msimbo mgumu, usioeleweka, kana kwamba maze yamegeuzwa kuwa scanning ya mstari. Tuliifanya ili badala ya mashine ya serikali, programu inaelezea njia kuu ya mwingiliano katika mfumo wa nambari ya kawaida ya lazima. Ni kwamba tu katika msimbo huu wa lazima unahitaji kuingiza mahali ambapo mlolongo wa utekelezaji unahitaji kuingiliwa kwa kusubiri data kutoka kwa mtandao, kupitisha muktadha wa utekelezaji kwa coroutine nyingine ( thread ya kijani ). Njia hii ni sawa na ukweli kwamba tunaandika njia inayotarajiwa zaidi kwenye maze mfululizo, na kisha kuongeza matawi ndani yake.
Kwa hivyo, tuna thread moja ambayo TCP inakubali na mzunguko-robin hupitisha muunganisho wa TPC kwa wafanyikazi wengi.
Katika kesi hii, kila muunganisho wa mteja daima huendesha kwenye processor moja. Na hii inakuwezesha kuifanya cache-kirafiki.
Na kwa kuongeza, tumeboresha kidogo mkusanyiko wa pakiti ndogo kwenye pakiti moja kubwa ili kupunguza mrundikano wa TCP wa mfumo.
Kwa kuongezea, tumeboresha uunganishaji wa shughuli kwa maana kwamba Odyssey, inaposanidiwa, inaweza kutuma CANCEL na ROLLBACK katika tukio la kushindwa kwa muunganisho wa mtandao, yaani, ikiwa hakuna mtu anayesubiri ombi, Odyssey itaambia hifadhidata isijaribu kutimiza ombi ambalo linaweza kupoteza rasilimali za thamani.
Na inapowezekana, tunaweka miunganisho kwa mteja sawa. Hii inaepuka kusakinisha tena application_name_add_host. Ikiwa hii inawezekana, basi sio lazima kuweka upya vigezo vinavyohitajika kwa uchunguzi.
Tunafanya kazi kwa maslahi ya Yandex.Cloud. Na ikiwa unatumia PostgreSQL iliyosimamiwa na kuwa na pooler ya uunganisho iliyosakinishwa, unaweza kuunda replication ya kimantiki kwa nje, yaani, tuache, ikiwa unataka, kwa kutumia urudufishaji wa kimantiki. Kiboreshaji hakitatoa mtiririko wa kimantiki wa urudufishaji nje.
Huu ni mfano wa kuanzisha urudufishaji wa kimantiki.
Kwa kuongezea, tuna msaada kwa urudufishaji wa nje. Katika Wingu, bila shaka, hii haiwezekani, kwa sababu basi nguzo itakupa habari nyingi kuhusu yenyewe. Lakini katika usakinishaji wako, ikiwa unahitaji urudufishaji wa kimwili kupitia kiboreshaji cha unganisho huko Odyssey, hii inawezekana.
Odyssey ina ufuatiliaji unaolingana kikamilifu na PgBouncer. Tunayo console sawa ambayo inaendesha karibu amri zote sawa. Ikiwa kitu kinakosekana, tuma ombi la kuvuta, au angalau suala kwenye GitHub, na tutakamilisha amri zinazohitajika. Lakini tayari tunayo utendaji kuu wa kiweko cha PgBouncer.
Na, bila shaka, tuna makosa ya usambazaji. Tutarudisha kosa lililoripotiwa na hifadhidata. Utapokea habari kuhusu kwa nini haujajumuishwa kwenye hifadhidata, na sio tu kwamba haujajumuishwa ndani yake.
Kipengele hiki kimezimwa ikiwa utahitaji uoanifu wa 100% na PgBouncer. Tunaweza kuishi kwa njia sawa na Bouncer, ili tu kuwa katika upande salama.
Maendeleo
Maneno machache kuhusu msimbo wa chanzo wa Odyssey.
Kwa mfano, kuna amri za "Sitisha / Endelea". Kawaida hutumiwa kusasisha hifadhidata. Ikiwa unahitaji kusasisha Postgres, basi unaweza kuisimamisha kwenye kiboreshaji cha unganisho, fanya pg_upgrade, kisha uendelee tena. Na kutoka kwa upande wa mteja itaonekana kana kwamba hifadhidata ilikuwa ikipungua tu. Utendaji huu uliletwa kwetu na watu kutoka kwa jamii. Bado hajagandishwa, lakini hivi karibuni kila kitu kitakuwa. (Tayari imeganda)
- tayari waliohifadhiwa
Kwa kuongeza, moja ya vipengele vipya katika PgBouncer ni usaidizi wa Uthibitishaji wa SCRAM, ambayo pia ililetwa kwetu na mtu ambaye hafanyi kazi katika Yandex.Cloud. Zote mbili ni utendaji mgumu na muhimu.
Kwa hivyo, ningependa kukuambia ni nini Odyssey imeundwa, ikiwa unataka pia kuandika nambari ndogo sasa.
Una msingi wa chanzo cha Odyssey, ambao unategemea maktaba kuu mbili. Maktaba ya Kiwi ni utekelezaji wa itifaki ya ujumbe wa Postgres. Hiyo ni, proto 3 asili ya Postgres ni ujumbe wa kawaida ambao ncha za mbele na za nyuma zinaweza kubadilishana. Zinatekelezwa katika maktaba ya Kiwi.
Maktaba ya Machinarium ni maktaba ya utekelezaji wa nyuzi. Sehemu ndogo ya Machinarium hii imeandikwa kwa lugha ya kusanyiko. Lakini usiogope, kuna mistari 15 tu.
Usanifu wa Odyssey. Kuna mashine kuu ambayo coroutines zinaendesha. Mashine hii hutekeleza kukubali miunganisho inayoingia ya TCP na kuisambaza kati ya wafanyikazi.
Kidhibiti cha wateja kadhaa kinaweza kufanya kazi ndani ya mfanyakazi mmoja. Uzi kuu pia huendesha koni na uchakataji wa kazi za crone ili kufuta miunganisho ambayo haihitajiki tena kwenye bwawa.
Odyssey inajaribiwa kwa kutumia darasa la kawaida la majaribio la Postgres. Tunaendesha ukaguzi wa kusakinisha tu kupitia Bouncer na kupitia Odyssey, tunapata div batili. Kuna majaribio kadhaa yanayohusiana na umbizo la tarehe ambayo hayapiti sawa kabisa katika Bouncer na Odyssey.
Kwa kuongeza, kuna madereva wengi ambao wana upimaji wao wenyewe. Na tunatumia vipimo vyao kujaribu Odyssey.
Kwa kuongezea, kwa sababu ya usanidi wetu wa mteremko, lazima tujaribu vifurushi anuwai: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey ili kuwa na uhakika kwamba ikiwa Odyssey iliishia katika sehemu yoyote kwenye cascade, pia bado inafanya kazi. kama tunavyotarajia.
Uvujaji
Tunatumia Odyssey katika uzalishaji. Na haitakuwa sawa ikiwa ningesema kwamba kila kitu kinafanya kazi tu. Hapana, yaani, ndiyo, lakini si mara zote. Kwa mfano, katika uzalishaji kila kitu kilifanya kazi tu, basi marafiki zetu kutoka PostgreSQL Professional walikuja na kusema kwamba tuna uvujaji wa kumbukumbu. Walikuwa kweli, tuliwasahihisha. Lakini ilikuwa rahisi.
Kisha tukagundua kuwa kiboreshaji cha muunganisho kina miunganisho inayoingia ya TLS na miunganisho ya TLS inayotoka. Na miunganisho inahitaji vyeti vya mteja na vyeti vya seva.
Vyeti vya seva ya Bouncer na Odyssey vinasomwa tena na pcache zao, lakini vyeti vya mteja havihitaji kusomwa tena kutoka kwa kompyuta, kwa sababu Odyssey yetu inayoweza kubadilika hatimaye itaingia kwenye utendaji wa mfumo wa kusoma cheti hiki. Hili lilikuja kama mshangao kwetu, kwa sababu haikumchukua muda mrefu kupinga. Mwanzoni iliongezeka kwa mstari, lakini baada ya miunganisho 20 inayoingia kwa wakati mmoja shida hii ilijidhihirisha.
Mbinu ya Uthibitishaji Inayoweza Kuchomekwa ni uwezo wa kuthibitisha kwa kutumia zana za Lunux zilizojengewa ndani. Katika PgBouncer inatekelezwa kwa namna ambayo kuna thread tofauti ya kusubiri jibu kutoka kwa PAM na kuna thread kuu ya PgBouncer inayohudumia muunganisho wa sasa na inaweza kuwauliza waishi kwenye thread ya PAM.
Hatukutekeleza hili kwa sababu moja rahisi. Tuna nyuzi nyingi. Kwa nini tunahitaji hili?
Hii inaweza hatimaye kuleta matatizo kwa kuwa ikiwa una uthibitishaji wa PAM na uthibitishaji usio wa PAM, basi wimbi kubwa la uthibitishaji wa PAM linaweza kuchelewesha kwa kiasi kikubwa uthibitishaji usio wa PAM. Hii ni moja ya mambo ambayo hatujarekebisha. Lakini ikiwa unataka kurekebisha, unaweza kufanya hivyo.
Njia nyingine ilikuwa kwamba tuna uzi mmoja ambao unakubali miunganisho yote inayoingia. Na kisha huhamishiwa kwenye bwawa la wafanyikazi, ambapo kupeana mkono kwa TLS kutafanyika.
Mstari wa chini, ikiwa una wimbi thabiti la miunganisho 20 ya mtandao, yote yatakubaliwa. Na kwa upande wa mteja libpq itaanza kuripoti kuisha. Kwa chaguo-msingi inaonekana kuwa sekunde 000.
Ikiwa wote hawawezi kuingia kwenye hifadhidata kwa wakati mmoja, basi hawawezi kuingia kwenye hifadhidata, kwa sababu yote haya yanaweza kufunikwa na jaribio lisilo la kielelezo.
Tulifikia hitimisho kwamba tulinakili mpango kutoka kwa PgBouncer hapa kwa ukweli kwamba tumepunguza idadi ya miunganisho ya TCP ambayo tunakubali.
Ikiwa tunaona kwamba tunakubali miunganisho, lakini hatimaye hawana muda wa kupeana mkono, tunawaweka kwenye foleni ili wasipoteze rasilimali za CPU. Hii inaongoza kwa ukweli kwamba kupeana mkono kwa wakati mmoja kunaweza kusifanyike kwa viunganisho vyote vilivyofika. Lakini angalau mtu ataingia kwenye hifadhidata, hata ikiwa mzigo ni mzito sana.
Roadmap
Ungependa kuona nini katika siku zijazo huko Odyssey? Je, tuko tayari kujiendeleza nini na tunatarajia nini kutoka kwa jamii?
Kuanzia Agosti 2019.
Hivi ndivyo ramani ya barabara ya Odyssey ilionekana mnamo Agosti:
- Tulitaka uthibitishaji wa SCRAM na PAM.
- Tulitaka kusambaza maombi ya kusoma kwenye hali ya kusubiri.
- Ningependa kuanzisha upya mtandaoni.
- Na uwezo wa kusitisha kwenye seva.
Nusu ya ramani hii ya barabara imekamilika, na sio sisi. Na hii ni nzuri. Kwa hivyo wacha tujadili kile kilichobaki na kuongeza zaidi.
? Tuna nakala ambazo zitapasha joto hewa bila kutekeleza maombi. Tunawahitaji watoe kushindwa na ubadilishaji. Katika kesi ya shida katika moja ya vituo vya data, ningependa kuzichukua kwa kazi muhimu. Kwa sababu hatuwezi kusanidi vichakataji sawa vya kati, kumbukumbu sawa tofauti, kwa sababu vinginevyo replication haitafanya kazi.
Kimsingi, katika Postgres, kuanzia 10, inawezekana kutaja session_attrs wakati wa kuunganisha. Unaweza kuorodhesha wapangishi wote wa hifadhidata kwenye muunganisho na kusema kwa nini unaenda kwenye hifadhidata: andika au soma pekee. Na dereva mwenyewe atachagua mwenyeji wa kwanza katika orodha ambayo anapenda zaidi, ambayo inatimiza mahitaji ya session_attrs.
Lakini shida na njia hii ni kwamba haidhibiti lagi ya kurudia tena. Unaweza kuwa na nakala ambayo imesalia nyuma kwa muda usiokubalika kwa huduma yako. Ili kuwezesha utekelezaji kamili wa hoja zilizosomwa kwenye nakala, tunahitaji kuunga mkono uwezo wa Odyssey wa kutoendesha wakati hauwezi kusomeka.
Odyssey lazima aende kwenye hifadhidata mara kwa mara na aombe umbali wa kurudia kutoka kwa msingi. Na ikiwa imefikia thamani ya kikomo, usiruhusu maombi mapya kwenye hifadhidata, mwambie mteja kwamba anahitaji kuanzisha tena miunganisho na, ikiwezekana, chagua mwenyeji mwingine kutekeleza maombi. Hii itaruhusu hifadhidata kurejesha haraka uzembe wa urudufishaji na kurudi tena ili kujibu ombi.
Ni vigumu kutoa muda wa utekelezaji, kwa sababu ni chanzo wazi. Lakini, natumai, sio miaka 2,5 kama wenzangu kutoka PgBouncer. Hiki ndicho kipengele ambacho ningependa kuona kwenye Odyssey.
. Sasa unaweza kuunda taarifa iliyoandaliwa kwa njia mbili. Kwanza, unaweza kutekeleza amri ya SQL, ambayo ni "tayari". Ili kuelewa amri hii ya SQL, tunahitaji kujifunza kuelewa SQL kwa upande wa Bouncer. Hii inaweza kuwa ya kupita kiasi, kwa sababu ni ya kupita kiasi, kwani tunahitaji kichanganuzi kizima. Hatuwezi kuchanganua kila amri ya SQL.
Lakini kuna taarifa iliyoandaliwa katika kiwango cha itifaki ya ujumbe kwenye proto3. Na hapa ndipo mahali ambapo taarifa kwamba taarifa iliyotayarishwa inaundwa inakuja katika muundo uliopangwa. Na tunaweza kuunga mkono ufahamu kwamba kwenye unganisho fulani la seva mteja aliuliza kuunda taarifa zilizotayarishwa. Na hata kama muamala umefungwa, bado tunahitaji kudumisha muunganisho kati ya seva na mteja.
Lakini hapa kuna tofauti katika mazungumzo, kwa sababu mtu anasema kwamba unahitaji kuelewa ni aina gani ya taarifa zilizoandaliwa ambazo mteja aliunda na kushiriki uunganisho wa seva kati ya wateja wote ambao waliunda muunganisho huu wa seva, i.e., ambaye aliunda taarifa kama hiyo iliyoandaliwa.
Andres Freund alisema kwamba ikiwa mteja anakuja kwako ambaye tayari ameunda taarifa kama hiyo iliyoandaliwa kwenye unganisho lingine la seva, basi umtengenezee. Lakini inaonekana ni makosa kidogo kutekeleza maswali kwenye hifadhidata badala ya mteja, lakini kwa mtazamo wa msanidi programu ambaye anaandika itifaki ya kuingiliana na hifadhidata, itakuwa rahisi ikiwa atapewa tu unganisho la mtandao ambalo kuna swala kama hilo lililoandaliwa.
Na kipengele kimoja zaidi ambacho tunahitaji kutekeleza. Sasa tuna ufuatiliaji unaoendana na PgBouncer. Tunaweza kurudisha wastani wa muda wa utekelezaji wa hoja. Lakini wakati wa wastani ni wastani wa joto katika hospitali: baadhi ni baridi, baadhi ni joto - kwa wastani, kila mtu ana afya. Sio kweli.
Tunahitaji kutekeleza usaidizi kwa asilimia ambayo inaweza kuonyesha kuwa kuna maswali ya polepole ambayo yanapoteza rasilimali na kufanya ufuatiliaji kukubalika zaidi.
Jambo muhimu zaidi ni kwamba nataka toleo la 1.0 (Toleo la 1.1 tayari limetolewa). Ukweli ni kwamba Odyssey sasa iko katika toleo la 1.0rc, yaani, mgombea wa kutolewa. Na shida zote ambazo niliorodhesha zilirekebishwa na toleo lile lile, isipokuwa kwa uvujaji wa kumbukumbu.
Toleo la 1.0 litamaanisha nini kwetu? Tunasambaza Odyssey kwa misingi yetu. Tayari inaendeshwa kwenye hifadhidata zetu, lakini inapofikia hatua ya maombi 1 kwa sekunde, basi tunaweza kusema kwamba hili ni toleo la kutolewa na hili ni toleo ambalo linaweza kuitwa 000.
Watu kadhaa katika jumuiya wameuliza kwamba toleo la 1.0 ni pamoja na kusitisha na SCRAM. Lakini hii itamaanisha kuwa tutahitaji kusambaza toleo linalofuata kwa toleo la umma, kwa sababu hakuna SCRAM wala pause bado zimeuawa. Lakini, uwezekano mkubwa, suala hili litatatuliwa haraka sana.
Nasubiri ombi lako la kuvuta. Ningependa pia kusikia una matatizo gani na Bouncer. Hebu tuyajadili. Labda tunaweza kutekeleza baadhi ya vipengele unavyohitaji.
Huu ndio mwisho wa sehemu yangu, ningependa kukusikiliza. Asante!
maswali
Nikiweka application_name yangu mwenyewe, je, itasambazwa kwa njia ipasavyo, ikiwa ni pamoja na kushiriki katika shughuli za Odyssey?
Odyssey au Bouncer?
Katika Odyssey. Katika Bouncer inatupwa.
Tutafanya seti.
Na ikiwa muunganisho wangu wa kweli utaruka kwenye viunganisho vingine, je, itapitishwa?
Tutafanya seti ya vigezo vyote vilivyoorodheshwa kwenye orodha. Siwezi kujua kama application_name iko kwenye orodha hii. Nadhani nilimwona huko. Tutaweka vigezo vyote sawa. Kwa ombi moja, seti itafanya kila kitu ambacho kiliwekwa na mteja wakati wa kuanza.
Asante, Andrey, kwa ripoti! Ripoti nzuri! Ninafurahi kuwa Odyssey inakua haraka na haraka kila dakika. Nataka kuendelea hivi. Tayari tumekuuliza uwe na muunganisho wa vyanzo vingi vya data ili Odyssey iweze kuunganisha kwenye hifadhidata tofauti wakati huo huo, yaani, mtumwa mkuu, na kisha kuunganisha kiotomatiki kwa bwana mpya baada ya kushindwa.
Ndiyo, ninaonekana kukumbuka mjadala huu. Sasa kuna hifadhi kadhaa. Lakini hakuna ubadilishaji kati yao. Kwa upande wetu, lazima tuchague seva kuwa bado iko hai na tuelewe kuwa kushindwa kumetokea, nani atapiga simu pg_recovery. Nina njia ya kawaida ya kuelewa kwamba hatukuja kwa bwana. Na tunapaswa kuelewa kwa namna fulani kutokana na makosa au nini? Hiyo ni, wazo hilo linavutia, linajadiliwa. Andika maoni zaidi. Ikiwa una wafanyikazi wanaojua C, basi hiyo ni nzuri.
Suala la kuongeza nakala katika nakala zote pia linatuvutia, kwa sababu tunataka kufanya upitishaji wa makundi yaliyojirudia iwe rahisi iwezekanavyo kwa wasanidi programu. Lakini hapa ningependa maoni zaidi, i.e. jinsi ya kuifanya, jinsi ya kuifanya vizuri.
Swali pia ni kuhusu nakala. Inageuka kuwa una bwana na replicas kadhaa. Na ni wazi kwamba huenda kwenye replica mara chache kuliko kwa bwana kwa viunganisho, kwa sababu wanaweza kuwa na tofauti. Ulisema kwamba tofauti katika data inaweza kuwa kwamba haitakidhi biashara yako na hautaenda huko hadi itakaporudiwa. Wakati huo huo, ikiwa haukuenda huko kwa muda mrefu, na kisha kuanza kwenda, basi data inayohitajika haitapatikana mara moja. Hiyo ni, ikiwa tunaenda kwa bwana kila wakati, basi kashe huko huwashwa, lakini kwenye replica cache inakaa kidogo.
Ndiyo ni kweli. Pcache haitakuwa na vizuizi vya data unavyotaka, cache halisi haitakuwa na habari kuhusu meza unayotaka, mipango haitakuwa na maswali yaliyochanganuliwa, hakutakuwa na chochote.
Na wakati una aina fulani ya nguzo, na kuongeza replica mpya huko, basi wakati inapoanza, kila kitu ni mbaya ndani yake, yaani, huongeza cache yake.
Nilipata wazo. Njia sahihi itakuwa kuendesha asilimia ndogo ya maswali kwenye nakala kwanza, ambayo ingeongeza kache. Kwa kusema, tuna sharti kwamba lazima tubaki nyuma ya bwana kwa si zaidi ya sekunde 10. Na hali hii haijajumuishwa katika wimbi moja, lakini vizuri kwa wateja wengine.
Ndio, ongeza uzito.
Hili ni wazo zuri. Lakini kwanza tunahitaji kutekeleza shutdown hii. Kwanza tunahitaji kuzima, na kisha tutafikiri jinsi ya kugeuka. Hiki ni kipengele kizuri cha kuwezesha vizuri.
Nginx ina chaguo hili slowly start katika kundi la seva. Na hatua kwa hatua huongeza mzigo.
Ndiyo, wazo zuri, tutalijaribu tutakapolifikia.
Chanzo: mapenzi.com