U svom izvještaju, Andrey Borodin će vam reći kako su uzeli u obzir iskustvo skaliranja PgBouncer-a prilikom dizajniranja spremišta veze , dok su ga pustili u proizvodnju. Osim toga, razgovarat ćemo o tome koje funkcije izvlakača želimo vidjeti u novim verzijama: važno nam je ne samo da zadovoljimo naše potrebe, već i da razvijamo korisničku zajednicu .
Video:
Zdravo svima! Moje ime je Andrew.
U Yandexu razvijam baze podataka otvorenog koda. A danas imamo temu o vezama spremišta veza.
Ako znate kako nazvati povezivač povezivanja na ruskom, onda mi recite. Zaista želim da pronađem dobar tehnički termin koji bi trebalo da bude uspostavljen u tehničkoj literaturi.
Tema je prilično komplicirana, jer je u mnogim bazama podataka ugrađen spremište veze i ne morate ni znati za njega. Naravno, svuda postoje neka podešavanja, ali u Postgresu to ne funkcioniše tako. I paralelno (na HighLoad++ 2019) postoji izvještaj Nikolaja Samokhvalova o postavljanju upita u Postgresu. I koliko sam shvatio, dolazili su ljudi koji su već savršeno konfigurisali svoje upite, a to su ljudi koji se suočavaju sa ređim sistemskim problemima vezanim za mrežu i korišćenje resursa. A na nekim mjestima bi to moglo biti prilično teško u smislu da problemi nisu očigledni.
Yandex ima Postgres. Mnoge usluge Yandexa žive u Yandex.Cloud. I imamo nekoliko petabajta podataka koji generišu najmanje milion zahteva u sekundi u Postgresu.
I mi obezbjeđujemo prilično standardni klaster za sve usluge - ovo je glavni primarni čvor čvora, uobičajene dvije replike (sinhrona i asinhrona), backup, skaliranje zahtjeva za čitanje na replici.
Svaki čvor klastera je Postgres, na kojem je pored Postgresa i sistema za praćenje instaliran i puler konekcija. 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 sa bazom podataka. To znači da je jedna veza jedan proces, jedan Postgres backend. A u ovom backendu postoji mnogo različitih keš memorija, koje je prilično skupo za različite veze.
Dodatno, Postgres kod ima niz pod nazivom procArray. Sadrži osnovne podatke o mrežnim vezama. I skoro svi algoritmi za obradu procArray-a imaju linearnu složenost; oni se kreću preko čitavog niza mrežnih veza. To je prilično brz ciklus, ali sa više dolaznih mrežnih veza stvari postaju malo skuplje. A kada stvari postanu malo skuplje, možete na kraju platiti vrlo visoku cijenu za mnogo mrežnih veza.
Postoje 3 moguća pristupa:
- Na strani aplikacije.
- Na strani baze podataka.
- I između, odnosno svih vrsta kombinacija.
Nažalost, ugrađeni pooler je trenutno u razvoju. Naši prijatelji u PostgreSQL Professional to uglavnom rade. Kada će se pojaviti teško je predvidjeti. I zapravo, imamo dva rješenja za arhitekte na izbor. To su bazen na strani aplikacije i proxy pool.
Bazen na strani aplikacije je najlakši način. I skoro svi klijentski drajveri pružaju vam način: predstavite milione vaših veza u kodu kao nekoliko desetina veza sa bazom podataka.
Problem koji se javlja je da u određenom trenutku želite da skalirate backend, želite da ga rasporedite na mnoge virtuelne mašine.
Tada shvatite da imate još nekoliko zona dostupnosti, nekoliko data centara. A pristup udruživanja na strani klijenta dovodi do velikih brojeva. Veliki su oko 10 priključaka. Ovo je rub koji može normalno raditi.
Ako govorimo o proxy poolerima, onda postoje dva poolera koji mogu učiniti mnogo stvari. Oni nisu samo sakupljači. Oni su poolers + više cool funkcionalnosti. Ovo и .
Ali, nažalost, nije svima potrebna ova dodatna funkcionalnost. I to dovodi do činjenice da pooleri podržavaju samo prikupljanje sesija, tj. jedan dolazni klijent, jedan odlazni klijent u bazu podataka.
Ovo nije baš prikladno za naše svrhe, pa koristimo PgBouncer, koji implementira prikupljanje transakcija, tj. serverske veze se uparuju sa klijentskim vezama samo za vrijeme trajanja transakcije.
I u našem poslu, to je tačno. Ali postoji nekoliko problema.
Problemi počinju kada želite dijagnosticirati sesiju, jer su sve vaše dolazne veze lokalne. Svi su došli sa povratnom petljom i nekako postaje teško pratiti sesiju.
Naravno, možete koristiti application_name_add_host. Ovo je način na strani izbacivača za dodavanje IP adrese aplikaciji_name. Ali application_name je postavljeno dodatnom vezom.
Na ovom grafikonu, gde su žuta linija stvarni zahtevi, a gde plava linija zahtevi koji lete u bazu podataka. A ova razlika je upravo u instalaciji aplikacije_name, koja je potrebna samo za praćenje, ali uopće nije besplatna.
Osim toga, u Bouncer-u ne možete ograničiti jedan bazen, tj. broj veza baze podataka po određenom korisniku, po određenoj bazi podataka.
čemu ovo vodi? Imate učitanu uslugu napisanu na C++-u i negdje u blizini mali servis na čvoru koji ne radi ništa strašno s bazom podataka, ali njen drajver poludi. Otvara 20 konekcija i sve ostalo će čekati. Čak je i vaš 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 učiniti na Postgres strani, odnosno ograničiti uloge u bazi po broju konekcija.
Ali tada gubite sposobnost da shvatite zašto nemate veze sa serverom. PgBouncer ne daje grešku u vezi, uvijek vraća iste informacije. I ne možete razumjeti: možda se vaša lozinka promijenila, možda se baza podataka jednostavno izgubila, možda nešto nije u redu. Ali nema dijagnoze. Ako sesija ne može biti uspostavljena, nećete znati zašto se ne može uspostaviti.
U određenom trenutku pogledate grafikone aplikacije i vidite da aplikacija ne radi.
Pogledajte vrh i vidite da je Bouncer jednonitni. Ovo je prekretnica u životu usluge. Shvaćate da ste se pripremali za skaliranje baze podataka za godinu i po dana, i morate skalirati pooler.
Došli smo do zaključka da nam treba više PgBouncera.
Bouncer je malo zakrpljen.
I napravili su tako da se nekoliko Bouncers-a može podići ponovnim korištenjem TCP porta. A operativni sistem automatski prenosi dolazne TCP veze između njih koristeći kružni rad.
Ovo je transparentno za klijente, što znači da izgleda kao da imate jedan Bouncer, ali imate fragmentaciju neaktivnih veza između pokrenutih Bouncer-a.
I u određenom trenutku možete primijetiti da ova 3 izbacivača svaki pojede svoje jezgro za 100%. Treba vam dosta izbacivača. Zašto?
Zato što imate TLS. Imate šifrovanu vezu. A ako uporedite Postgres sa i bez TLS-a, otkrićete da broj uspostavljenih veza opada za skoro dva reda veličine sa 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. Odnosno, iz nekog razloga stari primarni je bio nedostupan, cijelo opterećenje je poslano u drugi podatkovni centar. Svi će doći da se pozdrave sa TLS-om u isto vrijeme.
I veliki broj TLS rukovanja možda više neće pozdraviti izbacivača, već će mu stisnuti grlo. Zbog isteka vremena, val dolaznih veza može postati neprigušen. Ako ponovo pokušate sa bazom bez eksponencijalnog odustajanja, oni neće dolaziti iznova i iznova u koherentnom talasu.
Evo primjera 16 PgBouncers-a 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 opterećenju s Bouncer-om. Naši eksterni Bouncers se koriste za TCP rukovanje, a interni Bouncers se koriste za stvarno okupljanje, kako ne bi previše fragmentirali vanjske veze.
U ovoj konfiguraciji moguće je glatko ponovno pokretanje. Možete ponovo pokrenuti svih ovih 18 izbacivača jedan po jedan. Ali održavanje takve konfiguracije je prilično teško. Sysadmini, DevOps i ljudi koji su zapravo odgovorni za ovaj server neće biti baš zadovoljni ovim aranžmanom.
Čini se da se sva naša poboljšanja mogu promovirati u open source, ali Bouncer nije baš dobro podržan. Na primjer, mogućnost pokretanja nekoliko PgBouncers-a na jednom portu je izvršena prije mjesec dana. Postojao je zahtjev za povlačenjem s ovom funkcijom prije nekoliko godina.
Ili još jedan primjer. U Postgresu možete otkazati zahtjev koji je u toku slanjem tajne na drugu vezu bez nepotrebne autentifikacije. Ali neki klijenti jednostavno pošalju TCP reset, tj. prekidaju mrežnu vezu. Šta će Bouncer učiniti? Neće ništa da uradi. Nastavit će izvršavati zahtjev. Ako ste primili veliki broj konekcija koje su kreirale bazu podataka sa malim zahtjevima, tada jednostavno prekidanje veze s Bouncer-om neće biti dovoljno; također morate ispuniti one zahtjeve koji se pokreću u bazi podataka.
Ovo je zakrpljeno i ovaj problem još nije spojen sa Bouncer-ovim upstreamom.
I tako smo došli do zaključka da nam je potreban vlastiti pooler konekcija, koji će biti razvijen, zakrpljen, u kojem se problemi mogu brzo ispraviti i koji, naravno, mora biti višenitni.
Višenitnost smo postavili kao glavni zadatak. Moramo biti u mogućnosti da se dobro nosimo s talasom dolaznih TLS veza.
Da bismo to uradili, morali smo da razvijemo zasebnu biblioteku pod nazivom Machinarium, koja je dizajnirana da opiše stanje mašine mrežne veze kao sekvencijalni kod. Ako pogledate libpq izvorni kod, vidjet ćete neke prilično složene pozive koji vam mogu vratiti rezultat i reći: “Nazovi me kasnije. Trenutno imam IO za sada, ali kada IO nestane, imat ću opterećenje na procesoru.” A ovo je shema na više nivoa. Mrežnu komunikaciju obično opisuje državni stroj. Mnoga pravila poput „Ako sam prethodno primio zaglavlje paketa veličine N, sada čekam N bajtova“, „Ako sam poslao SYNC paket, sada čekam paket sa metapodacima rezultata“. Rezultat je prilično težak, kontraintuitivan kod, kao da je labirint pretvoren u linijsko skeniranje. Napravili smo tako da umjesto državnog stroja, programer opisuje glavni put interakcije u obliku običnog imperativnog koda. Samo u ovom imperativnom kodu trebate umetnuti mjesta na kojima se sekvenca izvršavanja treba prekinuti čekanjem podataka iz mreže, prosljeđivanjem konteksta izvršavanja drugoj korutini (zelena nit). Ovaj pristup je sličan činjenici da u nizu zapisujemo najočekivaniji put u lavirintu, a zatim mu dodajemo grane.
Kao rezultat toga, imamo jednu nit koja prihvata TCP i kružno prenosi TPC vezu mnogim radnicima.
U ovom slučaju, svaka klijentska veza uvijek radi na jednom procesoru. I to vam omogućava da ga učinite cache-friendly.
I pored toga, malo smo poboljšali prikupljanje malih paketa u jedan veliki paket kako bismo rasteretili sistemski TCP stek.
Osim toga, poboljšali smo prikupljanje transakcija u smislu da Odyssey, kada je konfiguriran, može poslati CANCEL i ROLLBACK u slučaju neuspjeha mrežne veze, tj. ako niko ne čeka zahtjev, Odyssey će reći bazi podataka da ne pokušava ispuniti zahtjev koji može izgubiti dragocjene resurse.
I kad god je to moguće, održavamo veze sa istim klijentom. Time se izbjegava ponovno instaliranje application_name_add_host. Ako je to moguće, onda ne moramo dodatno resetirati parametre koji su potrebni za dijagnostiku.
Radimo u interesu Yandex.Clouda. A ako koristite upravljani PostgreSQL i imate instaliran spremište veze, možete kreirati logičku replikaciju prema van, tj. ostaviti nas, ako želite, koristeći logičku replikaciju. Bouncer neće otpustiti logički tok replikacije izvana.
Ovo je primjer postavljanja logičke replikacije.
Osim toga, imamo podršku za fizičku replikaciju prema van. U Cloud-u je to, naravno, nemoguće, jer će vam tada klaster dati previše informacija o sebi. Ali u vašim instalacijama, ako vam je potrebna fizička replikacija putem spremišta veza u Odysseyu, to je moguće.
Odyssey ima potpuno kompatibilan nadzor sa PgBouncer-om. Imamo istu konzolu koja pokreće skoro sve iste komande. Ako nešto nedostaje, pošaljite zahtjev za povlačenjem, ili barem problem na GitHub-u, a mi ćemo izvršiti potrebne naredbe. Ali već imamo glavnu funkcionalnost konzole PgBouncer.
I, naravno, imamo prosljeđivanje grešaka. Vratit ćemo grešku koju je prijavila baza podataka. Dobit ćete informaciju zašto niste uključeni u bazu podataka, a ne samo da niste uključeni u nju.
Ova funkcija je onemogućena u slučaju da vam je potrebna 100% kompatibilnost sa PgBouncer-om. Možemo se ponašati na isti način kao Bouncer, samo da budemo sigurni.
Razvoj
Nekoliko riječi o izvornom kodu Odyssey.
Na primjer, postoje komande “Pauza / Nastavi”. Obično se koriste za ažuriranje baze podataka. Ako trebate ažurirati Postgres, onda ga možete pauzirati u spremištu veza, uraditi pg_upgrade, a zatim nastaviti. A sa strane klijenta će izgledati kao da se baza podataka jednostavno usporava. Ovu funkcionalnost su nam donijeli ljudi iz zajednice. Nije još zamrznuta, ali uskoro će sve biti. (već smrznuto)
- već smrznuto
Osim toga, jedna od novih mogućnosti u PgBouncer-u je podrška za SCRAM Authentication, koju nam je također donijela osoba koja ne radi u Yandex.Cloud-u. Obje su složene funkcionalnosti i važne.
Stoga bih vam želio reći od čega je napravljen Odyssey, u slučaju da i vi sada želite napisati mali kod.
Imate izvornu bazu Odyssey, koja se oslanja na dvije glavne biblioteke. Kiwi biblioteka je implementacija Postgres protokola za poruke. To jest, izvorni proto 3 Postgresa su standardne poruke koje front-end i back-end mogu razmjenjivati. Implementirani su u biblioteci Kiwi.
Biblioteka Machinarium je biblioteka implementacije niti. Mali fragment ovog Machinarium-a napisan je asemblerskim jezikom. Ali ne brinite, ima samo 15 redova.
Arhitektura Odiseje. Postoji glavna mašina na kojoj se pokreću korutine. Ova mašina implementira prihvatanje dolaznih TCP veza i njihovu distribuciju među radnicima.
Rukovalac za nekoliko klijenata može raditi unutar jednog radnika. Glavna nit također pokreće konzolu i obradu crone zadataka za brisanje veza koje više nisu potrebne u spremištu.
Odyssey je testiran korištenjem standardnog Postgres test paketa. Samo pokrenemo install-check kroz Bouncer i kroz Odyssey, dobijemo null div. Postoji nekoliko testova vezanih za formatiranje datuma koji ne prolaze potpuno isto u Bouncer i Odyssey.
Osim toga, postoji mnogo vozača koji imaju vlastito testiranje. A 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 ako Odyssey završi u nekom od dijelova kaskade, također i dalje radi kao što očekujemo.
Rake
U proizvodnji koristimo Odyssey. I ne bi bilo fer da kažem da sve funkcioniše. Ne, odnosno da, ali ne uvek. Na primjer, u produkciji je sve funkcionisalo, a 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 spremište veze ima dolazne TLS veze i odlazne TLS veze. Za veze su potrebni klijentski certifikati i certifikati servera.
Sertifikati Bouncer i Odyssey servera se ponovo čitaju njihovim pcache-om, ali klijentski certifikati ne moraju biti ponovo čitani iz pcache-a, jer naš skalabilni Odyssey na kraju nailazi na performanse sistema čitanja ovog certifikata. Ovo nas je iznenadilo, jer mu nije trebalo dugo da se odupre. U početku se linearno skalirao, ali nakon 20 dolaznih istovremenih veza ovaj problem se pokazao.
Pluggable Authentication Method je mogućnost provjere autentičnosti pomoću ugrađenih Lunux alata. U PgBouncer-u je implementiran na 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.
Ovo nismo implementirali iz jednog jednostavnog razloga. Imamo puno tema. Zašto nam ovo treba?
Ovo u konačnici može stvoriti probleme u tome što ako imate PAM autentifikaciju i ne-PAM autentifikaciju, onda veliki val PAM provjere autentičnosti može značajno odgoditi ne-PAM autentifikaciju. Ovo je jedna od onih stvari koje nismo popravili. Ali ako to želite popraviti, možete to učiniti.
Drugi rake je bio da imamo jednu nit koja prihvata sve dolazne veze. A zatim se prebacuju u grupu radnika, gdje će se održati TLS rukovanje.
Zaključak, ako imate koherentan val od 20 mrežnih veza, sve će biti prihvaćene. A na strani klijenta libpq će početi da izvještava o vremenskim ograničenjima. Podrazumevano se čini da je 000 sekunde.
Ako svi ne mogu ući u bazu podataka u isto vrijeme, onda ne mogu ući u bazu podataka, jer se sve to može pokriti neeksponencijalnim ponovnim pokušajem.
Došli smo do zaključka da smo kopirali shemu iz PgBouncera ovdje s činjenicom da imamo throttling broja TCP konekcija na koje prihvatamo.
Ako vidimo da prihvatamo veze, ali oni na kraju nemaju vremena za rukovanje, stavljamo ih u red kako ne bi troše CPU resurse. To dovodi do činjenice da se istovremeno rukovanje možda neće izvršiti za sve pristigle veze. Ali barem će neko ući u bazu podataka, čak i ako je opterećenje prilično veliko.
Roadmap
Šta biste voljeli vidjeti u budućnosti u Odiseji? Šta smo spremni da sami razvijamo i šta očekujemo od zajednice?
Od avgusta 2019.
Ovako je izgledala mapa puta Odiseje u avgustu:
- Htjeli smo SCRAM i PAM autentifikaciju.
- Htjeli smo proslijediti zahtjeve za čitanje u stanje pripravnosti.
- Želio bih ponovno pokretanje na mreži.
- I mogućnost pauziranja na serveru.
Polovina ove mape puta je završena, a ne mi. I ovo je dobro. Pa hajde da raspravimo šta je ostalo i dodajmo još.
? Imamo replike koje će jednostavno zagrijati zrak bez izvršavanja zahtjeva. Potrebni su nam da obezbede prelazak na grešku i prebacivanje. U slučaju problema u nekom od data centara, želio bih da ih zaokupim nekim korisnim poslom. Zato što ne možemo konfigurirati iste centralne procesore, istu memoriju različito, 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 za pisanje ili čitanje. I sam vozač će odabrati prvog hosta na listi koji mu se najviše sviđa, a koji ispunjava zahtjeve session_attrs.
Ali problem s ovim pristupom je što ne kontrolira kašnjenje replikacije. Možda imate neku repliku koja je zaostajala za neprihvatljivo vrijeme za vašu uslugu. Da bismo omogućili potpuno funkcionalno izvršavanje upita za čitanje na replici, u suštini moramo podržati Odyssey-ovu sposobnost da se ne pokreće kada se ne može pročitati.
Odyssey mora s vremena na vrijeme otići u bazu podataka i tražiti udaljenost replikacije od primarnog. A ako je dostigao graničnu vrijednost, ne dozvolite nove zahtjeve u bazu podataka, recite klijentu da treba ponovo pokrenuti veze i, eventualno, odabrati drugi host za izvršavanje zahtjeva. Ovo će omogućiti bazi podataka da brzo vrati kašnjenje replikacije i vrati se ponovo da odgovori sa zahtjevom.
Teško je dati vremenski okvir za implementaciju, jer je open source. Ali, nadam se, ne 2,5 godine kao moje kolege iz PgBouncera. Ovo je karakteristika koju bih volio vidjeti u Odiseji.
. Sada možete kreirati pripremljenu izjavu na dva načina. Prvo, možete izvršiti SQL naredbu, odnosno "prepared". Da bismo razumjeli ovu SQL naredbu, moramo naučiti razumjeti SQL na strani Bouncer. Ovo bi bilo pretjerano, jer je pretjerano, pošto nam je potreban cijeli parser. Ne možemo raščlaniti svaku SQL naredbu.
Ali postoji pripremljena izjava na nivou protokola poruke na proto3. I to je mjesto kada informacija da se kreira pripremljena izjava dolazi u strukturiranom obliku. I mogli bismo podržati razumijevanje da je na nekoj serverskoj vezi klijent tražio da kreira pripremljene izjave. Čak i ako je transakcija zatvorena, i dalje moramo održavati povezanost između servera i klijenta.
Ali ovdje dolazi do neslaganja u dijalogu, jer neko kaže da morate razumjeti kakve je pripremljene izjave klijent kreirao i podijeliti serversku vezu između svih klijenata koji su kreirali ovu serversku vezu, odnosno 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 stanovišta programera koji piše protokol za interakciju s bazom podataka, bilo bi zgodno kada bi mu se jednostavno dala mrežna veza u kojoj bi postoji tako pripremljen upit.
I još jedna karakteristika koju moramo implementirati. Sada imamo praćenje kompatibilno sa PgBouncer-om. 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 ukazivali da postoje spori upiti koji troše resurse i čine praćenje prihvatljivijim.
Najvažnije je da želim verziju 1.0 (verzija 1.1 je već objavljena). Činjenica je da je Odyssey sada u verziji 1.0rc, odnosno kandidat za izdanje. I svi problemi koje sam naveo su riješeni potpuno istom verzijom, osim curenja memorije.
Šta će verzija 1.0 značiti za nas? Uvodimo Odyssey u naše baze. Već radi na našim bazama podataka, ali kada dostigne tačku od 1 zahtjeva u sekundi, onda možemo reći da je ovo izdana verzija i da je to verzija koja se može nazvati 000.
Nekoliko ljudi u zajednici je tražilo da verzija 1.0 uključuje pauzu i SCRAM. Ali to će značiti da ćemo morati pustiti sljedeću verziju u proizvodnju, jer ni SCRAM ni pauza još nisu uništeni. Ali, najvjerovatnije, ovaj problem će biti riješen prilično brzo.
Čekam tvoj zahtjev za povlačenjem. Takođe bih voleo da čujem koje probleme imate sa Bouncer-om. Hajde da razgovaramo o njima. Možda možemo implementirati neke funkcije koje su vam potrebne.
Ovo je kraj mog dela, voleo bih da vas saslušam. Hvala ti!
Vaša pitanja
Ako postavim vlastitu aplikaciju_name, da li će ona biti ispravno proslijeđena, uključujući i prikupljanje transakcija u Odysseyu?
Odiseja ili izbacivač?
U Odiseji. U Bouncer-u se baca.
Napravićemo set.
A ako moja prava veza skoči na druge veze, hoće li se prenijeti?
Napravićemo skup svih parametara koji su navedeni na listi. Ne mogu reći da li je application_name na ovoj listi. Mislim da sam ga tamo video. Postavićemo sve iste parametre. Sa jednim zahtjevom, set će uraditi sve što je klijent instalirao prilikom pokretanja.
Hvala, Andrey, na izvještaju! Dobar izvještaj! Drago mi je da se Odyssey svakim minutom razvija sve brže. Želim da nastavim ovako. Već smo vas zamolili da imate višestruku vezu izvora podataka kako bi se Odyssey mogao povezati na različite baze podataka istovremeno, tj. na master slave, a zatim se automatski povezati s novim masterom nakon prelaska na grešku.
Da, izgleda da se sjećam ove rasprave. Sada postoji nekoliko skladišta. Ali između njih nema prebacivanja. Sa naše strane, moramo ispitati server da li je još uvijek živ i shvatiti da je došlo do greške, ko će pozvati pg_recovery. Ja na standardan način shvatam da nismo došli kod majstora. I treba li se nekako razumjeti iz grešaka ili šta? Odnosno, ideja je zanimljiva, o njoj se raspravlja. Napišite još komentara. Ako imate radnike koji znaju C, onda je to općenito odlično.
Pitanje skaliranja preko replika nas takođe zanima, jer želimo da usvajanje repliciranih klastera učinimo što jednostavnijim za programere aplikacija. Ali ovdje bih želio više komentara, odnosno kako to učiniti, kako to učiniti dobro.
Pitanje se odnosi i na replike. Ispostavilo se da imate majstora i nekoliko replika. I jasno je da oni rjeđe idu do replike nego kod mastera po veze, jer mogu imati razlike. Rekli ste da razlika u podacima može biti takva da neće zadovoljiti vaše poslovanje i da nećete ići tamo dok se ne repliciraju. U isto vrijeme, ako tamo niste otišli dugo vremena, a zatim počeli ići, tada potrebni podaci neće biti odmah dostupni. Odnosno, ako stalno idemo do mastera, tada se keš memorija tamo zagrijava, ali u replici keš malo zaostaje.
Da, to je istina. Pcache neće imati blokove podataka koje želite, pravi keš neće imati informacije o tabelama koje želite, planovi neće imati raščlanjene upite, neće biti ništa.
A kad imate neku vrstu klastera, i tamo dodate novu repliku, onda dok se pokrene sve je loše u njemu, tj. povećava svoju keš memoriju.
Imam ideju. Ispravan pristup bi bio da se prvo pokrene mali procenat upita na replici, što bi zagrejalo keš memoriju. Grubo rečeno, imamo uslov da za majstorom ne zaostajemo više od 10 sekundi. I ovo stanje nije uključeno u jedan talas, već glatko za neke klijente.
Da, povećajte težinu.
Ovo je dobra ideja. Ali prvo moramo implementirati ovo gašenje. Prvo trebamo isključiti, a onda ćemo razmišljati kako da upalimo. Ovo je odlična funkcija za nesmetano omogućavanje.
Nginx ima ovu opciju slowly start u klaster za server. I on postepeno povećava opterećenje.
Da, odlična ideja, isprobat ćemo je kad stignemo do nje.
izvor: www.habr.com