In u so discorsu, Andrey Borodin vi diciarà cumu anu pigliatu in contu l'esperienza di a scala PgBouncer quandu cuncepisce un pooler di cunnessione. , cumu si stende in a pruduzzione. Inoltre, discuteremu quali funzioni di u pooler vulemu vede in novi versioni: hè impurtante per noi micca solu per copre i nostri bisogni, ma per sviluppà a cumunità d'utilizatori. .
Video:
Salut à tutti ! Mi chjamu Andrew.
À Yandex, aghju sviluppatu basa di dati open source. È oghje avemu un tema nantu à e cunnessione pooler di cunnessione.
Se sapete cumu chjamà pooler di cunnessione in russo, allora dimmi. Vogliu veramente truvà un bonu termu tecnicu chì deve esse stabilitu in a literatura tecnica.
U tema hè abbastanza cumplicatu, perchè in parechje basa di dati u pooler di cunnessione hè integratu è ùn avete mancu bisognu di sapè. Certi paràmetri, sicuru, sò in ogni locu, ma in Postgres questu ùn funziona micca. È in parallelu (in HighLoad++ 2019) ci hè un rapportu di Nikolai Samokhvalov nantu à a creazione di e dumande in Postgres. E capiscu chì e persone sò ghjunte quì chì anu digià cunfiguratu richieste perfettamenti, è queste sò persone chì sò affruntate cù prublemi di sistema più rari in relazione à a reta, l'utilizazione di risorse. È in certi lochi pò esse abbastanza difficiule in u sensu chì i prublemi ùn sò micca evidenti.
Yandex hà Postgres. Parechji servizii Yandex campanu in Yandex.Cloud. È avemu parechji petabytes di dati chì generanu almenu un milione di richieste per seconda in Postgres.
È furnimu un cluster abbastanza tipicu per tutti i servizii - questu hè u node primariu principale di u node, i soliti dui rèplichi (sincroni è asincroni), copia di salvezza, scala di e dumande di lettura nantu à a replica.
Ogni node di cluster hè Postgres, nantu à quale, in più di Postgres è sistemi di monitoraghju, hè ancu installatu un pooler di cunnessione. Connection pooler hè utilizatu per l'esgrima è per u so scopu principale.
Chì ghjè u scopu principale di un pooler di cunnessione?
Postgres adopta un mudellu di prucessu per travaglià cù una basa di dati. Questu significa chì una cunnessione hè un prucessu, un backend Postgres. E ci sò parechje cache diverse in questu backend, chì sò abbastanza caru per fà diverse per e diverse cunnessione.
Inoltre, ci hè un array in u codice Postgres chjamatu procArray. Contene dati basi nantu à e cunnessione di rete. È quasi tutti l'algoritmi di trasfurmazioni di procArray anu una cumplessità lineale, passanu per tutta l'array di cunnessione di rete. Hè un ciculu abbastanza veloce, ma cù più cunnessione di rete entranti, e cose diventanu un pocu più caru. È quandu e cose diventanu un pocu più caru, finiscinu per pagà un prezzu assai altu per un gran numaru di cunnessione di rete.
Ci sò 3 approcci pussibuli:
- Da u latu di l'applicazione.
- Da u latu di a basa di dati.
- È trà, vale à dì, tutte e cumminazzioni pussibuli.
Sfortunatamente, u pooler integratu hè attualmente in sviluppu. L'amici di PostgreSQL Professional facenu questu soprattuttu. Quandu apparirà hè difficiule di predichendu. È in fattu, avemu dui suluzioni per a scelta di un architettu. Quessi sò u pool di l'applicazione è u pool proxy.
A piscina di l'applicazione hè u modu più faciule. È quasi tutti i cunduttori di u cliente vi furniscenu un modu: per rapprisintà milioni di e vostre cunnessione in u codice cum'è qualchi decine di cunnessione à a basa di dati.
Ci hè un prublema cù u fattu chì in un certu puntu vo vulete scalà u backend, vulete implementà à parechje macchine virtuale.
Allora avete sempre capitu chì avete parechje più zoni di dispunibilità, parechji centri di dati. È l'approcciu di pooling side di u cliente porta à grandi numeri. I grandi sò circa 10 000 cunnessione. Questu hè un bordu chì pò travaglià bè.
Se parlemu di proxy poolers, allora ci sò dui poolers chì ponu fà assai cose. Ùn sò micca solu poolers. Sò poolers + funziunalità più cool. Questu и .
Ma, sfurtunatamenti, micca tutti bisognu di sta funziunalità supplementu. È porta à u fattu chì i poolers supportanu solu a pooling di sessione, vale à dì un cliente entrante, un cliente in uscita à a basa di dati.
Questu ùn hè micca assai adattatu per i nostri compiti, cusì usemu PgBouncer, chì implementa a transazzione pooling, vale à dì chì e cunnessione di u servitore sò mappate à e cunnessione di u cliente solu per a durata di a transazzione.
È nantu à a nostra carica - hè vera. Ma ci sò parechji prublemi.
I prublemi cumincianu quandu vulete diagnosticà una sessione, perchè tutte e cunnessione entrate sò lucali. Tutti sò ghjunti cun loopback è in qualchì manera diventa difficiule di traccia a sessione.
Di sicuru, pudete aduprà application_name_add_host. Questu hè u modu Bouncer side per aghjunghje un indirizzu IP à l'applicazione_name. Ma application_name hè stabilitu da una cunnessione supplementu.
In questu graficu, induve a linea gialla hè dumande reali, è induve a linea blu hè e dumande chì volanu in a basa di dati. E sta diferenza hè precisamente l'impostazione di application_name, chì hè necessariu solu per a traccia, ma ùn hè micca in tuttu liberu.
Inoltre, Bouncer ùn pò micca limità una piscina, vale à dì u numeru di cunnessione di basa di dati per utilizatore, per basa di dati.
Chì porta questu? Avete un serviziu carricu scrittu in C ++ è in un locu vicinu à un picculu serviziu nantu à un node chì ùn face nunda di male cù a basa, ma u so cunduttore torna pazza. Apre 20 000 cunnessione è tuttu u restu aspittà. Ancu u vostru codice hè currettu.
Di sicuru, avemu scrittu un picculu patch per Bouncer chì aghjunghjenu sta paràmetra, vale à dì limità i clienti à a piscina.
Puderia esse fattu in u latu di Postgres, vale à dì, limità i roli in a basa di dati à u numeru di cunnessione.
Ma allora si perde a capacità di capisce perchè ùn avete micca cunnessione à u servitore. PgBouncer ùn tira micca un errore di cunnessione, torna sempre a stessa informazione. È ùn pudete micca capisce: forsi a vostra password hè cambiata, forse a basa di dati hè cascata, forse qualcosa hè sbagliatu. Ma ùn ci hè micca diagnosi. Se a sessione ùn pò esse stabilita, ùn sapete micca perchè ùn pò micca esse fattu.
À un certu puntu, guardate i grafici di l'applicazione è vede chì l'applicazione ùn funziona micca.
Fighjate à a cima è vede chì Bouncer hè unicu filatu. Questu hè un puntu di svolta in a vita di u serviziu. Avete capitu chì avete preparatu per scala a basa di dati in un annu è mezu, è avete bisognu di scala u pooler.
Avemu ghjuntu à a cunclusione chì avemu bisognu di più PgBouncers.
Bouncer hè statu un pocu patched.
E anu fattu cusì chì parechji Bouncers ponu esse risuscitati cù a reutilizazione di u portu TCP. È digià u sistema upirativu trasferimentu automaticamente cunnessioni TCP entranti trà elli da round-robin'om.
Questu hè trasparente per i clienti, vale à dì chì pare chì avete un Bouncer, ma avete frammentazione di cunnessione inattivu trà Bouncers in esecuzione.
È à qualchì puntu, pudete nutà chì questi 3 Bouncers manghjanu u so core da 100%. Avete bisognu di uni pochi di Bouncers. Perchè?
Perchè avete TLS. Avete una cunnessione criptata. È se benchmark Postgres cù è senza TLS, truverete chì u numeru di cunnessione stabilite cade da quasi dui ordini di grandezza cù a criptografia attivata, perchè u TLS handshake cunsuma risorse CPU.
È in a cima, pudete vede parechje funzioni criptografiche chì sò eseguite durante una onda di cunnessione entranti. Siccomu a nostra primaria pò cambià trà e zoni di dispunibilità, una onda di cunnessione in entrata hè una situazione abbastanza tipica. Questu hè, per qualchì mutivu, u vechju primariu ùn era micca dispunibule, tutta a carica hè stata mandata à un altru centru di dati. Tutti venenu à salutà TLS à u stessu tempu.
È un gran numaru di TLS handshake ùn pò micca salutà à Bouncer digià, ma stringhje a so gola. Una onda di cunnessione in entrata pò esse undamped per via di u timeout. Sì avete un ritruvà à a basa senza un backoff esponenziale, ùn torneranu più è torna in una onda coherente.
Eccu un esempiu di 16 PgBouncers chì caricanu 16 core à 100%.
Avemu ghjuntu à a cascata PgBouncer. Questa hè a megliu cunfigurazione chì pudemu ottene nantu à a nostra carica Bouncer. I nostri Bouncers esterni servenu per TCP handshake, è i Bouncers interni servenu per un veru pooling, per ùn frammentà assai e cunnessione esterne.
In questa cunfigurazione, un riavviu suave hè pussibule. Pudete riavvia tutti questi 18 Bouncers unu per unu. Ma mantene una tale cunfigurazione hè abbastanza difficiule. L'amministratori di u sistema, DevOps, è e persone chì sò veramente rispunsevuli di stu servitore ùn saranu micca assai cuntenti cù stu schema.
Sembra chì tutte e nostre migliure ponu esse promossi in open source, ma Bouncer ùn sustene micca bè. Per esempiu, a capacità di eseguisce parechje PgBouncers nantu à u stessu portu hè stata cummessa un mese fà. Una dumanda di pull cù sta funzione era uni pochi anni fà.
O un altru esempiu. In Postgres, pudete annullà una dumanda in esecuzione mandendu u sicretu à una altra cunnessione senza l'autentificazione extra. Ma certi clienti simpricimenti mandanu un TCP-reset, vale à dì chì rompenu a cunnessione di a rete. Chì farà Bouncer cun questu? Ùn farà nunda. Continuerà à eseguisce a dumanda. Sè avete ricevutu un gran numaru di cunnessione chì anu stabilitu a basa cù petite richieste, allora solu disconnecting the connection from Bouncer ùn serà micca abbastanza, avete sempre bisognu di cumpiendu quelli richieste chì sò in esecuzione in a basa di dati.
Questu hè statu patchatu è u prublema ùn hè ancu unitu in l'upstream di Bouncer.
È cusì avemu ghjuntu à a cunclusione chì avemu bisognu di u nostru propiu pooler di cunnessione, chì serà sviluppatu, patched, in quale serà pussibule di risolve rapidamente i prublemi è chì, sicuru, deve esse multi-threaded.
Avemu stabilitu multithreading cum'è u compitu principale. Avemu bisognu di pudè trattà bè l'onda di cunnessione TLS entranti.
Per fà questu, avemu avutu à sviluppà una libreria separata chjamata Machinarium, chì hè designatu per discriverà i stati di a macchina di una cunnessione di rete cum'è un codice seriale. Se guardate u codice fonte libpq, vi vede chjami abbastanza cumplessi chì ponu rinvià un risultatu à voi è dì: "Chjamate un pocu dopu. Avà aghju IO per avà, ma quandu l'IO passa, aghju una carica nantu à u processatore. È questu hè un schema multi-livellu. L'interazzione di a rete hè generalmente descritta da una macchina statale. Un saccu di regule cum'è "Se prima aghju ricevutu un pacchettu di pacchettu di taglia N, allora avà aghju aspittatu N bytes", "Se aghju mandatu un pacchettu SYNC, allora aghju aspittatu un pacchettu cù metadata di u risultatu". Risulta un codice contru-intuitivu piuttostu difficiule, cum'è se u labirintu hè statu cunvertitu in una scansione di linea. Avemu fattu cusì chì invece di una macchina statale, u programatore descrive a strada di interazzione principale in forma di codice imperativu ordinariu. Solu in questu codice imperativu, avete bisognu di inserisce i posti induve a sequenza di esecuzione deve esse interrotta da aspittendu dati da a reta, passendu u cuntestu di esecutivu à un altru coroutine (filu verde). Stu approcciu hè simile à u fattu chì avemu scrittu u percorsu più aspittatu in u labirintu in una fila, è poi aghjunghje rami.
In u risultatu, avemu un filu chì face un TCP accettà è round-robin passa una cunnessione TPC à parechji travagliadori.
In questu casu, ogni cunnessione di u cliente viaghja sempre nantu à un processore. È questu permette di fà u cache-friendly.
È in più, avemu ligeramente migliuratu a cullizzioni di picculi pacchetti in un grande pacchettu in modu di scaricate a pila TCP di u sistema.
Inoltre, avemu migliuratu u pooling transazionale in u sensu chì Odyssey, quandu cunfiguratu, pò mandà CANCEL è ROLLBACK in casu di un fallimentu di cunnessione di a rete, vale à dì, se nimu ùn aspetta per a dumanda, Odyssey diciarà à a basa di dati di ùn pruvà micca à cumpiendu. a dumanda chì pò perdi risorse preziose.
È sempre chì hè pussibule, mantenemu cunnessione cù u stessu cliente. Questu evita di avè da reinstallà application_name_add_host. Sè pussibule, ùn avemu micca un resettore supplementu di i paràmetri chì sò necessarii per u diagnosticu.
Travagliemu in l'interessi di Yandex.Cloud. È sì aduprate PostgreSQL gestitu è avete installatu un pooler di cunnessione, pudete creà una replicazione logica in l'esternu, vale à dì lasciateci se vulete, utilizendu replicazione logica. Bouncer fora di u flussu di replicazione logica ùn darà micca.
Questu hè un esempiu di stallà a replicazione logica.
Inoltre, avemu un supportu per a replicazione fisica esterna. In u Cloud, sicuru, hè impussibile, perchè allora u cluster vi darà troppu infurmazione nantu à ellu stessu. Ma in e vostre installazioni, se avete bisognu di replicazione fisica via pooler di cunnessione in Odyssey, hè pussibule.
Odyssey hà un monitoraghju cumplettamente cumpatibile cù PgBouncer. Avemu a stessa cunsola chì eseguisce quasi tutti i stessi cumandamenti. Se qualcosa manca, mandate una dumanda di pull, o almenu un prublema in GitHub, compieremu i cumandamenti necessarii. Ma avemu digià a funziunalità principale di a cunsola PgBouncer.
È di sicuru avemu l'invio d'errore. Ritornaremu l'errore signalatu da a basa. Truverete infurmazione perchè ùn site micca in a basa, micca solu chì ùn site micca in questu.
Questa funzione hè disattivata in casu avete bisognu di cumpatibilità 100% cù PgBouncer. Pudemu cumportà cum'è Bouncer, in casu.
Sviluppu
Uni pochi parolle nantu à u codice fonte Odyssey.
Per esempiu, ci sò cumandamenti "Pause / Resume". Sò generalmente usati per aghjurnà a basa di dati. Sè avete bisognu di aghjurnà Postgres, pudete mette in pausa in u pooler di cunnessione, fate un pg_upgrade, poi ripiglià. È da u latu di u cliente, parerà chì a basa di dati era solu rallentata. Sta funziunalità hè stata purtata à noi da e persone di a cumunità. Ùn hè ancu morta, ma prestu tuttu serà. (digià mortu)
- digià mortu
Inoltre, una di e funzioni novi in PgBouncer hè u supportu di autentificazione SCRAM, chì hè statu ancu purtatu à noi da una persona chì ùn travaglia micca in Yandex.Cloud. Tutti dui sò funziunalità cumplessu è impurtanti.
Per quessa, vogliu dì ciò chì hè fatta di l'Odissea, in casu chì vulete ancu scrive qualchì codice avà.
Avete a basa originale Odyssey, chì si basa in duie biblioteche principali. A biblioteca Kiwi hè una implementazione di u protocolu di messagiu Postgres. Questu hè, u proto 3 nativu di Postgres hè messagi standard chì i frontend è i backend ponu scambià. Sò implementati in a biblioteca Kiwi.
A libreria Machinarium hè una libreria di implementazione di thread. Un picculu fragmentu di stu Machinarium hè scrittu in assembler. Ma ùn vi preoccupate, ci sò solu 15 linee.
Odissea architettura. Ci hè una macchina principale chì esegue coroutines. Questa macchina implementa l'accettazione di cunnessione TCP entranti è a distribuzione trà i travagliadori.
Dentru un travagliadore, un gestore per parechji clienti pò travaglià. È ancu in u filu principale, a cunsola è a trasfurmazioni di i travaglii di crone per sguassà e cunnessione chì ùn sò più necessarii in a piscina sò spinning.
Odyssey hè pruvatu cù a suite di test standard Postgres. Eseguimu solu install-check attraversu Bouncer è attraversu Odyssey, avemu un null div. Ci sò parechje teste ligati à u furmatu di data chì fallenu esattamente u listessu in Bouncer è Odyssey.
Inoltre, ci sò parechji cunduttori chì anu a so propria prova. È avemu aduprà e so teste per pruvà Odyssey.
Inoltre, per via di a nostra cunfigurazione in cascata, avemu da pruvà diversi bundle: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey per esse sicuru chì, se Odyssey hè in una parte di a cascata, ancu funziona cum'è previstu. .
Rastrellu
Avemu aduprà Odyssey in a produzzione. È ùn saria micca ghjustu se dicu chì tuttu funziona solu. No, vale à dì sì, ma micca sempre. Per esempiu, in a produzzione tuttu hà travagliatu, allora i nostri amichi di PostgreSQL Professional sò ghjunti è dicenu chì avemu avutu una fuga di memoria. Eranu veramente, avemu riparatu. Ma era simplice.
Allora avemu trovu chì u pooler di cunnessione hà cunnessione TLS entranti è cunnessione TLS in uscita. E cunnessione necessitanu certificati di cliente è certificati di servitore.
I certificati di u servitore Bouncer è Odyssey sò riletti da pcache, ma i certificati di u cliente ùn anu micca bisognu di rileghje da pcache, perchè a nostra scalabile Odyssey eventualmente si basa nantu à u rendiment di u sistema di leghje stu certificatu. Questu hè stata una sorpresa per noi, perchè ùn hà micca riposu immediatamente. À u principiu, hà scalatu linearmente, è dopu à 20 000 cunnessione simultanee entrate, stu prublema si manifesta.
U Metudu di Autentificazione Pluggable hè a capacità di autentificà cù l'arnesi di lunux integrati. In PgBouncer, hè implementatu in tale manera chì ci hè un filu separatu chì aspetta una risposta da PAM è ci hè un filu principale PgBouncer chì serve a cunnessione attuale è pò dumandà à campà in u filu PAM.
Ùn avemu micca implementatu questu per una ragione simplice. Avemu parechji flussi. Perchè avemu bisognu?
In u risultatu, questu pò creà prublemi in quantu si avete l'autentificazione PAM è l'autentificazione non-PAM, allora una grande onda di autentificazione PAM pò ritardà significativamente l'autentificazione non-PAM. Hè una di queste cose chì ùn avemu micca riparatu. Ma sè vo vulete riparà, pudete fà questu.
Un altru rake era cù u fattu chì avemu un filu chì accetta tutte e cunnessione entranti. È dopu sò trasferiti à a piscina di i travagliadori, induve a stretta di mani TLS serà fatta.
In u risultatu, sè vo avete una onda coherente di cunnessione di rete 20, seranu tutti accettati. È da u latu di u cliente, libpq hà da cumincià à rapportà i timeouts. Per automaticamente, hè cum'è 000 seconde quì.
Se ùn ponu micca tutti entre in a basa à u stessu tempu, ùn ponu micca entra in a basa, perchè tuttu questu pò esse cupartu da un retry non-esponenziale.
Avemu finitu per copià u schema PgBouncer quì in modu chì avemu throttling u numeru di cunnessione TCP chì accettemu.
Se vedemu chì accettemu cunnessione, ma ùn anu micca u tempu di strincà à a fine, li mettemu in una fila per ùn cunsumà risorse CPU. Questu porta à u fattu chì una stretta di manu simultanea ùn pò esse realizatu per tutte e cunnessione chì sò ghjunti. Ma almenu qualchissia entrerà in a basa di dati, ancu s'è a carica hè abbastanza forte.
fogliu
Chì vulete vede in u futuru in Odissea ? Chì simu pronti à sviluppà noi stessi è chì aspittemu da a cumunità ?
Per Aostu 2019.
Eccu ciò chì pareva a roadmap Odyssey in Aostu:
- Vulemu l'autentificazione SCRAM è PAM.
- Vulemu trasmette e richieste di lettura in standby.
- Mi piacerebbe riavvia in linea.
- È a capacità di pause nantu à u servitore.
A mità di sta strada hè fatta, è micca da noi. È questu hè bonu. Allora discutemu ciò chì resta è aghjunghje più.
? Avemu rèpliche chì, senza risponde à e dumande, scaldaranu solu l'aria. Avemu bisognu di elli per furnisce u failover è u cambiamentu. In casu di prublemi in unu di i centri di dati, mi piacerebbe occupà cù qualchì travagliu utile. Perchè ùn pudemu micca cunfigurà i stessi processori cintrali, a stessa memoria in una manera diversa, perchè a replicazione ùn hà micca travagliatu altrimenti.
In principiu, in Postgres, partendu da 10, hè pussibule di specificà session_attrs quandu si cunnetta. Pudete listinu tutti l'ospiti di basa di dati in a cunnessione è dì perchè andate à a basa di dati: scrive o leghje solu. È u cunduttore stessu sceglierà u primu òspite in a lista chì li piace u più, chì cumpone i requisiti di session_attrs.
Ma u prublema cù questu approcciu hè chì ùn cuntrolla micca u lag di replicazione. Pudete avè qualchì tipu di replica chì hè daretu à un tempu inacceptable per u vostru serviziu. Per fà l'esekzione cumpleta di e dumande di lettura nantu à una replica, in fattu, avemu bisognu di sustene in Odyssey a capacità di ùn travaglià quandu hè impussibile di leghje.
Odyssey hà da andà à a basa di dati da u tempu à u tempu è dumandà a distanza di replicazione da u primariu. È s'ellu hà righjuntu u limitu, ùn lasciate micca novi richieste in a basa di dati, dite à u cliente chì avete bisognu di riavvià e cunnessione è, possibbilmente, selezziunate un altru host per eseguisce e dumande. Questu permetterà à a basa di dati per restaurà rapidamente u lag di replicazione è torna torna per risponde cù una dumanda.
Hè difficiuli di nome e date di implementazione, perchè hè open source. Ma, speru, micca 2,5 anni cum'è i culleghi di PgBouncer. Questa hè a funzione chì mi piacerebbe vede in Odyssey.
. Avà pudete creà una dichjarazione preparata in dui maneri. Prima, pudete eseguisce un cumandamentu SQL, vale à dì "preparatu". Per capisce stu cumandamentu SQL, avemu bisognu di sapè cumu capisce SQL in u latu Bouncer. Questu seria eccessiva perchè hè eccessiva, postu chì avemu bisognu di u parser tutale. Ùn pudemu micca analizà ogni cumanda SQL.
Ma ci hè una dichjarazione preparata à u nivellu di protokollu di messagiu nantu à proto3. È questu hè u locu quandu l'infurmazioni chì a dichjarazione preparata hè stata creata vene in una forma strutturata. È pudemu sustene a cunniscenza chì in qualchì cunnessione di u servitore u cliente hà dumandatu à creà dichjarazioni preparate. E ancu se a transazzione hè chjusa, avemu sempre bisognu di mantene u servitore è u cliente cunnessu.
Ma quì ci hè una discrepanza in u dialogu, perchè qualchissia dice chì avete bisognu di capisce quale dichjarazione preparata u cliente hà creatu è sparte a cunnessione di u servitore trà tutti i clienti chì creanu sta cunnessione di u servitore, vale à dì, chì hà creatu un tali dichjarazione preparata.
Andres Freund hà dettu chì, se un cliente hè vinutu à voi chì avia digià creatu una dichjarazione cusì preparata in una altra cunnessione di u servitore, allora crea per ellu. Ma pare chì hè un pocu sbagliatu per eseguisce dumande in a basa di dati invece di u cliente, ma da u puntu di vista di u sviluppatore chì scrive u protokollu per interagisce cù a basa di dati, saria cunvene s'ellu era solu datu una cunnessione di rete. chì hà una dumanda cusì preparata.
È una funzione più chì avemu bisognu di implementà. Avemu avà un monitoraghju cumpatibile cù PgBouncer. Pudemu rinvià u tempu mediu di esecuzione di a dumanda. Ma u tempu mediu hè a temperatura media in l'uspidale: qualcunu hè friddu, qualcunu hè caldu - in media tutti sò sani. Ùn hè micca veru.
Avemu bisognu di implementà u supportu per i percentili, chì indicà chì ci sò richieste lente chì cunsuma risorse è rende u monitoraghju più accettabile.
A più impurtante hè chì vogliu a versione 1.0 (a versione 1.1 hè digià stata liberata). U fattu hè chì avà Odyssey hè in versione 1.0rc, vale à dì candidatu di liberazione. È tuttu u rake chì aghju listatu hè stata riparata esattamente cù a listessa versione, eccettu per a fuga di memoria.
Chì significà a versione 1.0 per noi? Lancemu l'Odissea à e nostre basi. Hè digià in esecuzione nantu à e nostre basa di dati, ma quandu ghjunghje à u puntu di 1 richieste per seconda, allora pudemu dì chì questa hè una versione di liberazione è questa hè una versione chì pò esse chjamata 000.
Parechje persone in a cumunità anu dumandatu più pausa è SCRAM in a versione 1.0. Ma questu significarà chì averemu bisognu di sparghje a prossima versione à a pruduzzione, perchè nè SCRAM nè a pausa sò stati fusionati. Ma, assai prubabile, stu prublema serà risolta abbastanza rapidamente.
Aspettu a vostra dumanda di pull. È mi piacerebbe ancu sente ciò chì prublemi avete cù Bouncer. Discutemu di elli. Forsi pudemu implementà alcune funzioni chì avete bisognu.
Questu cuncludi a mo parte, vogliu sente da voi. Grazie!
I vostri dumanni
Se aghju messu u mo propiu application_name, serà ghjittatu currettamente, ancu in a transazzione pooling in Odyssey?
Odissea o Bouncer?
In Odissea. U Bouncer hè lanciatu.
Faremu un set.
È se a mo cunnessione vera salta sopra à altre cunnessione, serà trasmessa?
Avemu da fà un set di tutti i paràmetri chì sò listati. Ùn possu micca dì se application_name hè in questa lista. Pare avè vistu quì. Avemu da stabilisce tutti i stessi paràmetri. Cù una dumanda, u settore farà tuttu ciò chì hè statu stallatu da u cliente durante l'iniziu.
Grazie Andrey per u rapportu! Bon rapportu! Sò cuntentu chì Odyssey si sviluppa più veloce è più veloce ogni minutu. Vogliu cuntinuà u listessu. Avemu digià dumandatu à avè una cunnessione multi-fonte di dati in modu chì Odyssey pò cunnette à diverse basa di dati à u stessu tempu, vale à dì u maestru schiavu, è dopu cunnette automaticamente à u novu maestru dopu un failover.
Iè, mi pare di ricurdà quella discussione. Avà ci sò parechji magazzini. Ma ùn ci hè micca cambià trà elli. Da a nostra parte, duvemu interrogà u servitore chì hè sempre vivu è capisce chì un failover hè accadutu, chì chjamarà pg_recovery. Aghju un modu standard per capisce chì ùn avemu micca vinutu à u maestru. È duvemu capisce in qualchì manera da i sbagli o cumu? Vale à dì, l'idea hè interessante, hè in discussione. Scrivite più cumenti. Sì avete mani di travagliu chì cunnosci C, allora questu hè in generale maravigliu.
U prublema di scaling through replicas hè ancu d'interessu per noi, perchè vulemu fà l'adopzione di clusters replicati u più simplice pussibule per i sviluppatori di l'applicazioni. Ma quì mi piacerebbe più cumenti, vale à dì cumu fà, cumu fà bè.
A quistione hè ancu di ripliche. Ci hè chì avete un maestru è parechje rèpliche. È hè chjaru chì vanu à a rèplica menu spessu chì à u maestru per cunnessione, perchè puderanu avè una diferenza. Avete dettu chì a diffarenza di dati pò esse tale chì a vostra attività ùn hà micca suddisfà è ùn andate micca finu à chì hè replicatu. À u listessu tempu, s'è vo ùn andate ci per un bellu pezzu, è poi cuminciaru à andà, allura i dati chì vi tuccherà ùn sarà subitu disponibile. Vale à dì, se andemu constantemente à u maestru, allora u cache hè riscaldatu quì, è u cache hè un pocu daretu in a replica.
Iè hè vera. Ùn ci saranu micca blocchi di dati in u pcache chì vulete, in u cache reale ùn ci sarà micca infurmazione nantu à e tavule chì vulete, ùn ci sarà micca interrugazioni analizate in i piani, nunda in tuttu.
È quandu avete qualchì tipu di cluster, è aghjunghje una nova replica quì, allora mentre principia, tuttu hè male in questu, vale à dì chì cresce u so cache.
Aghju avutu l'idea. L'approcciu currettu seria di eseguisce un picculu percentuale di dumande nantu à a replica prima, chì scalda a cache. À pocu pressu, avemu una cundizione chì duvemu esse micca più di 10 seconde daretu à u maestru. È sta cundizione ùn deve esse inclusa in una sola onda, ma liscia per certi clienti.
Iè, cresce u pesu.
Questa hè una bona idea. Ma prima avete bisognu di implementà stu chjusu. Prima avemu bisognu di spegne, è poi penseremu à cumu accende. Questa hè una grande funzione per accende lisu.
nginx hà sta opzione slowly start in u cluster per u servitore. È gradualmente custruisce a carica.
Iè, ottima idea, daremu una prova quandu ghjunghjemu à questu.
Source: www.habr.com