I sin rapport vil Andrey Borodin fortælle dig, hvordan de tog højde for oplevelsen af at skalere PgBouncer, da de designede forbindelsespooleren , da de rullede det ud i produktion. Derudover vil vi diskutere, hvilke funktioner af aftrækkeren vi gerne vil se i nye versioner: det er vigtigt for os ikke kun at opfylde vores behov, men at udvikle brugerfællesskabet .
Video:
Hej alle! Mit navn er Andrew.
Hos Yandex udvikler jeg open source-databaser. Og i dag har vi et emne om forbindelsespooler-forbindelser.
Hvis du ved, hvordan man ringer til forbindelsespooler på russisk, så fortæl mig det. Jeg vil rigtig gerne finde et godt fagudtryk, som bør etableres i faglitteraturen.
Emnet er ret kompliceret, for i mange databaser er forbindelsespooleren indbygget, og du behøver ikke engang at vide om det. Selvfølgelig er der nogle indstillinger overalt, men i Postgres fungerer det ikke sådan. Og sideløbende (ved HighLoad++ 2019) er der en rapport af Nikolai Samokhvalov om opsætning af forespørgsler i Postgres. Og som jeg forstår det, kom folk her, som allerede havde konfigureret deres forespørgsler perfekt, og det er folk, der står over for mere sjældne systemproblemer relateret til netværket og ressourceudnyttelsen. Og nogle steder kunne det være ret svært i den forstand, at problemerne ikke er åbenlyse.
Yandex har Postgres. Mange Yandex-tjenester bor i Yandex.Cloud. Og vi har adskillige petabyte data, der genererer mindst en million anmodninger i sekundet i Postgres.
Og vi leverer en ret standard klynge til alle tjenester - dette er nodens primære hovedknude, de sædvanlige to replikaer (synkrone og asynkrone), backup, skalering af læseanmodninger på replikaen.
Hver cluster node er Postgres, hvorpå der udover Postgres og overvågningssystemer også er installeret en forbindelsespooler. Connection pooler bruges til hegn og til dets hovedformål.
Hvad er hovedformålet med forbindelsespooler?
Postgres anvender en procesmodel, når man arbejder med en database. Det betyder, at én forbindelse er én proces, én Postgres-backend. Og i denne backend er der en masse forskellige caches, som er ret dyre at lave forskellige til forskellige forbindelser.
Derudover har Postgres-koden et array kaldet procArray. Den indeholder grundlæggende data om netværksforbindelser. Og næsten alle procArray-behandlingsalgoritmer har lineær kompleksitet; de kører over hele rækken af netværksforbindelser. Det er en ret hurtig cyklus, men med flere indgående netværksforbindelser bliver tingene lidt dyrere. Og når tingene bliver lidt dyrere, kan du ende med at betale en meget høj pris for en masse netværksforbindelser.
Der er 3 mulige tilgange:
- På ansøgningssiden.
- På databasesiden.
- Og imellem, altså alle mulige kombinationer.
Desværre er den indbyggede pooler i øjeblikket under udvikling. Vores venner hos PostgreSQL Professional gør dette for det meste. Hvornår det dukker op, er svært at forudsige. Og faktisk har vi to løsninger, som arkitekten kan vælge imellem. Disse er pool på applikationssiden og proxy pool.
Pool på applikationssiden er den nemmeste måde. Og næsten alle klientdrivere giver dig en måde: præsentere millioner af dine forbindelser i kode som flere dusin forbindelser til databasen.
Problemet, der opstår, er, at du på et bestemt tidspunkt ønsker at skalere backend, vil du implementere den til mange virtuelle maskiner.
Så indser du, at du har flere tilgængelighedszoner, flere datacentre. Og pooling-tilgangen på klientsiden fører til større antal. Store er omkring 10 forbindelser. Dette er den kant, der kan fungere normalt.
Hvis vi taler om proxy-poolere, så er der to poolere, der kan mange ting. De er ikke kun poolere. De er poolere + mere cool funktionalitet. Det her и .
Men desværre er det ikke alle, der har brug for denne ekstra funktionalitet. Og det fører til, at poolere kun understøtter sessionspooling, dvs. én indgående klient, én udgående klient til databasen.
Dette er ikke særlig velegnet til vores formål, så vi bruger PgBouncer, som implementerer transaktionspooling, dvs. serverforbindelser matches kun til klientforbindelser i hele transaktionens varighed.
Og i vores arbejdsbyrde er dette sandt. Men der er et par problemer.
Problemerne starter, når du vil diagnosticere en session, fordi alle dine indgående forbindelser er lokale. Alle kom med et loopback og på en eller anden måde bliver det svært at spore sessionen.
Selvfølgelig kan du bruge application_name_add_host. Dette er en måde på Bouncer-siden at tilføje en IP-adresse til application_name. Men application_name er sat af en ekstra forbindelse.
På denne graf, hvor den gule linje er reelle anmodninger, og hvor den blå linje er anmodninger, der flyver ind i databasen. Og denne forskel er netop installationen af application_name, som kun er nødvendig for at spore, men det er slet ikke gratis.
Derudover kan du i Bouncer ikke begrænse én pulje, dvs. antallet af databaseforbindelser pr. specifik bruger, pr. specifik database.
Hvad fører dette til? Du har en indlæst tjeneste skrevet i C++ og et sted i nærheden en lille tjeneste på en node, der ikke gør noget forfærdeligt med databasen, men dens driver går amok. Det åbner 20 forbindelser, og alt andet vil vente. Selv din kode er normal.
Vi skrev selvfølgelig en lille patch til Bouncer, der tilføjede denne indstilling, dvs. begrænsede klienter til poolen.
Det ville være muligt at gøre dette på Postgres-siden, dvs. begrænse rollerne i databasen med antallet af forbindelser.
Men så mister du evnen til at forstå, hvorfor du ikke har nogen forbindelser til serveren. PgBouncer kaster ikke en forbindelsesfejl, den returnerer altid den samme information. Og du kan ikke forstå: måske er din adgangskode ændret, måske er databasen bare gået tabt, måske er der noget galt. Men der er ingen diagnose. Hvis en session ikke kan etableres, ved du ikke, hvorfor den ikke kan etableres.
På et vist tidspunkt ser du på applikationsgraferne og ser, at applikationen ikke virker.
Kig på toppen og se, at Bouncer er single-threaded. Dette er et vendepunkt i tjenestens liv. Du indser, at du forberedte dig på at skalere databasen om halvandet år, og du er nødt til at skalere pooleren.
Vi er kommet til den konklusion, at vi har brug for flere PgBouncere.
Bouncer er blevet lappet lidt.
Og de gjorde det, så flere Bouncers kunne rejses ved at genbruge TCP-porten. Og operativsystemet overfører automatisk indgående TCP-forbindelser mellem dem ved hjælp af round-robin.
Dette er gennemsigtigt for klienter, hvilket betyder, at det ser ud til, at du har én Bouncer, men du har fragmentering af ledige forbindelser mellem kørende Bouncers.
Og på et bestemt tidspunkt vil du måske bemærke, at disse 3 Bouncers hver æder deres kerne med 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 og uden TLS, vil du opdage, at antallet af etablerede forbindelser falder med næsten to størrelsesordener med kryptering aktiveret, fordi TLS-håndtrykket bruger CPU-ressourcer.
Og øverst kan du se en del kryptografiske funktioner, der udføres, når der er en bølge af indgående forbindelser. Da vores primære kan skifte mellem tilgængelighedszoner, er en bølge af indgående forbindelser en ret typisk situation. Det vil sige, af en eller anden grund var den gamle primære utilgængelig, hele belastningen blev sendt til et andet datacenter. De kommer alle sammen for at sige hej til TLS på samme tid.
Og et stort antal TLS-håndtryk siger måske ikke længere hej til Bouncer, men vil klemme ham i halsen. På grund af timeout kan bølgen af indgående forbindelser blive udæmpede. Hvis du prøver igen til basen uden eksponentiel backoff, vil de ikke komme igen og igen i en sammenhængende bølge.
Her er et eksempel på 16 PgBouncers, der indlæser 16 kerner med 100 %.
Vi kom til kaskaden PgBouncer. Dette er den bedste konfiguration, der kan opnås på vores belastning med Bouncer. Vores eksterne Bouncers bruges til TCP-håndtryk, og interne Bouncers bruges til ægte pooling, for ikke at fragmentere eksterne forbindelser for meget.
I denne konfiguration er en jævn genstart mulig. Du kan genstarte alle disse 18 Bouncers én efter én. Men det er ret svært at opretholde en sådan konfiguration. Sysadmins, DevOps og folk, der faktisk er ansvarlige for denne server, vil ikke være særlig tilfredse med dette arrangement.
Det ser ud til, at alle vores forbedringer kan fremmes til open source, men Bouncer er ikke særlig godt understøttet. For eksempel blev muligheden for at køre flere PgBouncers på én port begået for en måned siden. Der var en pull-anmodning med denne funktion for flere år siden.
Eller et eksempel mere. I Postgres kan du annullere en igangværende anmodning ved at sende hemmeligheden til en anden forbindelse uden unødvendig godkendelse. Men nogle klienter sender simpelthen en TCP-nulstilling, dvs. de bryder netværksforbindelsen. Hvad vil Bouncer gøre? Han vil ikke gøre noget. Den vil fortsætte med at udføre anmodningen. Hvis du har modtaget et stort antal forbindelser, der har oprettet en database med små anmodninger, vil det ikke være nok blot at afbryde forbindelsen fra Bouncer; du skal også fuldføre de anmodninger, der kører i databasen.
Dette er blevet rettet, og dette problem er endnu ikke blevet flettet ind i Bouncer's upstream.
Og så kom vi frem til, at vi har brug for vores egen forbindelsespooler, som skal udvikles, lappes, hvori problemer hurtigt kan rettes, og som selvfølgelig skal multitrådes.
Vi sætter multithreading som hovedopgave. Vi skal være i stand til at håndtere bølgen af indkommende TLS-forbindelser godt.
For at gøre dette var vi nødt til at udvikle et separat bibliotek kaldet Machinarium, som er designet til at beskrive maskintilstandene for en netværksforbindelse som sekventiel kode. Hvis du ser på libpq-kildekoden, vil du se nogle ret komplekse opkald, der kan returnere dig et resultat og sige: "Ring til mig senere. Lige nu har jeg IO for nu, men når IO'en forsvinder, vil jeg have en belastning på processoren." Og dette er en ordning på flere niveauer. Netværkskommunikation beskrives normalt af en statsmaskine. Masser af regler som "Hvis jeg tidligere har modtaget en pakkeoverskrift på størrelse N, venter jeg nu på N bytes," "Hvis jeg sendte en SYNC-pakke, venter jeg nu på en pakke med resultatmetadata." Resultatet er en ret vanskelig, kontraintuitiv kode, som om labyrinten blev konverteret til linjescanning. Vi gjorde det sådan, at programmøren i stedet for en tilstandsmaskine beskriver interaktionens hovedvej i form af almindelig imperativ kode. Det er bare, at du i denne imperative kode skal indsætte steder, hvor eksekveringssekvensen skal afbrydes ved at vente på data fra netværket, videregive eksekveringskonteksten til en anden coroutine (grøn tråd). Denne tilgang ligner det faktum, at vi nedskriver den mest forventede sti i labyrinten i en række og derefter tilføjer grene til den.
Som et resultat har vi en tråd, som TCP accepterer, og round-robin videregiver TPC-forbindelsen til mange arbejdere.
I dette tilfælde kører hver klientforbindelse altid på én processor. Og dette giver dig mulighed for at gøre det cache-venligt.
Og derudover har vi forbedret indsamlingen af små pakker lidt til én stor pakke for at aflaste systemets TCP-stakken.
Derudover har vi forbedret transaktionspooling i den forstand, at Odyssey, når den er konfigureret, kan sende CANCEL og ROLLBACK i tilfælde af en netværksforbindelsesfejl, dvs. hvis ingen venter på en anmodning, vil Odyssey bede databasen om ikke at forsøge at opfylde anmodningen, der kan spilde dyrebare ressourcer.
Og når det er muligt, bevarer vi forbindelser til den samme klient. Dette undgår at skulle geninstallere application_name_add_host. Hvis dette er muligt, behøver vi ikke yderligere at nulstille de parametre, der er nødvendige for diagnostik.
Vi arbejder i Yandex.Clouds interesse. Og hvis du bruger administreret PostgreSQL og har en forbindelsespooler installeret, kan du oprette logisk replikering udad, dvs. lade os, hvis du vil, bruge logisk replikering. Bouncer vil ikke frigive det logiske replikationsflow udenfor.
Dette er et eksempel på opsætning af logisk replikering.
Derudover har vi støtte til fysisk replikation udadtil. I Skyen er det selvfølgelig umuligt, for så vil klyngen give dig for meget information om sig selv. Men i dine installationer, hvis du har brug for fysisk replikering gennem forbindelsespooleren i Odyssey, er dette muligt.
Odyssey har fuldt kompatibel overvågning med PgBouncer. Vi har den samme konsol, der kører næsten alle de samme kommandoer. Hvis noget mangler, send en pull-anmodning eller i det mindste et problem på GitHub, og vi vil fuldføre de nødvendige kommandoer. Men vi har allerede PgBouncer-konsollens hovedfunktionalitet.
Og selvfølgelig har vi fejlvideresendelse. Vi returnerer fejlen rapporteret af databasen. Du får information om, hvorfor du ikke er med i databasen, og ikke blot at du ikke er med i den.
Denne funktion er deaktiveret, hvis du har brug for 100 % kompatibilitet med PgBouncer. Vi kan opføre os på samme måde som Bouncer, bare for at være på den sikre side.
design
Et par ord om Odyssey-kildekoden.
For eksempel er der "Pause / Genoptag"-kommandoer. De bruges normalt til at opdatere databasen. Hvis du har brug for at opdatere Postgres, så kan du sætte det på pause i forbindelsespooleren, lave pg_upgrade og derefter genoptage. Og fra klientens side vil det se ud, som om databasen simpelthen blev langsommere. Denne funktionalitet blev bragt til os af folk fra samfundet. Hun er ikke frosset endnu, men snart vil alt være. (Allerede frosset)
- allerede frosset
Derudover er en af de nye funktioner i PgBouncer understøttelse af SCRAM Authentication, som også blev bragt til os af en person, der ikke arbejder i Yandex.Cloud. Begge er komplekse funktionaliteter og vigtige.
Derfor vil jeg gerne fortælle dig, hvad Odyssey er lavet af, hvis du nu også vil skrive lidt kode.
Du har Odyssey-kildebasen, som er afhængig af to hovedbiblioteker. Kiwi-biblioteket er en implementering af Postgres-meddelelsesprotokollen. Det vil sige, at native proto 3 af Postgres er standardbeskeder, som front-ends og back-ends kan udveksle. De er implementeret i Kiwi-biblioteket.
Machinarium-biblioteket er et trådimplementeringsbibliotek. Et lille fragment af dette Machinarium er skrevet på samlesprog. Men vær ikke forskrækket, der er kun 15 linjer.
Odyssey arkitektur. Der er en hovedmaskine, hvorpå der kører coroutiner. Denne maskine implementerer at acceptere indgående TCP-forbindelser og distribuere dem blandt arbejdere.
En handler for flere klienter kan arbejde inden for en medarbejder. Hovedtråden kører også konsollen og behandlingen af crone-opgaver for at slette forbindelser, der ikke længere er nødvendige i puljen.
Odyssey er testet ved hjælp af standard Postgres test suite. Vi kører bare install-check gennem Bouncer og gennem Odyssey får vi en null div. Der er adskillige tests relateret til datoformatering, som ikke består nøjagtigt det samme i Bouncer og i Odyssey.
Derudover er der mange chauffører, der har deres egen test. Og vi bruger deres tests til at teste Odyssey.
Derudover er vi på grund af vores kaskadekonfiguration nødt til at teste forskellige bundter: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey for at være sikre på, at hvis Odyssey endte i nogen af delene i kaskaden, virker det også stadig som vi forventer.
Rive
Vi bruger Odyssey i produktionen. Og det ville ikke være fair, hvis jeg sagde, at alt bare fungerer. Nej, altså, ja, men ikke altid. For eksempel i produktionen virkede alt bare, så kom vores venner fra PostgreSQL Professional og sagde, at vi havde en hukommelseslækage. Det var de virkelig, vi rettede dem. Men det var simpelt.
Så opdagede vi, at forbindelsespooleren har indgående TLS-forbindelser og udgående TLS-forbindelser. Og forbindelser kræver klientcertifikater og servercertifikater.
Bouncer- og Odyssey-servercertifikater genlæses af deres pcache, men klientcertifikater skal ikke genlæses fra pcache, fordi vores skalerbare Odyssey i sidste ende løber ind i systemets ydeevne ved at læse dette certifikat. Dette kom som en overraskelse for os, for det tog ham ikke lang tid at modstå. Først skaleres det lineært, men efter 20 indkommende samtidige forbindelser viste dette problem sig.
Pluggable Authentication Method er evnen til at godkende ved hjælp af indbyggede Lunux-værktøjer. I PgBouncer er det implementeret på en sådan måde, at der er en separat tråd til at vente på svar fra PAM, og der er en hoved-PgBouncer-tråd, der servicerer den aktuelle forbindelse og kan bede dem om at leve i PAM-tråden.
Vi implementerede dette ikke af en simpel grund. Vi har mange tråde. Hvorfor har vi brug for dette?
Dette kan i sidste ende skabe problemer ved, at hvis du har PAM-godkendelse og ikke-PAM-godkendelse, så kan en stor bølge af PAM-godkendelse betydeligt forsinke ikke-PAM-godkendelsen. Dette er en af de ting, vi ikke har rettet. Men hvis du vil rette det, kan du gøre dette.
En anden rake var, at vi har én tråd, der accepterer alle indgående forbindelser. Og så bliver de overført til arbejderpuljen, hvor TLS-håndtrykket vil finde sted.
Bundlinjen, hvis du har en sammenhængende bølge af 20 netværksforbindelser, vil de alle blive accepteret. Og på klientsiden vil libpq begynde at rapportere timeouts. Som standard ser det ud til at være 000 sekunder.
Hvis de ikke alle kan komme ind i databasen på samme tid, så kan de ikke komme ind i databasen, fordi alt dette kan dækkes af et ikke-eksponentielt genforsøg.
Vi kom til den konklusion, at vi kopierede skemaet fra PgBouncer her med det faktum, at vi har droslet antallet af TCP-forbindelser, som vi accepterer.
Hvis vi ser, at vi accepterer forbindelser, men de i sidste ende ikke har tid til at give hånd, sætter vi dem i en kø, så de ikke spilder CPU-ressourcer. Dette fører til, at et samtidigt håndtryk muligvis ikke udføres for alle forbindelser, der er ankommet. Men i det mindste vil nogen komme ind i databasen, selvom belastningen er ret tung.
køreplan
Hvad kunne du tænke dig at se i fremtiden i Odyssey? Hvad er vi klar til selv at udvikle, og hvad forventer vi af fællesskabet?
Fra august 2019.
Sådan så Odyssey-køreplanen ud i august:
- Vi ønskede SCRAM- og PAM-godkendelse.
- Vi ønskede at videresende læseanmodninger til standby.
- Jeg vil gerne have en online genstart.
- Og muligheden for at holde pause på serveren.
Halvdelen af denne køreplan er gennemført, og ikke af os. Og det her er godt. Så lad os diskutere, hvad der er tilbage og tilføje mere.
? Vi har replikaer, der simpelthen opvarmer luften uden at udføre anmodninger. Vi har brug for dem til at levere failover og switchover. I tilfælde af problemer i et af datacentrene, vil jeg gerne beskæftige dem med noget nyttigt arbejde. Fordi vi ikke kan konfigurere de samme centrale processorer, den samme hukommelse forskelligt, fordi ellers vil replikering ikke fungere.
I princippet er det i Postgres, startende fra 10, muligt at angive session_attrs ved tilslutning. Du kan liste alle databaseværterne i forbindelsen og sige, hvorfor du går til databasen: skrive eller skrivebeskyttet. Og chaufføren vil selv vælge den første vært på listen, som han bedst kan lide, som opfylder kravene til session_attrs.
Men problemet med denne tilgang er, at den ikke kontrollerer replikationsforsinkelsen. Du har muligvis en replika, der har haltet bagud i en uacceptabel lang tid for din tjeneste. For at muliggøre fuldfunktionsudførelse af læseforespørgsler på en replika, skal vi grundlæggende understøtte Odysseys evne til ikke at køre, når den ikke kan læses.
Odyssey skal fra tid til anden gå til databasen og bede om replikeringsafstanden fra den primære. Og hvis den har nået grænseværdien, tillad ikke nye anmodninger ind i databasen, fortæl klienten, at den skal genstarte forbindelser og eventuelt vælge en anden vært til at udføre anmodninger. Dette vil give databasen mulighed for hurtigt at gendanne replikeringsforsinkelsen og vende tilbage igen for at svare med en anmodning.
Det er svært at give en tidsramme for implementering, fordi det er open source. Men, jeg håber, ikke 2,5 år som mine kolleger fra PgBouncer. Det er den funktion, jeg gerne vil se i Odysseen.
. Nu kan du oprette en forberedt erklæring på to måder. Først kan du udføre SQL-kommandoen, nemlig "forberedt". For at forstå denne SQL-kommando skal vi lære at forstå SQL'en på Bouncer-siden. Dette ville være et overkill, fordi det er overkill, da vi har brug for hele parseren. Vi kan ikke parse hver SQL-kommando.
Men der er en forberedt erklæring på meddelelsesprotokolniveau på proto3. Og det er her, hvor informationen om, at en udarbejdet erklæring bliver oprettet, kommer i en struktureret form. Og vi kunne støtte forståelsen af, at klienten på en eller anden serverforbindelse bad om at lave forberedte erklæringer. Og selvom transaktionen er afsluttet, skal vi stadig bevare forbindelsen mellem serveren og klienten.
Men her opstår der en uoverensstemmelse i dialogen, fordi nogen siger, at du skal forstå, hvilken slags forberedte erklæringer klienten har oprettet og dele serverforbindelsen mellem alle klienter, der har oprettet denne serverforbindelse, altså hvem der har lavet sådan en forberedt erklæring.
Andres Freund sagde, at hvis en klient kommer til dig, som allerede har oprettet en sådan forberedt erklæring i en anden serverforbindelse, så opret den for ham. Men det virker lidt forkert at udføre forespørgsler i databasen i stedet for klienten, men fra udviklerens synspunkt, der skriver protokollen til interaktion med databasen, ville det være praktisk, hvis han blot fik en netværksforbindelse, hvor der er sådan en 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ørgsler. Men den gennemsnitlige tid er gennemsnitstemperaturen på hospitalet: nogle er kolde, nogle er varme - i gennemsnit er alle raske. Det er ikke sandt.
Vi er nødt til at implementere understøttelse af percentiler, der indikerer, at der er langsomme forespørgsler, der spilder ressourcer og gør overvågning mere acceptabel.
Det vigtigste er, at jeg vil have version 1.0 (Version 1.1 er allerede udgivet). Faktum er, at Odyssey nu er i version 1.0rc, altså udgivelseskandidat. Og alle de problemer, jeg nævnte, blev løst med nøjagtig den samme version, bortset fra hukommelseslækagen.
Hvad vil version 1.0 betyde for os? Vi ruller Odyssey ud til vores baser. Det kører allerede på vores databaser, men når det når punktet på 1 anmodninger i sekundet, så kan vi sige, at dette er udgivelsesversionen, og det er en version, der kan kaldes 000.
Flere personer i samfundet har bedt om, at version 1.0 inkluderer pause og SCRAM. Men det vil betyde, at vi bliver nødt til at rulle den næste version ud til produktion, for hverken SCRAM eller pause er endnu blevet dræbt. Men højst sandsynligt vil dette problem blive løst ret hurtigt.
Jeg venter på din pull-anmodning. 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.
Dette er slutningen på min del, jeg vil gerne lytte til dig. Tak skal du have!
R'RѕRїSЂRѕSЃS <
Hvis jeg indstiller mit eget application_name, vil det så blive videresendt korrekt, inklusive i transaktionspooling i Odyssey?
Odyssey eller Bouncer?
I Odyssey. I Bouncer bliver det kastet.
Vi laver et sæt.
Og hvis min rigtige forbindelse hopper på andre forbindelser, vil den så blive transmitteret?
Vi vil lave et sæt af alle parametre, der er opført på listen. Jeg kan ikke se, om application_name er på denne liste. Jeg tror, jeg så ham der. Vi vil indstille alle de samme parametre. Med én anmodning vil sættet gøre alt, hvad der blev installeret af klienten under opstarten.
Tak, Andrey, for rapporten! God rapport! Jeg er glad for, at Odyssey udvikler sig hurtigere og hurtigere for hvert minut. Sådan vil jeg fortsætte. Vi har allerede bedt dig om at have en multidatakildeforbindelse, så Odyssey kan oprette forbindelse til forskellige databaser samtidigt, dvs. en masterslave, og derefter automatisk oprette forbindelse til en ny master efter failover.
Ja, jeg synes at huske denne diskussion. Nu er der flere depoter. Men der er ingen skift mellem dem. På vores side skal vi spørge serveren om, at den stadig er i live og forstå, at der er sket en failover, som vil kalde pg_recovery. Jeg har en standard måde at forstå, at vi ikke kom til mesteren. Og skal vi på en eller anden måde forstå fejlene eller hvad? Det vil sige, at ideen er interessant, den bliver diskuteret. Skriv flere kommentarer. Hvis du har arbejdere, der kender C, så er det fantastisk.
Spørgsmålet om skalering på tværs af replikaer er også af interesse for os, fordi vi ønsker at gøre brugen af replikerede klynger så enkel som muligt for applikationsudviklere. Men her vil jeg gerne have flere kommentarer, altså præcis hvordan man gør det, hvordan man gør det godt.
Spørgsmålet handler også om replikaer. Det viser sig, at du har en mester og flere replikaer. Og det er klart, at de går til replikaen sjældnere end til mesteren for forbindelser, fordi de kan have forskelle. Du sagde, at forskellen i dataene kan være sådan, at de ikke vil tilfredsstille din virksomhed, og du vil ikke tage dertil, før de er replikeret. På samme tid, hvis du ikke gik der i lang tid og derefter begyndte at gå, så vil de nødvendige data ikke være umiddelbart tilgængelige. Det vil sige, at hvis vi konstant går til masteren, bliver cachen der varmet op, men i replikaen halter cachen lidt.
Ja, det er sandt. PCache'en vil ikke have de datablokke, du ønsker, den rigtige cache vil ikke have information om de tabeller, du ønsker, planerne vil ikke have parsede forespørgsler, der vil ikke være noget overhovedet.
Og når du har en slags klynge, og du tilføjer en ny replika der, så mens den starter, er alt dårligt i den, dvs. den øger sin cache.
Jeg fik ideen. Den korrekte tilgang ville være at køre en lille procentdel af forespørgsler på replikaen først, hvilket ville varme cachen op. Groft sagt har vi en betingelse om, at vi højst må halte bagud mesteren med 10 sekunder. Og denne betingelse er ikke inkluderet i én bølge, men glat for nogle klienter.
Ja, øg vægten.
Det er en god idé. Men først skal vi implementere denne nedlukning. Først skal vi slukke, og så tænker vi på, hvordan vi tænder. Dette er en fantastisk funktion til at aktivere problemfrit.
Nginx har denne mulighed slowly start i en klynge til serveren. Og han øger gradvist belastningen.
Ja, god ide, vi prøver det, når vi når det.
Kilde: www.habr.com