Yn syn rapport sil Andrey Borodin jo fertelle hoe't se rekken holden mei de ûnderfining fan skaalfergrutting fan PgBouncer by it ûntwerpen fan de ferbiningspooler , sa't se it útrôle yn produksje. Derneist sille wy beprate hokker funksjes fan 'e puller wy wolle sjen yn nije ferzjes: it is wichtich foar ús net allinich om oan ús behoeften te foldwaan, mar om de brûkersmienskip te ûntwikkeljen .
Video:
Hoi allegearre! Myn namme is Andrew.
By Yandex ûntwikkelje ik iepen boarne databases. En hjoed hawwe wy in ûnderwerp oer ferbining pooler ferbiningen.
As jo witte hoe't jo ferbining pooler yn it Russysk kinne skilje, fertel my dan. Ik wol echt in goede technyske term fine dy't fêstlein wurde moat yn 'e technyske literatuer.
It ûnderwerp is frij yngewikkeld, want yn in protte databases is de ferbiningspooler ynboud en jo hoege der net iens fan te witten. Fansels binne der oeral wat ynstellingen, mar yn Postgres wurket it net sa. En parallel (by HighLoad++ 2019) is d'r in rapport fan Nikolai Samokhvalov oer it ynstellen fan fragen yn Postgres. En sa't ik it begryp, kamen hjir minsken dy't har queries al perfekt konfigureare hiene, en dit binne minsken dy't te krijen hawwe mei seldsumer systeemproblemen yn ferbân mei it netwurk en gebrûk fan boarnen. En op guon plakken kin it frij lestich wêze yn 'e sin dat de problemen net dúdlik binne.
Yandex hat Postgres. In protte Yandex-tsjinsten libje yn Yandex.Cloud. En wy hawwe ferskate petabytes oan gegevens dy't op syn minst in miljoen oanfragen per sekonde generearje yn Postgres.
En wy leverje in frij standert kluster foar alle tsjinsten - dit is de wichtichste primêre knooppunt fan 'e knooppunt, de gewoane twa replika's (syngroane en asynchrone), reservekopy, skaalfergrutting fan lêsfersiken op' e replika.
Elk klusterknooppunt is Postgres, dêr't, neist Postgres en monitorsystemen, ek in ferbiningspooler ynstallearre is. Connection pooler wurdt brûkt foar fencing en foar syn wichtichste doel.
Wat is it haaddoel fan ferbining pooler?
Postgres nimt in prosesmodel oan by it wurkjen mei in databank. Dit betsjut dat ien ferbining is ien proses, ien Postgres backend. En yn dizze backend binne d'r in protte ferskillende caches, dy't frij djoer binne om oars te meitsjen foar ferskate ferbiningen.
Derneist hat Postgres-koade in array neamd procArray. It befettet basisgegevens oer netwurkferbiningen. En hast alle procArray-ferwurkingsalgoritmen hawwe lineêre kompleksiteit; se rinne oer de heule array fan netwurkferbiningen. It is in frij rappe syklus, mar mei mear ynkommende netwurkferbiningen wurde dingen in bytsje djoerder. En as dingen in bytsje djoerder wurde, kinne jo úteinlik in heul hege priis betelje foar in protte netwurkferbiningen.
D'r binne 3 mooglike oanpak:
- Oan de applikaasje kant.
- Oan de databank kant.
- En tusken, dat is, allerhanne kombinaasjes.
Spitigernôch is de ynboude pooler op it stuit yn ûntwikkeling. Us freonen by PostgreSQL Professional dogge dit meast. Wannear't it sil ferskine is dreech te foarsizzen. En yn feite hawwe wy twa oplossingen foar de arsjitekt om út te kiezen. Dit binne pool-side-pool en proxy-pool.
Swimbad oan de applikaasjekant is de maklikste manier. En hast alle client-bestjoerders jouwe jo in manier: presintearje miljoenen fan jo ferbinings yn koade yn 'e foarm fan ferskate tsientallen ferbiningen mei de databank.
It probleem dat ûntstiet is dat jo op in bepaald punt de backend wolle skaalje, jo wolle it ynsette op in protte firtuele masines.
Dan realisearje jo dat jo ferskate mear beskikberensônes hawwe, ferskate datasintra. En de oanpak fan pooling oan 'e kant fan' e kliïnt liedt ta grutte oantallen. Grutte binne sa'n 10 ferbiningen. Dit is de râne dy't normaal kin wurkje.
As wy prate oer proxy poolers, dan binne der twa poolers dy't kinne dwaan in soad dingen. Se binne net allinnich poolers. Se binne poolers + mear koele funksjonaliteit. Dit и .
Mar, spitigernôch, net elkenien hat dizze ekstra funksjonaliteit nedich. En it liedt ta it feit dat poolers allinich sesje-pooling stypje, dus ien ynkommende klant, ien útgeande klant nei de databank.
Dit is net heul geskikt foar ús doelen, dus wy brûke PgBouncer, dy't transaksje-pooling ymplementearret, d.w.s. tsjinnerferbiningen wurde allinich oerienkomme mei kliïntferbiningen foar de doer fan 'e transaksje.
En yn ús wurkdruk is dit wier. Mar d'r binne in pear problemen.
De problemen begjinne as jo in sesje diagnoaze wolle, om't al jo ynkommende ferbiningen lokaal binne. Elkenien kaam mei in loopback en op ien of oare manier wurdt it dreech om de sesje te tracearen.
Fansels kinne jo applikaasje_name_add_host brûke. Dit is in manier oan 'e Bouncer-kant om in IP-adres ta te foegjen oan application_name. Mar application_name wurdt ynsteld troch in ekstra ferbining.
Op dizze grafyk, dêr't de giele line is echte fersiken, en dêr't de blauwe line is fersiken dy't fleane yn de databank. En dit ferskil is krekt de ynstallaasje fan application_name, dy't allinich nedich is foar tracing, mar it is hielendal net fergees.
Derneist kinne jo yn Bouncer ien pool net beheine, dus it oantal databankferbiningen per spesifike brûker, per spesifike databank.
Wat liedt dit ta? Jo hawwe in laden tsjinst skreaun yn C ++ en earne tichtby in lytse tsjinst op in knooppunt dat docht neat ferskriklik mei de databank, mar syn bestjoerder wurdt gek. It iepenet 20 ferbiningen en al it oare sil wachtsje. Sels jo koade is normaal.
Wy hawwe fansels in lytse patch skreaun foar Bouncer dy't dizze ynstelling tafoege, dat wol sizze klanten beheine ta it swimbad.
It soe mooglik wêze om dit te dwaan oan 'e Postgres-kant, dat wol sizze, de rollen yn' e database beheine troch it oantal ferbiningen.
Mar dan ferlieze jo de mooglikheid om te begripen wêrom't jo gjin ferbiningen hawwe mei de tsjinner. PgBouncer smyt gjin ferbiningsflater, it jout altyd deselde ynformaasje werom. En jo kinne it net begripe: miskien is jo wachtwurd feroare, miskien is de databank gewoan ferlern gien, miskien is der wat mis. Mar der is gjin diagnoaze. As in sesje net fêststeld wurde kin, sille jo net witte wêrom't it net fêststeld wurde kin.
Op in bepaald punt sjogge jo nei de applikaasjegrafiken en sjogge jo dat de applikaasje net wurket.
Sjoch nei de top en sjoch dat Bouncer is single-threaded. Dit is in kearpunt yn it libben fan 'e tsjinst. Jo realisearje dat jo har tariede op it skaaljen fan de databank yn in jier en in heal, en jo moatte de pooler skaalje.
Wy binne ta de konklúzje kommen dat wy mear PgBouncers nedich binne.
Bouncer is in bytsje patched.
En se makken it sa dat ferskate Bouncers koene wurde opwekke troch de TCP-poarte opnij te brûken. En it bestjoeringssysteem ferpleatst automatysk ynkommende TCP-ferbiningen tusken har mei round-robin.
Dit is trochsichtich foar kliïnten, wat betsjut dat it liket as jo ien Bouncer hawwe, mar jo hawwe fragmintaasje fan idle ferbiningen tusken rinnende Bouncers.
En op in bepaald momint kinne jo merke dat dizze 3 Bouncers elk har kearn mei 100% ite. Jo moatte nochal in pear Bouncers. Wêrom?
Om't jo TLS hawwe. Jo hawwe in fersifere ferbining. En as jo Postgres benchmarkearje mei en sûnder TLS, sille jo fine dat it oantal fêststelde ferbiningen sakket mei hast twa oarders fan grutte mei fersifering ynskeakele, om't de TLS-handshake CPU-boarnen ferbrûkt.
En oan 'e boppekant kinne jo nochal wat kryptografyske funksjes sjen dy't wurde útfierd as d'r in weach fan ynkommende ferbinings is. Sûnt ús primêre kin wikselje tusken beskikberens sônes, in weach fan ynkommende ferbinings is in frij typyske situaasje. Dat is, om ien of oare reden wie de âlde primêre net beskikber, de folsleine lading waard stjoerd nei in oar datasintrum. Se sille allegear tagelyk komme om TLS hallo te sizzen.
En in grut oantal TLS handshake meie net langer sizze hello tsjin Bouncer, mar sil squeeze syn kiel. Troch de time-out kin de weach fan ynkommende ferbiningen undemped wurde. As jo besykje op 'e basis sûnder eksponinsjele backoff, se sille net komme wer en wer yn in gearhingjende weach.
Hjir is in foarbyld fan 16 PgBouncers dy't 16 kearnen op 100% lade.
Wy kamen by de kaskade PgBouncer. Dit is de bêste konfiguraasje dy't kin wurde berikt op ús lading mei Bouncer. Us eksterne Bouncers wurde brûkt foar TCP-handshake, en ynterne Bouncers wurde brûkt foar echte pooling, om eksterne ferbiningen net te folle te fragmintearjen.
Yn dizze konfiguraasje is in soepele werstart mooglik. Jo kinne al dizze 18 Bouncers ien foar ien opnij starte. Mar it behâld fan sa'n konfiguraasje is frij lestich. Sysadmins, DevOps, en minsken dy't eins ferantwurdlik binne foar dizze tsjinner sille net hiel bliid mei dizze regeling.
It soe lykje dat al ús ferbetterings kinne wurde befoardere ta iepen boarne, mar Bouncer wurdt net hiel goed stipe. Bygelyks, de mooglikheid om ferskate PgBouncers op ien haven út te fieren waard in moanne lyn ynset. D'r wie ferskate jierren lyn in pull-fersyk mei dizze funksje.
Of noch ien foarbyld. Yn Postgres kinne jo in oanfraach annulearje troch it geheim nei in oare ferbining te stjoeren sûnder ûnnedige autentikaasje. Mar guon kliïnten stjoere gewoan in TCP-reset, d.w.s. se brekke de netwurkferbining. Wat sil Bouncer dwaan? Hy sil neat dwaan. It sil trochgean mei it útfieren fan it fersyk. As jo in enoarm oantal ferbiningen hawwe krigen dy't in databank hawwe makke mei lytse oanfragen, dan sil it gewoan ôfbrekke fan de ferbining fan Bouncer net genôch wêze; jo moatte ek de oanfragen foltôgje dy't rinne yn 'e databank.
Dit is patched en dit probleem is noch net gearfoege yn Bouncer's streamop.
En sa kamen wy ta de konklúzje dat wy in eigen ferbiningspooler nedich hawwe, dy't ûntwikkele wurde, patched, wêryn problemen fluch korrizjearre wurde kinne en dy't fansels multi-threaded wurde moatte.
Wy sette multithreading as de haadtaak. Wy moatte de welle fan ynkommende TLS-ferbiningen goed kinne omgean.
Om dit te dwaan, moasten wy in aparte bibleteek ûntwikkelje mei de namme Machinarium, dy't is ûntworpen om de masine-staten fan in netwurkferbining te beskriuwen as opfolgjende koade. As jo nei de libpq-boarnekoade sjogge, sille jo wat frij komplekse oproppen sjen dy't jo in resultaat kinne weromjaan en sizze: "Rop my letter. Op it stuit haw ik IO foar no, mar as de IO fuort giet, sil ik in lading hawwe op 'e prosessor. En dit is in multi-level skema. Netwurk kommunikaasje wurdt meastal beskreaun troch in steat masine. In protte regels lykas "As ik earder in pakketkop fan grutte N krige, wachtsje ik no op N bytes," "As ik in SYNC-pakket stjoerde, wachtsje ik no op in pakket mei resultaatmetadata." It resultaat is in nochal drege, tsjinoerstelde koade, as soe it doalhôf omboud wurde ta line scan. Wy makken it sa dat ynstee fan in steat masine, de programmeur beskriuwt de wichtichste paad fan ynteraksje yn 'e foarm fan gewoane ymperatyf koade. It is gewoan dat jo yn dizze ymperatyf koade plakken moatte ynfoegje wêr't de útfieringssekwinsje moat wurde ûnderbrutsen troch te wachtsjen op gegevens fan it netwurk, troch de útfieringskontekst nei in oare koroutine (griene tried). Dizze oanpak is fergelykber mei it feit dat wy it meast ferwachte paad yn 'e doalhôf op in rige opskriuwe, en dan tûken tafoegje.
As gefolch hawwe wy ien thread dy't TCP akseptearret en round-robin de TPC-ferbining trochjaan oan in protte arbeiders.
Yn dit gefal rint elke klantferbining altyd op ien prosessor. En dit kinne jo meitsje it cache-freonlik.
En boppedat hawwe wy de kolleksje fan lytse pakketten in bytsje ferbettere yn ien grut pakket om it systeem TCP-stapel te ûntlêsten.
Derneist hawwe wy transaksjonele pooling ferbettere yn 't sin dat Odyssey, as ynsteld, CANCEL en ROLLBACK stjoere kin yn it gefal fan in netwurkferbining mislearre, dus as gjinien wachtet op in fersyk, sil Odyssey de databank fertelle om net te besykjen om foltôgje it fersyk dat kostbere boarnen kin fergrieme.
En as it mooglik is, hâlde wy ferbiningen mei deselde klant. Dit foarkomt om application_name_add_host opnij te ynstallearjen. As dit mooglik is, hoege wy de parameters dy't nedich binne foar diagnostyk net ekstra werom te setten.
Wy wurkje yn 'e belangen fan Yandex.Cloud. En as jo managed PostgreSQL brûke en in ferbiningspooler ynstalleare hawwe, kinne jo logyske replikaasje nei bûten oanmeitsje, dat wol sizze, lit ús, as jo wolle, logyske replikaasje brûke. Bouncer sil de logyske replikaasjestream net bûten loslitte.
Dit is in foarbyld fan it ynstellen fan logyske replikaasje.
Derneist hawwe wy stipe foar fysike replikaasje nei bûten. Yn de Wolk is dat fansels net mooglik, want dan jout it kluster tefolle ynformaasje oer himsels. Mar yn jo ynstallaasjes, as jo fysike replikaasje nedich binne fia de ferbiningspooler yn Odyssey, is dit mooglik.
Odyssey hat folslein kompatibele tafersjoch mei PgBouncer. Wy hawwe deselde konsole dy't hast allegear deselde kommando's útfiert. As der wat mist, stjoer dan in pull-fersyk, of op syn minst in probleem op GitHub, en wy sille de nedige kommando's foltôgje. Mar wy hawwe al de haadfunksjonaliteit fan 'e PgBouncer-konsole.
En, fansels, wy hawwe flater trochstjoere. Wy sille weromkomme de flater rapportearre troch de databank. Jo krije ynformaasje oer wêrom't jo net opnommen binne yn 'e databank, en net allinich dat jo der net yn binne.
Dizze funksje is útskeakele yn gefal jo 100% kompatibiliteit nedich binne mei PgBouncer. Wy kinne ús op deselde manier gedrage as Bouncer, gewoan foar de feilige kant.
Untwikkeling
In pear wurden oer de Odyssey boarnekoade.
D'r binne bygelyks "Pauze / Ferfetsje" kommando's. Se wurde normaal brûkt om de databank te aktualisearjen. As jo Postgres moatte bywurkje, dan kinne jo it pauze yn 'e ferbiningspooler, do pg_upgrade, dan ferfetsje. En fan 'e kant fan' e kliïnt sil it lykje as soe de database gewoan fertrage. Dizze funksjonaliteit is oan ús brocht troch minsken út 'e mienskip. Se is noch net beferzen, mar gau sil alles wêze. (Al beferzen)
- al beferzen
Derneist is ien fan 'e nije funksjes yn PgBouncer stipe foar SCRAM Authentication, dy't ek oan ús brocht waard troch in persoan dy't net wurket yn Yandex.Cloud. Beide binne komplekse funksjonaliteit en wichtich.
Dêrom wol ik jo graach fertelle wêr't Odyssey fan makke is, foar it gefal dat jo no ek in bytsje koade skriuwe wolle.
Jo hawwe de Odyssey boarne basis, dy't fertrout op twa haadbiblioteken. De Kiwi-bibleteek is in ymplemintaasje fan it Postgres-berjochtprotokol. Dat is, native proto 3 fan Postgres is standert berjochten dy't front-ends en back-ends kinne útwikselje. Se wurde ymplementearre yn 'e Kiwi-bibleteek.
De Machinarium-bibleteek is in thread-ymplemintaasjebibleteek. In lyts fragmint fan dit Machinarium is skreaun yn gearstallingstaal. Mar wês net bang, d'r binne mar 15 rigels.
Odyssey arsjitektuer. D'r is in haadmasine wêrop coroutines rinne. Dizze masine ymplementearret akseptearjen fan ynkommende TCP-ferbiningen en fersprieden se ûnder arbeiders.
In handler foar ferskate kliïnten kin wurkje binnen ien arbeider. De haadthread rint ek de konsole en it ferwurkjen fan crone-taken om ferbiningen te wiskjen dy't net mear nedich binne yn it swimbad.
Odyssey wurdt hifke mei de standert Postgres testsuite. Wy rinne gewoan install-check fia Bouncer en fia Odyssey, wy krije in null div. D'r binne ferskate testen relatearre oan datumopmaak dy't net krekt itselde passe yn Bouncer en yn Odyssey.
Derneist binne d'r in protte bestjoerders dy't har eigen testen hawwe. En wy brûke har tests om de Odyssey te testen.
Derneist moatte wy, fanwegen ús kaskadekonfiguraasje, ferskate bondels testen: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey om der wis fan te wêzen dat as Odyssey yn ien fan 'e dielen yn' e kaskade einige, it ek noch wurket lykas wy ferwachtsje.
Rake
Wy brûke Odyssey yn produksje. En it soe net earlik wêze as ik sei dat alles gewoan wurket. Nee, dat is, ja, mar net altyd. Bygelyks, yn 'e produksje wurke alles gewoan, doe kamen ús freonen fan PostgreSQL Professional en seine dat wy in ûnthâldlek hienen. Se wiene echt, wy hawwe se korrizjearre. Mar it wie ienfâldich.
Doe ûntdutsen wy dat de ferbiningspooler ynkommende TLS-ferbiningen en útgeande TLS-ferbiningen hat. En ferbinings fereaskje client sertifikaten en tsjinner sertifikaten.
Bouncer- en Odyssey-tsjinnersertifikaten wurde opnij lêzen troch har pcache, mar kliïntsertifikaten hoege net opnij te lêzen fan pcache, om't ús skalbere Odyssey úteinlik rint yn 'e systeemprestaasjes fan it lêzen fan dit sertifikaat. Dit kaam ús as in ferrassing, want it duorre net lang om him tsjin te hâlden. Yn 't earstoan skaalde it lineêr, mar nei 20 ynkommende simultane ferbiningen die dit probleem himsels.
Pluggable Authentication Method is de mooglikheid om te ferifiearjen mei ynboude Lunux-ark. Yn PgBouncer wurdt it op sa'n manier ymplementearre dat d'r in aparte thread is om te wachtsjen op in antwurd fan PAM en d'r is in haad PgBouncer-thread dy't de hjoeddeistige ferbining betsjinnet en har kin freegje om te libjen yn 'e PAM-thread.
Wy hawwe dit net útfierd foar ien ienfâldige reden. Wy hawwe in protte triedden. Wêrom hawwe wy dit nedich?
Dit kin úteinlik problemen meitsje yn dat as jo PAM-ferifikaasje en net-PAM-autentikaasje hawwe, dan kin in grutte golf fan PAM-ferifikaasje de net-PAM-autentikaasje signifikant fertrage. Dit is ien fan 'e dingen dy't wy net hawwe repareare. Mar as jo it reparearje wolle, kinne jo dit dwaan.
In oare rake wie dat wy hawwe ien tried dy't akseptearret alle ynkommende ferbinings. En dan wurde se oerbrocht nei it arbeiderspool, dêr't de TLS-handshake plakfynt.
Bottom line, as jo in gearhingjende weach fan 20 netwurkferbiningen hawwe, sille se allegear wurde aksepteare. En oan 'e kliïntside sil libpq begjinne mei it rapportearjen fan timeouts. Standert liket it 000 sekonden te wêzen.
As se allegear net tagelyk de databank ynfiere kinne, dan kinne se net yn de databank komme, om't dit alles troch net-eksponinsjele opnij besocht wurde kin.
Wy kamen ta de konklúzje dat wy it skema fan PgBouncer hjir kopieare mei it feit dat wy it oantal TCP-ferbiningen wêrmei't wy akseptearje hawwe throttling.
As wy sjogge dat wy ferbinings akseptearje, mar se hawwe úteinlik gjin tiid om te handshaken, sette wy se yn in wachtrige, sadat se gjin CPU-boarnen fergrieme. Dit liedt ta it feit dat in simultane handshake miskien net útfierd wurde foar alle ferbinings dy't oankommen binne. Mar op syn minst immen sil ynfiere de databank, sels as de lading is frij swier.
Roadmap
Wat wolle jo yn 'e takomst sjen yn Odyssey? Wat binne wy ree om ússels te ûntwikkeljen en wat ferwachtsje wy fan de mienskip?
Mei yngong fan augustus 2019.
Dit is hoe't de Odyssey roadmap der yn augustus útseach:
- Wy woenen SCRAM- en PAM-ferifikaasje.
- Wy woene lêsfersiken trochstjoere nei standby.
- Ik soe graach in online opnij starte.
- En de mooglikheid om te stopjen op 'e tsjinner.
De helte fan dizze roadmap is foltôge, en net troch ús. En dit is goed. Litte wy dus beprate wat der oerbliuwt en mear tafoegje.
? Wy hawwe replika's dy't de loft gewoan ferwaarme sûnder oanfragen út te fieren. Wy hawwe se nedich om failover en switchover te leverjen. Yn gefal fan problemen yn ien fan 'e datasintra soe ik se graach besette mei wat nuttich wurk. Omdat wy kinne net ynstelle deselde sintrale processors, itselde ûnthâld oars, omdat oars replikaasje sil net wurkje.
Yn prinsipe, yn Postgres, begjinnend fan 10, is it mooglik om session_attrs op te jaan by it ferbinen. Jo kinne alle database-hosts yn 'e ferbining listje en sizze wêrom't jo nei de databank geane: skriuwe of allinich lêze. En de bestjoerder sels sil de earste host yn 'e list selektearje dy't hy it bêste fynt, dy't foldocht oan de easken fan session_attrs.
Mar it probleem mei dizze oanpak is dat it de replikaasjelag net kontrolearret. Jo kinne wat replika hawwe dy't in ûnakseptabele tiid efter is foar jo tsjinst. Om folsleine útfiering fan lêsfragen op in replika yn te skeakeljen, moatte wy yn essinsje it fermogen fan Odyssey stypje om net te rinnen as it net kin wurde lêzen.
Odyssey moat fan tiid ta tiid nei de databank gean en freegje om de replikaasjeôfstân fan 'e primêre. En as it de limytwearde hat berikt, lit jo gjin nije oanfragen yn 'e database tastean, fertel de kliïnt dat it ferbiningen opnij moat begjinne en, mooglik, in oare host selektearje om oanfragen út te fieren. Dit sil de databank de replikaasjefertraging fluch werstelle en wer weromkomme om te reagearjen mei in fersyk.
It is lestich om in tiidframe te jaan foar ymplemintaasje, om't it iepen boarne is. Mar, ik hoopje, net 2,5 jier lykas myn kollega's fan PgBouncer. Dit is de funksje dy't ik graach sjen soe yn 'e Odyssey.
. No kinne jo op twa manieren in tariede ferklearring meitsje. Earst kinne jo it SQL-kommando útfiere, nammentlik "tariede". Om dit SQL-kommando te begripen, moatte wy leare om de SQL oan 'e Bouncer-kant te begripen. Dit soe in overkill wêze, om't it oerkill is, om't wy de folsleine parser nedich binne. Wy kinne net elk SQL kommando parse.
Mar d'r is in tariede ferklearring op it berjochtprotokolnivo op proto3. En dit is it plak as de ynformaasje dat in tariede ferklearring wurdt makke yn in strukturearre foarm komt. En wy koene it begryp stypje dat op guon serverferbining de kliïnt frege om tarete útspraken te meitsjen. En sels as de transaksje is sletten, moatte wy noch ferbining hâlde tusken de tsjinner en de kliïnt.
Mar hjir ûntstiet in diskrepânsje yn 'e dialooch, om't immen seit dat jo moatte begripe hokker soarte fan taret útspraken de kliïnt makke en diele de serverferbining tusken alle kliïnten dy't dizze serverferbining makke hawwe, dus wa't sa'n taret ferklearring makke.
Andres Freund sei dat as in kliïnt nei jo komt dy't al sa'n taret ferklearring makke hat yn in oare serverferbining, meitsje it dan foar him. Mar it liket in bytsje ferkeard om fersiken út te fieren yn 'e databank ynstee fan' e kliïnt, mar út it eachpunt fan 'e ûntwikkelder dy't it protokol skriuwt foar ynteraksje mei de databank, soe it handich wêze as hy gewoan in netwurkferbining krige wêryn't der is sa'n taret fersyk.
En noch ien funksje dy't wy moatte ymplementearje. Wy hawwe no monitoring kompatibel mei PgBouncer. Wy kinne de gemiddelde útfieringstiid fan query weromjaan. Mar de gemiddelde tiid is de gemiddelde temperatuer yn it sikehûs: guon binne kâld, guon binne waarm - yn trochsneed is elkenien sûn. It is net wier.
Wy moatte stipe ymplementearje foar percentiles dy't soe oanjaan dat d'r trage fragen binne dy't boarnen fergrieme en tafersjoch akseptabeler meitsje.
It wichtichste is dat ik ferzje 1.0 wol (ferzje 1.1 is al frijlitten). It feit is dat Odyssey no yn ferzje 1.0rc is, dus frijlittingskandidaat. En alle problemen dy't ik neamde waarden reparearre mei krekt deselde ferzje, útsein it ûnthâldlek.
Wat sil ferzje 1.0 foar ús betsjutte? Wy rôlje Odyssey út nei ús bases. It rint al op ús databases, mar as it it punt fan 1 oanfragen per sekonde berikt, dan kinne wy sizze dat dit de releaseferzje is en dit is in ferzje dy't 000 neamd wurde kin.
Ferskate minsken yn 'e mienskip hawwe frege dat ferzje 1.0 pauze en SCRAM omfettet. Mar dit sil betsjutte dat wy de folgjende ferzje moatte útrolje nei produksje, om't noch SCRAM noch pauze binne fermoarde. Mar, nei alle gedachten, dit probleem sil wurde oplost frij gau.
Ik wachtsje op jo pull-fersyk. Ik wol ek graach hearre hokker problemen jo hawwe mei Bouncer. Litte wy se beprate. Miskien kinne wy wat funksjes ymplementearje dy't jo nedich binne.
Dit is de ein fan myn part, ik soe graach harkje nei dy. Dankewol!
Jo fragen
As ik myn eigen application_name ynstelle, sil it dan goed trochstjoerd wurde, ynklusyf yn transaksjepooling yn Odyssey?
Odyssey of Bouncer?
In Odyssey. Yn Bouncer wurdt smiten.
Wy meitsje in set.
En as myn echte ferbining op oare ferbiningen springt, sil it dan wurde oerstjoerd?
Wy sille in set meitsje fan alle parameters dy't yn 'e list steane. Ik kin net fertelle oft application_name is yn dizze list. Ik tink dat ik him dêr seach. Wy sille alle deselde parameters ynstelle. Mei ien fersyk sil de set alles dwaan wat troch de kliïnt ynstalleare is tidens it opstarten.
Tankewol, Andrey, foar it rapport! Goed ferslach! Ik bin bliid dat Odyssey elke minút rapper en rapper ûntwikkelet. Ik wol sa trochgean. Wy hawwe jo al frege om in ferbining mei meardere gegevensboarnen te hawwen, sadat Odyssey tagelyk kin ferbine mei ferskate databases, dus in masterslave, en dan automatysk ferbine mei in nije master nei failover.
Ja, ik liket my dizze diskusje te ûnthâlden. No binne d'r ferskate opslach. Mar der is gjin wikseljen tusken harren. Oan ús kant moatte wy de tsjinner ûndersiikje dat it noch libbet en begripe dat in failover bard is, wa sil pg_recovery neame. Ik haw in standert manier om te begripen dat wy net by de master kamen. En moatte wy op ien of oare manier begripe út de flaters of wat? Dat is, it idee is nijsgjirrich, it wurdt besprutsen. Skriuw mear opmerkings. As jo arbeiders hawwe dy't C kenne, dan is dat oer it algemien geweldich.
It probleem fan skaalfergrutting oer replika's is ek fan belang foar ús, om't wy it oannimmen fan replikearre klusters sa ienfâldich mooglik meitsje wolle foar applikaasje-ûntwikkelders. Mar hjir wol ik mear opmerkings, dus krekt hoe te dwaan, hoe te dwaan it goed.
De fraach giet ek oer replika's. It docht bliken dat jo in master en ferskate replika's hawwe. En it is dúdlik dat se minder faak nei de replika gean as nei de master foar ferbiningen, om't se ferskillen hawwe kinne. Jo hawwe sein dat it ferskil yn 'e gegevens sa wêze kin dat it jo bedriuw net sil foldwaan en jo sille der net hinne gean oant it wurdt replikearre. Tagelyk, as jo dêr in lange tiid net gien, en dan begon te gean, dan sille de gegevens dy't nedich binne net direkt beskikber wêze. Dat is, as wy hieltyd nei de master gean, dan wurdt de cache dêr opwarmd, mar yn 'e replika bliuwt de cache in bytsje.
Ja it is wier. De pcache sil net de gegevensblokken hawwe dy't jo wolle, de echte cache sil gjin ynformaasje hawwe oer de tabellen dy't jo wolle, de plannen sille gjin parsearde queries hawwe, d'r sil hielendal neat wêze.
En as jo in soarte fan kluster hawwe, en jo tafoegje in nije replika dêr, dan wylst it begjint, alles is min yn it, dat wol sizze it fergruttet syn cache.
Ik krige it idee. De juste oanpak soe wêze om earst in lyts persintaazje fragen op 'e replika út te fieren, wat de cache soe opwarmje. Rûchwei hawwe wy in betingst dat wy net mear as 10 sekonden efter de master bliuwe moatte. En dizze betingst is net opnommen yn ien welle, mar soepel foar guon kliïnten.
Ja, gewicht ferheegje.
Dit is in goed idee. Mar earst moatte wy dizze shutdown útfiere. Earst moatte wy útsette, en dan sille wy tinke oer hoe't wy ynskeakelje. Dit is in geweldige funksje om soepel yn te skeakeljen.
Nginx hat dizze opsje slowly start yn in kluster foar de tsjinner. En hy fergruttet stadichoan de lading.
Ja, geweldich idee, wy sille it besykje as wy deroan komme.
Boarne: www.habr.com