V svojem poročilu vam bo Andrey Borodin povedal, kako so pri načrtovanju poolerja povezav upoštevali izkušnje s skaliranjem PgBouncer , ko so ga uvedli v proizvodnjo. Poleg tega bomo razpravljali o tem, katere funkcije snemalca bi radi videli v novih različicah: za nas je pomembno ne samo, da zadovoljimo svoje potrebe, ampak da razvijemo skupnost uporabnikov .
Video:
Pozdravljeni vsi skupaj! Moje ime je Andrew.
Pri Yandexu razvijam odprtokodne baze podatkov. In danes imamo temo o povezavah povezovalnega bazena.
Če veste, kako poklicati povezovalni bazen v ruščini, mi povejte. Zelo si želim najti dober tehnični izraz, ki bi se moral uveljaviti v strokovni literaturi.
Tema je precej zapletena, saj je v veliko podatkovnih bazah vgrajen omejevalnik povezav in vam zanj sploh ni treba vedeti. Seveda so povsod neke nastavitve, vendar v Postgresu ne gre tako. In vzporedno (na HighLoad++ 2019) obstaja poročilo Nikolaja Samokhvalova o nastavljanju poizvedb v Postgresu. In kolikor razumem, so sem prišli ljudje, ki so že popolnoma konfigurirali svoje poizvedbe, in to so ljudje, ki se soočajo z bolj redkimi sistemskimi težavami, povezanimi z omrežjem in uporabo virov. In ponekod je lahko precej težko v smislu, da težave niso očitne.
Yandex ima Postgres. Številne storitve Yandex živijo v Yandex.Cloudu. In imamo več petabajtov podatkov, ki ustvarijo vsaj milijon zahtev na sekundo v Postgresu.
In nudimo dokaj standardno gručo za vse storitve - to je glavno primarno vozlišče vozlišča, običajni dve replici (sinhrona in asinhrona), varnostno kopiranje, skaliranje bralnih zahtev na replici.
Vsako vozlišče gruče je Postgres, na katerem je poleg Postgresa in nadzornih sistemov nameščen tudi povezovalni bazen. Connection pooler se uporablja za ograje in za svoj glavni namen.
Kaj je glavni namen omejevalnika povezav?
Postgres sprejme procesni model pri delu z bazo podatkov. To pomeni, da je ena povezava en proces, eno zaledje Postgres. In v tem ozadju je veliko različnih predpomnilnikov, katerih izdelava za različne povezave je precej draga.
Poleg tega ima koda Postgres matriko, imenovano procArray. Vsebuje osnovne podatke o omrežnih povezavah. In skoraj vsi algoritmi za obdelavo procArray imajo linearno kompleksnost; delujejo čez celotno paleto omrežnih povezav. To je precej hiter cikel, vendar z več dohodnimi omrežnimi povezavami stvari postanejo nekoliko dražje. In ko stvari postanejo nekoliko dražje, lahko na koncu plačate zelo visoko ceno za veliko omrežnih povezav.
Obstajajo 3 možni pristopi:
- Na strani aplikacije.
- Na strani baze podatkov.
- In med, torej vse vrste kombinacij.
Na žalost je vgrajeni pooler trenutno v razvoju. To večinoma počnejo naši prijatelji pri PostgreSQL Professional. Kdaj se bo pojavil, je težko napovedati. In pravzaprav imamo arhitektu na izbiro dve rešitvi. To sta bazen na strani aplikacije in proxy bazen.
Bazen na strani aplikacije je najlažji način. In skoraj vsi odjemalski gonilniki vam ponujajo način: predstavite milijone svojih povezav v kodi kot več deset povezav z bazo podatkov.
Težava, ki se pojavi, je, da na določeni točki želite povečati zaledje in ga želite razmestiti v veliko virtualnih strojev.
Potem ugotovite, da imate več območij razpoložljivosti, več podatkovnih centrov. In pristop združevanja na strani odjemalca vodi do velikih številk. Velike so približno 10 povezav. To je rob, ki lahko normalno deluje.
Če govorimo o proxy poolerjih, potem obstajata dva poolerja, ki lahko naredita veliko stvari. Niso samo bazeni. So zbiralniki + več kul funkcionalnosti. to и .
Toda na žalost vsi ne potrebujejo te dodatne funkcije. In to vodi do dejstva, da združenja podpirajo samo združevanje sej, tj. en dohodni odjemalec, en odhodni odjemalec v bazo podatkov.
To ni zelo primerno za naše namene, zato uporabljamo PgBouncer, ki izvaja združevanje transakcij, tj. strežniške povezave se ujemajo s povezavami odjemalcev samo za čas trajanja transakcije.
In glede na našo delovno obremenitev je to res. Vendar obstaja nekaj težav.
Težave se začnejo, ko želite diagnosticirati sejo, ker so vse vaše dohodne povezave lokalne. Vsi so prišli s povratno zanko in nekako je težko izslediti sejo.
Seveda lahko uporabite application_name_add_host. To je način za dodajanje naslova IP na strani Bouncer v ime_aplikacije. Vendar je ime_aplikacije nastavljeno z dodatno povezavo.
Na tem grafu so rumena črta prave zahteve, modra pa zahteve, ki priletijo v bazo podatkov. In ta razlika je ravno v namestitvi application_name, ki je potrebna samo za sledenje, ni pa sploh brezplačna.
Poleg tega v Bouncerju ne morete omejiti enega bazena, tj. števila povezav baze podatkov na določenega uporabnika, na določeno bazo podatkov.
Kaj to vodi? Imate naloženo storitev, napisano v C++, in nekje v bližini majhno storitev na vozlišču, ki ne naredi nič groznega z bazo podatkov, vendar njen gonilnik ponori. Odpre 20 povezav, vse ostalo bo počakalo. Tudi tvoja koda je normalna.
Seveda smo napisali majhen popravek za Bouncer, ki je dodal to nastavitev, tj. omejevanje strank na bazen.
To bi bilo mogoče storiti na strani Postgresa, torej omejiti vloge v bazi s številom povezav.
Toda potem izgubite sposobnost razumevanja, zakaj nimate povezave s strežnikom. PgBouncer ne vrže napake povezave, vedno vrne iste informacije. In ne morete razumeti: morda se je vaše geslo spremenilo, morda se je zbirka podatkov samo izgubila, morda je nekaj narobe. Toda diagnoze ni. Če seje ni mogoče vzpostaviti, ne boste vedeli, zakaj je ni mogoče vzpostaviti.
Na določeni točki pogledate grafe aplikacij in vidite, da aplikacija ne deluje.
Poglejte na vrh in vidite, da je Bouncer enoniten. To je prelomnica v življenju službe. Zavedate se, da ste se pripravljali na povečanje baze podatkov v letu in pol in morate povečati zbiralnik podatkov.
Prišli smo do zaključka, da potrebujemo več PgBouncerjev.
Bouncer je bil malo popravljen.
In naredili so tako, da je bilo mogoče dvigniti več odbijačev s ponovno uporabo vrat TCP. In operacijski sistem samodejno prenaša dohodne povezave TCP med njimi z uporabo krožnega dela.
To je pregledno za odjemalce, kar pomeni, da je videti, kot da imate enega Bouncerja, vendar imate razdrobljene nedejavne povezave med delujočimi Bouncerji.
In v določenem trenutku boste morda opazili, da ti 3 odbijači vsak požrejo svoje jedro za 100%. Potrebujete kar nekaj odbijačev. Zakaj?
Ker imaš TLS. Imate šifrirano povezavo. In če primerjate Postgres z in brez TLS, boste ugotovili, da se število vzpostavljenih povezav zmanjša za skoraj dva reda velikosti z omogočenim šifriranjem, ker rokovanje TLS porablja sredstva CPE.
In na vrhu lahko vidite kar nekaj kriptografskih funkcij, ki se izvajajo, ko pride do vala dohodnih povezav. Ker lahko naš primarni preklaplja med območji razpoložljivosti, je val dohodnih povezav dokaj tipična situacija. To pomeni, da iz nekega razloga stari primarni ni bil na voljo, celotno breme je bilo poslano v drug podatkovni center. Vsi bodo prišli pozdravit TLS hkrati.
In veliko število rokovanj TLS morda ne bo več pozdravilo Bouncerja, ampak mu bo stisnilo grlo. Zaradi časovne omejitve lahko val dohodnih povezav postane nezadušen. Če poskusite znova v bazo brez eksponentnega odmika, ne bodo prihajali vedno znova v skladnem valu.
Tukaj je primer 16 PgBouncerjev, ki naložijo 16 jeder pri 100 %.
Prišli smo do kaskade PgBouncer. To je najboljša konfiguracija, ki jo lahko dosežemo na našem tovoru z Bouncerjem. Naši zunanji odbijači se uporabljajo za rokovanje TCP, notranji odbijači pa se uporabljajo za resnično združevanje, da zunanjih povezav ne razdrobimo preveč.
V tej konfiguraciji je možen gladek ponovni zagon. Vseh teh 18 odbijačev lahko znova zaženete enega za drugim. Toda vzdrževanje takšne konfiguracije je precej težko. Sistemski skrbniki, DevOps in ljudje, ki so dejansko odgovorni za ta strežnik, ne bodo preveč zadovoljni s to ureditvijo.
Zdi se, da je vse naše izboljšave mogoče prenesti v odprtokodno, vendar Bouncer ni zelo dobro podprt. Na primer, možnost izvajanja več PgBouncerjev na enem pristanišču je bila odobrena pred mesecem dni. Pred nekaj leti je bila zahteva za vleko s to funkcijo.
Ali pa še en primer. V Postgresu lahko zahtevo, ki je v teku, prekličete tako, da skrivnost pošljete drugi povezavi brez nepotrebnega preverjanja pristnosti. Toda nekateri odjemalci preprosto pošljejo ponastavitev TCP, kar pomeni, da prekinejo omrežno povezavo. Kaj bo naredil Bouncer? Nič ne bo naredil. Nadaljeval bo z izvajanjem zahteve. Če ste prejeli ogromno povezav, ki so ustvarile zbirko podatkov z majhnimi zahtevami, preprosto prekinitev povezave z Bouncerjem ne bo dovolj; dokončati morate tudi tiste zahteve, ki se izvajajo v bazi podatkov.
To je bilo popravljeno in ta težava še ni bila združena v Bouncerjev navzgor.
In tako smo prišli do zaključka, da potrebujemo svoj povezovalni pooler, ki bo razvit, popravljen, v katerem se da hitro odpraviti težave in ki mora biti seveda večniten.
Kot glavno nalogo smo postavili večnitnost. Moramo biti sposobni dobro obvladati val dohodnih povezav TLS.
Da bi to naredili, smo morali razviti ločeno knjižnico, imenovano Machinarium, ki je zasnovana tako, da opisuje strojna stanja omrežne povezave kot zaporedno kodo. Če pogledate izvorno kodo libpq, boste videli nekaj precej zapletenih klicev, ki vam lahko vrnejo rezultat in rečejo: »Pokliči me pozneje. Trenutno imam IO za zdaj, ko pa IO izgine, bom obremenil procesor.” In to je shema na več ravneh. Omrežno komunikacijo običajno opisuje stanje stroj. Veliko pravil, kot je »Če sem prej prejel glavo paketa velikosti N, zdaj čakam na N bajtov«, »Če sem poslal paket SYNC, zdaj čakam na paket z metapodatki o rezultatih.« Rezultat je precej težavna, kontraintuitivna koda, kot če bi labirint pretvorili v črtno skeniranje. Naredili smo tako, da programer namesto državnega avtomata opiše glavno pot interakcije v obliki navadne imperativne kode. Samo v to imperativno kodo morate vstaviti mesta, kjer je treba zaporedje izvajanja prekiniti s čakanjem na podatke iz omrežja, s posredovanjem konteksta izvajanja drugi korutini (zelena nit). Ta pristop je podoben temu, da v labirintu zaporedoma zapišemo najbolj pričakovano pot in ji nato dodamo veje.
Posledično imamo eno nit, ki TCP sprejema in krožno posreduje povezavo TPC številnim delavcem.
V tem primeru vsaka odjemalska povezava vedno deluje na enem procesorju. In to vam omogoča, da je prijazen do predpomnilnika.
Poleg tega smo nekoliko izboljšali zbiranje majhnih paketov v en velik paket, da bi razbremenili sistemski sklad TCP.
Poleg tega smo izboljšali transakcijsko združevanje v smislu, da lahko Odyssey, ko je konfiguriran, pošlje CANCEL in ROLLBACK v primeru okvare omrežne povezave, tj. če nihče ne čaka na zahtevo, Odyssey pove bazi podatkov, naj ne poskuša izpolniti zahtevo, ki lahko zapravi dragocene vire.
In kadar koli je to mogoče, ohranjamo povezave z istim odjemalcem. S tem se izognete ponovni namestitvi application_name_add_host. Če je to možno, nam parametrov, ki so potrebni za diagnostiko, ni treba dodatno ponastavljati.
Delujemo v interesu Yandex.Cloud. In če uporabljate upravljani PostgreSQL in imate nameščen omejevalnik povezav, lahko ustvarite logično replikacijo navzven, tj. prepustite nam, če želite, uporabo logične replikacije. Bouncer ne bo poslal logičnega toka replikacije ven.
To je primer nastavitve logične replikacije.
Poleg tega imamo podporo za fizično replikacijo navzven. V oblaku je to seveda nemogoče, saj vam bo potem gruča dala preveč informacij o sebi. Toda v vaših namestitvah, če potrebujete fizično podvajanje prek omejevalnika povezav v Odysseyju, je to mogoče.
Odyssey ima popolnoma združljivo spremljanje s PgBouncer. Imamo isto konzolo, ki izvaja skoraj vse iste ukaze. Če nekaj manjka, pošljite zahtevo za vlečenje ali vsaj težavo na GitHub in dokončali bomo potrebne ukaze. Toda glavno funkcionalnost konzole PgBouncer že imamo.
In seveda imamo posredovanje napak. Vrnili bomo napako, ki jo je sporočila zbirka podatkov. Prejeli boste informacijo o tem, zakaj niste vključeni v bazo podatkov, in ne samo, da niste vključeni vanjo.
Ta funkcija je onemogočena, če potrebujete 100-odstotno združljivost s PgBouncer. Lahko se obnašamo enako kot Bouncer, samo da smo na varni strani.
Razvoj
Nekaj besed o izvorni kodi Odiseje.
Na primer, obstajajo ukazi »Premor / Nadaljuj«. Običajno se uporabljajo za posodobitev baze podatkov. Če morate posodobiti Postgres, ga lahko začasno ustavite v omejevalniku povezav, naredite pg_upgrade in nato nadaljujte. In s strani odjemalca bo videti, kot da se baza podatkov preprosto upočasnjuje. To funkcionalnost so nam prinesli ljudje iz skupnosti. Ni še zamrznjena, a kmalu bo vse. (Že zamrznjeno)
- že zamrznjeno
Poleg tega je ena od novosti v PgBouncerju podpora za SCRAM Authentication, ki nam jo je prav tako prinesla oseba, ki ne dela v Yandex.Cloudu. Oba sta kompleksna in pomembna.
Zato bi vam rad povedal, iz česa je sestavljena Odyssey, če bi tudi vi zdaj želeli napisati malo kode.
Imate izvorno bazo Odyssey, ki temelji na dveh glavnih knjižnicah. Knjižnica Kiwi je implementacija sporočilnega protokola Postgres. To pomeni, da so izvorni proto 3 Postgresa standardna sporočila, ki si jih lahko izmenjujeta sprednji in zadnji del. Implementirani so v knjižnici Kiwi.
Knjižnica Machinarium je knjižnica implementacije niti. Majhen fragment tega Machinariuma je napisan v zbirnem jeziku. Ampak ne bodite prestrašeni, obstaja le 15 vrstic.
Odisejeva arhitektura. Obstaja glavni stroj, na katerem tečejo korutine. Ta stroj izvaja sprejemanje dohodnih povezav TCP in njihovo razdeljevanje med delavce.
Znotraj enega delavca lahko dela vodja za več strank. Glavna nit izvaja tudi konzolo in obdelavo kronskih nalog za brisanje povezav, ki niso več potrebne v bazenu.
Odyssey je testiran s standardnim testnim paketom Postgres. Samo zaženemo install-check skozi Bouncer in skozi Odyssey, dobimo ničelni div. Obstaja več testov, povezanih z oblikovanjem datuma, ki v Bouncer in Odyssey ne opravijo povsem enako.
Poleg tega obstaja veliko voznikov, ki imajo svoje testiranje. Njihove teste uporabljamo za testiranje Odiseje.
Poleg tega moramo zaradi naše kaskadne konfiguracije testirati različne pakete: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, da se prepričamo, da Odyssey, če se je znašel v katerem koli delu kaskade, še vedno deluje kot pričakujemo.
Rake
V proizvodnji uporabljamo Odyssey. In ne bi bilo pošteno, če bi rekel, da vse preprosto deluje. Ne, se pravi, da, vendar ne vedno. Na primer, v proizvodnji je vse preprosto delovalo, potem so prišli naši prijatelji iz PostgreSQL Professional in rekli, da imamo puščanje pomnilnika. Res so bili, smo jih popravili. Ampak bilo je preprosto.
Potem smo odkrili, da ima omejevalnik povezav dohodne povezave TLS in odhodne povezave TLS. In povezave zahtevajo potrdila odjemalca in potrdila strežnika.
Potrdila strežnika Bouncer in Odyssey ponovno prebere njihov pcache, potrdil odjemalca pa ni treba ponovno prebrati iz pcache, ker naš razširljivi Odyssey na koncu naleti na sistemsko zmogljivost branja tega potrdila. To nas je presenetilo, saj se ni dolgo upiral. Sprva se je merilo linearno, toda po 20 dohodnih sočasnih povezavah se je ta težava pokazala.
Pluggable Authentication Method je zmožnost preverjanja pristnosti z uporabo vgrajenih orodij Lunux. V PgBouncer je implementiran tako, da obstaja ločena nit, ki čaka na odgovor PAM-a, in obstaja glavna nit PgBouncer, ki servisira trenutno povezavo in jih lahko prosi, da živijo v niti PAM.
Tega nismo uvedli iz enega preprostega razloga. Imamo veliko niti. Zakaj potrebujemo to?
To lahko na koncu povzroči težave, če imate preverjanje pristnosti PAM in preverjanje pristnosti brez PAM, potem lahko velik val preverjanja pristnosti PAM znatno zakasni preverjanje pristnosti brez PAM. To je ena tistih stvari, ki jih nismo popravili. Če pa želite to popraviti, lahko to storite.
Druga prednost je bila, da imamo eno nit, ki sprejema vse dohodne povezave. Nato se prenesejo v skupino delavcev, kjer bo potekalo rokovanje TLS.
Pod črto, če imate koherenten val 20 omrežnih povezav, bodo vse sprejete. In na strani odjemalca bo libpq začel poročati o časovnih omejitvah. Privzeto se zdi, da so 000 sekunde.
Če vsi ne morejo vstopiti v bazo hkrati, potem ne morejo vstopiti v bazo, ker je vse to mogoče pokriti z neeksponentnim ponovnim poskusom.
Tukaj smo kopirali shemo iz PgBouncerja z dejstvom, da smo omejili število povezav TCP, ki jih sprejemamo.
Če vidimo, da sprejemamo povezave, vendar na koncu nimajo časa za rokovanje, jih postavimo v čakalno vrsto, da ne zapravljajo virov procesorja. To vodi do dejstva, da hkratno rokovanje morda ne bo izvedeno za vse prispele povezave. Bo pa vsaj nekdo vstopil v bazo, tudi če bo obremenitev precej velika.
Načrt
Kaj bi radi videli v prihodnosti v Odiseji? Kaj smo pripravljeni razvijati sami in kaj pričakujemo od skupnosti?
Od avgusta 2019.
Takole je bil videti načrt Odiseje avgusta:
- Želeli smo avtentikacijo SCRAM in PAM.
- Zahteve za branje smo želeli posredovati v stanje pripravljenosti.
- Rad bi ponovni zagon prek spleta.
- In možnost premora na strežniku.
Polovica tega načrta je bila dokončana in ne mi. In to je dobro. Pogovorimo se torej o tem, kaj ostane, in dodamo še več.
? Imamo replike, ki bodo preprosto ogrele zrak brez izvajanja zahtev. Potrebujemo jih, da zagotovijo samodejni preklop in preklop. V primeru težav v enem od podatkovnih centrov bi jih rad zaposlil s koristnim delom. Ker istih centralnih procesorjev, istega pomnilnika ne moremo drugače konfigurirati, ker sicer replikacija ne bo delovala.
Načeloma je v Postgresu, od 10 naprej, možno določiti session_attrs pri povezovanju. Navedete lahko vse gostitelje baze podatkov v povezavi in poveste, zakaj greste v bazo podatkov: samo pisanje ali branje. In voznik bo sam izbral prvega gostitelja na seznamu, ki mu je najbolj všeč, ki izpolnjuje zahteve session_attrs.
Toda težava s tem pristopom je, da ne nadzoruje zamika podvajanja. Morda imate kakšno repliko, ki je za vašo storitev zaostajala nesprejemljivo dolgo. Da bi omogočili popolno izvajanje bralnih poizvedb na repliki, moramo v bistvu podpirati sposobnost Odysseyja, da se ne zažene, ko je ni mogoče prebrati.
Odyssey mora občasno obiskati bazo podatkov in vprašati za razdaljo replikacije od primarne. In če je dosegel mejno vrednost, ne dovolite novih zahtev v bazo podatkov, povejte odjemalcu, da mora znova vzpostaviti povezave in po možnosti izberite drugega gostitelja za izvajanje zahtev. To bo bazi podatkov omogočilo, da hitro obnovi zakasnitev replikacije in se znova vrne, da odgovori z zahtevo.
Težko je dati časovni okvir za izvedbo, ker je odprtokoden. Upam pa, da ne 2,5 leti kot moji kolegi iz PgBouncerja. To je funkcija, ki bi jo rad videl v Odiseji.
. Zdaj lahko pripravljeno izjavo ustvarite na dva načina. Najprej lahko izvedete ukaz SQL, in sicer "pripravljeno". Da bi razumeli ta ukaz SQL, se moramo naučiti razumeti SQL na strani Bouncer. To bi bilo odveč, ker je odveč, saj potrebujemo celoten razčlenjevalnik. Ne moremo razčleniti vsakega ukaza SQL.
Obstaja pa pripravljena izjava na ravni protokola sporočil na proto3. In to je kraj, ko informacija, da se pripravlja izjava, pride v strukturirani obliki. In lahko bi podprli razumevanje, da je na neki strežniški povezavi odjemalec zahteval ustvarjanje pripravljenih stavkov. In tudi če je transakcija zaključena, moramo še vedno vzdrževati povezljivost med strežnikom in odjemalcem.
Tukaj pa nastane neskladje v dialogu, ker nekdo pravi, da je treba razumeti, kakšne pripravljene izjave je ustvaril odjemalec in deliti povezavo s strežnikom med vse odjemalce, ki so ustvarili to povezavo s strežnikom, torej tisti, ki so ustvarili tako pripravljeno izjavo.
Andres Freund je rekel, da če pride k vam stranka, ki je že ustvarila tako pripravljeno izjavo v drugi povezavi strežnika, potem jo ustvarite zanj. Zdi pa se malo narobe izvajati poizvedbe v bazi podatkov namesto odjemalca, a z vidika razvijalca, ki piše protokol za interakcijo z bazo, bi bilo priročno, če bi mu preprosto dali omrežno povezavo, v kateri obstaja taka pripravljena poizvedba.
In še ena funkcija, ki jo moramo implementirati. Zdaj imamo nadzor, združljiv s PgBouncer. Lahko vrnemo povprečni čas izvedbe poizvedbe. A povprečni čas je povprečna temperatura v bolnišnici: nekaterim je hladno, drugim toplo – v povprečju so vsi zdravi. Ni res.
Implementirati moramo podporo za percentile, ki bi kazali, da obstajajo počasne poizvedbe, ki zapravljajo vire, in narediti spremljanje bolj sprejemljivo.
Najbolj pomembno je, da želim različico 1.0 (verzija 1.1 je že izdana). Dejstvo je, da je Odyssey zdaj v različici 1.0rc, torej kandidatu za izdajo. In vse težave, ki sem jih naštel, so bile odpravljene s popolnoma isto različico, razen puščanja pomnilnika.
Kaj bo različica 1.0 pomenila za nas? Odyssey uvajamo v naše baze. V naših bazah podatkov se že izvaja, a ko doseže točko 1 zahtevkov na sekundo, potem lahko rečemo, da je to izdajna različica in to je različica, ki jo lahko imenujemo 000.
Več ljudi v skupnosti je zahtevalo, da različica 1.0 vključuje premor in SCRAM. Toda to bo pomenilo, da bomo morali uvesti naslednjo različico v proizvodnjo, ker niti SCRAM niti pause še nista bila uničena. Toda najverjetneje bo to vprašanje rešeno precej hitro.
Čakam na vašo zahtevo za vleko. Prav tako bi rad slišal, kakšne težave imaš z Bouncerjem. Razpravljajmo o njih. Morda lahko implementiramo nekatere funkcije, ki jih potrebujete.
To je konec mojega dela, rad bi vas poslušal. Hvala vam!
vprašanja
Če nastavim lastno ime_aplikacije, ali bo pravilno posredovano, vključno z združevanjem transakcij v Odyssey?
Odisej ali Izbijač?
V Odiseji. V Bouncerju se meče.
Naredili bomo komplet.
In če moja resnična povezava preskoči na druge povezave, ali se bo prenašala?
Izdelali bomo nabor vseh parametrov, ki so navedeni na seznamu. Ne morem ugotoviti, ali je ime_aplikacije na tem seznamu. Mislim, da sem ga videl tam. Nastavili bomo vse enake parametre. Z eno zahtevo bo set opravil vse, kar je ob zagonu namestil odjemalec.
Hvala, Andrej, za poročilo! Dobro poročilo! Veseli me, da se Odyssey vsako minuto razvija hitreje in hitreje. Tako želim nadaljevati. Prosili smo vas že, da imate povezavo z več viri podatkov, tako da se lahko Odyssey hkrati poveže z različnimi bazami podatkov, tj. glavno podrejeno, in se nato samodejno poveže z novo glavno zbirko po preklopu.
Ja, zdi se mi, da se spomnim te razprave. Zdaj je več skladišč. Toda preklapljanja med njimi ni. Na naši strani moramo vprašati strežnik, ali je še vedno živ in razumeti, da je prišlo do napake, ki bo poklical pg_recovery. Standardno razumem, da nismo prišli do mojstra. In naj iz napak nekako razumemo ali kaj? Se pravi, ideja je zanimiva, o njej se razpravlja. Napišite več komentarjev. Če imate delavce, ki poznajo C, potem je to super.
Zanima nas tudi vprašanje skaliranja po replikah, saj želimo razvijalcem aplikacij čim bolj poenostaviti prevzem podvojenih gruč. Tukaj pa bi rad več komentarjev, tj. kako točno to narediti, kako to narediti dobro.
Vprašanje je tudi glede replik. Izkazalo se je, da imate mojstra in več replik. In jasno je, da gredo k repliki manj pogosto kot k mojstru za povezave, ker imajo lahko razlike. Rekli ste, da je lahko razlika v podatkih tolikšna, da ne bo zadovoljila vašega podjetja in da ne boste šli tja, dokler se ne ponovi. Hkrati, če niste šli tja dlje časa in potem začeli iti, potem potrebni podatki ne bodo takoj na voljo. To pomeni, da če nenehno gremo do masterja, se predpomnilnik tam segreje, v replici pa predpomnilnik malo zaostaja.
Ja, res je. Pcache ne bo imel podatkovnih blokov, ki jih želite, pravi predpomnilnik ne bo imel informacij o želenih tabelah, načrti ne bodo imeli razčlenjenih poizvedb, sploh ne bo ničesar.
In ko imaš neko gručo in tam dodaš novo repliko, potem ko se zažene, je v njej vse slabo, se pravi, poveča svoj predpomnilnik.
Dobil sem idejo. Pravilen pristop bi bil, da najprej zaženete majhen odstotek poizvedb na replici, kar bi ogrelo predpomnilnik. Okvirno povedano imamo pogoj, da za gospodarjem ne smemo zaostajati več kot 10 sekund. In ta pogoj ni vključen v enem valu, ampak gladko za nekatere stranke.
Da, povečati težo.
To je dobra ideja. Toda najprej moramo izvesti to zaustavitev. Najprej se moramo izklopiti, potem pa bomo razmišljali, kako vklopiti. To je odlična funkcija za nemoteno omogočanje.
Nginx ima to možnost slowly start v gruči za strežnik. In postopoma povečuje obremenitev.
Ja, odlična ideja, bomo poskusili, ko nam bo uspelo.
Vir: www.habr.com