I sin rapport vil Andrey Borodin fortelle deg hvordan de tok hensyn til opplevelsen av å skalere PgBouncer når de designet tilkoblingspooleren , da de rullet den ut i produksjon. I tillegg vil vi diskutere hvilke funksjoner av trekkeren vi ønsker å se i nye versjoner: det er viktig for oss ikke bare å møte våre behov, men å utvikle brukerfellesskapet .
Video:
Hei alle sammen! Mitt navn er Andrew.
Hos Yandex utvikler jeg databaser med åpen kildekode. Og i dag har vi et emne om forbindelsespooler-tilkoblinger.
Hvis du vet hvordan du ringer forbindelsespooler på russisk, fortell meg det. Jeg ønsker virkelig å finne et godt fagbegrep som bør etableres i faglitteraturen.
Emnet er ganske komplisert, fordi i mange databaser er tilkoblingspooleren innebygd, og du trenger ikke engang å vite om det. Selvfølgelig er det noen innstillinger overalt, men i Postgres fungerer det ikke slik. Og parallelt (på HighLoad++ 2019) er det en rapport av Nikolai Samokhvalov om å sette opp spørringer i Postgres. Og slik jeg forstår det, kom folk hit som allerede hadde konfigurert spørringene sine perfekt, og dette er folk som står overfor mer sjeldne systemproblemer knyttet til nettverket og ressursutnyttelsen. Og noen steder kan det være ganske vanskelig i den forstand at problemene ikke er åpenbare.
Yandex har Postgres. Mange Yandex-tjenester bor i Yandex.Cloud. Og vi har flere petabyte med data som genererer minst en million forespørsler per sekund i Postgres.
Og vi tilbyr en ganske standard klynge for alle tjenester - dette er hovednoden til noden, de vanlige to replikaene (synkrone og asynkrone), backup, skalering av leseforespørsler på replikaen.
Hver klyngennode er Postgres, hvor det i tillegg til Postgres og overvåkingssystemer også er installert en tilkoblingspooler. Connection pooler brukes til inngjerding og til hovedformålet.
Hva er hovedformålet med forbindelsespooler?
Postgres tar i bruk en prosessmodell når du arbeider med en database. Dette betyr at én tilkobling er én prosess, én Postgres-backend. Og i denne backend er det mange forskjellige cacher, som er ganske dyre å lage forskjellige for forskjellige tilkoblinger.
I tillegg har Postgres-koden en matrise kalt procArray. Den inneholder grunnleggende data om nettverkstilkoblinger. Og nesten alle procArray-behandlingsalgoritmer har lineær kompleksitet; de kjører over hele utvalget av nettverksforbindelser. Det er en ganske rask syklus, men med flere innkommende nettverkstilkoblinger blir ting litt dyrere. Og når ting blir litt dyrere, kan du ende opp med å betale en veldig høy pris for mange nettverkstilkoblinger.
Det er 3 mulige tilnærminger:
- På søknadssiden.
- På databasesiden.
- Og mellom, altså alle slags kombinasjoner.
Dessverre er den innebygde pooleren for tiden under utvikling. Våre venner i PostgreSQL Professional gjør dette stort sett. Når det dukker opp er vanskelig å forutsi. Og faktisk har vi to løsninger for arkitekten å velge mellom. Disse er applikasjonssidepool og proxy pool.
Basseng på applikasjonssiden er den enkleste måten. Og nesten alle klientdrivere gir deg en måte: presentere millioner av tilkoblingene dine i kode som flere dusin tilkoblinger til databasen.
Problemet som oppstår er at du på et bestemt tidspunkt ønsker å skalere backend, vil du distribuere den til mange virtuelle maskiner.
Da skjønner du at du har flere tilgjengelighetssoner, flere datasentre. Og pooling-tilnærmingen på klientsiden fører til større antall. Store er omtrent 10 000 forbindelser. Dette er kanten som kan fungere normalt.
Hvis vi snakker om proxy-poolere, så er det to poolere som kan gjøre mange ting. De er ikke bare poolere. De er poolere + mer kul funksjonalitet. Dette и .
Men dessverre er det ikke alle som trenger denne tilleggsfunksjonen. Og det fører til det faktum at poolere kun støtter sesjonspooling, dvs. én innkommende klient, én utgående klient til databasen.
Dette er lite egnet for våre formål, så vi bruker PgBouncer, som implementerer transaksjonspooling, dvs. servertilkoblinger matches kun med klienttilkoblinger så lenge transaksjonen varer.
Og i vår arbeidsmengde er dette sant. Men det er noen problemer.
Problemene starter når du ønsker å diagnostisere en økt, fordi alle dine innkommende tilkoblinger er lokale. Alle kom med en loopback og på en eller annen måte blir det vanskelig å spore økten.
Selvfølgelig kan du bruke application_name_add_host. Dette er en måte på Bouncer-siden å legge til en IP-adresse til application_name. Men application_name er satt av en ekstra tilkobling.
På denne grafen, hvor den gule linjen er reelle forespørsler, og hvor den blå linjen er forespørsler som flyr inn i databasen. Og denne forskjellen er nettopp installasjonen av application_name, som bare er nødvendig for å spore, men det er ikke gratis i det hele tatt.
I tillegg kan du i Bouncer ikke begrense én pool, dvs. antall databasetilkoblinger per spesifikk bruker, per spesifikk database.
Hva fører dette til? Du har en lastet tjeneste skrevet i C++ og et sted i nærheten en liten tjeneste på en node som ikke gjør noe forferdelig med databasen, men driveren blir gal. Den åpner 20 000 tilkoblinger og alt annet vil vente. Selv koden din er normal.
Vi skrev selvfølgelig en liten oppdatering for Bouncer som la til denne innstillingen, dvs. begrenset klienter til bassenget.
Det ville være mulig å gjøre dette på Postgres-siden, dvs. begrense rollene i databasen med antall tilkoblinger.
Men da mister du muligheten til å forstå hvorfor du ikke har noen tilkoblinger til serveren. PgBouncer kaster ikke en tilkoblingsfeil, den returnerer alltid den samme informasjonen. Og du kan ikke forstå: kanskje passordet ditt har endret seg, kanskje databasen bare gikk tapt, kanskje noe er galt. Men det er ingen diagnose. Hvis en økt ikke kan etableres, vil du ikke vite hvorfor den ikke kan opprettes.
På et visst tidspunkt ser du på applikasjonsgrafene og ser at applikasjonen ikke fungerer.
Se på toppen og se at Bouncer er entrådet. Dette er et vendepunkt i tjenestens liv. Du innser at du forberedte deg på å skalere databasen om halvannet år, og du må skalere pooleren.
Vi har kommet til den konklusjonen at vi trenger flere PgBouncers.
Bouncer har blitt lappet litt.
Og de gjorde det slik at flere Bouncers kunne heves ved å gjenbruke TCP-porten. Og operativsystemet overfører automatisk innkommende TCP-forbindelser mellom dem ved hjelp av round-robin.
Dette er gjennomsiktig for klienter, noe som betyr at det ser ut som du har én Bouncer, men du har fragmentering av ledige forbindelser mellom kjørende Bouncers.
Og på et bestemt tidspunkt kan du legge merke til at disse 3 spretterne spiser opp kjernen sin med 100 %. Du trenger ganske mange bouncers. Hvorfor?
Fordi du har TLS. Du har en kryptert tilkobling. Og hvis du benchmarker Postgres med og uten TLS, vil du finne at antallet etablerte tilkoblinger synker med nesten to størrelsesordener med kryptering aktivert, fordi TLS-håndtrykket bruker CPU-ressurser.
Og øverst kan du se ganske mange kryptografiske funksjoner som utføres når det er en bølge av innkommende forbindelser. Siden vår primære kan bytte mellom tilgjengelighetssoner, er en bølge av innkommende forbindelser en ganske typisk situasjon. Det vil si at av en eller annen grunn var den gamle primæren utilgjengelig, hele lasten ble sendt til et annet datasenter. De vil alle komme for å hilse på TLS samtidig.
Og et stort antall TLS-håndtrykk sier kanskje ikke lenger hei til Bouncer, men vil klemme ham på halsen. På grunn av tidsavbruddet kan bølgen av innkommende tilkoblinger bli udempet. Hvis du prøver på nytt til basen uten eksponentiell backoff, vil de ikke komme igjen og igjen i en sammenhengende bølge.
Her er et eksempel på 16 PgBouncers som laster 16 kjerner med 100 %.
Vi kom til kaskaden PgBouncer. Dette er den beste konfigurasjonen som kan oppnås på lasten vår med Bouncer. Våre eksterne Bouncers brukes til TCP-håndtrykk, og interne Bouncers brukes til ekte pooling, for ikke å fragmentere eksterne forbindelser for mye.
I denne konfigurasjonen er en jevn omstart mulig. Du kan starte alle disse 18 spretterne på nytt én etter én. Men å opprettholde en slik konfigurasjon er ganske vanskelig. Sysadmins, DevOps og personer som faktisk er ansvarlige for denne serveren vil ikke være veldig fornøyd med denne ordningen.
Det ser ut til at alle forbedringene våre kan fremmes til åpen kildekode, men Bouncer er ikke særlig godt støttet. For eksempel ble muligheten til å kjøre flere PgBouncers på én port begått for en måned siden. Det var en pull-forespørsel med denne funksjonen for flere år siden.
Eller ett eksempel til. I Postgres kan du avbryte en pågående forespørsel ved å sende hemmeligheten til en annen tilkobling uten unødvendig autentisering. Men noen klienter sender ganske enkelt en TCP-tilbakestilling, det vil si at de bryter nettverksforbindelsen. Hva vil Bouncer gjøre? Han vil ikke gjøre noe. Den vil fortsette å utføre forespørselen. Hvis du har mottatt et stort antall tilkoblinger som har opprettet en database med små forespørsler, vil det ikke være nok å bare koble fra tilkoblingen fra Bouncer; du må også fullføre de forespørslene som kjører i databasen.
Dette har blitt korrigert og dette problemet er ennå ikke slått sammen med Bouncers oppstrøms.
Og så kom vi til den konklusjonen at vi trenger vår egen tilkoblingspooler, som skal utvikles, lappes, der problemer raskt kan rettes og som selvfølgelig må flertrådes.
Vi setter multithreading som hovedoppgave. Vi må være i stand til å håndtere bølgen av innkommende TLS-forbindelser godt.
For å gjøre dette, måtte vi utvikle et eget bibliotek kalt Machinarium, som er designet for å beskrive maskintilstandene til en nettverksforbindelse som sekvensiell kode. Hvis du ser på libpq-kildekoden, vil du se noen ganske komplekse anrop som kan gi deg et resultat og si: "Ring meg senere. Akkurat nå har jeg IO for nå, men når IO forsvinner vil jeg ha en belastning på prosessoren." Og dette er en ordning på flere nivåer. Nettverkskommunikasjon er vanligvis beskrevet av en statsmaskin. Mange regler som "Hvis jeg tidligere mottok en pakkeoverskrift av størrelse N, nå venter jeg på N byte," "Hvis jeg sendte en SYNC-pakke, venter jeg nå på en pakke med resultatmetadata." Resultatet er en ganske vanskelig, kontraintuitiv kode, som om labyrinten ble konvertert til linjeskanning. Vi gjorde det slik at i stedet for en tilstandsmaskin, beskriver programmereren hovedveien for interaksjon i form av vanlig imperativ kode. Det er bare at i denne imperative koden må du sette inn steder der utførelsessekvensen må avbrytes ved å vente på data fra nettverket, og overføre utførelseskonteksten til en annen korutine (grønn tråd). Denne tilnærmingen ligner på det faktum at vi skriver ned den mest forventede banen i labyrinten på rad, og deretter legger til grener til den.
Som et resultat har vi en tråd som godtar TCP og round-robin sender TPC-forbindelsen til mange arbeidere.
I dette tilfellet kjører hver klienttilkobling alltid på én prosessor. Og dette lar deg gjøre det cache-vennlig.
Og i tillegg har vi forbedret innsamlingen av små pakker litt til én stor pakke for å avlaste systemets TCP-stabel.
I tillegg har vi forbedret transaksjonspooling i den forstand at Odyssey, når den er konfigurert, kan sende CANCEL og ROLLBACK i tilfelle nettverkstilkoblingsfeil, dvs. hvis ingen venter på en forespørsel, vil Odyssey fortelle databasen om ikke å prøve å oppfylle forespørselen som kan kaste bort dyrebare ressurser.
Og når det er mulig, beholder vi forbindelser til samme klient. Dette unngår å måtte installere application_name_add_host på nytt. Hvis dette er mulig, trenger vi ikke å tilbakestille parameterne som er nødvendige for diagnostikk.
Vi jobber i Yandex.Clouds interesse. Og hvis du bruker administrert PostgreSQL og har en tilkoblingspooler installert, kan du lage logisk replikering utover, dvs. la oss, hvis du vil, bruke logisk replikering. Bouncer vil ikke frigjøre den logiske replikeringsflyten utenfor.
Dette er et eksempel på å sette opp logisk replikering.
I tillegg har vi støtte for fysisk replikering utad. I skyen er dette selvfølgelig umulig, for da vil klyngen gi deg for mye informasjon om seg selv. Men i installasjonene dine, hvis du trenger fysisk replikering gjennom tilkoblingspooleren i Odyssey, er dette mulig.
Odyssey har fullt kompatibel overvåking med PgBouncer. Vi har den samme konsollen som kjører nesten alle de samme kommandoene. Hvis noe mangler, send en pull-forespørsel, eller i det minste et problem på GitHub, og vi vil fullføre de nødvendige kommandoene. Men vi har allerede hovedfunksjonaliteten til PgBouncer-konsollen.
Og selvfølgelig har vi feilvideresending. Vi vil returnere feilen rapportert av databasen. Du vil få informasjon om hvorfor du ikke er inkludert i databasen, og ikke bare at du ikke er inkludert i den.
Denne funksjonen er deaktivert i tilfelle du trenger 100 % kompatibilitet med PgBouncer. Vi kan oppføre oss på samme måte som Bouncer, bare for å være på den sikre siden.
utforming
Noen få ord om Odyssey-kildekoden.
For eksempel er det "Pause / Fortsett"-kommandoer. De brukes vanligvis til å oppdatere databasen. Hvis du trenger å oppdatere Postgres, kan du sette den på pause i tilkoblingspooleren, gjøre pg_upgrade og deretter gjenoppta. Og fra klientens side vil det se ut som om databasen rett og slett bremset ned. Denne funksjonaliteten ble brakt til oss av folk fra samfunnet. Hun er ikke frosset ennå, men snart er alt. (Allerede frosset)
- allerede frosset
I tillegg er en av de nye funksjonene i PgBouncer støtte for SCRAM Authentication, som også ble brakt til oss av en person som ikke jobber i Yandex.Cloud. Begge er kompleks funksjonalitet og viktig.
Derfor vil jeg gjerne fortelle deg hva Odyssey er laget av, i tilfelle du også vil skrive litt kode nå.
Du har Odyssey-kildebasen, som er avhengig av to hovedbiblioteker. Kiwi-biblioteket er en implementering av Postgres-meldingsprotokollen. Det vil si at native proto 3 av Postgres er standardmeldinger som front-ends og back-ends kan utveksle. De er implementert i Kiwi-biblioteket.
Machinarium-biblioteket er et trådimplementeringsbibliotek. Et lite fragment av dette Machinarium er skrevet på samlespråk. Men ikke vær redd, det er bare 15 linjer.
Odyssey arkitektur. Det er en hovedmaskin som koroutiner kjører på. Denne maskinen implementerer å akseptere innkommende TCP-tilkoblinger og distribuere dem blant arbeidere.
En behandler for flere klienter kan jobbe innenfor én arbeider. Hovedtråden kjører også konsollen og behandlingen av crone-oppgaver for å slette tilkoblinger som ikke lenger er nødvendige i bassenget.
Odyssey er testet med standard Postgres testsuite. Vi kjører bare install-check gjennom Bouncer og gjennom Odyssey får vi en null div. Det er flere tester knyttet til datoformatering som ikke består nøyaktig det samme i Bouncer og i Odyssey.
I tillegg er det mange sjåfører som har egen testing. Og vi bruker testene deres til å teste Odyssey.
I tillegg, på grunn av vår kaskadekonfigurasjon, må vi teste ulike bunter: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey for å være sikre på at hvis Odyssey havnet i noen av delene i kaskaden, fungerer den også fortsatt som vi forventer.
Rake
Vi bruker Odyssey i produksjonen. Og det ville ikke være rettferdig hvis jeg sa at alt bare fungerer. Nei, altså, ja, men ikke alltid. For eksempel, i produksjon bare fungerte alt, så kom vennene våre fra PostgreSQL Professional og sa at vi hadde en minnelekkasje. Det var de virkelig, vi korrigerte dem. Men det var enkelt.
Så oppdaget vi at tilkoblingspooleren har innkommende TLS-tilkoblinger og utgående TLS-tilkoblinger. Og tilkoblinger krever klientsertifikater og serversertifikater.
Bouncer- og Odyssey-serversertifikater leses på nytt av pcache, men klientsertifikater trenger ikke å leses på nytt fra pcache, fordi vår skalerbare Odyssey til slutt kjører inn i systemytelsen for å lese dette sertifikatet. Dette kom som en overraskelse for oss, fordi det ikke tok ham lang tid å motstå. Først skalert det lineært, men etter 20 000 innkommende samtidige tilkoblinger viste dette problemet seg.
Pluggbar autentiseringsmetode er muligheten til å autentisere ved hjelp av innebygde Lunux-verktøy. I PgBouncer er det implementert på en slik måte at det er en egen tråd for å vente på svar fra PAM og det er en hoved PgBouncer-tråd som betjener gjeldende tilkobling og kan be dem om å leve i PAM-tråden.
Vi implementerte ikke dette av en enkel grunn. Vi har mange tråder. Hvorfor trenger vi dette?
Dette kan til slutt skape problemer ved at hvis du har PAM-autentisering og ikke-PAM-autentisering, kan en stor bølge av PAM-autentisering betydelig forsinke ikke-PAM-autentiseringen. Dette er en av de tingene vi ikke har fikset. Men hvis du vil fikse det, kan du gjøre dette.
En annen rake var at vi har én tråd som aksepterer alle innkommende forbindelser. Og så blir de overført til arbeiderbassenget, hvor TLS-håndtrykket vil finne sted.
Bunnlinjen, hvis du har en sammenhengende bølge av 20 000 nettverkstilkoblinger, vil de alle bli akseptert. Og på klientsiden vil libpq begynne å rapportere tidsavbrudd. Som standard ser det ut til å være 3 sekunder.
Hvis de ikke alle kan gå inn i databasen samtidig, kan de ikke gå inn i databasen, fordi alt dette kan dekkes av ikke-eksponensielle forsøk.
Vi kom til den konklusjonen at vi kopierte opplegget fra PgBouncer her med det faktum at vi har begrenset antall TCP-forbindelser som vi godtar.
Hvis vi ser at vi godtar tilkoblinger, men de til slutt ikke har tid til å håndtrykke, setter vi dem i en kø slik at de ikke kaster bort CPU-ressurser. Dette fører til at et samtidig håndtrykk kanskje ikke utføres for alle tilkoblinger som har ankommet. Men i det minste vil noen komme inn i databasen, selv om belastningen er ganske tung.
Roadmap
Hva vil du se i fremtiden i Odyssey? Hva er vi klare til å utvikle selv og hva forventer vi av samfunnet?
Fra august 2019.
Slik så Odyssey-veikartet ut i august:
- Vi ønsket SCRAM- og PAM-autentisering.
- Vi ønsket å videresende leseforespørsler til standby.
- Jeg vil ha en online omstart.
- Og muligheten til å pause på serveren.
Halvparten av dette veikartet er fullført, og ikke av oss. Og dette er bra. Så la oss diskutere hva som gjenstår og legge til mer.
? Vi har kopier som ganske enkelt vil varme opp luften uten å utføre forespørsler. Vi trenger dem for å gi failover og switchover. I tilfelle problemer i et av datasentrene, vil jeg gjerne okkupere dem med noe nyttig arbeid. Fordi vi ikke kan konfigurere de samme sentrale prosessorene, det samme minnet annerledes, fordi ellers vil ikke replikering fungere.
I prinsippet, i Postgres, fra 10, er det mulig å spesifisere session_attrs når du kobler til. Du kan liste opp alle databasevertene i forbindelsen og si hvorfor du går til databasen: skrive eller skrivebeskyttet. Og sjåføren vil selv velge den første verten i listen som han liker best, som oppfyller kravene til session_attrs.
Men problemet med denne tilnærmingen er at den ikke kontrollerer replikasjonsforsinkelsen. Du kan ha en replika som har ligget etter i en uakseptabel tid for tjenesten din. For å muliggjøre fullfunksjons kjøring av lesespørringer på en replika, må vi i hovedsak støtte Odysseys evne til å ikke kjøre når den ikke kan leses.
Odyssey må gå til databasen fra tid til annen og be om replikeringsavstanden fra primæren. Og hvis den har nådd grenseverdien, ikke tillat nye forespørsler inn i databasen, fortell klienten at den må starte tilkoblinger på nytt og eventuelt velge en annen vert for å utføre forespørsler. Dette vil tillate databasen å raskt gjenopprette replikeringsforsinkelsen og returnere igjen for å svare med en forespørsel.
Det er vanskelig å gi en tidsramme for implementering, fordi det er åpen kildekode. Men, håper jeg, ikke 2,5 år som mine kolleger fra PgBouncer. Dette er funksjonen jeg ønsker å se i Odyssey.
. Nå kan du lage en forberedt uttalelse på to måter. Først kan du utføre SQL-kommandoen, nemlig "prepared". For å forstå denne SQL-kommandoen, må vi lære å forstå SQL-en på Bouncer-siden. Dette ville være en overkill, fordi det er overkill, siden vi trenger hele parseren. Vi kan ikke analysere hver SQL-kommando.
Men det er en forberedt uttalelse på meldingsprotokollnivå på proto3. Og dette er stedet når informasjonen om at en utarbeidet erklæring blir opprettet kommer i en strukturert form. Og vi kunne støtte forståelsen av at klienten på en serverforbindelse ba om å lage forberedte uttalelser. Og selv om transaksjonen er avsluttet, må vi fortsatt opprettholde tilkoblingen mellom serveren og klienten.
Men her oppstår et avvik i dialogen, fordi noen sier at du må forstå hva slags forberedte uttalelser klienten opprettet og dele serverforbindelsen mellom alle klienter som opprettet denne serverforbindelsen, dvs. hvem som har laget en slik forberedt setning.
Andres Freund sa at hvis en klient kommer til deg som allerede har laget en slik forberedt uttalelse i en annen serverforbindelse, så lag den for ham. Men det virker litt feil å utføre spørringer i databasen i stedet for klienten, men fra synspunktet til utvikleren som skriver protokollen for å samhandle med databasen, ville det være praktisk om han ganske enkelt fikk en nettverkstilkobling som det er et slikt forberedt spørsmål.
Og en funksjon til som vi må implementere. Vi har nå overvåking som er kompatibel med PgBouncer. Vi kan returnere gjennomsnittlig utførelsestid for spørringer. Men gjennomsnittstiden er gjennomsnittstemperaturen på sykehuset: noen er kalde, noen er varme - i gjennomsnitt er alle friske. Det er ikke sant.
Vi må implementere støtte for persentiler som tyder på at det er trege forespørsler som sløser med ressurser og gjør overvåking mer akseptabel.
Det viktigste er at jeg vil ha versjon 1.0 (versjon 1.1 er allerede sluppet). Faktum er at Odyssey nå er i versjon 1.0rc, det vil si utgivelseskandidat. Og alle problemene som jeg listet opp ble løst med nøyaktig samme versjon, bortsett fra minnelekkasjen.
Hva vil versjon 1.0 bety for oss? Vi ruller ut Odyssey til våre baser. Den kjører allerede på våre databaser, men når den når punktet på 1 000 000 forespørsler per sekund, så kan vi si at dette er utgivelsesversjonen og dette er en versjon som kan kalles 1.0.
Flere personer i samfunnet har bedt om at versjon 1.0 inkluderer pause og SCRAM. Men dette vil bety at vi må rulle ut neste versjon til produksjon, fordi verken SCRAM eller pause har blitt drept ennå. Men mest sannsynlig vil dette problemet løses ganske raskt.
Jeg venter på pull-forespørselen din. Jeg vil også gjerne høre hvilke problemer du har med Bouncer. La oss diskutere dem. Kanskje vi kan implementere noen funksjoner du trenger.
Dette er slutten på min del, jeg vil gjerne høre på deg. Takk skal du ha!
spørsmål
Hvis jeg angir mitt eget application_name, vil det videresendes riktig, inkludert i transaksjonspooling i Odyssey?
Odyssey eller Bouncer?
I Odyssey. I Bouncer blir det kastet.
Vi lager et sett.
Og hvis den virkelige forbindelsen min hopper på andre forbindelser, vil den da bli overført?
Vi vil lage et sett med alle parametere som er oppført i listen. Jeg kan ikke se om application_name er på denne listen. Jeg tror jeg så ham der. Vi vil sette alle de samme parameterne. Med én forespørsel vil settet gjøre alt som ble installert av klienten under oppstarten.
Takk, Andrey, for rapporten! God rapport! Jeg er glad for at Odyssey utvikler seg raskere og raskere for hvert minutt. Jeg vil fortsette slik. Vi har allerede bedt deg om å ha en multidatakildetilkobling slik at Odyssey kan koble til forskjellige databaser samtidig, det vil si en masterslave, og deretter automatisk koble til en ny master etter failover.
Ja, jeg ser ut til å huske denne diskusjonen. Nå er det flere lager. Men det er ingen veksling mellom dem. På vår side må vi spørre serveren om at den fortsatt er i live og forstå at en failover har skjedd, som vil kalle pg_recovery. Jeg har en standard måte å forstå at vi ikke kom til mesteren. Og skal vi på en eller annen måte forstå av feilene eller hva? Det vil si at ideen er interessant, den diskuteres. Skriv flere kommentarer. Hvis du har arbeidere som kjenner C, så er det flott.
Spørsmålet om skalering på tvers av replikaer er også av interesse for oss, fordi vi ønsker å gjøre bruken av replikerte klynger så enkel som mulig for applikasjonsutviklere. Men her vil jeg gjerne ha flere kommentarer, dvs. nøyaktig hvordan man gjør det, hvordan man gjør det bra.
Spørsmålet handler også om kopier. Det viser seg at du har en mester og flere kopier. Og det er klart at de går til replikaen sjeldnere enn til mesteren for forbindelser, fordi de kan ha forskjeller. Du sa at forskjellen i dataene kan være slik at de ikke vil tilfredsstille virksomheten din, og du vil ikke gå dit før den er replikert. På samme tid, hvis du ikke dro dit på lenge, og deretter begynte å gå, vil ikke dataene som trengs umiddelbart være tilgjengelige. Det vil si at hvis vi hele tiden går til masteren, blir cachen der varmet opp, men i replikaen henger cachen litt.
Ja det er sant. PCache vil ikke ha datablokkene du ønsker, den virkelige cachen vil ikke ha informasjon om tabellene du vil ha, planene vil ikke ha analyserte spørringer, det vil ikke være noe i det hele tatt.
Og når du har en slags klynge, og du legger til en ny replika der, så mens den starter, er alt dårlig i den, det vil si at den øker cachen.
Jeg fikk ideen. Den riktige tilnærmingen ville være å kjøre en liten prosentandel av spørringene på replikaen først, noe som ville varme opp hurtigbufferen. Grovt sett har vi en betingelse om at vi ikke må ligge bak mesteren med ikke mer enn 10 sekunder. Og denne tilstanden er ikke inkludert i én bølge, men jevnt for noen klienter.
Ja, øk vekten.
Dette er en god idé. Men først må vi implementere denne nedleggelsen. Først må vi slå av, og så vil vi tenke på hvordan vi slår på. Dette er en flott funksjon for å aktivere jevnt.
Nginx har dette alternativet slowly start i en klynge for serveren. Og han øker gradvis belastningen.
Ja, god idé, vi prøver det når vi kommer til det.
Kilde: www.habr.com