I rapporten vil Andrey Borodin fortælle, hvordan de tog erfaringerne fra skalering af PgBouncer i betragtning ved designet af connection pooleren. , og hvordan de rullede det ud i produktion. Derudover vil vi diskutere, hvilke funktioner vi gerne vil se i nye versioner af pooleren: det er vigtigt for os ikke kun at dække vores egne behov, men også at udvikle brugersamfundet. .
Video:
Hejsa alle! Jeg hedder Andrey.
Hos Yandex arbejder jeg med udvikling af open source-databaser. I dag skal vi tale om connection pooler.
Hvis du ved, hvordan man oversætter connection pooler til russisk, så sig det til mig. Jeg vil meget gerne finde en god teknisk term, der kan etablere sig i den tekniske litteratur.
Emnet er ret komplekst, fordi mange databaser har indbyggede connection poolere, som man ikke engang behøver at vide noget om. Der er selvfølgelig nogle indstillinger overalt, men sådan er det ikke i Postgres. Og parallelt (på HighLoad++ 2019) er der et oplæg fra Nikolai Samokhvalov om forespørgselsindstillinger i Postgres. Og jeg forstår, at her er kommet folk, som allerede har indstillet deres forespørgsler perfekt, og det er folk, der står over for mere sjældne systemproblemer, relateret til netværk og ressourceudnyttelse. Nogle gange kan det være ret svært, fordi problemerne ikke er åbenlyse.
I Yandex findes der Postgres. I Yandex.Cloud lever mange af Yandex' tjenester. Vi har flere petabyte data, som genererer ikke mindre end en million forespørgsler i sekundet i Postgres.
Og vi tilbyder et temmelig standardiseret cluster til alle tjenester – dette er den primære node, almindelige to replikaer (synkron og asynkron), backup, og skalerer læseforespørgsler på replikaen.
Hver node i clusteren er en Postgres, hvor der udover Postgres og systemmonitorering også er installeret en connection pooler. Connection pooleren bruges til fencing og til sit primære formål.
Hvad er det primære formål med connection pooleren?
I Postgres anvendes en procesmodel, når man arbejder med databasen. Det betyder, at én forbindelse svarer til én proces, én Postgres-backend. Og i denne backend er der mange forskellige caches, som er ret dyre at gøre forskellige for forskellige forbindelser.
Derudover er der i Postgres-koden et array, der hedder procArray. Det indeholder de grundlæggende data om netværksforbindelser. Og næsten alle algoritmer til behandling af procArray har lineær kompleksitet, da de gennemgår hele arrayet med netværksforbindelser. Det er en ret hurtig løkke, men med et stort antal indkommende netværksforbindelser bliver det lidt dyrere. Og når det hele bliver lidt dyrere, kan man i sidste ende betale en meget høj pris for et stort antal netværksforbindelser.
Der er 3 mulige tilgange:
- På applikationssiden.
- På databasesiden.
- Og imellem, dvs. forskellige kombinationer.
Desværre er den indbyggede pooler stadig under udvikling. Vennerne i PostgreSQL Professional arbejder hovedsageligt med det. Hvornår det bliver tilgængeligt, er svært at forudsige. Faktisk har vi to løsninger tilgængelige for arkitekten. Det er application-side pool og proxy pool.
Application-side pool er den nemmeste måde. Og næsten alle klientdrivere giver dig en måde: at repræsentere millioner af dine forbindelser i koden som nogle få dusin forbindelser til databasen.
Der opstår et problem, når du på et givent tidspunkt ønsker at skalere backend'en, når du ønsker at implementere den på mange virtuelle maskiner.
Så indser du, at du også har flere tilgængelighedszoner, flere datacentre. Og tilgangen med client side pooling fører til store tal. Store tal er omkring 10.000 forbindelser. Det er grænsen for, hvad der kan fungere ordentligt.
Når vi taler om proxy poolers, er der to poolers, som kan en masse forskellige ting. De er ikke kun poolers. De er poolers + yderligere fantastisk funktionalitet. Det er og .
Men desværre er denne ekstra funktionalitet ikke nødvendig for alle. Og den fører til, at poolers kun understøtter session pooling, dvs. én indkommende klient, én udgående klient til databasen.
Til vores opgaver passer det ikke så godt, derfor bruger vi PgBouncer, som implementerer transaction pooling, dvs. serverforbindelser matches med klientforbindelser kun i løbet af transaktionen.
Og under vores belastning – det er sandt. Men der er nogle problemer..
Problemerne begynder, når du ønsker at diagnosticere en session, fordi alle indkommende forbindelser er lokale. Alle kommer fra loopback, og det bliver svært at spore sessionen.
Selvfølgelig kan du bruge application_name_add_host. Det er en måde for Bouncer at tilføje en IP-adresse til application_name på. Men application_name oprettes med en ekstra forbindelse.
I denne graf er den gule linje de faktiske forespørgsler, mens den blå linje viser forespørgsler, der flyder ind i databasen. Og denne forskel illustrerer netop indstillingen af application_name, som kun er nødvendigt for sporing, men som ikke er gratis.
Desuden kan man ikke begrænse én pool i Bouncer, dvs. antallet af databaserforbindelser til en bestemt bruger, til en bestemt database.
Hvad fører det til? Du har en belastet service skrevet i C++, og et lille serviceprogram på Node, der ikke forvolder databasen nogen skade, men hvor driveren går amok. Den åbner 20.000 forbindelser, og alt andet må vente. Du har endda en god kode.
Vi skrev selvfølgelig en lille patch til Bouncer, der tilføjede denne indstilling, dvs. grænsen for klienter på poolen.
Det kunne også gøres på Postgres-siden, dvs. at begrænse rollerne i databasen til et bestemt antal forbindelser.
Men så mister du muligheden for at forstå, hvorfor du ikke har forbindelser til serveren. PgBouncer videresender ikke forbindelsesfejl, den returnerer altid den samme information. Og du kan ikke forstå: måske er dit kodeord ændret, måske er databasen bare nede, måske er der noget galt. Men der er ingen diagnosticering. Hvis sessionen ikke kan etableres, finder du ikke ud af, hvorfor det ikke er muligt.
På et bestemt tidspunkt ser du på applikationens grafer og bemærker, at applikationen ikke fungerer.
Du kigger på toppen og ser, at Bouncer er enkelttrådet. Det er et vendepunkt i tjenestens liv. Du indser, at du forberedte dig på at skalere databasen om halvandet år, men du skal skalere pooleren.
Vi er nået frem til, at vi har brug for flere PgBouncer'ere.
Vi har lidt patched Bouncer.
Og vi har gjort det muligt at starte flere Bouncers med genbrug af TCP-porten. Og operativsystemet håndterer nu indgående TCP-forbindelser automatisk ved hjælp af round-robin.
Det er gennemsigtigt for klienterne, dvs. alt ser ud som om du har én Bouncer, men der er fragmentering af inaktive forbindelser mellem de kørende Bouncers.
Og på et bestemt tidspunkt kan du bemærke, at disse 3 Bouncers bruger hver deres kerne 100 %. Du har brug for en hel del Bouncers. Hvorfor?
Fordi du har TLS. Du har en krypteret forbindelse. Og hvis du benchmarker Postgres med TLS og uden TLS, vil du opdage, at antallet af etablerede forbindelser falder med næsten to ordener, når krypteringen er aktiveret, fordi TLS handshake bruger CPU-ressourcer.
Og øverst kan du se et ret stort antal kryptografiske funktioner, der udføres under en bølge af indkommende forbindelser. Da vores primære kan skifte mellem tilgængelighedszoner, er en bølge af indkommende forbindelser en ret typisk situation. Det vil sige, at af en eller anden grund var den gamle primære utilgængelig, og al belastning blev sendt til et andet datacenter. De vil alle komme og hilse på TLS samtidigt.
Og et stort antal TLS handshakes kan måske ikke hilse på Bouncer, men klemme dets hals. På grund af timeout kan bølgen af indkommende forbindelser blive vedvarende. Hvis du har retries til databasen uden eksponentiel backoff, vil de fortsætte med at komme igen og igen i en sammenhængende bølge.
Her er et eksempel med 16 PgBouncers, der belaster 16 kerner 100 %.
Vi er nået til det kaskadede PgBouncer. Dette er den bedste konfiguration, vi kan opnå med vores belastning af Bouncer. Eksterne Bouncers tjener os til TCP handshake, mens interne Bouncers bruges til den reelle pooling, for at undgå at fraktionere de eksterne forbindelser for meget.
I en sådan konfiguration er en glidende genstart mulig. Du kan genstarte alle disse 18 Bouncers én ad gangen. Men det er ret svært at vedligeholde en sådan konfiguration. Systemadministratorer, DevOps og de personer, der faktisk har ansvaret for denne server, vil ikke være meget glade for en sådan skema.
Det kunne synes, at vi kunne fremme alle vores forbedringer som open source, men Bouncer understøttes ikke særlig godt. For eksempel blev muligheden for at køre flere PgBouncers på én port committet for en måned siden. Og pull requesten med denne funktion blev sendt for flere år siden.
Eller et andet eksempel. I Postgres kan du annullere en kørende forespørgsel ved at sende en hemmelighed til en anden forbindelse uden ekstra autentificering. Men nogle klienter sender blot en TCP-reset, dvs. de afbryder netværksforbindelsen. Hvad vil Bouncer så gøre? Han vil ikke gøre noget. Han vil fortsætte med at udføre forespørgslen. Hvis du har modtaget et enormt antal forbindelser, som med små forespørgsler har belastet databasen, vil det ikke være tilstrækkeligt bare at afbryde forbindelsen fra Bouncer, du skal også afslutte de forespørgsler, der kører i databasen.
Dette blev patchet, og dette problem er stadig ikke blevet integreret i upstream Bouncer.
Og således kom vi frem til, at vi havde brug for vores egen connection pooler, som ville udvikle sig, blive patchet, hvor vi hurtigt kunne rette problemer, og som selvfølgelig skulle være multitrådet.
Multitrådning satte vi som en primær opgave. Vi har brug for at kunne håndtere en stor bølge af indgående TLS-forbindelser.
For dette måtte vi udvikle et separat bibliotek, der hedder Machinarium, som er beregnet til at beskrive maskintilstande for netværksforbindelsen som sekventiel kode. Hvis du ser i kildekoden til libpq, vil du se ret komplekse opkald, som kan returnere et resultat og sige: "Kald mig lidt senere. Jeg har netop IO nu, men når IO er færdigt, vil jeg have CPU-belastning." Og dette er et flerlags system. Netværk interaktioner beskrives normalt med en tilstandsautomat. Et væld af regler som "Hvis jeg tidligere har modtaget en pakke header størrelse N, så venter jeg nu på N bytes", "Hvis jeg har sendt en SYNC-pakke, så venter jeg nu på en pakke med metadata resultatet." Det resulterer i ret svært kontraintuitiv kode, som om et labyrint var konverteret til en linjeudfoldning. Vi har gjort det sådan, at i stedet for en tilstandsautomat, beskriver programmøren den primære interaktionsvej i form af almindelig imperativ kode. Bare i denne imperativ kode skal der indsættes steder, hvor udførelsesrækkefølgen skal brydes for at vente på data fra netværket ved at overføre udførelseskonteksten til en anden korutine (green thread). Denne metode ligner det, at vi skriver den mest forventede vej i labyrinten ned, og så tilføjer vi forgreninger til den.
Som vi har endeligt har vi én tråd, der håndterer TCP accept og vidarefører forbindelsen til mange workers med round-robin.
Desuden kører hver klientforbindelse altid på én processor, hvilket gør den cache-venlig.
Vi har også foretaget lidt arbejde med at samle små pakker til én stor pakke for at aflaste det systemmæssige TCP-stack.
Derudover har vi forbedret transaktionspuljen, så Odyssey med den rette indstilling kan sende CANCEL og ROLLBACK i tilfælde af afbrudt netværksforbindelse, dvs. hvis ingen venter på forespørgslen, vil Odyssey fortælle databasen, at den ikke skal forsøge at udføre den forespørgsel, som kan bruge værdifulde ressourcer.
Og så vidt muligt bevarer vi forbindelserne til den samme klient. Dette gør det muligt ikke at geninstallere application_name_add_host. Hvis muligt, har vi ingen yderligere geninstallation af de parametre, der er nødvendige til diagnosticering.
Vi arbejder for Yandex.Cloud. Hvis du bruger managed PostgreSQL og har en connection pooler indstillet, kan du oprette en logisk replikation udad, dvs. forlade os, hvis du ønsker det, ved hjælp af logisk replikation. Bouncer vil ikke give udadgående strøm af logisk replikation.
Dette er et eksempel på opsætning af logisk replikation.
Derudover har vi support for fysisk replikation udad. I clouden er det selvfølgelig umuligt, da klusteret så ville give for meget information om sig selv. Men i dine installationer, hvis du har brug for fysisk replikation gennem connection pooler i Odyssey, er det muligt.
Odyssey har fuldt kompatibel overvågning med PgBouncer. Vi har et lignende interface, der udfører næsten alle de samme kommandoer. Hvis der mangler noget, så send os en pull request eller i det mindste en issue på GitHub, så vi kan forfine de nødvendige kommandoer. Men den grundlæggende funktionalitet fra PgBouncer konsollen er allerede til stede.
Og selvfølgelig har vi fejl-videreføring. Vi vil returnere den fejl, som databasen rapporterede. Du vil få information om, hvorfor du ikke kan få adgang til databasen, og ikke bare, at du ikke kan.
Denne mulighed kan deaktiveres, hvis du har brug for 100%-kompatibilitet med PgBouncer. Vi kan opføre os som Bouncer, bare for en sikkerheds skyld.
Udvikling
Lidt om kildekoden til Odyssey.
For eksempel er der kommandoer som «Pause / Resume». De bruges normalt til at opdatere databasen. Hvis du har brug for at opdatere Postgres, kan du sætte det på pause i connection pooler, udføre pg_upgrade, og derefter genoptage. Og for klienten vil det se ud som om, databasen bare har været langsom. Denne funktionalitet blev bragt til os af folk fra fællesskabet. Den er endnu ikke merged, men det kommer snart. (Allerede merged)
— allerede merged
Desuden er en af de nye funktioner i PgBouncer understøttelsen af SCRAM-godkendelse, som også blev bragt til os af en person, der ikke arbejder i Yandex.Cloud. Begge dele er kompleks funktionalitet og vigtige.
Derfor vil jeg gerne fortælle om, hvad Odyssey er lavet af, hvis du også ønsker at skrive noget kode.
Du har en grundlæggende Odyssey-database, som bygger på to hovedbiblioteker. Kiwi-biblioteket er en implementering af Postgres' meddelelsesprotokol. Det vil sige, at den native proto 3 i Postgres er de standardmeddelelser, som frontends og backends kan udveksle. De er implementeret i Kiwi-biblioteket.
Machinarium-biblioteket er et bibliotek til implementering af streams. Et lille fragment af dette Machinarium er skrevet i assembler. Men bekymr dig ikke, der er kun 15 linjer.
Odyssey-arkitektur. Der er en hovedmaskine, hvor coroutines kører. I denne maskine håndteres accept af indgående TCP-forbindelser og fordeling til workers.
Inden i én worker kan der køre en behandler for flere klienter. Desuden kører konsollen og håndteringen af crone-opgaver til at fjerne forbindelser, der ikke længere er nødvendige i poolen, i hovedtråden.
Til testning af Odyssey bruges et standard sæt tests fra Postgres. Vi kører blot install-check via Bouncer og via Odyssey, og vi får en nul div. Der er flere tests, hvor formatering af datoer ikke bestået præcis ens i Bouncer og Odyssey.
Derudover er der mange drivere, som har deres test. Og deres tests bruger vi til at teste Odyssey.
Desuden på grund af vores kaskadekonfiguration er vi nødt til at teste forskellige kombinationer: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey for at være sikre på, at hvis Odyssey optræder i en af delene i kaskaden, vil det stadig fungere som forventet.
Rive
Vi bruger Odyssey i produktionen. Og det ville være uretfærdigt at sige, at alt bare fungerer. Nej, altså ja, men ikke altid. For eksempel fungerede alt bare i produktionen, så kom vores venner fra PostgreSQL Professional og sagde, at vi har et hukommelseslækkage. De havde ret, og vi fik det rettet. Men det var bare.
Senere opdagede vi, at der er indgående TLS-forbindelser og udgående TLS-forbindelser i connection pooleren. Og der kræves klientcertifikater og servercertifikater i forbindelserne.
Servercertifikaterne Bouncer og Odyssey genlæser deres pcache, men klientcertifikaterne skal ikke genlæses fra pcache, fordi vores skalerbare Odyssey til sidst støder på systemets læseevne for dette certifikat. Det kom som en overraskelse for os, fordi det ikke satte sig fast med det samme. Først skalerede det lineært, og efter 20.000 samtidige indgående forbindelser blev dette problem synligt.
Pluggable Authentication Method er muligheden for at autentificere sig med de indbyggede Linux-midler. I PgBouncer er det implementeret sådan, at der er en separat tråd, der venter på svar fra PAM, og der er hovedtråden PgBouncer, som betjener den aktuelle forbindelse og kan bede dem om at vente i PAM-tråden.
Vi besluttede ikke at implementere dette af en simpel grund. Vi har jo mange tråde. Hvorfor skal vi have dette?
I sidste ende kan det skabe problemer, hvis du har PAM-autentificering og ikke-PAM-autentificering, så kan en stor bølge af PAM-autentificering betydeligt forsinke ikke-PAM-autentificering. Det er en af de ting, vi ikke har rettet. Men hvis du ønsker at rette dette, kan du tage fat på det.
En anden faldgrube var, at vi har én tråd, der accepterer alle indgående forbindelser. Og derefter overfører dem til worker pool, hvor TLS handshake vil finde sted.
I sidste ende, hvis du har en sammenhængende bølge af 20.000 netværksforbindelser, vil de alle blive accepteret. Og på klientsiden vil libpq begynde at tælle ned til tidsafbrud. Som standard ser det ud til, at der er 3 sekunder.
Hvis de alle ikke kan få adgang til databasen samtidigt, kan de ikke få adgang til databasen, fordi alt dette kan dækkes af ikke-eksponentiel retry.
Vi kom frem til, at vi her kopierede skemaet fra PgBouncer med det, at vi har throttling af antallet af TCP-forbindelser, som vi accepterer.
Hvis vi ser, at vi accepterer forbindelser, men de ikke når at fuldføre handshake, sætter vi dem i kø, så de ikke bruger CPU-ressourcer. Det betyder, at samtidig handshake muligvis ikke kan udføres for alle forbindelser, der kom. Men i det mindste kommer nogen ind i databasen, selvom belastningen er ret høj.
Roadmap
Hvad vil vi gerne se i fremtiden i Odyssey? Hvad er vi klar til selv at udvikle, og hvad forventer vi fra fællesskabet?
I august 2019.
Sådan så roadmappen for Odyssey ud i august:
- Vi ønskede SCRAM og PAM autentificering.
- Vi ønskede at forwarde læseanmodninger til standby.
- Vi ville gerne have online-genstart.
- Og muligheden for at sætte serveren på pause.
Halvdelen af denne roadmap er udført, og det er ikke os. Og det er godt. Så lad os diskutere, hvad der er tilbage, og tilføje mere.
? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.
I princippet, i Postgres, siden version 10, er der mulighed for at angive session_attrs ved oprettelse af forbindelse. Du kan liste alle databaserne i forbindelsen og angive, hvorfor du går til databasen: for at skrive eller kun læse. Og driveren vælger selv den første host på listen, som opfylder session_attrs.
Men problemet med denne tilgang er, at den ikke kontrollerer replicationslag. Du kan have en replika, der er forsinket i en uacceptabel tid for din service. For at kunne udføre læseanmodninger fuldt ud på replikken, skal vi reelt understøtte muligheden for i Odyssey ikke at arbejde, når det ikke kan læses.
Odyssey skal af og til kontakte databasen og spørge om replikationsafstanden fra primary. Og hvis det når en grænseværdi, skal nye forespørgsler blokeres, fortælle klienten, at de skal geninitiativere forbindelserne og muligvis vælge en anden host til at udføre anmodningerne. Dette vil gøre det muligt for databasen hurtigt at genoprette replicationslaget og igen være i stand til at svare på anmodninger.
Det er svært at angive en tidsramme for implementeringen, fordi det er open source. Men jeg håber, det ikke tager 2,5 år som hos kollegerne fra PgBouncer. Denne funktion ville jeg gerne se i Odyssey.
. Du kan nu oprette prepared statements på to måder. For det første kan du udføre SQL-kommandoen, nemlig "prepared". For at forstå denne SQL-kommando, skal vi lære at forstå SQL fra Bouncer-siden. Det ville være overkill, fordi vi har brug for en fuld parser. Vi kan ikke parse hver SQL-kommando.
Men der er prepared statements på niveauet for meddelelsesprotokol på proto3. Og det er her, informationen om, at der oprettes et prepared statement, kommer i struktureret form. Vi kunne støtte forståelsen af, at en klient har bedt om at oprette prepared statements på en eller anden serverforbindelse. Og selvom transaktionen er afsluttet, skal vi stadig opretholde sammenhængen mellem serveren og klienten.
Men her opstår der et misforhold i dialogen, fordi nogen siger, at det er nødvendigt at forstå, hvilken præcist prepared statement klienten har oprettet, og at dele serverforbindelsen mellem alle klienter, der har oprettet denne serverforbindelse, dvs. hvilke der har oprettet et sådant prepared statement.
Andres Freund sagde, at hvis en klient kommer til dig, som allerede har oprettet et sådant prepared statement i en anden serverforbindelse, så opret det for ham. Men det virker lidt forkert at udføre forespørgsler i databasen i stedet for klienten, men set fra en udviklers perspektiv, der skriver protokollen for interaktion med databasen, ville det være praktisk, hvis han bare fik en netværksforbindelse, hvor der var en sådan forberedt forespørgsel.
Og endnu en funktion, som vi skal implementere. Vi har nu overvågning, der er kompatibel med PgBouncer. Vi kan returnere den gennemsnitlige udførelsestid for forespørgslen. Men den gennemsnitlige tid er som gennemsnitstemperaturen på hospitalet: nogen er kolde, nogen er varme – i gennemsnit er alle raske. Det er ikke sandt.
Vi skal implementere støtte til percentiler, som ville angive, at der er langsomme forespørgsler, der forbruger ressourcer, og gøre overvågningen mere acceptabel.
Det vigtigste er, at vi ønsker version 1.0 (Version 1.1 er allerede udgivet). Faktisk er Odyssey i øjeblikket i version 1.0rc, dvs. release candidate. Og alle de problemer, jeg har nævnt, blev løst med netop den version, bortset fra memory leak.
Hvad betyder version 1.0 for os? Vi ruller Odyssey ud på vores databaser. Det fungerer allerede nu på vores systemer, men når det når 1.000.000 forespørgsler i sekundet, kan vi sige, at det er en release-version, og det er den version, der kan kaldes 1.0.
I fællesskabet har flere bedt om, at version 1.0 også inkluderer pause og SCRAM. Men det vil betyde, at vi skal rulle den næste version ud i produktion, fordi hverken SCRAM eller pause er blevet merged endnu. Men det er sandsynligvis et spørgsmål, der vil blive løst hurtigt.
Jeg venter på dine pull requests. Og jeg vil også gerne høre, hvilke problemer du har med Bouncer. Lad os diskutere dem. Måske kan vi implementere nogle funktioner, som du har brug for.
Nu er min del slut, jeg vil gerne høre fra dig. Tak!
Spørgsmål
Hvis jeg angiver application_name, vil det korrekt blive videregivet, også i transaction pooling i Odyssey?
I Odyssey eller i Bouncer?
I Odyssey. I Bouncer bliver det videregivet.
Vi vil lave et sæt.
Og hvis min faktiske forbindelse hopper mellem andre forbindelser, vil den så blive videregivet?
Vi vil lave et sæt af alle parametre, der er angivet i listen. Jeg kan ikke sige, om application_name er i denne liste. Jeg mener, jeg har set det der. Vi vil stille alle de samme parametre op. Med én forespørgsel vil sættet gøre alt det, der var indstillet af klienten ved opstart.
Tak, Andrey, for præsentationen! God præsentation! Jeg er glad for, at Odyssey udvikler sig hurtigere for hver minut. Jeg ønsker, at det fortsætter sådan. Vi har allerede kontaktet jer med en forespørgsel om at have multi data-source forbindelse, så Odyssey kan tilsluttes samtidig til forskellige databaser, dvs. master-slave, og derefter automatisk skifte til den nye master efter failover.
Ja, jeg mener, jeg husker denne diskussion. Der er nu flere lagre. Men der er ikke nogen skift imellem dem. Vi skal på vores side spørge serveren, om den stadig er aktiv og forstå, at der er sket en failover, hvem der vil kalde pg_recovery. Jeg har en standardmetode til at forstå, at vi ikke er kommet til masteren. Og skal vi forstå noget fra fejlene, eller hvordan? Dvs. ideen er interessant, den diskuteres. Skriv flere kommentarer. Hvis du har aktive hænder, der kender C, ville det være fantastisk.
Spørgsmålet om skalering via replikaer interesserer os også, fordi vi ønsker at gøre adoptionen af replikerede klynger så enkel som muligt for applikationsudviklerne. Men her ville jeg gerne have mere kommentarer, altså hvordan det præcist gøres, og hvordan man gør det godt.
Spørgsmålet handler også om replikaer. Det viser sig, at I har en master og flere replikaer. Og det er klart, at der forbindes sjældnere til en replika end til masteren, fordi der kan være forskelle. I har sagt, at forskellene i data kan være sådan, at det ikke vil opfylde jeres forretning, og I vil ikke tage til den, før den er blevet replikeret. Hvis I har været lidt længe væk, og så begyndt at forbinde igen, så vil de data, I har brug for, ikke være tilgængelige med det samme. Det vil sige, at hvis vi konstant forbinder til masteren, så er cachen der varm, mens cachen i replikaen er lidt bagud.
Ja, det er rigtigt. I pcache vil der ikke være de data, som I ønsker, i real cache vil der ikke være information om de tabeller, som I ønsker, i planerne vil der ikke være parsede forespørgsler, overhovedet ingenting vil være der.
Og når I har en eller anden klynge, og I tilføjer en ny replika til den, så mens den starter op, er den i en dårlig tilstand, altså den opbygger sin cache.
Jeg forstod ideen. Den rigtige tilgang ville være at køre en lille procentdel af forespørgslerne først til replikaen for at varme cachen op. Groft sagt, vi har en betingelse om, at vi ikke må være mere end 10 sekunder bagud i forhold til masteren. Og denne betingelse skal ikke aktiveres i én bølge, men gradvist for nogle kunder.
Ja, øge vægten.
Det er en god idé. Men først skal vi implementere denne frakobling. Først skal vi koble fra, og så tænker vi over, hvordan vi kobler til igen. Det er en fremragende funktion, at vi kan koble til gradvist.
I nginx er der en sådan mulighed slowly start i klyngen til serveren. Og den øger gradvist belastningen.
Ja, fantastisk idé, vi prøver, når vi når dertil.
Kilde: habr.com
