Di raporta xwe de, Andrey Borodin dê ji we re vebêje ka wan çawa ezmûna pîvandina PgBouncer di dema sêwirana hewza pêwendiyê de hesibandine. , ji ber ku ew derxistin nav hilberînê. Digel vê yekê, em ê nîqaş bikin ka kîjan fonksiyonên kêşkerê ku em dixwazin di guhertoyên nû de bibînin: ji me re girîng e ku ne tenê hewcedariyên xwe bicîh bînin, lê pêşvexistina civata bikarhêner. .
Video:
Silav hemû! Navê min Andrew e.
Li Yandex, ez databasên çavkaniya vekirî pêş dixe. Û îro me mijarek di derbarê girêdanên pooler ên pêwendiyê de heye.
Ger hûn dizanin ka meriv çawa bi rûsî gazî pooler-a girêdanê dike, wê hingê ji min re bêje. Ez bi rastî dixwazim termek teknîkî ya baş bibînim ku divê di edebiyata teknîkî de were damezrandin.
Mijar pir tevlihev e, ji ber ku di gelek databasan de hewza pêwendiyê çêkirî ye û ne hewce ye ku hûn pê zanibin. Bê guman, li her derê hin mîheng hene, lê di Postgres de ew bi vî rengî naxebite. Û di heman demê de (li HighLoad ++ 2019) raporek ji hêla Nikolai Samokhvalov ve li ser sazkirina pirsan li Postgres heye. Û wekî ku ez jê fam dikim, mirovên ku berê pirsên xwe bi rengek bêkêmasî mîheng kiribûn hatin vir, û ev kes in ku bi pirsgirêkên pergalê yên hindiktir ên têkildarî karanîna torê û çavkaniyê re rû bi rû ne. Û li hin deveran dibe ku di vê wateyê de dijwar be ku pirsgirêk ne diyar in.
Yandex Postgres heye. Gelek xizmetên Yandex li Yandex.Cloud dijîn. Û me çend petabytes dane hene ku li Postgres bi kêmî ve mîlyonek daxwazî di çirkeyê de çêdikin.
Û em ji bo hemî karûbaran komek standard standard peyda dikin - ev girêka sereke ya girêkê ye, du kopiyên adetî (hevdem û asynkron), paşvekişandin, pîvandina daxwazên xwendinê yên li ser replikayê.
Her girêka komê Postgres e, ku li ser wê, ji bilî Postgres û pergalên çavdêriyê, hewzek pêwendiyê jî tê saz kirin. Poolera girêdanê ji bo dorpêçkirinê û ji bo armanca xwe ya sereke tê bikar anîn.
Armanca sereke ya girêdana pooler çi ye?
Postgres dema ku bi databasê re dixebite modelek pêvajoyê qebûl dike. Ev tê vê wateyê ku yek girêdan yek pêvajo ye, yek paşdeya Postgres e. Û di vê paşperdeyê de gelek kaşên cihêreng hene, ku ji bo girêdanên cihêreng çêkirina wan pir biha ne.
Wekî din, koda Postgres xwedan rêzek bi navê procArray heye. Ew daneyên bingehîn di derbarê girêdanên torê de vedihewîne. Hema hema hemî algorîtmayên pêvajoyê yên procArray xwedan tevliheviya xêzikî ne; ew li ser tevahiya rêza girêdanên torê dimeşînin. Ew çerxek zû zû ye, lê digel bêtir girêdanên torê yên hatinî tişt hinekî bihatir dibin. Û gava ku tişt hinekî biha dibin, hûn dikarin ji bo gelek girêdanên torê bihayek pir giran bidin.
3 rêgezên gengaz hene:
- Li aliyê serîlêdanê.
- Li aliyê databasê.
- Û di navbera, ango, hemû cureyên kombînasyona.
Mixabin, hewza çêkirî niha di pêşkeftinê de ye. Hevalên me li PostgreSQL Professional bi piranî vê yekê dikin. Dema ku ew ê xuya bibe dijwar e ku meriv pêşbîn bike. Û di rastiyê de, du çareseriyên me hene ku mîmar ji wan hilbijêrin. Ev hewza-side serîlêdanê û hewza proxy ne.
Hewza aliyê serîlêdanê riya herî hêsan e. Hema hema hemî ajokarên xerîdar rêyek ji we re peyda dikin: bi mîlyonan girêdanên xwe di kodê de wekî çend dehan girêdan bi databasê re pêşkêş bikin.
Pirsgirêka ku derdikeve ev e ku di nuqteyek diyarkirî de hûn dixwazin paşnavê mezin bikin, hûn dixwazin wê li gelek makîneyên virtual bicîh bikin.
Dûv re hûn fêhm dikin ku we çend deverên peydabûnê, gelek navendên daneyê hene. Û nêzîkatiya berhevkirina aliyê xerîdar dibe sedema hejmarên mezin. Yên mezin nêzî 10 girêdan in. Ev qeraxa ku dikare normal bixebite ye.
Ger em li ser proxy poolers biaxivin, wê hingê du pool hene ku dikarin gelek tiştan bikin. Ew ne tenê pooler in. Ew pooler + fonksiyonek bêtir xweş in. Ev и .
Lê, mixabin, ne her kes hewceyê vê fonksiyona zêde ye. Û ev rê li ber vê yekê vedike ku pooler tenê piştgirî dide berhevkirina danişînê, ango yek xerîdarek tê, yek xerîdarek derketî databasê.
Ev ji bo mebestên me ne pir maqûl e, ji ber vê yekê em PgBouncer bikar tînin, ku berhevkirina danûstendinê pêk tîne, ango girêdanên serverê tenê ji bo dirêjahiya danûstendinê bi girêdanên xerîdar re têne hev kirin.
Û di xebata me de, ev rast e. Lê çend pirsgirêk hene.
Pirsgirêk dema ku hûn dixwazin danişînek teşhîs bikin dest pê dikin, ji ber ku hemî girêdanên weyên hatin herêmî ne. Her kes bi paşvekêşek hat û bi rengekî peydakirina danişînê dijwar dibe.
Bê guman hûn dikarin application_name_add_host bikar bînin. Ev rêyek li alîyê Bouncer e ku navnîşek IP-ê li application_name zêde bike. Lê application_name ji hêla pêwendiyek zêde ve hatî danîn.
Li ser vê grafîkê, cihê ku xeta zer daxwazên rastîn e, û li ku derê xeta şîn daxwazên ku di nav databasê de difirin e. Û ev cûdahî bi rastî sazkirina application_name ye, ku tenê ji bo şopandinê hewce ye, lê ew qet ne belaş e.
Wekî din, di Bouncer de hûn nekarin yek hewzê, ango hejmara girêdanên databasê ji bo bikarhênerek taybetî, ji bo databasa taybetî sînordar bikin.
Ev ber bi çi ve dibe? We karûbarek barkirî heye ku bi C++ hatî nivîsandin û li cîhek nêzîk karûbarek piçûk li ser girêkek ku bi databasê re tiştek xirab nake, lê ajokera wê dîn dibe. Ew 20 girêdan vedike û her tiştê din dê li bendê bimîne. Tewra koda we jî normal e.
Me, bê guman, ji bo Bouncer pişkek piçûk nivîsand ku vê mîhengê zêde kir, ango xerîdaran li hewzê sînordar kir.
Dê mimkun be ku meriv vê yekê li alîyê Postgres bike, ango, rolên di databasê de bi hejmara girêdanan ve sînordar bike.
Lê dûv re hûn şiyana ku hûn fêm bikin çima pêwendiya we bi serverê re tune ne winda dikin. PgBouncer xeletiyek pêwendiyê nade, ew her gav heman agahdariyê vedigerîne. Û hûn nikarin fêm nakin: dibe ku şîfreya we guherî, dibe ku databas tenê winda bûye, dibe ku tiştek xelet e. Lê teşhîs tune. Ger danişînek neyê damezrandin, hûn ê nizanin çima ew nikare were damezrandin.
Di xalek diyar de, hûn li grafikên serîlêdanê dinêrin û dibînin ku serîlêdan nexebite.
Li jor binihêrin û bibînin ku Bouncer yek-têlek e. Ev di jiyana xizmetê de xalek veguherînek e. Hûn fêhm dikin ku we xwe amade dikir ku di salek û nîvê de databasê mezin bikin, û hûn hewce ne ku pîvana hevzêde bikin.
Em gihîştin vê encamê ku em hewceyê bêtir PgBouncers in.
Bouncer piçekî hatiye patch kirin.
Û wan wusa kir ku çend Bouncer bi ji nû ve karanîna porta TCP-ê werin rakirin. Û pergala xebitandinê bixweber girêdanên TCP-ê yên di navbera wan de bi karanîna dor-robin veguhezîne.
Ev ji xerîdaran re zelal e, tê vê wateyê ku we dixuye ku we yek Bouncer heye, lê we perçebûna girêdanên betal ên di navbera Bouncers dimeşîne de heye.
Û di demek diyarkirî de hûn dikarin bala xwe bidin ku ev 3 Bouncer her yek ji sedî 100 bingeha xwe dixwin. Ji we re çend Bouncer hewce ne. Çima?
Ji ber ku we TLS heye. Têkiliyek we ya şîfrekirî heye. Û heke hûn Postgres bi TLS û bêyî TLS-ê re pîvan bikin, hûn ê bibînin ku hejmara girêdanên damezrandî hema hema bi du rêzikên mezinahiyê digel şîfrekirina çalak dadikeve, ji ber ku desta TLS çavkaniyên CPU-yê dixwe.
Û li jor hûn dikarin çend fonksiyonên krîptografîk ên ku di dema pêlek girêdanên hatinê de têne darve kirin bibînin. Ji ber ku meya seretayî dikare di navbera deverên berdestbûnê de biguhezîne, pêlek girêdanên hatinî rewşek pir tîpîk e. Ango, ji ber hin sedeman seretayîya kevn tune bû, tevaya barkirinê ji navendek daneya din re hate şandin. Ew ê hemî werin ku di heman demê de ji TLS re silav bikin.
Û hejmareke mezin ji destên TLS-ê dibe ku êdî silavê nebêjin Bouncer, lê dê qirika wî biqelişe. Ji ber dema derbasbûnê, dibe ku pêla pêwendiyên hatinê nemir bibe. Ger hûn bêyî paşvekêşana berbiçav dîsa li bingehê biceribînin, ew ê dîsa û dîsa di pêlek hevgirtî de neyên.
Li vir mînakek 16 PgBouncers e ku 16 core li 100% bar dikin.
Em hatin kaskada PgBouncer. Ev konfigurasyona çêtirîn e ku dikare li ser barê me bi Bouncer re were bidestxistin. Bouncerên me yên derveyî ji bo destanên TCP-ê têne bikar anîn, û Bouncerên hundurîn jî ji bo berhevkirina rastîn têne bikar anîn, da ku têkiliyên derveyî pir zêde perçe nebin.
Di vê veavakirinê de, ji nû ve destpêkek hêsan gengaz e. Hûn dikarin van 18 Bouncers yek bi yek ji nû ve bidin destpêkirin. Lê domandina konfigurasyonek wusa pir dijwar e. Sysadmins, DevOps, û kesên ku bi rastî ji vê serverê berpirsiyar in dê ji vê rêkeftinê pir kêfxweş nebin.
Wusa dixuye ku hemî pêşkeftinên me dikarin li çavkaniya vekirî werin pêşve xistin, lê Bouncer pir baş nayê piştgirî kirin. Mînakî, şiyana xebitandina çend PgBouncers li ser yek portê mehek berê hate kirin. Çend sal berê bi vê taybetmendiyê daxwazek kişandinê hebû.
An jî mînakek din. Di Postgres de, hûn dikarin daxwazek di pêşkeftinê de betal bikin bi şandina razê ji pêwendiyek cûda re bêyî pejirandina nehewce. Lê hin xerîdar bi tenê vesazkirina TCP-ê dişînin, ango ew pêwendiya torê dişkînin. Bouncer dê çi bike? Ew ê tiştekî neke. Dê pêkanîna daxwazê bidome. Ger we hejmareke mezin ji girêdanên ku bi daxwazên piçûk databasek çêkirine wergirtine, wê hingê tenê qutkirina pêwendiyê ji Bouncer ne bes e; hûn jî hewce ne ku wan daxwazên ku di databasê de têne xebitandin temam bikin.
Ev hate xêz kirin û ev pirsgirêk hîna di jora jorîn a Bouncer de nehatiye yek kirin.
Ji ber vê yekê em gihîştin vê encamê ku em hewcedariya pêwendiya xweya xweya hewzê heye, ya ku dê were pêşve xistin, biqelînin, ku tê de pirsgirêk zû werin rast kirin û ya ku, bê guman, pêdivî ye ku pir-tewre be.
Me multithreading wekî karê sereke destnîşan kir. Pêdivî ye ku em karibin pêla girêdanên TLS-ê yên tê de baş bi rê ve bibin.
Ji bo vê yekê, me neçar bû ku pirtûkxaneyek cihê bi navê Machinarium pêşve bixin, ku ji bo danasîna rewşên makîneyê yên pêwendiya torê wekî kodek rêzdar hatî çêkirin. Ger hûn li koda çavkaniyê ya libpq binêrin, hûn ê hin bangên pir tevlihev bibînin ku dikarin encamek ji we re vegerînin û bibêjin, "Paşê gazî min bike. Heya nuha ji bo min IO heye, lê gava ku IO ji holê rabe ez ê barek li ser pêvajoyê hebe. Û ev planek pir-asta ye. Têkiliya torê bi gelemperî ji hêla makîneyek dewletê ve tê vegotin. Gelek qaîdeyên mîna "Heke min berê sernavek pakêtê ya bi mezinahiya N wergirt, naha ez li benda N byte me," "Heke min pakêtek SYNC şand, naha ez li benda pakêtek bi metadata encamê me." Encam kodek zehf dijwar, berevajî ye, mîna ku mazî ji bo şopandina rêzê were veguheztin. Me wisa kir ku li şûna makîneyek dewletê, bernamesaz riya bingehîn a danûstendinê di forma koda fermanî ya asayî de vedibêje. Tenê ev e ku di vê koda mecbûrî de hûn hewce ne ku cîhên ku rêzika darvekirinê lê hewce ye ku li benda daneya ji torê were qut kirin têxin nav xwe, ku çarçoweya darvekirinê derbasî kortînek din (mijara kesk) bikin. Ev nêzîkatî dişibihe wê yekê ku em riya herî bendewar a di mazî de li pey hev dinivîsin, û dûv re şaxên wê lê zêde dikin.
Wekî encamek, me yek mijarek heye ku TCP qebûl dike û dor-robin pêwendiya TPC ji gelek karkeran re derbas dike.
Di vê rewşê de, her pêwendiya xerîdar her gav li ser yek pêvajoyê dimeşe. Û ev dihêle hûn wê cache-heval bikin.
Wekî din, me berhevkirina pakêtên piçûk di pakêtek mezin de hinekî çêtir kiriye da ku stûyê TCP-ya pergalê rehet bike.
Digel vê yekê, me berhevkirina danûstendinê çêtir kiriye di vê wateyê de ku Odyssey, dema ku were mîheng kirin, dikare di bûyera têkçûna pêwendiya torê de BETAL û REŞANDIN bişîne, ango heke kes li benda daxwazekê nebe, Odyssey dê ji databasê re bêje ku hewl nede. daxwaza ku dibe ku çavkaniyên giranbiha winda bike pêk bîne.
Û gava ku gengaz be, em girêdanên bi heman xerîdar re digirin. Ev ji nûve sazkirina application_name_add_host dûr dikeve. Ger ev gengaz be, wê hingê ne hewce ye ku em pêvekên ku ji bo tespîtkirinê hewce ne ji nû ve vegerînin.
Em di berjewendiya Yandex.Cloud de dixebitin. Û heke hûn PostgreSQL-ya birêvebir bikar bînin û hewzek pêwendiyê saz bikin, hûn dikarin berevajîkirina mentiqî li derve biafirînin, ango, heke hûn bixwazin, ji me re bihêlin, bi karanîna rengdêriya mantiqî. Bouncer dê herikîna dubarekirina mantiqî li derve bernede.
Ev mînakek sazkirina dubarekirina mentiqî ye.
Digel vê yekê, me ji bo dubarekirina laşî li derve piştgirî heye. Di Cloud de, bê guman, ev ne gengaz e, ji ber ku wê hingê kom dê di derheqê xwe de pir agahdarî bide we. Lê di sazkirinên we de, heke hûn hewceyê dubarekirina laşî bi navgîniya pêwendiya pêwendiyê li Odyssey, ev gengaz e.
Odyssey bi PgBouncer re çavdêriya bi tevahî lihevhatî heye. Me heman konsolê heye ku hema hema hemî heman fermanan dimeşîne. Ger tiştek wenda be, daxwazek kişandinê, an bi kêmanî pirsgirêkek li ser GitHub bişînin, û em ê emrên pêwîst temam bikin. Lê me jixwe fonksiyona sereke ya konsolê PgBouncer heye.
Û, bê guman, şandina xeletiya me heye. Em ê xeletiya ku ji hêla databasê ve hatî ragihandin vegerînin. Hûn ê agahdarî bistînin ka çima hûn di databasê de ne, û ne tenê ku hûn di nav wê de ne.
Di rewşa ku hûn hewcedariya 100% lihevhatina bi PgBouncer re hewce bikin ev taybetmendî neçalak e. Em dikarin bi heman rengî wekî Bouncer tevbigerin, tenê ji bo ku li tenişta ewle bin.
Pêşveçûn
Çend peyvan li ser koda çavkaniyê ya Odyssey.
Mînakî, emrên "Pause / Resume" hene. Ew bi gelemperî ji bo nûvekirina databasê têne bikar anîn. Heke hûn hewce ne ku Postgres nûve bikin, wê hingê hûn dikarin wê di hewza pêwendiyê de rawestînin, pg_upgrade bikin, dûv re ji nû ve bidin destpêkirin. Û ji hêla xerîdar ve ew ê wekî ku databas bi hêsanî hêdî dibe xuya bike. Ev fonksîyon ji aliyê kesên ji civakê ve ji me re hat. Ew hîn cemidî nebûye, lê di nêzîk de dê her tişt bibe. (Jixwe cemidî ye)
- jixwe cemidî
Digel vê yekê, yek ji taybetmendiyên nû yên li PgBouncer piştgirîkirina SCRAM Authentication e, ku ew jî ji hêla kesek ku li Yandex.Cloud-ê naxebite ji me re anî. Her du fonksiyonên tevlihev û girîng in.
Ji ber vê yekê, ez dixwazim ji we re bibêjim Odyssey ji çi hatî çêkirin, heke hûn jî dixwazin nuha kodek piçûk binivîsin.
We bingeha çavkaniya Odyssey heye, ku xwe dispêre du pirtûkxaneyên sereke. Pirtûkxaneya Kiwi pêkanîna protokola peyama Postgres e. Ango, proto 3-ya xwecihî ya Postgres peyamên standard e ku pêş-end û paşîn dikarin biguhezînin. Ew di pirtûkxaneya Kiwi de têne bicihkirin.
Pirtûkxaneya Machinarium pirtûkxaneyek bicîhkirina mijarê ye. Parçeyek piçûk ji vê Machinariumê bi zimanê meclîsê hatiye nivîsandin. Lê netirsin, tenê 15 rêz hene.
mîmariya Odyssey. Makîneyek sereke heye ku korutîn li ser dimeşîne. Vê makîneyê pejirandina girêdanên TCP-ê yên hatî û wan di nav karkeran de belav dike.
Rêvebirek ji bo çend xerîdar dikare di hundurê yek karker de bixebite. Mijara sereke di heman demê de konsolê û hilanîna karên kronê dimeşîne da ku girêdanên ku êdî di hewzê de ne hewce ne jêbirin.
Odyssey bi karanîna testa standard ya Postgres ve tê ceribandin. Em tenê bi Bouncer-ê û bi navgîniya Odyssey ve sazkirin-kontrolê dimeşînin, em div-ya null distînin. Gelek îmtîhanên bi formatkirina dîrokê ve girêdayî hene ku di Bouncer û Odyssey de tam eynî derbas nakin.
Wekî din, gelek ajokarên ku ceribandina xwe hene hene. Û em ceribandinên wan bikar tînin ku Odyssey biceribînin.
Digel vê yekê, ji ber veavakirina kaskada me, pêdivî ye ku em cûrbecûr pakêtan biceribînin: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey da ku em pê bawer bin ku ger Odyssey di yek ji beşên kaskadê de biqede, ew jî hîn jî dixebite. wek ku em hêvî dikin.
Rake
Em Odyssey di hilberînê de bikar tînin. Û eger ez bibêjim ku her tişt tenê dixebite, dê ne adil be. Na, ew e, erê, lê ne her gav. Mînakî, di hilberînê de her tişt tenê xebitî, dûv re hevalên me yên ji PostgreSQL Professional hatin û gotin ku me lekeyek bîranînê heye. Bi rastî ew bûn, me ew rast kirin. Lê ew hêsan bû.
Dûv re me kifş kir ku hewza pêwendiyê girêdanên TLS-ê yên tê û girêdanên TLS-ê yên derketinê hene. Û pêwendiyan sertîfîkayên xerîdar û sertîfîkayên serverê hewce dike.
Sertîfîkayên servera Bouncer û Odyssey ji hêla pcache-ya xwe ve ji nû ve têne xwendin, lê sertîfîkayên xerîdar ne hewce ne ku ji pcache-ê ji nû ve werin xwendin, ji ber ku Odyssey-ya meya berbelav di dawiyê de di xwendina vê sertîfîkayê de dikeve nav performansa pergalê. Ev yek ji me re surprîzek bû, ji ber ku wî demek dirêj li ber xwe neda. Di destpêkê de ew bi rengek xêzkirî mezin bû, lê piştî 20 girêdanên hevdemî hatin vê pirsgirêkê xwe nîşan da.
Rêbaza Nasnameya Pluggable şiyana rastkirina bi karanîna amûrên Lunux-ê yên çêkirî ye. Di PgBouncer de ew bi vî rengî tête bicîh kirin ku mijarek veqetandî heye ku li benda bersivek ji PAM-ê bimîne û mijarek sereke ya PgBouncer heye ku girêdana heyî xizmet dike û dikare ji wan bixwaze ku di mijara PAM-ê de bijîn.
Me ev yek ji ber sedemek hêsan pêk neanî. Gelek mijarên me hene. Çima em hewceyê vê yekê ne?
Ev di dawiyê de dikare pirsgirêkan biafirîne ku heke we piştrastkirina PAM û ne-PAM-ê hebe, wê hingê pêlek mezin a rastkirina PAM-ê dikare bi girîngî pejirandina ne-PAM dereng bike. Ev yek ji wan tiştan e ku me rast nekiriye. Lê heke hûn dixwazin wê rast bikin, hûn dikarin vê yekê bikin.
Rakerek din jî ev bû ku me yek mijarek heye ku hemî girêdanên gihîştî qebûl dike. Dûv re ew têne veguheztin hewza karkeran, ku li wir dê destana TLS pêk were.
Rêza jêrîn, heke we pêlek hevgirtî ya 20 girêdanên torê hebe, ew ê hemî bêne pejirandin. Û li aliyê xerîdar libpq dê dest bi raporkirina demjimêran bike. Ji hêla xwerû ve ew 000 saniye xuya dike.
Heke ew hemî nikaribin di heman demê de têkevin databasê, wê hingê ew nikanin têkevin databasê, ji ber ku ev hemî dikare bi ceribandina ne-tevgerî were vegirtin.
Em gihîştin wê encamê ku me nexşerêya ji PgBouncer li vir kopî kir bi vê yekê ku me hejmara girêdanên TCP-ê yên ku em qebûl dikin kêm kirine.
Ger em bibînin ku em pêwendiyan qebûl dikin, lê di dawiyê de wextê wan tune ku destan bihejînin, em wan dixin rêzê da ku ew çavkaniyên CPU winda nekin. Ev dibe sedema vê yekê ku dibe ku ji bo hemî girêdanên ku gihîştine destanek hevdem neyê kirin. Lê bi kêmanî kesek dê têkeve databasê, her çend bar pir giran be.
nexşerêyeke
Hûn dixwazin di pêşerojê de di Odyssey de çi bibînin? Em amade ne ku xwe bi pêş bixin û çi ji civakê hêvî dikin?
Ji Tebax 2019.
Nexşeya rê ya Odyssey di Tebaxê de ev e:
- Me piştrastkirina SCRAM û PAM dixwest.
- Me xwest ku daxwazên xwendinê bigihînin standby.
- Ez ji nû ve destpêkirina serhêl dixwazim.
- Û şiyana sekinandina li ser serverê.
Nîvê vê nexşerêyê temam bûye, ne ji aliyê me ve. Û ev baş e. Ji ber vê yekê em bipeyivin ka çi dimîne û bêtir zêde bike.
? Bersivên me hene ku bêyî pêkanîna daxwazan dê hewa germ bikin. Pêwîstiya me bi wan heye ku têkçûn û veguherînê peyda bikin. Di rewşên pirsgirêkên li yek ji navendên daneyê de, ez dixwazim wan bi hin karên kêrhatî re mijûl bikim. Ji ber ku em nikarin heman pêvajoyên navendî, heman bîranînê bi rengek cûda mîheng bikin, ji ber ku wekî din dubarekirin dê nexebite.
Di prensîbê de, di Postgres de, ji 10-an dest pê dike, dema ku tê girêdan gengaz e ku meriv session_attrs diyar bike. Hûn dikarin hemî mêvandarên databasê di pêwendiyê de navnîş bikin û bibêjin çima hûn diçin databasê: tenê binivîsin an bixwînin. Û ajokar bixwe dê di navnîşê de mêvandarê yekem hilbijêrin ku ew çêtirîn jê hez dike, ku hewcedariyên session_attrs pêk tîne.
Lê pirsgirêka vê nêzîkbûnê ev e ku ew derengiya dubarekirinê kontrol nake. Dibe ku hin kopiyek we hebe ku ji bo karûbarê we demek nepejirandî li paş maye. Ji bo ku em pêkanîna tev-taybetmendî ya pirsên xwendinê li ser kopiyek çalak bikin, di bingeh de pêdivî ye ku em piştgirî bidin kapasîteya Odyssey ku dema ku neyê xwendin nexebite.
Pêdivî ye ku Odyssey dem bi dem biçe databasê û dûrbûna dubarekirinê ji ya seretayî bipirse. Û heke ew gihîştiye nirxa sînor, destûr nedin daxwazên nû di nav databasê de, ji xerîdar re bêjin ku ew hewce dike ku ji nû ve girêdanan bide destpêkirin û, dibe ku, mêvandarek din hilbijêrin da ku daxwazan bicîh bîne. Ev ê dihêle ku databas zû derengiya dubarekirinê sererast bike û dîsa vegere da ku bi daxwazek bersiv bide.
Zehmet e ku meriv çarçoveyek dem ji bo bicîhkirinê bide, ji ber ku ew çavkaniya vekirî ye. Lê, ez hêvî dikim, ne 2,5 sal mîna hevkarên min ji PgBouncer. Ev taybetmendiya ku ez dixwazim di Odyssey de bibînim ev e.
. Naha hûn dikarin bi du awayan daxuyaniyek amade bikin. Pêşîn, hûn dikarin fermana SQL, ango "amadekirî" bicîh bikin. Ji bo ku em vê fermana SQL fam bikin, pêdivî ye ku em fêr bibin ku SQL li alîyê Bouncer fam bikin. Ev ê pir zêde be, ji ber ku ew pir zêde ye, ji ber ku em hewceyê tevahiya parserê ne. Em nikarin her fermana SQL parsek bikin.
Lê di asta protokola peyamê de li ser proto3 daxuyaniyek amadekirî heye. Û ev cîh e ku dema ku agahdariya ku daxuyaniyek amadekirî tête çêkirin bi rengek birêkûpêk tê. Û em dikarin piştgirî bidin têgihiştina ku li ser hin girêdana serverê xerîdar xwest ku daxuyaniyên amade biafirîne. Û her çend danûstendin girtî be jî, em hîn jî hewce ne ku pêwendiya di navbera server û xerîdar de biparêzin.
Lê li vir nakokiyek di diyalogê de derdikeve holê, ji ber ku kesek dibêje ku hûn hewce ne ku hûn fêm bikin ka xerîdar çi cûre daxuyaniyên amade afirandiye û girêdana serverê di navbera hemî xerîdarên ku ev pêwendiya serverê afirandine de parve bikin, ango, kê daxuyaniyek wusa amade afirandiye.
Andres Freund got ku ger xerîdarek were ba we ku berê di girêdanek serverek din de daxuyaniyek wusa amade çêkiriye, wê hingê wê ji wî re biafirînin. Lê hindek xelet xuya dike ku li şûna xerîdar lêpirsînan di databasê de bicîh bikin, lê ji hêla pêşdebirê ku protokola danûstandina bi databasê re dinivîse, dê rehet be ger ku ew bi tenê pêwendiyek torê were dayîn ku tê de pirseke wisa amadekirî heye.
Û taybetmendiyek din ku divê em bicîh bikin. Naha me çavdêriya ku bi PgBouncer re hevaheng e heye. Em dikarin dema darvekirina pirsê ya navîn vegerînin. Lê dema navîn germahiya navîn e li nexweşxaneyê: hin sar in, hin germ in - bi navînî, her kes saxlem e. Ew ne rast e.
Pêdivî ye ku em piştgirîya ji bo sedî bicîh bikin, ku dê destnîşan bike ku pirsên hêdî hene ku çavkaniyan winda dikin û dê çavdêrîkirina bêtir meqbûl bike.
Ya herî girîng ev e ku ez guhertoya 1.0 dixwazim (Guhertoya 1.1 berê derketiye). Rastî ev e ku Odyssey naha di guhertoya 1.0rc de ye, ango berendamê berdanê. Û hemî pirsgirêkên ku min navnîş kirin bi tam heman guhertoyê ve hatin sererast kirin, ji bilî rijandina bîranînê.
Wê guhertoya 1.0 ji bo me çi be? Em Odyssey ber bi bingehên xwe ve radikin. Ew jixwe li ser databasên me dimeşîne, lê gava ku ew digihîje nuqteya 1 daxwazî di çirkeyê de, wê hingê em dikarin bibêjin ku ev guhertoya berdanê ye û ev guhertoyek e ku dikare jê re 000 were gotin.
Gelek kesên di civatê de xwestine ku guhertoya 1.0 pause û SCRAM bihewîne. Lê ev ê tê vê wateyê ku em ê hewce bikin ku guhertoya paşîn ji hilberînê re derxînin, ji ber ku ne SCRAM û ne jî rawestin hîn nehatine kuştin. Lê, bi îhtîmaleke mezin, ev pirsgirêk dê pir zû çareser bibe.
Ez li benda daxwaza te ya kişandinê me. Ez jî dixwazim bibihîzim ka çi pirsgirêkên we bi Bouncer re hene. Werin em wan nîqaş bikin. Dibe ku em dikarin hin fonksiyonên ku hûn hewce ne bicîh bikin.
Ev dawiya beşa min e, ez dixwazim li we guhdarî bikim. Sipas ji were!
Pirsên
Ger ez serlêdana_navê xwe destnîşan bikim, gelo ew ê rast were şandin, tevî berhevkirina danûstendinê li Odyssey?
Odyssey an Bouncer?
Di Odyssey. Di Bouncer de tê avêtin.
Em ê setek çêbikin.
Û ger pêwendiya min a rastîn li ser girêdanên din bisekine, gelo ew ê were veguheztin?
Em ê komek ji hemî pîvanên ku di navnîşê de têne navnîş kirin çêbikin. Ez nikarim bibêjim ka application_name di vê navnîşê de ye. Ez difikirim ku min ew li wir dît. Em ê hemî heman pîvanan saz bikin. Bi yek daxwazek, set dê her tiştê ku di dema destpêkirinê de ji hêla xerîdar ve hatî saz kirin bike.
Spas, Andrey, ji bo raporê! Raporta baş! Ez kêfxweş im ku Odyssey her hûrdem zûtir û zûtir pêş dikeve. Ez dixwazim bi vî awayî berdewam bikim. Me berê ji we xwestiye ku hûn pêwendiyek pir-çavkaniya daneyê hebe da ku Odyssey bi hevdemî bi databasên cihêreng ve girêbide, ango xulamek master, û dûv re bixweber piştî têkçûn bi serwerek nû ve were girêdan.
Erê, dixuye ku ev nîqaş tê bîra min. Niha gelek depo hene. Lê di navbera wan de ti guhertin tune. Ji hêla xwe ve, divê em serverê rapirsin ku ew hîn jî sax e û fêm bikin ku têkçûnek çêbûye, kî dê gazî pg_recovery bike. Ez rêgezek standard a têgihîştinê heye ku em nehatine cem axayê. Û divê em bi awayekî ji xeletiyan fêm bikin an çi? Yanî fikir balkêş e, tê nîqaşkirin. Bêtir şîroveyan binivîsin. Ger we xebatkarên ku C dizanin hene, wê hingê ew pir baş e.
Pirsgirêka pîvandina li ser kopiyan jî ji me re eleqedar e, ji ber ku em dixwazin pejirandina komikên dubarekirî ji bo pêşdebirên serîlêdanê bi qasî ku pêkan hêsan bikin. Lê li vir ez bêtir şîroveyan dixwazim, ango tam çawa bikim, meriv çawa baş bike.
Pirs jî li ser replicayan e. Derket holê ku we masterek û çend kopiyên we hene. Û eşkere ye ku ew ji bo girêdanan kêmtir caran ji masterê re diçin kopiyê, ji ber ku dibe ku cûdahiyên wan hebin. We got ku dibe ku cûdahiya daneyan wusa be ku ew karsaziya we têr neke û hûn ê neçin wir heya ku ew dubare nebe. Di heman demê de, heke hûn demek dirêj neçûn wir, û dûv re dest bi çûnê kir, wê hingê daneyên ku hewce ne dê tavilê peyda bibin. Ango, heke em bi domdarî herin cem master, wê hingê cache li wir germ dibe, lê di replica de cache piçekî dereng dimîne.
Erê rast e. Dê pcache ne xwediyê blokên daneya ku hûn dixwazin bin, kacheya rastîn dê di derheqê tabloyên ku hûn dixwazin de agahdarî nebin, dê planan ne pirsên parskirî bin, dê qet tiştek tune be.
Û gava ku we celebek komek hebe, û hûn li wir kopiyek nû lê zêde bikin, wê hingê dema ku ew dest pê dike, her tişt tê de xirab e, ango ew cacheya xwe zêde dike.
Min fikir girt. Nêzîkatiya rast dê ev be ku meriv rêjeyek piçûk a pirsan li ser kopiyê pêşî bimeşîne, ku dê cache germ bike. Bi gelemperî, şertek me heye ku divê em ji 10 saniyeyan zêdetir li paş axayê xwe nemînin. Û ev rewş ne di yek pêlekê de, lê ji bo hin xerîdar bi hêsanî tête nav kirin.
Erê, giraniya xwe zêde bike.
Ev fikreke baş e. Lê pêşî divê em vê girtinê pêk bînin. Pêşî pêdivî ye ku em vemirînin, û dûv re em ê bifikirin ka meriv çawa vemirîne. Ev taybetmendiyek mezin e ku meriv bi hêsanî çalak bike.
Nginx ev vebijark heye slowly start di komekê de ji bo serverê. Û ew hêdî hêdî bargiraniyê zêde dike.
Erê, ramanek mezin, dema ku em li dora wê bigerin em ê wê biceribînin.
Source: www.habr.com