U svom izlaganju, Andrej Borodin će objasniti kako su uzeli u obzir iskustvo skaliranja PgBouncer pri projektiranju connection poolera. , te kako su ga uveli u proizvodnu upotrebu. Također, raspraviti ćemo koje bi funkcije connection poolera voljeli vidjeti u novim verzijama: važno nam je ne samo zadovoljiti vlastite potrebe, već i razvijati zajednicu korisnika. .
Video:
Pozdrav svima! Moje ime je Andrej.
U Yandexu se bavim razvojem open source baza podataka. I danas imamo temu o connection pooleru.
Ako znate kako se connection pooler zove na hrvatskom, javite mi. Stvarno želim pronaći dobar tehnički termin koji bi trebao postati ustaljen u tehničkoj literaturi.
Tema je prilično složena, jer u mnogim bazama podataka je connection pooler ugrađen i zapravo nije potrebno ni znati za njega. Naravno, postoje neka podešavanja, ali to u Postgresu ne prolazi tako jednostavno. Paralelno (na HighLoad++ 2019) ide izlaganje Nikolaja Samohvalova o podešavanju upita u Postgresu. Razumijem da su ovdje ljudi koji su već savršeno postavili upite, i to su ljudi koji se suočavaju s rjeđim sistemskim problemima, povezanim s mrežom i iskorištavanjem resursa. Ponekad to može biti prilično složeno, jer problemi nisu očiti.
U Yandexu imamo Postgres. U Yandex.Cloudu žive mnogi servisi Yandexa. I imamo nekoliko petabajta podataka koji generiraju ne manje od milijun upita u sekundi u Postgresu.
Pruža se dovoljno tipičan klaster svim uslugama – to je osnovna primarna čvorna jedinica, obično dvije replikacije (sinhrona i asinhrona), rezervne kopije, skaliranje čitajućih upita na replikama.
Svaki čvor klastera je Postgres na kojem, osim Postgresa i sustava za praćenje, još je instaliran connection pooler. Connection pooler se koristi za fencing i po svojstvu namjene.
Što je osnovna namjena connection poolera?
U Postgresu je usvojena procesna paradigma pri radu s bazom podataka. To znači da je jedna veza jedan proces, jedan backend Postgresa. I u tom backendu ima mnogo različitih cache-ova koji je prilično skupo praviti različitima za razne veze.
Osim toga, u Postgres kodu postoji niz koji se zove procArray. Sadrži osnovne podatke o mrežnim vezama. Gotovo svi algoritmi za obradu procArray imaju linearni složenost, prolaze kroz cijeli niz mrežnih veza. To je prilično brza petlja, ali kada je u pitanju veći broj ulaznih mrežnih veza, sve postaje malo skuplje. A kada sve postane malo skuplje, na kraju možete platiti vrlo visoku cijenu za veliki broj mrežnih veza.
Postoje 3 moguća pristupa:
- Na strani aplikacije.
- Na strani baze podataka.
- I između, tj. razne kombinacije.
Nažalost, ugrađeni pooler je trenutno u fazi razvoja. Prijatelji iz tvrtke PostgreSQL Professional se uglavnom time bave. Kada će biti dostupan, teško je predvidjeti. I zapravo, arhitekt ima dvije opcije. To su application-side pool i proxy pool.
Application-side pool je najjednostavniji način. Gotovo svi klijentski drajveri pružaju mogućnost: milijune vaših veza u kodu predstaviti kao nekoliko desetaka veza u bazi podataka.
Pojavljuje se problem kada u određenom trenutku želite skalirati backend, želite ga rasporediti na više virtualnih mašina.
Tada shvatite da imate nekoliko dostupnih zona, nekoliko data centara. A pristup s client side pooling vodi do velikih brojeva. Velikih – oko 10 000 veza. To je kraj koji može normalno raditi.
Kada govorimo o proxy poolerima, postoje dva poolera koja znaju mnogo. Oni nisu samo pooleri. Oni su pooleri + dodatna sjajna funkcionalnost. To su i .
Ali, nažalost, ta dodatna funkcionalnost nije svima potrebna. I dovodi do toga da pooleri podržavaju samo sesijski pooling, tj. jedan ulazni klijent, jedan izlazni klijent u bazi podataka.
Za naše potrebe to nije baš dobro, stoga koristimo PgBouncer, koji implementira transaction pooling, tj. serverske veze se usklađuju s klijentskim vezama samo tijekom trajanja transakcije.
I pod našim opterećenjem – to je istina. Ali postoje neki problemi..
Problemi počinju kada želite dijagnosticirati sesiju, jer su sve ulazne veze lokalne. Sve dolaze s loopback-a i nekako je teško pratiti sesiju.
Naravno, možete koristiti application_name_add_host. To je način na strani Bouncer-a za dodavanje IP adrese u application_name. Ali application_name se postavlja dodatnom vezom.
Na ovom grafikonu, gdje je žuta linija stvarni zahtjevi, a plava linija su zahtjevi koji ulaze u bazu. I ta razlika predstavlja postavljanje application_name koje je potrebno samo za praćenje, ali nije potpuno besplatno.
Osim toga, u Bouncer-u nije moguće ograničiti jedan pool, tj. broj veza s bazom podataka za određenog korisnika ili određenu bazu.
K čemu to vodi? Imate opterećenu uslugu napisanju u C++ i negdje u blizini malu uslugu na nodu koja ne radi ništa strašno s bazom, ali njezin drajver poludi. Otvara 20.000 veza, a sve ostalo čeka. Čak imate i normalan kod.
Naravno, napisali smo mali patch za Bouncer koji je dodao ovu postavku, tj. ograničenje klijenata na pool.
To se moglo napraviti na strani Postgresa, tj. uloge u bazi podataka ograničiti brojem veza.
Ali tada gubite mogućnost da shvatite zašto nemate veze sa serverom. PgBouncer ne prolazi grešku veze, uvijek vraća istu informaciju. I ne možete shvatiti: možda vam se promijenila lozinka, možda je baza jednostavno pala, možda nešto nije u redu. Ali nema dijagnostike. Ako se sesija ne može uspostaviti, nećete saznati zašto to ne možete učiniti.
U jednom trenutku gledate grafikone aplikacije i vidite da aplikacija ne radi.
Gledate u top i vidite da je Bouncer jednopotni. To je prekretnica u životu usluge. Shvaćate da ste se pripremali za skaliranje baze podataka za godinu i pol, a sada morate skalirati pooler.
Došli smo do toga da nam treba više PgBouncer-a.
Malo smo ispravili Bouncer.
I napravili smo tako da može biti podignuto više Bouncer-a s ponovnom upotrebom TCP porta. A već operacijski sustav automatski prebacuje dolazne TCP veze između njih na round-robin način.
To je transparentno za klijente, tj. sve izgleda kao da imate jedan Bouncer, ali imate fragmentaciju idle veza između pokrenutih Bouncer-a.
U nekom trenutku možete primijetiti da ova tri Bouncer-a koriste 100 % svojih jezgri. Trebat će vam prilično puno Bouncer-a. Zašto?
Zato što imate TLS. Imate šifriranu vezu. Ako benchmarkirate Postgres s TLS-om i bez njega, otkrit ćete da broj uspostavljenih veza pada skoro za dva reda veličine kada se uključi šifriranje, jer TLS handshake troši resurse CPU-a.
Na vrhu možete vidjeti prilično mnogo kriptografskih funkcija koje se izvode tijekom vala dolaznih veza. Budući da naš primary može prelaziti između dostupnosnih zona, val dolaznih veza je prilično uobičajena situacija. To jest, iz nekog razloga stari primary je bio nedostupan, a sav teret je prebačen u drugi podatkovni centar. Oni će svi odjednom doći da se pozdrave s TLS-om.
Veliki broj TLS handshake-a možda se više ne pozdravlja s Bouncer-om, već mu može zagušiti kapacitet. Zbog vremenskog ograničenja val dolaznih veza može postati neiscrpan. Ako imate retry prema bazi bez eksponencijalnog backoff-a, oni neće ponovo dolaziti kao koherentni val.
Evo primjer 16 PgBouncer-a koji opterećuju 16 jezgri na 100 %.
Došli smo do kaskadnog PgBouncer-a. Ovo je najbolja konfiguracija koju možemo postići pod našim opterećenjem s Bouncer-om. Vanjski Bouncers služe za TCP handshake, dok unutarnji Bouncers služe za stvarno pooliranje, kako ne bi previše fragmentirali vanjske veze.
U takvoj konfiguraciji moguć je glatki restart. Možete restartati svih 18 Bouncer-a jedan po jedan. No, održavanje takve konfiguracije prilično je teško. Sustavni administratori, DevOps i ljudi koji su zaista odgovorni za ovaj server neće biti previše zadovoljni takvom shemom.
Činilo bi se da sve naše nadogradnje možemo promovirati u open source, ali Bouncer se ne podržava dobro. Na primjer, mogućnost pokretanja nekoliko PgBouncer-a na jednoj portu je odobrena prije mjesec dana. A pull request sa tom funkcijom bio je nekoliko godina ranije.
Ili još jedan primjer. U Postgresu možete prekinuti izvršavanje upita tako da pošaljete tajnu na drugu vezu bez dodatne autentifikacije. No neki klijenti jednostavno šalju TCP-reset, tj. prekidaju mrežnu vezu. Što će Bouncer učiniti u tom slučaju? Ništa. Nastavit će izvršavati upit. Ako imate ogroman broj veza koje malim upitima opterećuju bazu, samo prekinuti vezu s Bouncerom neće biti dovoljno; potrebno je također završiti one upite koji se izvršavaju u bazi.
To je ispravljeno i ovaj problem još nije integriran u upstream Bouncera.
I tako smo došli do zaključka da nam treba vlastiti connection pooler koji će se razvijati, ispravljati, u kojem će se moći brzo rješavati problemi i koji, naravno, treba biti višedretven.
Višedretvenost smo postavili kao glavni cilj. Moramo dobro podnositi val dolaznih TLS veza.
Zbog toga smo razvili posebnu biblioteku koja se zove Machinarium, koja je namijenjena opisivanju stanja mrežne veze kao sekvencijalnog koda. Ako pogledate izvorni kod libpq, vidjet ćete prilično složene pozive koji vam mogu vratiti rezultat i reći: 'Pozovi me malo kasnije. Sada radim IO, ali kada IO završi, imat ću opterećenje za procesor.' To je višeslojni sustav. Mrežna interakcija se obično opisuje kao mašina stanja. Mnogim pravilima, poput 'Ako sam ranije primio paketni zaglavlje veličine N, sada čekam N bajtova', 'Ako sam slao paket SYNC, sada čekam paket s metapodacima rezultata.' Dobija se prilično kompliciran kod koji ide protiv intuicije, kao da se labirint pretvara u linearno razlaganje. Napravili smo da umjesto mašine stanja programer opisuje glavni put interakcije u obliku običnog imperativnog koda. Jednostavno, u tom imperativnom kodu potrebno je umetnuti mjesta gdje se sekvenca izvršenja mora prekinuti čekanjem podataka s mreže, proslijedivši kontekst izvršenja drugoj korutini (green thread-u). Ovaj pristup je sličan onome da se najčešće očekivani put u labirintu zapisuje jedan za drugim, a zatim mu se dodaju grane.
Na kraju imamo jedan tok koji izvršava TCP akcept i round-robin distribuira više workers TPC veza.
Svaka klijentska veza uvek radi na jednom procesoru. To omogućava da bude friendly prema cache-u.
Osim toga, malo smo doradili sakupljanje malih paketa u jedan veliki paket radi olakšavanja sistemskog TCP stacka.
Takođe, poboljšali smo transakcijsko povlačenje tako da Odyssey uz postavljenu konfiguraciju može poslati CANCEL i ROLLBACK u slučaju prekida mrežne veze, tj. ako niko ne čeka na zahtev, Odyssey će reći bazi da ne pokušava da izvrši taj zahtev koji može trošiti dragocene resurse.
Po mogućstvu, zadržavamo veze za istog klijenta. To omogućava da se ne ponovo postavlja application_name_add_host. Ako je to moguće, nemamo dodatno ponavljanje parametara koji su potrebni za dijagnostiku.
Radimo u interesu Yandex. Oblaka. Ako koristite managed PostgreSQL i imate postavljen connection pooler, možete kreirati logičku replikaciju napolje, tj. otići od nas, ako želite, pomoću logičke replikacije. Bouncer neće proslediti tok logičke replikacije napolje.
Ovo je primer podešavanja logičke replikacije.
Takođe, imamo podršku za fizičku replikaciju napolje. U Oblaku je to, naravno, nemoguće, jer bi vaš klaster preneo previše informacija o sebi. Ali u vašim instalacijama, ako vam je potrebna fizička replikacija kroz connection pooler u Odyssey, to je moguće.
U Odyssey imamo potpuno kompatibilno praćenje sa PgBouncer. Imamo istu konzolu koja izvršava gotovo sve iste komande. Ako nešto nedostaje, pošaljite pull request ili bar issue na GitHub, dodaćemo neophodne komande. No, osnovna funkcionalnost konzole PgBouncer već postoji kod nas.
I, naravno, imamo prosleđivanje grešaka. Vraćamo onu grešku koju je prijavila baza. Dobijaćete informacije zašto ne možete da se povežete na bazu, a ne samo da ne možete da se povežete.
Ova mogućnost se isključuje u slučaju da vam je potrebna 100%-na kompatibilnost sa PgBouncer. Možemo se ponašati kao Bouncer, samo u slučaju.
Razvoj
Nekoliko reči o izvorom kodu Odyssey.
Na primjer, postoje komande „Pause / Resume“. Obično se koriste za ažuriranje baze podataka. Ako trebate ažurirati Postgres, možete ga staviti na pauzu u connection pooler-u, izvršiti pg_upgrade, a zatim nastaviti. Iz perspektive klijenta, to će izgledati kao da je baza jednostavno usporila. Ovu funkcionalnost su nam donijeli ljudi iz zajednice. Još nije spojeno, ali uskoro će sve biti. (Već je spojeno)
— već je spojeno
Osim toga, jedna od novih funkcija u PgBounceru je podrška za SCRAM Authentication, koju nam je također donio osoba koja ne radi u Yandex.Cloud-u. I jedno i drugo – vrlo su kompleksne funkcionalnosti i važne.
Stoga želim reći iz čega je sastavljen Odyssey, možda biste i vi željeli malo pisati kod.
Imate izvorni Odyssey koji se oslanja na dvije glavne biblioteke. Biblioteka Kiwi – to je implementacija Postgres protokola poruka. To jest, nativni proto 3 u Postgres-u su standardne poruke s kojima se frontend-i i backend-i mogu razmjenjivati. One su implementirane u biblioteci Kiwi.
Biblioteka Machinarium – to je biblioteka za implementaciju tokova. Mali dio ovog Machinarium-a napisan je u asembleru. Ali, ne bojte se, tu je samo 15 redaka.
Arhitektura Odyssey. Tu je glavna mašina u kojoj su pokrenute coroutines. U toj mašini je implementirano prihvaćanje dolaznih TCP veza i raspodjela po worker-ima.
Unutar jednog workera može raditi upravitelj više klijenata. Također, u glavnoj niti vrte se konzola i obrada crone-zadataka za uklanjanje veza koje više nisu potrebne u pool-u.
Za testiranje Odyssey-a koristi se standardni set testova Postgres-a. Jednostavno pokrećemo install-check kroz Bouncer i kroz Odyssey, dobijamo nulti div. Tu je nekoliko testova vezanih za formatiranje datuma koji se ne prolaze potpuno identično u Bouncer-u i u Odyssey-u.
Osim toga, postoji mnogo drajvera koji imaju svoje testiranje. Njihove teste koristimo za testiranje Odyssey-a.
Također, zbog naše kaskadne konfiguracije moramo testirati različite kombinacije: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey kako bismo bili sigurni da, ako se Odyssey nađe u nekom dijelu kaskade, on također nastavlja raditi onako kako očekujemo.
Grablje
Koristimo Odyssey u produkciji. Ne bi bilo pošteno reći da sve jednostavno radi. Da, u nekim slučajevima, ali ne uvijek. Na primjer, u produkciji je sve jednostavno radilo, a onda su nam naši prijatelji iz PostgreSQL Professional rekli da imamo curenje memorije. Doista su to otkrili, ispravili smo to. No, bilo je to jednostavno.
Tada smo otkrili da u connection pooleru postoje ulazne TLS veze i izlazne TLS veze. Za te veze su potrebni klijentni certifikati i serverski certifikati.
Serverski certifikati Bouncer i Odyssey ponovo pročitavaju iz svog pcache-a, ali klijentni certifikati ne trebaju biti ponovo pročitani iz pcache-a, jer naš skalabilni Odyssey u konačnici nailazi na sistemske performanse pri čitanju tog certifikata. To nam je bilo iznenađenje, jer se to nije dogodilo odmah. U početku se linearno skalirao, a nakon 20 000 istovremenih ulaznih veza problem se počeo manifestirati.
Pluggable Authentication Method je mogućnost autentifikacije ugrađenim linuxovim sredstvima. U PgBouncer-u to je implementirano tako da postoji poseban tok koji čeka na odgovor od PAM-a i postoji glavni tok PgBouncer-a koji opslužuje trenutnu vezu i može zatražiti da se zadrži u PAM toku.
To nismo implementirali zbog jedne jednostavne stvari. Imamo mnogo tokova. Zašto bi nam to bilo potrebno?
Na kraju, to može stvoriti probleme jer, ako imate PAM autentifikaciju i ne-PAM autentifikaciju, velika valna PAM autentifikacija može značajno usporiti ne-PAM autentifikaciju. To je jedna od onih stvari koju nismo ispravili. No, ako želite to ispraviti, možete se time pozabaviti.
Još jedan problem bio je to što imamo jedan tok koji prihvaća sve ulazne veze. I zatim ih prosljeđuje na worker pool, gdje će se odvijati TLS handshake.
Na kraju, ako imate koherentnu valnu od 20 000 mrežnih veza, sve će biti prihvaćene. I na strani klijenta libpq počet će odbrojavanje vremenskih ograničenja. Čini se da je osnovno vremensko ograničenje 3 sekunde.
Ako svi ne mogu istovremeno ući u bazu, ne mogu ući u bazu, jer sve to može biti pokriveno neeksponencijalnim ponovnim pokušajem.
Došli smo do toga da smo ovdje kopirali shemu iz PgBouncer-a s time da imamo ograničenje broja TCP veza koje prihvaćamo.
Ako vidimo da prihvaćamo veze, a one na kraju ne mogu uspostaviti handshake, stavljamo ih u red kako ne bi trošile resurse središnjeg procesora. To dovodi do toga da se istovremeni handshake ne može odvijati za sve veze koje su došle. No, barem će netko ući u bazu, čak i ako je opterećenje prilično snažno.
Putokaz
Što bismo željeli vidjeti u budućnosti u Odyssey? Što smo spremni sami razvijati i što čekamo od zajednice?
Za kolovoz 2019. godine.
Ovako je izgledao putokaz Odyssey u kolovozu:
- Željeli smo SCRAM i PAM autentifikaciju.
- Željeli smo preusmjeravanje upita za čitanje na standby.
- Željeli bismo online-restart.
- I mogućnost stavljanja poslužitelja na pauzu.
Polovica ovog putokaza je ostvarena, i to ne od nas. I to je dobro. Stoga, razgovarajmo o onome što je ostalo i dodajmo još.
? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.
U principu, u Postgresu, počevši od verzije 10, postoji mogućnost da pri povezivanju navedete i session_attrs. U vezi možete navesti sve hostove baza podataka i reći zašto idete u bazu podataka: za zapisivanje ili samo za čitanje. I drajver će sam odabrati prvi host na listi koji mu više odgovara, a koji ispunjava zahtjeve session_attrs.
Ali problem ovog pristupa je u tome što ne kontrolira kašnjenje replikacije. Može postojati neka replika koja kasni na neprihvatljivo vrijeme za vašu uslugu. Da bismo omogućili potpuno funkcionalno izvršavanje upita za čitanje na replici, u osnovi, trebamo podržati u Odyssey mogućnost da ne radi kada nije moguće čitati.
Odyssey bi trebao s vremena na vrijeme ići u bazu i pitati o replikacijskom razmaku od primarnog. I ako dostigne ograničenje, nove upite u bazu ne smije propustiti, reći klijentu da treba ponovo inicirati veze i, možda, odabrati drugi host za izvršavanje upita. To će omogućiti da se baza brže oporavi od replikacijskog kašnjenja i ponovo se vrati na odgovaranje na upite.
Teško je odrediti vremenske okvire realizacije, jer je to open source. No, nadam se da neće trajati 2,5 godine kao kod kolega iz PgBouncer. Ovu funkciju bismo željeli vidjeti u Odyssey.
. Sada možete stvoriti pripremljenu izjavu na dva načina. Prvo, možete izvršiti SQL naredbu, konkretno „pripremljenu“. Da bismo razumeli ovu SQL naredbu, moramo naučiti kako razumevati SQL s strane Bouncera. To bi bilo pretjerano, jer nam je potreban cjelokupni parser. Ne možemo parsirati svaku SQL naredbu.
No, postoji pripremljena izjava na nivou protokola poruka na proto3. I to je trenutak kada informacije o tome da se stvara pripremljena izjava dolaze u strukturiranom obliku. Mogli bismo podržati razumevanje da je na nekoj server konekciji klijent zatražio stvaranje pripremljenih izjava. Čak i ako je transakcija zatvorena, i dalje moramo održavati povezanost servera i klijenta.
Međutim, ovde dolazi do nesuglasja u dijalogu, jer neko govori o tome da je potrebno razumeti koju je točno pripremljenu izjavu klijent stvorio i razdvojiti server konekciju među svim klijentima koji su stvorili ovu server konekciju, tj. koji su stvorili takvu pripremljenu izjavu.
Andres Freund je rekao da, ako vam dođe klijent koji je već stvorio takvu pripremljenu izjavu na drugoj server konekciji, treba da je stvorite umesto njega. No, čini se da je pomalo pogrešno izvršavati upite u bazi umesto klijenta, ali s gledišta programera koji piše protokol interakcije sa bazom, bilo bi zgodno kada bi mu jednostavno dali mrežnu konekciju u kojoj postoji takav pripremljeni upit.
I još jedna funkcionalnost koju trebamo implementirati. Trenutno imamo monitoring kompatibilan s PgBouncerom. Možemo vratiti prosečno vreme izvršavanja upita. Ali prosečno vreme je prosek: neko je hladan, neko je topao - u proseku su svi zdravi. To nije istina.
Treba da implementiramo podršku za percentile koji bi ukazivali na to da postoje spori upiti koji troše resurse, a što bi monitoring učinilo prihvatljivijim.
Najvažnije – potrebna nam je verzija 1.0 (Verzija 1.1 je već objavljena). Činjenica je da je trenutno Odyssey u verziji 1.0rc, tj. release candidate. Svi problemi koje sam naveo su rešeni upravo s tom verzijom, osim curenja memorije.
Što za nas znači verzija 1.0? Izbacujemo Odyssey na naše baze. Već sada radi na našim bazama, ali kada postigne razinu od 1.000.000 zahtjeva u sekundi, možemo reći da je to verzija za izdavanje i da može biti nazvana 1.0.
U zajednici je nekoliko ljudi zatražilo da verzija 1.0 uključuje i pauzu i SCRAM. No to bi značilo da bismo morali odmah izbaciti sljedeću verziju u produkciju, jer ni SCRAM ni pauza još nisu spojeni. Ali, vjerojatno će se to pitanje riješiti dovoljno brzo.
Čekam vaše pull requestove. Također bih volio čuti koje probleme imate s Bouncer-om. O tome možemo razgovarati. Možda bismo mogli implementirati neke funkcije koje su vam potrebne.
Moja je uloga završila, volio bih čuti vas. Hvala!
Pitanja
Ako postavim application_name, hoće li se ispravno proslijediti, uključujući u transaction pooling u Odyssey?
U Odyssey ili u Bouncer-u?
U Odyssey. U Bouncer-u se proslijedi.
Postavit ćemo set.
I ako će moja stvarna veza skakati na druge veze, hoće li se ona proslijediti?
Učinit ćemo set svih parametara navedenih na popisu. Ne mogu reći je li application_name na tom popisu. Čini se da sam ga vidio. Postavit ćemo sve iste parametre. Jednim zahtjevom set će napraviti sve što je klijent postavio prilikom pokretanja.
Hvala, Andrej, na izlaganju! Dobro izlaganje! Drago mi je što se Odyssey s svakom minutom razvija sve brže. Želim da tako nastavite. Već smo se obratili s molbom da imamo multi data-source povezivanje kako bi Odyssey mogao istovremeno povezivati s različitim bazama podataka, tj. master slave, a zatim se automatski nakon failover-a povezivati s novim masterom.
Da, čini se da se sjećam te rasprave. Trenutno postoji nekoliko spremišta. No nema prebacivanja između njih. Moramo na našoj strani provjeriti server da li je još uvijek živ i shvatiti da je došlo do failover-a, tko će pozvati pg_recovery. Imam standardni način razumjeti da nismo došli na master. I moramo razumjeti na neki način iz grešaka ili kako? Ideja je zanimljiva, raspravlja se. Pišite više komentara. Ako imate radne ruke koje znaju C, to bi bilo sjajno.
Pitanje skaliranja replikama nas također zanima jer želimo učiniti usvajanje replikiranih klastera maksimalno jednostavnim za programere aplikacija. Međutim, ovdje bismo voljeli više komentara, tj. kako točno učiniti, kako to dobro učiniti.
Pitanje je također o replikama. Ispada da imate majstora i nekoliko replikacija. Jasno je da se u replice povezuje rjeđe nego u majstora, jer mogu postojati razlike. Rekli ste da razlike u podacima mogu biti takve da neće zadovoljiti vaše poslovanje i nećete se povezivati dok se ne replikiraju. U tom slučaju, ako dugo niste odlazili tamo, a zatim počnete, podaci koji su potrebni neće odmah biti dostupni. To jest, ako se stalno povezujemo s majstorom, tada je keš zagrijan, a u replici je keš malo zaostao.
Da, to je istina. U pcache neće biti blokova podataka koje želite, u real cache neće biti informacija o tablicama koje želite, u planovima neće biti analiziranih upita, jednostavno neće biti ničega.
I kada imate neki klaster i dodate novu repliku, dok se ona pokreće, u njoj je sve loše, tj. ona povećava svoj keš.
Shvatio sam ideju. Ispravan pristup bi bio pokrenuti mali postotak upita prvo na replici, koji bi zagrijali keš. Drugim riječima, imamo uvjet da ne smijemo zaostajati više od 10 sekundi za majstora. I to uključiti ne jednom, nego postepeno za neke klijente.
Da, povećati težinu.
To je dobra ideja. Ali prvo treba implementirati ovo isključivanje. Prvo se treba isključiti, a onda ćemo razmišljati kako se uključiti. To je odlična funkcija za postepeno uključivanje.
U nginx-u postoji takva opcija polako započeti u klasteru za server. I polako povećava opterećenje.
Da, odlična ideja, pokušat ćemo kada dođemo do toga.
Izvor: habr.com
