U svom izvješću, Andrey Borodin će vam reći kako su uzeli u obzir iskustvo skaliranja PgBouncera prilikom dizajniranja poolera veze , dok su ga puštali u proizvodnju. Osim toga, razgovarat ćemo o funkcijama izvlakača koje bismo željeli vidjeti u novim verzijama: važno nam je ne samo zadovoljiti naše potrebe, već i razviti zajednicu korisnika .
Video:
Bok svima! Moje ime je Andrew.
U Yandexu razvijam baze podataka otvorenog koda. A danas imamo temu o vezama skupljača veza.
Ako znate kako nazvati pooler veze na ruskom, recite mi. Stvarno želim pronaći dobar tehnički termin koji bi se trebao uvriježiti u tehničkoj literaturi.
Tema je prilično komplicirana, jer je u mnogim bazama podataka skupnik veza ugrađen i ne morate ni znati za njega. Naravno, posvuda postoje neke postavke, ali u Postgresu to ne radi tako. A paralelno (na HighLoad++ 2019) postoji izvješće Nikolaja Samokhvalova o postavljanju upita u Postgresu. I koliko sam shvatio, ovdje su došli ljudi koji su već savršeno konfigurirali svoje upite, a to su ljudi koji se suočavaju s rijetkim sistemskim problemima koji se odnose na mrežu i korištenje resursa. A na nekim mjestima može biti prilično teško u smislu da problemi nisu očiti.
Yandex ima Postgres. Mnoge Yandexove usluge žive u Yandex.Cloudu. I imamo nekoliko petabajta podataka koji generiraju najmanje milijun zahtjeva u sekundi u Postgresu.
I pružamo prilično standardni klaster za sve usluge - ovo je glavni primarni čvor čvora, uobičajene dvije replike (sinkrona i asinkrona), sigurnosna kopija, skaliranje zahtjeva za čitanje na replici.
Svaki čvor klastera je Postgres, na kojem je uz Postgres i nadzorne sustave instaliran i konekcioni pooler. Connection pooler se koristi za ograđivanje i za svoju glavnu namjenu.
Koja je glavna svrha skupljača veza?
Postgres usvaja model procesa kada radi s bazom podataka. To znači da je jedna veza jedan proces, jedan Postgres backend. A u ovoj pozadini postoji puno različitih predmemorija, koje je prilično skupo napraviti različitim za različite veze.
Dodatno, Postgresov kod ima niz koji se zove procArray. Sadrži osnovne podatke o mrežnim vezama. Gotovo svi algoritmi za obradu procArray imaju linearnu složenost; pokreću cijeli niz mrežnih veza. To je prilično brz ciklus, ali s više dolaznih mrežnih veza stvari postaju malo skuplje. A kada stvari postanu malo skuplje, na kraju možete platiti vrlo visoku cijenu za puno mrežnih veza.
Postoje 3 moguća pristupa:
- Na strani aplikacije.
- Na strani baze podataka.
- I između, odnosno svakakvih kombinacija.
Nažalost, ugrađeni pooler trenutno je u razvoju. Naši prijatelji u PostgreSQL Professionalu to uglavnom rade. Kada će se pojaviti, teško je prognozirati. I zapravo, imamo dva rješenja za arhitekta na izbor. To su skup na strani aplikacije i proxy skup.
Skup na strani aplikacije je najlakši način. I gotovo svi upravljački programi klijenta pružaju vam način: predstavite milijune svojih veza u kodu kao nekoliko desetaka veza s bazom podataka.
Problem koji se javlja je da u određenom trenutku želite skalirati pozadinu, želite je implementirati na mnogo virtualnih strojeva.
Tada shvatite da imate još nekoliko zona dostupnosti, nekoliko podatkovnih centara. A pristup udruživanju na strani klijenta dovodi do velikih brojeva. Veliki su oko 10 veza. Ovo je rub koji može normalno raditi.
Ako govorimo o proxy skupljačima, onda postoje dva skupljača koji mogu učiniti puno stvari. Oni nisu samo bazenari. Oni su skupljači + još cool funkcija. Ovaj и .
Ali, nažalost, nije svima potrebna ova dodatna funkcionalnost. I to dovodi do činjenice da skupljači podržavaju samo skupljanje sesija, tj. jedan dolazni klijent, jedan odlazni klijent u bazu podataka.
Ovo nije baš prikladno za naše svrhe, pa koristimo PgBouncer, koji implementira skupljanje transakcija, tj. veze poslužitelja uspoređuju se s vezama klijenata samo za vrijeme trajanja transakcije.
I u našem opterećenom poslu, to je istina. Ali postoji nekoliko problema.
Problemi počinju kada želite dijagnosticirati sesiju, jer su sve vaše dolazne veze lokalne. Svi su došli s povratnom petljom i nekako postaje teško pratiti sesiju.
Naravno, možete koristiti application_name_add_host. Ovo je način na strani Bouncera za dodavanje IP adrese u application_name. Ali application_name postavlja dodatna veza.
Na ovom grafikonu, žuta linija je stvarni zahtjevi, a plava linija zahtjevi koji lete u bazu podataka. A ta razlika je upravo u instalaciji application_name koja je potrebna samo za praćenje, ali nije uopće besplatna.
Osim toga, u Bounceru ne možete ograničiti jedan bazen, tj. broj veza s bazom podataka po određenom korisniku, po određenoj bazi podataka.
Čemu to vodi? Imate učitanu uslugu napisanu u C++ i negdje u blizini malu uslugu na čvoru koja ne radi ništa strašno s bazom podataka, ali njen upravljački program poludi. Otvara 20 000 veza i sve ostalo će pričekati. Čak je i tvoj kod normalan.
Mi smo, naravno, napisali malu zakrpu za Bouncer koja je dodala ovu postavku, tj. ograničavanje klijenata na bazen.
To bi bilo moguće napraviti na strani Postgresa, odnosno ograničiti uloge u bazi brojem veza.
Ali tada gubite sposobnost razumijevanja zašto nemate veze s poslužiteljem. PgBouncer ne javlja grešku veze, uvijek vraća iste informacije. I ne možete razumjeti: možda se vaša lozinka promijenila, možda se baza podataka upravo izgubila, možda nešto nije u redu. Ali dijagnoze nema. Ako se sesija ne može uspostaviti, nećete znati zašto se ne može uspostaviti.
U određenom trenutku pogledate grafikone aplikacija i vidite da aplikacija ne radi.
Pogledajte vrh i vidite da je Bouncer jednonitni. Ovo je prekretnica u životu službe. Shvatili ste da ste se pripremali skalirati bazu podataka za godinu i pol dana i trebate skalirati skupljač.
Došli smo do zaključka da nam treba više PgBouncera.
Bouncer je malo zakrpan.
I napravili su to tako da se nekoliko izbacivača može podići ponovnim korištenjem TCP priključka. A operativni sustav automatski prenosi dolazne TCP veze između njih koristeći kružni postupak.
Ovo je transparentno za klijente, što znači da izgleda kao da imate jednog izbacivača, ali imate fragmentaciju neaktivnih veza između pokrenutih izbacivača.
I u određenom trenutku možete primijetiti da ova 3 izbacivača svaki pojede svoju jezgru za 100%. Treba vam dosta izbacivača. Zašto?
Zato što imate TLS. Imate šifriranu vezu. A ako usporedite Postgres sa i bez TLS-a, vidjet ćete da broj uspostavljenih veza pada za gotovo dva reda veličine s omogućenom enkripcijom, jer TLS rukovanje troši CPU resurse.
A na vrhu možete vidjeti dosta kriptografskih funkcija koje se izvršavaju kada postoji val dolaznih veza. Budući da se naš primarni može prebacivati između zona dostupnosti, val dolaznih veza je prilično tipična situacija. To jest, iz nekog razloga stari primarni nije bio dostupan, cijelo opterećenje je poslano u drugi podatkovni centar. Svi će doći pozdraviti TLS u isto vrijeme.
A velik broj TLS rukovanja možda više neće pozdraviti Bouncera, ali će mu stisnuti grlo. Uslijed vremenskog ograničenja, val dolaznih veza može postati neprigušen. Ako ponovno pokušate do baze bez eksponencijalnog povlačenja, oni neće dolaziti uvijek iznova u koherentnom valu.
Evo primjera 16 PgBouncera koji učitavaju 16 jezgri na 100%.
Došli smo do kaskade PgBouncer. Ovo je najbolja konfiguracija koja se može postići na našem teretu s Bouncerom. Naši vanjski izbacivači koriste se za TCP rukovanje, a unutarnji izbacivači koriste se za stvarno udruživanje, kako se vanjske veze ne bi previše fragmentirale.
U ovoj konfiguraciji moguće je glatko ponovno pokretanje. Možete ponovno pokrenuti svih ovih 18 izbacivača jednog po jednog. Ali održavanje takve konfiguracije je prilično teško. Sysadmini, DevOps i ljudi koji su zapravo odgovorni za ovaj poslužitelj neće biti baš zadovoljni ovim aranžmanom.
Čini se da se sva naša poboljšanja mogu promovirati u otvoreni kod, ali Bouncer nije baš dobro podržan. Na primjer, mogućnost pokretanja nekoliko PgBouncera na jednom portu uvedena je prije mjesec dana. Prije nekoliko godina postojao je zahtjev za povlačenjem s ovom značajkom.
Ili još jedan primjer. U Postgresu možete otkazati zahtjev koji je u tijeku slanjem tajne na drugu vezu bez nepotrebne provjere autentičnosti. Ali neki klijenti jednostavno pošalju TCP reset, tj. prekinu mrežnu vezu. Što će Bouncer učiniti? Neće učiniti ništa. Nastavit će izvršavati zahtjev. Ako ste primili veliki broj veza koje su stvorile bazu podataka s malim zahtjevima, tada jednostavno prekidanje veze s Bouncerom neće biti dovoljno; također trebate dovršiti one zahtjeve koji se izvode u bazi podataka.
Ovo je zakrpano i ovaj problem još nije spojen u Bouncerov uzvodni dio.
I tako smo došli do zaključka da nam treba vlastiti pooler veza, koji će se razvijati, krpati, u kojem se mogu brzo ispravljati problemi i koji, naravno, mora biti multi-thread.
Multithreading smo postavili kao glavni zadatak. Moramo se moći dobro nositi s valom dolaznih TLS veza.
Da bismo to učinili, morali smo razviti zasebnu biblioteku pod nazivom Machinarium, koja je dizajnirana da opiše stanja stroja mrežne veze kao sekvencijalni kod. Ako pogledate izvorni kod libpq, vidjet ćete neke prilično složene pozive koji vam mogu vratiti rezultat i reći: “Nazovi me kasnije. Trenutačno imam IO za sada, ali kada IO nestane, imat ću opterećenje na procesoru.” A ovo je shema na više razina. Mrežna komunikacija obično se opisuje strojem stanja. Mnoštvo pravila poput "Ako sam prethodno primio zaglavlje paketa veličine N, sada čekam N bajtova", "Ako sam poslao SYNC paket, sada čekam paket s metapodacima rezultata." Rezultat je prilično težak, kontraintuitivan kod, kao da je labirint pretvoren u skeniranje linija. Napravili smo to tako da umjesto stroja stanja, programer opisuje glavni put interakcije u obliku običnog imperativnog koda. Samo što u ovaj imperativni kod trebate umetnuti mjesta na kojima treba prekinuti sekvencu izvršenja čekanjem podataka s mreže, prosljeđivanjem konteksta izvršenja u drugu korutinu (zelena nit). Ovaj pristup je sličan činjenici da u nizu zapišemo najočekivaniji put u labirintu, a zatim mu dodamo grane.
Kao rezultat, imamo jednu nit koja TCP prihvaća i kružno prosljeđuje TPC vezu mnogim radnicima.
U ovom slučaju, svaka veza klijenta uvijek radi na jednom procesoru. A to vam omogućuje da bude prilagođen predmemoriji.
Osim toga, malo smo poboljšali skupljanje malih paketa u jedan veliki paket kako bismo rasteretili TCP stack sustava.
Osim toga, poboljšali smo transakcijsko udruživanje u smislu da Odyssey, kada je konfiguriran, može poslati CANCEL i ROLLBACK u slučaju kvara mrežne veze, tj. ako nitko ne čeka zahtjev, Odyssey će reći bazi podataka da ne pokušava ispuniti zahtjev koji može uzalud potrošiti dragocjene resurse.
I kad god je to moguće, održavamo veze s istim klijentom. Time se izbjegava ponovna instalacija application_name_add_host. Ako je to moguće, tada ne moramo dodatno resetirati parametre koji su potrebni za dijagnostiku.
Radimo u interesu Yandex.Clouda. A ako koristite upravljani PostgreSQL i imate instaliran alat za skupljanje veza, možete kreirati logičku replikaciju prema van, tj. prepustite nam, ako želite, korištenje logičke replikacije. Bouncer neće osloboditi tok logičke replikacije izvana.
Ovo je primjer postavljanja logičke replikacije.
Osim toga, imamo podršku za fizičku replikaciju prema van. U Cloudu je to naravno nemoguće jer će vam onda klaster dati previše informacija o sebi. Ali u vašim instalacijama, ako vam je potrebna fizička replikacija kroz skup povezivanja u Odysseyju, to je moguće.
Odyssey ima potpuno kompatibilan nadzor s PgBouncerom. Imamo istu konzolu koja pokreće gotovo sve iste naredbe. Ako nešto nedostaje, pošaljite zahtjev za povlačenjem ili barem problem na GitHubu, a mi ćemo izvršiti potrebne naredbe. Ali već imamo glavnu funkcionalnost PgBouncer konzole.
I, naravno, imamo prosljeđivanje grešaka. Vratit ćemo pogrešku koju je prijavila baza podataka. Dobit ćete informaciju o tome zašto niste uvršteni u bazu podataka, a ne samo da niste uvršteni u nju.
Ova značajka je onemogućena u slučaju da vam je potrebna 100% kompatibilnost s PgBouncerom. Možemo se ponašati isto kao i Bouncer, samo da budemo sigurni.
dizajn
Nekoliko riječi o izvornom kodu Odiseje.
Na primjer, postoje naredbe "Pauza / Nastavi". Obično se koriste za ažuriranje baze podataka. Ako trebate ažurirati Postgres, možete ga pauzirati u skupu poveznica, napraviti pg_upgrade, a zatim nastaviti. A sa strane klijenta izgledat će kao da baza podataka jednostavno usporava. Ovu funkcionalnost donijeli su nam ljudi iz zajednice. Još nije zamrznuta, ali uskoro će sve biti. (Već zamrznuto)
- već smrznuto
Osim toga, jedna od novosti u PgBounceru je podrška za SCRAM Authentication, koju nam je također donijela osoba koja ne radi u Yandex.Cloudu. Oba su složena funkcionalnost i važna.
Stoga bih vam želio reći od čega je napravljena Odyssey, u slučaju da želite sada napisati i mali kod.
Imate izvornu bazu Odyssey, koja se oslanja na dvije glavne biblioteke. Knjižnica Kiwi implementacija je protokola za poruke Postgres. Odnosno, izvorni proto 3 Postgresa standardne su poruke koje front-end i back-end mogu razmjenjivati. Implementirani su u biblioteci Kiwi.
Biblioteka Machinarium je biblioteka implementacije niti. Mali fragment ovog Machinarijuma napisan je asemblerskim jezikom. Ali nemojte se uznemiriti, ima samo 15 redaka.
Odisejska arhitektura. Postoji glavni stroj na kojem se izvode korutine. Ovaj stroj implementira prihvaćanje dolaznih TCP veza i njihovu distribuciju među radnicima.
U okviru jednog radnika može raditi rukovatelj za više klijenata. Glavna nit također pokreće konzolu i obradu crone zadataka za brisanje veza koje više nisu potrebne u skupu.
Odyssey je testiran pomoću standardnog Postgres paketa testova. Samo pokrenemo install-check kroz Bouncer i kroz Odyssey, dobivamo null div. Postoji nekoliko testova povezanih s formatiranjem datuma koji ne prolaze jednako u Bounceru i Odysseyju.
Osim toga, postoji mnogo vozača koji imaju vlastita testiranja. I mi koristimo njihove testove da testiramo Odyssey.
Osim toga, zbog naše kaskadne konfiguracije, moramo testirati razne pakete: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey kako bismo bili sigurni da Odyssey, ako je završio u bilo kojem dijelu kaskade, i dalje radi kako očekujemo.
Grablje
U proizvodnji koristimo Odyssey. I ne bi bilo pošteno da kažem da sve jednostavno radi. Ne, to jest, da, ali ne uvijek. Na primjer, u proizvodnji je sve jednostavno radilo, onda su došli naši prijatelji iz PostgreSQL Professionala i rekli da imamo curenje memorije. Stvarno jesu, ispravili smo ih. Ali bilo je jednostavno.
Zatim smo otkrili da alat za skupljanje veza ima dolazne TLS veze i odlazne TLS veze. A veze zahtijevaju certifikate klijenta i certifikate poslužitelja.
Bouncer i Odyssey poslužiteljske certifikate ponovno čita njihov pcache, ali klijentske certifikate ne treba ponovno čitati iz pcache-a, jer naš skalabilni Odyssey u konačnici nailazi na performanse sustava pri čitanju ovog certifikata. To nas je iznenadilo, jer mu nije trebalo dugo da odoli. Isprva se skalirao linearno, ali nakon 20 dolaznih istodobnih veza ovaj se problem pokazao.
Pluggable Authentication Method je mogućnost autentifikacije pomoću ugrađenih Lunux alata. U PgBounceru to je implementirano na takav način da postoji zasebna nit koja čeka odgovor od PAM-a i postoji glavna PgBouncer nit koja servisira trenutnu vezu i može od njih tražiti da žive u PAM niti.
Nismo to implementirali iz jednog jednostavnog razloga. Imamo puno niti. Zašto nam ovo treba?
To u konačnici može stvoriti probleme jer ako imate PAM provjeru autentičnosti i ne-PAM provjeru autentičnosti, tada veliki val PAM provjere autentičnosti može značajno odgoditi ne-PAM provjeru autentičnosti. Ovo je jedna od onih stvari koje nismo popravili. Ali ako to želite popraviti, možete to učiniti.
Još jedna prednost je što imamo jednu nit koja prihvaća sve dolazne veze. Zatim se prebacuju u skup radnika, gdje će se dogoditi TLS rukovanje.
Zaključak, ako imate koherentan val od 20 000 mrežnih veza, sve će biti prihvaćene. A na strani klijenta libpq će početi izvještavati o isteku vremena. Prema zadanim postavkama čini se da je 3 sekunde.
Ako svi ne mogu ući u bazu u isto vrijeme, onda ne mogu ući u bazu, jer se sve to može pokriti neeksponencijalnim ponovnim pokušajem.
Došli smo do zaključka da smo ovdje kopirali shemu iz PgBouncera s činjenicom da imamo ograničenje broja TCP veza na koje prihvaćamo.
Ako vidimo da prihvaćamo veze, ali oni na kraju nemaju vremena za rukovanje, stavljamo ih u red čekanja kako ne bi uzalud trošili CPU resurse. To dovodi do činjenice da se istovremeno rukovanje možda neće izvesti za sve veze koje su stigle. Ali barem će netko ući u bazu podataka, čak i ako je opterećenje prilično veliko.
Putokaz
Što biste voljeli vidjeti u budućnosti u Odiseji? Što smo spremni sami razvijati i što očekujemo od zajednice?
Od kolovoza 2019.
Ovako je izgledao plan Odiseje u kolovozu:
- Htjeli smo SCRAM i PAM autentifikaciju.
- Htjeli smo proslijediti zahtjeve za čitanje u stanje pripravnosti.
- Želio bih online ponovno pokretanje.
- I mogućnost pauziranja na poslužitelju.
Pola ovog plana je dovršeno, i to ne mi. I ovo je dobro. Pa raspravimo o tome što ostaje i dodamo još.
? Imamo replike koje će jednostavno zagrijati zrak bez izvršavanja zahtjeva. Trebamo ih da osiguraju failover i switchover. U slučaju problema u nekom od podatkovnih centara, volio bih ih okupirati nekim korisnim poslom. Zato što ne možemo drugačije konfigurirati iste središnje procesore, istu memoriju, jer inače replikacija neće raditi.
U principu, u Postgresu, počevši od 10, moguće je navesti session_attrs prilikom povezivanja. Možete navesti sve hostove baze podataka u vezi i reći zašto idete u bazu podataka: samo pisanje ili čitanje. A vozač će sam odabrati prvi host na popisu koji mu se najviše sviđa, koji ispunjava zahtjeve session_attrs.
Ali problem s ovim pristupom je taj što ne kontrolira kašnjenje replikacije. Možda imate neku repliku koja je za vašu uslugu zaostajala nedopustivo dugo. Kako bismo omogućili potpuno izvršenje upita za čitanje na replici, u biti moramo podržati sposobnost Odysseyja da se ne pokreće kada se ne može pročitati.
Odyssey mora s vremena na vrijeme otići u bazu podataka i pitati za udaljenost replikacije od primarne. A ako je dosegla graničnu vrijednost, nemojte dopustiti nove zahtjeve u bazu podataka, recite klijentu da mora ponovno pokrenuti veze i, eventualno, odaberite drugo računalo za izvršavanje zahtjeva. Ovo će omogućiti bazi podataka da brzo obnovi kašnjenje replikacije i ponovno se vrati kako bi odgovorila sa zahtjevom.
Teško je dati vremenski okvir za implementaciju, jer je open source. Ali, nadam se, ne 2,5 godine kao moji kolege iz PgBouncera. Ovo je značajka koju bih želio vidjeti u Odiseji.
. Sada možete kreirati pripremljenu izjavu na dva načina. Prvo, možete izvršiti SQL naredbu, odnosno "pripremljeno". Kako bismo razumjeli ovu SQL naredbu, moramo naučiti razumjeti SQL na strani izbacivača. Ovo bi bilo pretjerano, jer je pretjerano, jer nam treba cijeli parser. Ne možemo analizirati svaku SQL naredbu.
Ali postoji pripremljena izjava na razini protokola poruka na proto3. I to je mjesto gdje informacija da se priprema pripremljena izjava dolazi u strukturiranom obliku. I mogli bismo podržati razumijevanje da je na nekoj vezi s poslužiteljem klijent tražio stvaranje pripremljenih izjava. Čak i ako je transakcija zatvorena, i dalje moramo održavati povezanost između poslužitelja i klijenta.
Ali tu nastaje diskrepanca u dijalogu, jer netko kaže da treba razumjeti kakve je pripremljene iskaze klijent kreirao i dijeliti serversku vezu između svih klijenata koji su kreirali tu serversku vezu, tj. koji su kreirali tako pripremljenu izjavu.
Andres Freund je rekao da ako vam dođe klijent koji je već kreirao tako pripremljenu izjavu u drugoj serverskoj vezi, onda je kreirajte za njega. Ali čini se malo pogrešnim izvršavati upite u bazi podataka umjesto klijenta, ali sa stajališta programera koji piše protokol za interakciju s bazom podataka, bilo bi zgodno da mu se jednostavno da mrežna veza u kojoj postoji takav pripremljeni upit.
I još jedna značajka koju moramo implementirati. Sada imamo nadzor kompatibilan s PgBouncerom. Možemo vratiti prosječno vrijeme izvršenja upita. Ali prosječno vrijeme je prosječna temperatura u bolnici: nekome je hladno, nekome toplo - u prosjeku su svi zdravi. To nije istina.
Moramo implementirati podršku za percentile koji bi pokazali da postoje spori upiti koji troše resurse i učinili praćenje prihvatljivijim.
Najvažnije je da želim verziju 1.0 (verzija 1.1 je već izašla). Činjenica je da je Odyssey sada u verziji 1.0rc, tj. kandidatu za izdanje. I svi problemi koje sam nabrojao riješeni su potpuno istom verzijom, osim curenja memorije.
Što će verzija 1.0 značiti za nas? Postavljamo Odyssey u naše baze. Već radi u našim bazama podataka, ali kada dosegne točku od 1 zahtjeva u sekundi, onda možemo reći da je ovo verzija izdanja i to je verzija koja se može nazvati 000.
Nekoliko ljudi u zajednici zatražilo je da verzija 1.0 uključi pauzu i SCRAM. Ali to će značiti da ćemo morati pokrenuti sljedeću verziju za proizvodnju, jer ni SCRAM ni pauza još nisu prekinuti. Ali najvjerojatnije će se ovo pitanje riješiti vrlo brzo.
Čekam tvoj zahtjev za povlačenjem. Također bih volio čuti kakve probleme imaš s Bouncerom. Raspravljajmo o njima. Možda možemo implementirati neke funkcije koje su vam potrebne.
Ovo je kraj mog dijela, htio bih vas poslušati. Hvala vam!
pitanja
Ako postavim svoj vlastiti application_name, hoće li biti ispravno proslijeđen, uključujući u skupljanje transakcija u Odysseyju?
Odiseja ili izbacivač?
U Odiseji. U Bounceru se baca.
Napravit ćemo set.
I ako moja stvarna veza skoči na druge veze, hoće li se prenijeti?
Napravit ćemo skup svih parametara koji su navedeni u listi. Ne mogu reći je li application_name na ovom popisu. Mislim da sam ga tamo vidio. Postavit ćemo sve iste parametre. S jednim zahtjevom, set će učiniti sve što je klijent instalirao prilikom pokretanja.
Hvala, Andrej, na izvješću! Dobar izvještaj! Drago mi je da se Odyssey svake minute razvija sve brže i brže. Želim nastaviti ovako. Već smo vas zamolili da imate vezu s više izvora podataka kako bi se Odyssey mogao povezati s različitim bazama podataka istovremeno, tj. glavnom podređenom bazom podataka, a zatim se automatski spojiti na novu glavnu bazu podataka nakon prelaska u grešku.
Da, čini mi se da se sjećam ove rasprave. Sada postoji nekoliko skladišta. Ali između njih nema prebacivanja. S naše strane, moramo ispitati poslužitelj da li je još živ i shvatiti da je došlo do failovera, koji će pozvati pg_recovery. Ja na standardni način razumijem da nismo došli do gospodara. I trebamo li nekako shvatiti iz grešaka ili što? Odnosno, ideja je zanimljiva, o njoj se raspravlja. Napišite više komentara. Ako imate radnike koji znaju C, onda je to super.
Pitanje skaliranja preko replika također nas zanima, jer želimo učiniti usvajanje repliciranih klastera što je moguće jednostavnijim za programere aplikacija. Ali ovdje bih želio više komentara, tj. kako točno to učiniti, kako to učiniti dobro.
Pitanje je i replika. Ispostavilo se da imate majstora i nekoliko replika. I jasno je da rjeđe idu kod replike nego kod majstora po spojeve, jer mogu imati razlike. Rekli ste da razlika u podacima može biti tolika da neće zadovoljiti vaše poslovanje i da nećete ići tamo dok se ne replicira. Istodobno, ako tamo niste išli dugo vremena, a onda ste krenuli, tada vam potrebni podaci neće biti odmah dostupni. Odnosno, ako stalno idemo do mastera, tada se predmemorija tamo zagrijava, ali u replici predmemorija malo zaostaje.
Da, istina je. Pcache neće imati blokove podataka koje želite, pravi cache neće imati informacije o tablicama koje želite, planovi neće imati analizirane upite, neće biti ničega.
A kad imaš nekakav klaster, pa tamo dodaš novu repliku, onda dok se pokrene, u njemu je sve loše, tj. poveća keš.
Shvatila sam. Ispravan pristup bio bi prvo pokrenuti mali postotak upita na replici, što bi zagrijalo predmemoriju. Grubo rečeno, imamo uvjet da za majstorom ne smijemo zaostajati više od 10 sekundi. I ovo stanje nije uključeno u jednom valu, ali glatko za neke klijente.
Da, povećati težinu.
Ovo je dobra ideja. Ali prvo moramo provesti ovo gašenje. Prvo trebamo isključiti, a onda ćemo razmišljati kako uključiti. Ovo je sjajna značajka za glatko omogućavanje.
Nginx ima ovu opciju slowly start u klasteru za poslužitelj. I postupno povećava opterećenje.
Da, super ideja, isprobat ćemo je kad stignemo.
Izvor: www.habr.com