En sia raporto, Andrey Borodin rakontos al vi, kiel ili konsideris la sperton de grimpi PgBouncer dum desegnado de la konekto-pooler. , ĉar ili elvolvis ĝin en produktadon. Krome, ni diskutos kiajn funkciojn de la tirilo ni ŝatus vidi en novaj versioj: gravas por ni ne nur renkonti niajn bezonojn, sed evoluigi la uzantkomunumon. .
Video:
Saluton al ĉiuj! Mi nomiĝas Andreo.
Ĉe Yandex, mi disvolvas malfermfontajn datumbazojn. Kaj hodiaŭ ni havas temon pri konekto-pooler-konektoj.
Se vi scias kiel nomi konekton pooler en la rusa, do diru al mi. Mi vere volas trovi bonan teknikan terminon, kiu devus esti establita en la teknika literaturo.
La temo estas sufiĉe komplika, ĉar en multaj datumbazoj la konektokolektilo estas enkonstruita kaj vi eĉ ne bezonas scii pri ĝi. Kompreneble, estas iuj agordoj ĉie, sed en Postgres ĝi ne funkcias tiel. Kaj paralele (ĉe HighLoad++ 2019) estas raporto de Nikolaj Samokhvalov pri starigo de demandoj en Postgres. Kaj kiel mi komprenas, venis ĉi tien homoj, kiuj jam perfekte agordis siajn demandojn, kaj ĉi tiuj estas homoj, kiuj alfrontas pli maloftajn sistemajn problemojn rilate al la reto kaj utiligo de rimedoj. Kaj kelkloke povus esti sufiĉe malfacila en la senco, ke la problemoj ne estas evidentaj.
Yandex havas Postgres. Multaj Yandex-servoj vivas en Yandex.Cloud. Kaj ni havas plurajn petabajtojn da datumoj, kiuj generas almenaŭ milionon da petoj sekundo en Postgres.
Kaj ni provizas sufiĉe norman grapolon por ĉiuj servoj - ĉi tio estas la ĉefa primara nodo de la nodo, la kutimaj du kopioj (sinkronaj kaj nesinkronaj), sekurkopioj, skalo de legaj petoj sur la kopio.
Ĉiu clusternodo estas Postgres, sur kiu, krom Postgres kaj monitoraj sistemoj, ankaŭ estas instalita konekto-komunilo. Konekto-pooler estas uzata por skermado kaj por ĝia ĉefa celo.
Kio estas la ĉefa celo de konekto-pooler?
Postgres adoptas procezmodelon kiam laboras kun datumbazo. Ĉi tio signifas, ke unu konekto estas unu procezo, unu Postgres-backend. Kaj en ĉi tiu backend estas multaj malsamaj kaŝmemoroj, kiuj estas sufiĉe multekostaj por fari malsamajn por malsamaj konektoj.
Aldone, Postgres-kodo havas tabelon nomitan procArray. Ĝi enhavas bazajn datumojn pri retkonektoj. Kaj preskaŭ ĉiuj procArray-pretigaj algoritmoj havas linearan kompleksecon; ili trairas la tutan aron de retkonektoj. Ĝi estas sufiĉe rapida ciklo, sed kun pli da envenantaj retaj konektoj aferoj fariĝas iom pli multekostaj. Kaj kiam aferoj iom pli multekostas, vi povas fini pagi tre altan prezon por multaj retaj konektoj.
Estas 3 eblaj aliroj:
- Sur la aplika flanko.
- Sur la datumbaza flanko.
- Kaj inter, tio estas, ĉiaj kombinaĵoj.
Bedaŭrinde, la enkonstruita pooler estas nuntempe evoluanta. Niaj amikoj ĉe PostgreSQL Professional faras ĉi tion plejparte. Kiam ĝi aperos estas malfacile antaŭdiri. Kaj fakte, ni havas du solvojn por ke la arkitekto elektu. Ĉi tiuj estas aplikaĵ-flanka naĝejo kaj prokura naĝejo.
Aplikflanka naĝejo estas la plej facila maniero. Kaj preskaŭ ĉiuj klientŝoforoj provizas al vi manieron: prezentu milionojn da viaj konektoj en kodo kiel kelkajn dekojn da konektoj al la datumbazo.
La problemo, kiu ekestas, estas, ke ĉe certa punkto vi volas skali la backend, vi volas disfaldi ĝin al multaj virtualaj maŝinoj.
Tiam vi rimarkas, ke vi havas plurajn pliajn havebleczonojn, plurajn datumcentrojn. Kaj la klientflanka kunigo aliro kondukas al pli grandaj nombroj. Grandaj estas proksimume 10 konektoj. Ĉi tiu estas la rando, kiu povas funkcii normale.
Se ni parolas pri prokuraj poolers, tiam estas du poolers, kiuj povas fari multajn aferojn. Ili ne estas nur poolers. Ili estas poolers + pli bonega funkcieco. Ĉi tio и .
Sed, bedaŭrinde, ne ĉiuj bezonas ĉi tiun aldonan funkcion. Kaj ĝi kondukas al tio, ke poolers nur subtenas kunsidon de sesio, t.e. unu envenanta kliento, unu eliranta kliento al la datumbazo.
Ĉi tio ne tre taŭgas por niaj celoj, do ni uzas PgBouncer, kiu efektivigas transakcian kunigon, t.e. servilaj konektoj kongruas kun klientkonektoj nur dum la daŭro de la transakcio.
Kaj en nia laborŝarĝo, ĉi tio estas vera. Sed estas kelkaj problemoj.
La problemoj komenciĝas kiam vi volas diagnozi seancon, ĉar ĉiuj viaj envenantaj konektoj estas lokaj. Ĉiuj venis kun loopback kaj iel fariĝas malfacile spuri la sesion.
Kompreneble vi povas uzi application_name_add_host. Ĉi tio estas maniero ĉe Bouncer por aldoni IP-adreson al application_name. Sed aplikaĵo_nomo estas agordita de plia konekto.
Sur ĉi tiu grafikaĵo, kie la flava linio estas realaj petoj, kaj kie la blua linio estas petoj, kiuj flugas en la datumbazon. Kaj ĉi tiu diferenco estas ĝuste la instalado de application_name, kiu estas bezonata nur por spurado, sed ĝi tute ne estas senpaga.
Krome, en Bouncer vi ne povas limigi unu naĝejon, t.e. la nombron da datumbazaj konektoj por specifa uzanto, per specifa datumbazo.
Al kio ĉi tio kondukas? Vi havas ŝarĝitan servon skribitan en C++ kaj ie proksime malgrandan servon sur nodo, kiu faras nenion teruran kun la datumbazo, sed ĝia ŝoforo freneziĝas. Ĝi malfermas 20 konektojn kaj ĉio alia atendos. Eĉ via kodo estas normala.
Ni, kompreneble, skribis malgrandan peceton por Bouncer, kiu aldonis ĉi tiun agordon, t.e. limigante klientojn al la naĝejo.
Eblus fari tion ĉe la flanko de Postgres, t.e. limigi la rolojn en la datumbazo per la nombro da konektoj.
Sed tiam vi perdas la kapablon kompreni kial vi ne havas konektojn al la servilo. PgBouncer ne ĵetas konektan eraron, ĝi ĉiam resendas la saman informon. Kaj vi ne povas kompreni: eble via pasvorto ŝanĝiĝis, eble la datumbazo ĵus perdiĝis, eble io misas. Sed ne estas diagnozo. Se sesio ne povas esti establita, vi ne scios kial ĝi ne povas esti establita.
Je certa punkto, vi rigardas la aplikajn grafikojn kaj vidas, ke la aplikaĵo ne funkcias.
Rigardu la supron kaj vidu, ke Bouncer estas unufadena. Ĉi tio estas turnopunkto en la vivo de la servo. Vi rimarkas, ke vi prepariĝis por skali la datumbazon en jaro kaj duono, kaj vi devas skali la pooler.
Ni alvenis al la konkludo, ke ni bezonas pli da PgBouncers.
Bouncer estis iom flikita.
Kaj ili faris ĝin tiel ke pluraj Bouncers povus esti levitaj per reuzo de la TCP-haveno. Kaj la operaciumo aŭtomate transdonas envenantajn TCP-ligojn inter ili uzante cirkuladon.
Ĉi tio estas travidebla por klientoj, tio signifas, ke ĝi aspektas kiel vi havas unu Bouncer, sed vi havas fragmentiĝon de neaktivaj ligoj inter kurantaj Bouncers.
Kaj en certa momento vi eble rimarkos, ke ĉi tiuj 3 Bouncers ĉiu manĝas sian kernon je 100%. Vi bezonas sufiĉe da Bouncers. Kial?
Ĉar vi havas TLS. Vi havas ĉifritan konekton. Kaj se vi komparu Postgres kun kaj sen TLS, vi trovos, ke la nombro da establitaj konektoj malpliiĝas je preskaŭ du grandordoj kun ĉifrado ebligita, ĉar la TLS-manpremo konsumas CPU-resursojn.
Kaj ĉe la supro vi povas vidi sufiĉe da kriptografiaj funkcioj, kiuj estas ekzekutitaj kiam estas ondo de envenantaj ligoj. Ĉar nia ĉefa povas ŝanĝi inter haveblecaj zonoj, ondo de alvenantaj ligoj estas sufiĉe tipa situacio. Tio estas, ial la malnova primara estis neatingebla, la tuta ŝarĝo estis sendita al alia datumcentro. Ili ĉiuj venos por saluti TLS samtempe.
Kaj granda nombro da TLS-manpremo eble ne plu salutos Bouncer, sed premos lian gorĝon. Pro la tempodaŭro, la ondo de alvenantaj ligoj povas iĝi nemalseketigita. Se vi reprovas al la bazo sen eksponenta retroiro, ili ne venos denove kaj denove en kohera ondo.
Jen ekzemplo de 16 PgBouncers, kiuj ŝarĝas 16 kernojn je 100%.
Ni venis al la kaskado PgBouncer. Ĉi tiu estas la plej bona agordo, kiu povas esti atingita sur nia ŝarĝo kun Bouncer. Niaj eksteraj Bouncers estas uzataj por TCP-manpremo, kaj internaj Bouncers estas uzataj por reala kunigo, por ne tro fragmenti eksterajn konektojn.
En ĉi tiu agordo, glata rekomenco eblas. Vi povas rekomenci ĉiujn ĉi tiujn 18 Bouncers unu post la alia. Sed konservi tian agordon estas sufiĉe malfacila. Administrantoj de sistemoj, DevOps kaj homoj, kiuj efektive respondecas pri ĉi tiu servilo, ne estos tre feliĉaj pri ĉi tiu aranĝo.
Ŝajnus, ke ĉiuj niaj plibonigoj povas esti promociitaj al malferma fonto, sed Bouncer ne estas tre bone subtenata. Ekzemple, la kapablo funkciigi plurajn PgBouncers sur unu haveno estis farita antaŭ monato. Ekzistis tirpeto kun ĉi tiu funkcio antaŭ pluraj jaroj.
Aŭ unu plian ekzemplon. En Postgres, vi povas nuligi peton en progreso sendante la sekreton al malsama konekto sen nenecesa aŭtentigo. Sed iuj klientoj simple sendas TCP-restarigon, t.e. ili rompas la retan konekton. Kion faros Bouncer? Li nenion faros. Ĝi daŭre plenumos la peton. Se vi ricevis grandegan nombron da konektoj, kiuj kreis datumbazon kun malgrandaj petoj, tiam simple malkonekti la konekton de Bouncer ne sufiĉos; vi ankaŭ devas plenumi tiujn petojn, kiuj funkcias en la datumbazo.
Ĉi tio estis flikita kaj ĉi tiu problemo ankoraŭ ne estis kunfandita en la kontraŭfluon de Bouncer.
Kaj do ni venis al la konkludo, ke ni bezonas nian propran konekton-pooler, kiu estos evoluigita, flikita, en kiu problemoj povas esti rapide korektitaj kaj kiu, kompreneble, devas esti multfadena.
Ni starigas multfadenadon kiel ĉefan taskon. Ni devas povi bone trakti la ondon de alvenantaj TLS-konektoj.
Por fari tion, ni devis evoluigi apartan bibliotekon nomitan Machinarium, kiu estas dizajnita por priskribi la maŝinajn statojn de retkonekto kiel sinsekvan kodon. Se vi rigardas la fontkodon de libpq, vi vidos kelkajn sufiĉe kompleksajn vokojn, kiuj povas redoni al vi rezulton kaj diri: "Voku min poste. Ĝuste nun mi havas IO nuntempe, sed kiam la IO foriros, mi havos ŝarĝon sur la procesoro." Kaj ĉi tio estas plurnivela skemo. Reta komunikado estas kutime priskribita de ŝtatmaŝino. Multaj reguloj kiel "Se mi antaŭe ricevis pakaĵetan kaplinion de grandeco N, nun mi atendas N bajtojn", "Se mi sendis SYNC-pakaĵon, nun mi atendas pakaĵeton kun rezultmetadatenoj." La rezulto estas sufiĉe malfacila, kontraŭintuicia kodo, kvazaŭ la labirinto estus konvertita al linio-skanado. Ni faris ĝin tiel, ke anstataŭ ŝtatmaŝino, la programisto priskribas la ĉefan vojon de interago en la formo de ordinara imperativa kodo. Nur en ĉi tiu imperativa kodo vi devas enmeti lokojn, kie la ekzekutsekvenco devas esti interrompita atendante datumojn de la reto, pasante la ekzekutkuntekston al alia korutino (verda fadeno). Ĉi tiu aliro similas al tio, ke ni skribas la plej atenditan vojon en la labirinto en vico, kaj poste aldonas branĉojn al ĝi.
Kiel rezulto, ni havas unu fadenon kiu TCP akceptas kaj cirkla-subskribolista pasas la TPC-konekton al multaj laboristoj.
En ĉi tiu kazo, ĉiu klienta konekto ĉiam funkcias per unu procesoro. Kaj ĉi tio permesas vin fari ĝin kaŝmemor-amika.
Kaj krome, ni iomete plibonigis la kolekton de malgrandaj pakaĵoj en unu grandan pakaĵon por malpezigi la sisteman TCP-stakon.
Krome, ni plibonigis transakcian kunigon en la senco, ke Odyssey, kiam agordita, povas sendi CANCEL kaj ROLLBACK en la okazo de malsukceso de retkonekto, t.e. se neniu atendas peton, Odyssey diros al la datumbazo ne provi. plenumi la peton, kiu povas malŝpari altvalorajn rimedojn.
Kaj kiam ajn eblas, ni konservas rilatojn al la sama kliento. Ĉi tio evitas devi reinstali application_name_add_host. Se ĉi tio eblas, tiam ni ne devas aldone restarigi la parametrojn necesajn por diagnozo.
Ni laboras en la interesoj de Yandex.Cloud. Kaj se vi uzas administritan PostgreSQL kaj havas konekton-kolektilon instalita, vi povas krei logikan reproduktadon eksteren, t.e. lasu nin, se vi volas, uzante logikan reproduktadon. Bouncer ne liberigos la logikan reproduktan fluon ekstere.
Ĉi tio estas ekzemplo de agordo de logika reproduktado.
Krome, ni havas subtenon por fizika reproduktado eksteren. En la Nubo, kompreneble, tio estas neebla, ĉar tiam la areto donos al vi tro da informoj pri si mem. Sed en viaj instalaĵoj, se vi bezonas fizikan reproduktadon per la konekto-kolektilo en Odiseado, tio eblas.
Odyssey havas plene kongruan monitoradon kun PgBouncer. Ni havas la saman konzolon, kiu funkcias preskaŭ ĉiujn samajn komandojn. Se io mankas, sendu tiran peton, aŭ almenaŭ problemon ĉe GitHub, kaj ni kompletigos la necesajn komandojn. Sed ni jam havas la ĉefan funkcion de la konzolo PgBouncer.
Kaj, kompreneble, ni havas eraran plusendon. Ni resendos la eraron raportitan de la datumbazo. Vi ricevos informojn pri kial vi ne estas inkluzivita en la datumbazo, kaj ne nur ke vi ne estas inkluzivita en ĝi.
Ĉi tiu funkcio estas malŝaltita se vi bezonas 100% kongruon kun PgBouncer. Ni povas konduti same kiel Bouncer, nur por esti sur la sekura flanko.
Disvolviĝo
Kelkaj vortoj pri la fontkodo Odyssey.
Ekzemple, estas "Paŭzo / Rekomenco" komandoj. Ili estas kutime uzataj por ĝisdatigi la datumbazon. Se vi bezonas ĝisdatigi Postgres, tiam vi povas paŭzi ĝin en la konekto-kolektilo, faru pg_upgrade, poste rekomenci. Kaj de la flanko de la kliento ĝi aspektos kvazaŭ la datumbazo simple malrapidiĝis. Ĉi tiu funkcio estis alportita al ni de homoj de la komunumo. Ŝi ankoraŭ ne estas frostigita, sed baldaŭ ĉio estos. (Jam frostigita)
- jam frostigita
Krome, unu el la novaj funkcioj en PgBouncer estas subteno por SCRAM Authentication, kiu ankaŭ estis alportita al ni de persono, kiu ne funkcias en Yandex.Cloud. Ambaŭ estas kompleksaj funkcioj kaj gravaj.
Tial mi ŝatus diri al vi, el kio estas farita Odiseado, se vi ankaŭ volas skribi kodon nun.
Vi havas la fontbazon Odyssey, kiu dependas de du ĉefaj bibliotekoj. La Kiwi-biblioteko estas efektivigo de la Postgres-mesaĝo-protokolo. Tio estas, denaska pra 3 de Postgres estas normaj mesaĝoj, kiujn front-finaĵoj kaj back-ends povas interŝanĝi. Ili estas efektivigitaj en la Kiwi-biblioteko.
La Machinarium-biblioteko estas fadena efektivigbiblioteko. Malgranda fragmento de ĉi tiu Machinarium estas skribita en asembla lingvo. Sed ne maltrankviliĝu, estas nur 15 linioj.
Odiseado-arkitekturo. Estas ĉefa maŝino sur kiu kurutines funkcias. Ĉi tiu maŝino efektivigas akcepti envenantajn TCP-konektojn kaj distribui ilin inter laboristoj.
Prizorganto por pluraj klientoj povas labori ene de unu laboristo. La ĉefa fadeno ankaŭ funkciigas la konzolon kaj la prilaboradon de kronaj taskoj por forigi ligojn, kiuj ne plu bezonas en la naĝejo.
Odiseado estas provita per la norma Postgres-testamplekso. Ni nur funkcias instal-kontrolon per Bouncer kaj per Odyssey, ni ricevas nulan div. Estas pluraj testoj rilataj al datformatado, kiuj ne pasas precize same en Bouncer kaj en Odyssey.
Krome, estas multaj ŝoforoj, kiuj havas siajn proprajn provojn. Kaj ni uzas iliajn provojn por testi la Odiseadon.
Krome, pro nia kaskada agordo, ni devas testi diversajn pakaĵojn: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey por certigi, ke se Odiseado finiĝis en iu el la partoj en la kaskado, ĝi ankaŭ daŭre funkcias. kiel ni atendas.
Rake
Ni uzas Odiseadon en produktado. Kaj ne estus juste, se mi dirus, ke ĉio nur funkcias. Ne, tio estas, jes, sed ne ĉiam. Ekzemple, en produktado ĉio nur funkciis, tiam niaj amikoj de PostgreSQL Professional venis kaj diris, ke ni havis memorfluon. Ili vere estis, ni korektis ilin. Sed ĝi estis simpla.
Tiam ni malkovris, ke la konekto-komunilo havas envenantajn TLS-konektojn kaj elirantajn TLS-konektojn. Kaj konektoj postulas klientajn atestilojn kaj servilojn.
Atestiloj pri servilo de Bouncer kaj Odyssey estas relegitaj per sia pcache, sed klientaj atestiloj ne bezonas esti relegitaj de pcache, ĉar nia skalebla Odiseado finfine renkontas la sisteman rendimenton de legado de ĉi tiu atestilo. Ĉi tio surprizis nin, ĉar li ne bezonis longe por rezisti. Komence ĝi skaliĝis linie, sed post 20 000 alvenantaj samtempaj konektoj tiu ĉi problemo montriĝis.
Plugable Authentication Method estas la kapablo aŭtentikigi uzante enkonstruitajn Lunux-ilojn. En PgBouncer ĝi estas efektivigita tiel ke ekzistas aparta fadeno por atendi respondon de PAM kaj ekzistas ĉefa PgBouncer-fadeno kiu servas la nunan konekton kaj povas peti ilin vivi en la PAM-fadeno.
Ni ne efektivigis ĉi tion pro unu simpla kialo. Ni havas multajn fadenojn. Kial ni bezonas ĉi tion?
Ĉi tio finfine povas krei problemojn en tio, ke se vi havas PAM-aŭtentikigon kaj ne-PAM-aŭtentikigon, tiam granda ondo de PAM-aŭtentigo povas signife prokrasti la ne-PAM-aŭtentikigon. Ĉi tio estas unu el tiuj aferoj, kiujn ni ne riparis. Sed se vi volas ripari ĝin, vi povas fari ĉi tion.
Alia rastilo estis, ke ni havas unu fadenon, kiu akceptas ĉiujn envenantajn konektojn. Kaj poste ili estas translokigitaj al la laborista naĝejo, kie okazos la manpremo de TLS.
Malsupre, se vi havas koheran ondon de 20 retaj konektoj, ili ĉiuj estos akceptitaj. Kaj ĉe la klientflanko libpq komencos raporti eltempon. Defaŭlte ĝi ŝajnas esti 000 sekundoj.
Se ili ĉiuj ne povas eniri la datumbazon samtempe, tiam ili ne povas eniri la datumbazon, ĉar ĉio ĉi povas esti kovrita per ne-eksponenta reprovo.
Ni alvenis al la konkludo, ke ni kopiis la skemon de PgBouncer ĉi tie kun la fakto, ke ni strebas la nombron da TCP-konektoj al kiuj ni akceptas.
Se ni vidas, ke ni akceptas konektojn, sed ili finfine ne havas tempon por manpremo, ni metas ilin en atendovico por ke ili ne malŝparu CPU-resursojn. Ĉi tio kondukas al la fakto, ke samtempa manpremo eble ne estas farita por ĉiuj alvenintaj konektoj. Sed almenaŭ iu eniros la datumbazon, eĉ se la ŝarĝo estas sufiĉe peza.
vojmapo
Kion vi ŝatus vidi estonte en Odiseado? Kion ni pretas disvolvi nin kaj kion ni atendas de la komunumo?
Ekde aŭgusto 2019.
Jen kiel aspektis la vojmapo de Odiseado en aŭgusto:
- Ni volis SCRAM kaj PAM-aŭtentikigon.
- Ni volis plusendi legopetojn al standby.
- Mi ŝatus interretan rekomencon.
- Kaj la kapablo paŭzi sur la servilo.
Duono de ĉi tiu vojmapo estis kompletigita, kaj ne de ni. Kaj ĉi tio estas bona. Do ni diskutu pri kio restas kaj aldonu pli.
? Ni havas kopiojn, kiuj simple varmigos la aeron sen plenumi petojn. Ni bezonas ilin provizi malsukceson kaj ŝanĝadon. Okaze de problemoj en unu el la datumcentroj, mi ŝatus okupi ilin per iu utila laboro. Ĉar ni ne povas agordi la samajn centrajn procesorojn, la saman memoron malsame, ĉar alie reproduktado ne funkcios.
Principe, en Postgres, ekde 10, eblas specifi session_attrs dum konekto. Vi povas listigi ĉiujn datumbazajn gastigantojn en la konekto kaj diri kial vi iras al la datumbazo: skribu aŭ legu nur. Kaj la ŝoforo mem elektos la unuan gastiganton en la listo, kiun li plej ŝatas, kiu plenumas la postulojn de session_attrs.
Sed la problemo kun ĉi tiu aliro estas ke ĝi ne kontrolas la reproduktan malfruon. Vi eble havas iun kopion, kiu postrestis dum neakceptebla tempo por via servo. Por ebligi plenefikan ekzekuton de legodemandoj sur kopio, ni esence devas subteni la kapablon de Odyssey ne funkcii kiam ĝi ne legeblas.
Odyssey devas iri al la datumbazo de tempo al tempo kaj peti la reproduktan distancon de la primara. Kaj se ĝi atingis la limvaloron, ne permesu novajn petojn en la datumbazon, diru al la kliento, ke ĝi devas rekomenci konektojn kaj, eble, elektu alian gastiganton por plenumi petojn. Ĉi tio permesos al la datumbazo rapide restarigi la reproduktan malfruon kaj reveni denove por respondi per peto.
Estas malfacile doni tempon por efektivigo, ĉar ĝi estas malferma fonto. Sed, mi esperas, ne 2,5 jarojn kiel miaj kolegoj de PgBouncer. Ĉi tiu estas la trajto, kiun mi ŝatus vidi en la Odiseado.
. Nun vi povas krei pretan deklaron en du manieroj. Unue, vi povas ekzekuti la SQL-komandon, nome "preparita". Por kompreni ĉi tiun SQL-komandon, ni devas lerni kompreni la SQL ĉe la Bouncer-flanko. Ĉi tio estus troa, ĉar ĝi estas troa, ĉar ni bezonas la tutan analizilon. Ni ne povas analizi ĉiun SQL-ordonon.
Sed estas preta deklaro ĉe la mesaĝa protokolo-nivelo sur proto3. Kaj ĉi tie estas la loko, kiam la informo, ke preparita deklaro estas kreita, venas en strukturita formo. Kaj ni povus subteni la komprenon, ke en iu servila konekto la kliento petis krei pretajn deklarojn. Kaj eĉ se la transakcio estas fermita, ni ankoraŭ devas konservi konekteblecon inter la servilo kaj la kliento.
Sed ĉi tie aperas malkongruo en la dialogo, ĉar iu diras, ke vi devas kompreni kiajn preparitajn deklarojn la kliento kreis kaj dividi la servilan konekton inter ĉiuj klientoj, kiuj kreis ĉi tiun servilan konekton, t.e., kiuj kreis tian pretan deklaron.
Andreo Freund diris, ke se venas al vi kliento, kiu jam kreis tian pretan deklaron en alia servila konekto, tiam kreu ĝin por li. Sed ŝajnas iomete malĝuste efektivigi demandojn en la datumbazo anstataŭ la kliento, sed el la vidpunkto de la programisto, kiu skribas la protokolon por interagado kun la datumbazo, estus oportune, se oni simple donus al li retkonekton en kiu ekzistas tia preta demando.
Kaj unu plian funkcion, kiun ni devas efektivigi. Ni nun havas monitoradon kongrua kun PgBouncer. Ni povas redoni la mezan demandan ekzekuttempon. Sed la averaĝa tempo estas la averaĝa temperaturo en la hospitalo: kelkaj estas malvarmaj, kelkaj estas varmaj - averaĝe, ĉiuj estas sanaj. Ĝi ne estas vera.
Ni devas efektivigi subtenon por procentoj, kiuj indikus, ke estas malrapidaj demandoj, kiuj malŝparas rimedojn kaj faras monitoradon pli akceptebla.
La plej grava afero estas, ke mi volas version 1.0 (Versio 1.1 jam estis publikigita). La fakto estas, ke Odiseado nun estas en versio 1.0rc, t.e. liberigo-kandidato. Kaj ĉiuj problemoj, kiujn mi listigis, estis solvitaj per ekzakte la sama versio, krom la memorfuĝo.
Kion signifos por ni versio 1.0? Ni disvolvas Odiseadon al niaj bazoj. Ĝi jam funkcias en niaj datumbazoj, sed kiam ĝi atingas la punkton de 1 petoj sekundo, tiam ni povas diri, ke ĉi tiu estas la eldonversio kaj ĉi tiu estas versio kiu povas esti nomita 000.
Pluraj homoj en la komunumo petis, ke versio 1.0 inkluzivas paŭzon kaj SCRAM. Sed ĉi tio signifos, ke ni devos lanĉi la sekvan version al produktado, ĉar nek SCRAM nek paŭzo ankoraŭ estis mortigitaj. Sed, plej verŝajne, ĉi tiu problemo estos solvita sufiĉe rapide.
Mi atendas vian tiran peton. Mi ankaŭ ŝatus aŭdi kiajn problemojn vi havas kun Bouncer. Ni diskutu ilin. Eble ni povas efektivigi iujn funkciojn, kiujn vi bezonas.
Jen la fino de mia parto, mi ŝatus aŭskulti vin. Dankon!
Viaj demandoj
Se mi fiksas mian propran aplikaĵon, ĉu ĝi estos ĝuste plusendita, inkluzive en transakcia kunigo en Odiseado?
Odiseado aŭ Bouncer?
En Odiseado. En Bouncer ĝi estas ĵetita.
Ni faros aron.
Kaj se mia reala konekto saltas sur aliajn konektojn, ĉu ĝi estos transdonita?
Ni faros aron de ĉiuj parametroj, kiuj estas listigitaj en la listo. Mi ne povas diri ĉu aplikaĵo_nomo estas en ĉi tiu listo. Mi pensas, ke mi vidis lin tie. Ni starigos ĉiujn samajn parametrojn. Kun unu peto, la aro faros ĉion, kio estis instalita de la kliento dum la ekfunkciigo.
Dankon, Andreo, pro la raporto! Bona raporto! Mi ĝojas, ke Odiseado evoluas pli kaj pli rapide ĉiuminute. Mi volas daŭrigi tiel. Ni jam petis vin havi plurdatumfontan konekton por ke Odyssey povu konekti al malsamaj datumbazoj samtempe, t.e. majstra sklavo, kaj poste aŭtomate konektiĝi al nova majstro post malsukceso.
Jes, mi ŝajnas memori ĉi tiun diskuton. Nun estas pluraj stokejoj. Sed ne estas ŝanĝado inter ili. Niaflanke, ni devas sondi la servilon ke ĝi ankoraŭ vivas kaj kompreni ke malsukceso okazis, kiu nomos pg_recovery. Mi havas norman manieron kompreni, ke ni ne venis al la majstro. Kaj ĉu ni iel komprenu el la eraroj aŭ kio? Tio estas, la ideo estas interesa, ĝi estas diskutata. Skribu pli da komentoj. Se vi havas laboristojn kiuj konas C, tiam tio estas bonega.
Ankaŭ interesas nin la temo de skalo trans kopioj, ĉar ni volas fari la adopton de reproduktitaj aretoj kiel eble plej simpla por programistoj de aplikaĵoj. Sed ĉi tie mi ŝatus pli da komentoj, t.e. ĝuste kiel fari ĝin, kiel fari ĝin bone.
La demando temas ankaŭ pri kopioj. Rezultas, ke vi havas majstron kaj plurajn kopiojn. Kaj estas klare, ke ili iras al la kopio malpli ofte ol al la majstro por rilatoj, ĉar ili povas havi diferencojn. Vi diris, ke la diferenco en la datumoj povas esti tia, ke ĝi ne kontentigos vian komercon kaj vi ne iros tien ĝis ĝi estas reproduktita. Samtempe, se vi ne iris tien dum longa tempo, kaj tiam komencis iri, tiam la necesaj datumoj ne estos tuj haveblaj. Tio estas, se ni konstante iras al la majstro, tiam la kaŝmemoro tie estas varmigita, sed en la kopio la kaŝmemoro iom postrestas.
Jes estas vero. La pcache ne havos la datumblokojn, kiujn vi volas, la vera kaŝmemoro ne havos informojn pri la tabeloj, kiujn vi volas, la planoj ne havos analizitajn demandojn, estos nenio.
Kaj kiam vi havas ian areton, kaj vi aldonas novan kopion tie, tiam dum ĝi komenciĝas, ĉio estas malbona en ĝi, t.e. ĝi pliigas sian kaŝmemoron.
Mi ricevis la ideon. La ĝusta aliro estus ruli malgrandan procenton de demandoj sur la kopio unue, kio varmigos la kaŝmemoron. Malglate parolante, ni havas kondiĉon, ke ni devas postresti malantaŭ la majstro ne pli ol 10 sekundojn. Kaj ĉi tiu kondiĉo ne estas inkluzivita en unu ondo, sed glate por iuj klientoj.
Jes, pliigu pezon.
Ĉi tio estas bona ideo. Sed unue ni devas efektivigi ĉi tiun haltigon. Unue ni devas malŝalti, kaj poste ni pripensos kiel ŝalti. Ĉi tio estas bonega funkcio por ebligi glate.
Nginx havas ĉi tiun opcion slowly start en areto por la servilo. Kaj li iom post iom pliigas la ŝarĝon.
Jes, bonega ideo, ni provos ĝin kiam ni atingos ĝin.
fonto: www.habr.com