I sin rapport kommer Andrey Borodin att berätta hur de tog hänsyn till upplevelsen av att skala PgBouncer när de designade anslutningspoolern , när de rullade ut den i produktion. Dessutom kommer vi att diskutera vilka funktioner av avdragaren vi skulle vilja se i nya versioner: det är viktigt för oss att inte bara möta våra behov, utan att utveckla användargemenskapen .
videor:
Hej alla! Jag heter Andrew.
På Yandex utvecklar jag databaser med öppen källkod. Och idag har vi ett ämne om anslutningspooleranslutningar.
Om du vet hur man ringer anslutningspooler på ryska, berätta för mig. Jag vill verkligen hitta en bra fackterm som bör etableras i facklitteraturen.
Ämnet är ganska komplicerat, för i många databaser är anslutningspoolern inbyggd och du behöver inte ens veta om det. Naturligtvis finns det vissa inställningar överallt, men i Postgres fungerar det inte så. Och parallellt (vid HighLoad++ 2019) finns en rapport av Nikolai Samokhvalov om att ställa in frågor i Postgres. Och som jag förstår det kom folk hit som redan hade konfigurerat sina frågor perfekt, och det här är människor som står inför mer sällsynta systemproblem relaterade till nätverket och resursutnyttjandet. Och på vissa ställen kan det vara ganska svårt i den meningen att problemen inte är uppenbara.
Yandex har Postgres. Många Yandex-tjänster finns i Yandex.Cloud. Och vi har flera petabyte data som genererar minst en miljon förfrågningar per sekund i Postgres.
Och vi tillhandahåller ett ganska standardkluster för alla tjänster - detta är nodens huvudnod, de vanliga två replikerna (synkrona och asynkrona), backup, skalning av läsbegäranden på repliken.
Varje klusternod är Postgres, på vilken förutom Postgres och övervakningssystem även en anslutningspooler är installerad. Connection pooler används för stängsel och för dess huvudsakliga syfte.
Vad är huvudsyftet med anslutningspooler?
Postgres använder en processmodell när man arbetar med en databas. Detta innebär att en anslutning är en process, en Postgres-backend. Och i denna backend finns det många olika cacher, som är ganska dyra att göra olika för olika anslutningar.
Dessutom har Postgres-koden en array som heter procArray. Den innehåller grundläggande data om nätverksanslutningar. Och nästan alla procArray-bearbetningsalgoritmer har linjär komplexitet, de körs över hela uppsättningen av nätverksanslutningar. Det är en ganska snabb cykel, men med fler inkommande nätverksanslutningar blir det lite dyrare. Och när saker och ting blir lite dyrare kan du sluta med att betala ett väldigt högt pris för många nätverksanslutningar.
Det finns 3 möjliga tillvägagångssätt:
- På applikationssidan.
- På databassidan.
- Och mellan, det vill säga alla möjliga kombinationer.
Tyvärr är den inbyggda poolern för närvarande under utveckling. Våra vänner på PostgreSQL Professional gör det mesta. När det dyker upp är svårt att förutse. Och faktiskt har vi två lösningar för arkitekten att välja mellan. Dessa är pool på applikationssidan och proxypool.
Pool på applikationssidan är det enklaste sättet. Och nästan alla klientdrivrutiner ger dig ett sätt: presentera miljontals av dina anslutningar i kod som flera dussin anslutningar till databasen.
Problemet som uppstår är att du vid en viss punkt vill skala backend, du vill distribuera den till många virtuella maskiner.
Då inser du att du har flera fler tillgänglighetszoner, flera datacenter. Och tillvägagångssättet för pooling på klientsidan leder till stora antal. Stora är cirka 10 000 anslutningar. Detta är kanten som kan fungera normalt.
Om vi pratar om proxypoolare, så finns det två poolare som kan göra många saker. De är inte bara poolare. De är poolare + mer cool funktionalitet. Detta и .
Men tyvärr behöver inte alla denna extra funktionalitet. Och det leder till det faktum att poolare endast stöder sessionspooling, det vill säga en inkommande klient, en utgående klient till databasen.
Detta är inte särskilt lämpligt för våra syften, så vi använder PgBouncer, som implementerar transaktionspooling, dvs serveranslutningar matchas till klientanslutningar endast under transaktionens varaktighet.
Och i vår arbetsbörda är detta sant. Men det finns några problem.
Problemen börjar när du vill diagnostisera en session, eftersom alla dina inkommande anslutningar är lokala. Alla kom med en loopback och på något sätt blir det svårt att spåra sessionen.
Naturligtvis kan du använda application_name_add_host. Detta är ett sätt på Bouncer-sidan att lägga till en IP-adress till application_name. Men application_name ställs in av en extra anslutning.
På denna graf, där den gula linjen är verkliga förfrågningar, och där den blå linjen är förfrågningar som flyger in i databasen. Och denna skillnad är just installationen av application_name, som bara behövs för att spåra, men det är inte alls gratis.
Dessutom kan du i Bouncer inte begränsa en pool, det vill säga antalet databasanslutningar per specifik användare, per specifik databas.
Vad leder detta till? Du har en laddad tjänst skriven i C++ och någonstans i närheten en liten tjänst på en nod som inte gör något hemskt med databasen, men dess drivrutin blir galen. Den öppnar 20 000 anslutningar och allt annat väntar. Även din kod är normal.
Vi skrev naturligtvis en liten patch för Bouncer som lade till den här inställningen, det vill säga begränsa klienterna till poolen.
Det skulle vara möjligt att göra detta på Postgres-sidan, d.v.s. begränsa rollerna i databasen med antalet anslutningar.
Men då tappar man förmågan att förstå varför man inte har några anslutningar till servern. PgBouncer kastar inte ett anslutningsfel, det returnerar alltid samma information. Och du kan inte förstå: kanske ditt lösenord har ändrats, kanske databasen bara har gått vilse, kanske något är fel. Men det finns ingen diagnos. Om en session inte kan upprättas vet du inte varför den inte kan upprättas.
Vid ett visst tillfälle tittar man på applikationsgraferna och ser att applikationen inte fungerar.
Titta på toppen och se att Bouncer är entrådig. Detta är en vändpunkt i tjänstens liv. Du inser att du förberedde att skala databasen på ett och ett halvt år, och du måste skala poolern.
Vi har kommit fram till att vi behöver fler PgBouncers.
Bouncer har lappats lite.
Och de gjorde det så att flera Bouncers kunde höjas genom att återanvända TCP-porten. Och operativsystemet överför automatiskt inkommande TCP-anslutningar mellan dem med hjälp av round-robin.
Detta är transparent för klienter, vilket innebär att det ser ut som att du har en Bouncer, men du har fragmentering av lediga anslutningar mellan körande Bouncers.
Och vid ett visst ögonblick kanske du märker att dessa 3 Bouncers var och en äter upp sin kärna med 100%. Du behöver en hel del Bouncers. Varför?
Eftersom du har TLS. Du har en krypterad anslutning. Och om du jämför Postgres med och utan TLS, kommer du att upptäcka att antalet etablerade anslutningar sjunker med nästan två storleksordningar med kryptering aktiverad, eftersom TLS-handskakningen förbrukar CPU-resurser.
Och längst upp kan du se en hel del kryptografiska funktioner som exekveras när det finns en våg av inkommande anslutningar. Eftersom vår primära kan växla mellan tillgänglighetszoner är en våg av inkommande anslutningar en ganska typisk situation. Det vill säga, av någon anledning var den gamla primära inte tillgänglig, hela lasten skickades till ett annat datacenter. De kommer alla att säga hej till TLS samtidigt.
Och ett stort antal TLS-handslag kanske inte längre säger hej till Bouncer, utan kommer att krama hans hals. På grund av timeout kan vågen av inkommande anslutningar bli odämpade. Om du försöker till basen igen utan exponentiell backoff kommer de inte att komma igen och igen i en koherent våg.
Här är ett exempel på 16 PgBouncers som laddar 16 kärnor med 100 %.
Vi kom till kaskaden PgBouncer. Detta är den bästa konfigurationen som kan uppnås på vår last med Bouncer. Våra externa Bouncers används för TCP-handskakning, och interna Bouncers används för riktig pooling, för att inte fragmentera externa anslutningar för mycket.
I den här konfigurationen är en smidig omstart möjlig. Du kan starta om alla dessa 18 Bouncers en efter en. Men att upprätthålla en sådan konfiguration är ganska svårt. Sysadmins, DevOps och personer som faktiskt är ansvariga för denna server kommer inte att vara särskilt nöjda med detta arrangemang.
Det verkar som att alla våra förbättringar kan främjas till öppen källkod, men Bouncer stöds inte särskilt väl. Till exempel, möjligheten att köra flera PgBouncers på en port togs i bruk för en månad sedan. Det fanns en pull-begäran med den här funktionen för flera år sedan.
Eller ytterligare ett exempel. I Postgres kan du avbryta en pågående begäran genom att skicka hemligheten till en annan anslutning utan onödig autentisering. Men vissa klienter skickar helt enkelt en TCP-återställning, det vill säga de bryter nätverksanslutningen. Vad kommer Bouncer att göra? Han kommer inte att göra någonting. Den kommer att fortsätta att utföra begäran. Om du har fått ett stort antal anslutningar som har skapat en databas med små förfrågningar, räcker det inte att bara koppla bort anslutningen från Bouncer, du måste också slutföra de förfrågningar som körs i databasen.
Detta har korrigerats och detta problem har ännu inte slagits samman med Bouncers uppströms.
Och så kom vi fram till att vi behöver en egen anslutningspooler, som kommer att utvecklas, lappas, där problem snabbt kan åtgärdas och som naturligtvis måste vara flertrådad.
Vi satte multithreading som huvuduppgift. Vi måste kunna hantera vågen av inkommande TLS-anslutningar väl.
För att göra detta var vi tvungna att utveckla ett separat bibliotek som heter Machinarium, som är utformat för att beskriva maskintillstånden för en nätverksanslutning som sekventiell kod. Om du tittar på libpq-källkoden kommer du att se några ganska komplicerade anrop som kan returnera dig ett resultat och säga, "Ring mig senare. Just nu har jag IO för nu, men när IO försvinner kommer jag att ha en belastning på processorn." Och detta är ett flernivåschema. Nätverkskommunikation beskrivs vanligtvis av en tillståndsmaskin. Många regler som "Om jag tidigare fick ett pakethuvud av storlek N, nu väntar jag på N byte", "Om jag skickade ett SYNC-paket, väntar jag nu på ett paket med resultatmetadata." Resultatet är en ganska svår, kontraintuitiv kod, som om labyrinten skulle omvandlas till linjeavsökning. Vi gjorde det så att i stället för en tillståndsmaskin beskriver programmeraren huvudvägen för interaktion i form av vanlig imperativ kod. Det är bara det att du i den här imperativa koden måste infoga platser där exekveringssekvensen måste avbrytas genom att vänta på data från nätverket och skicka exekveringskontexten till en annan koroutin (grön tråd). Detta tillvägagångssätt liknar det faktum att vi skriver ner den mest förväntade banan i labyrinten i rad och sedan lägger till grenar till den.
Som ett resultat har vi en tråd som TCP accepterar och round-robin skickar TPC-anslutningen till många arbetare.
I det här fallet körs varje klientanslutning alltid på en processor. Och detta gör att du kan göra den cache-vänlig.
Och dessutom har vi förbättrat insamlingen av små paket till ett enda stort paket för att avlasta systemets TCP-stacken.
Dessutom har vi förbättrat transaktionspooling i den meningen att Odyssey, när den är konfigurerad, kan skicka CANCEL och ROLLBACK i händelse av ett nätverksanslutningsfel, dvs om ingen väntar på en förfrågan kommer Odyssey att säga åt databasen att inte försöka uppfylla begäran som kan slösa med värdefulla resurser.
Och när det är möjligt behåller vi kopplingar till samma kund. Detta undviker att behöva installera om application_name_add_host. Om detta är möjligt behöver vi inte ytterligare återställa parametrarna som behövs för diagnostik.
Vi arbetar i Yandex.Clouds intresse. Och om du använder hanterad PostgreSQL och har en anslutningspooler installerad, kan du skapa logisk replikering utåt, d.v.s. lämna oss, om du vill, med logisk replikering. Bouncer kommer inte att släppa det logiska replikeringsflödet utanför.
Detta är ett exempel på hur du ställer in logisk replikering.
Dessutom har vi stöd för fysisk replikering utåt. I molnet är detta naturligtvis omöjligt, för då kommer klustret att ge dig för mycket information om sig själv. Men i dina installationer, om du behöver fysisk replikering genom anslutningspoolern i Odyssey, är detta möjligt.
Odyssey har helt kompatibel övervakning med PgBouncer. Vi har samma konsol som kör nästan alla samma kommandon. Om något saknas, skicka en pull-förfrågan, eller åtminstone ett problem på GitHub, så kommer vi att slutföra de nödvändiga kommandona. Men vi har redan huvudfunktionaliteten i PgBouncer-konsolen.
Och naturligtvis har vi felvidarebefordran. Vi kommer att returnera felet som rapporterats av databasen. Du får information om varför du inte ingår i databasen, och inte bara att du inte ingår i den.
Den här funktionen är inaktiverad om du behöver 100 % kompatibilitet med PgBouncer. Vi kan bete oss på samma sätt som Bouncer, bara för att vara på den säkra sidan.
utformning
Några ord om Odyssey-källkoden.
Det finns till exempel "Paus/Fortsätt"-kommandon. De används vanligtvis för att uppdatera databasen. Om du behöver uppdatera Postgres kan du pausa det i anslutningspoolern, göra pg_upgrade och sedan fortsätta. Och från klientens sida kommer det att se ut som om databasen helt enkelt saktade ner. Denna funktion kom till oss av människor från samhället. Hon är inte frusen än, men snart är allt. (Redan fryst)
- redan frusna
Dessutom är en av de nya funktionerna i PgBouncer stöd för SCRAM Authentication, som också kom till oss av en person som inte arbetar i Yandex.Cloud. Båda är komplexa funktioner och viktiga.
Därför skulle jag vilja berätta vad Odyssey är gjord av, ifall du också vill skriva lite kod nu.
Du har Odyssey-källbasen, som är beroende av två huvudbibliotek. Kiwi-biblioteket är en implementering av Postgres meddelandeprotokoll. Det vill säga native proto 3 av Postgres är standardmeddelanden som front-ends och back-ends kan utbyta. De är implementerade i Kiwi-biblioteket.
Machinarium-biblioteket är ett trådimplementeringsbibliotek. Ett litet fragment av detta Machinarium är skrivet på assemblerspråk. Men var inte orolig, det finns bara 15 rader.
Odyssey arkitektur. Det finns en huvudmaskin som koroutiner körs på. Denna maskin implementerar att acceptera inkommande TCP-anslutningar och distribuera dem bland arbetare.
En hanterare för flera klienter kan arbeta inom en arbetare. Huvudtråden kör också konsolen och bearbetningen av crone-uppgifter för att ta bort anslutningar som inte längre behövs i poolen.
Odyssey testas med Postgres standardtestsvit. Vi kör bara install-check genom Bouncer och genom Odyssey får vi en noll div. Det finns flera tester relaterade till datumformatering som inte klarar exakt samma i Bouncer och i Odyssey.
Dessutom finns det många förare som har sina egna tester. Och vi använder deras tester för att testa Odyssey.
Dessutom, på grund av vår kaskadkonfiguration, måste vi testa olika buntar: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey för att vara säkra på att om Odyssey hamnade i någon av delarna i kaskaden, så fungerar det också fortfarande som vi förväntar oss.
rake
Vi använder Odyssey i produktionen. Och det vore inte rättvist om jag sa att allt bara fungerar. Nej, det vill säga, ja, men inte alltid. Till exempel, i produktionen fungerade bara allt, sedan kom våra vänner från PostgreSQL Professional och sa att vi hade en minnesläcka. Det var de verkligen, vi rättade till dem. Men det var enkelt.
Sedan upptäckte vi att anslutningspoolaren har inkommande TLS-anslutningar och utgående TLS-anslutningar. Och anslutningar kräver klientcertifikat och servercertifikat.
Bouncer- och Odyssey-servercertifikat läses om av deras pcache, men klientcertifikat behöver inte läsas om från pcache, eftersom vår skalbara Odyssey slutligen körs in i systemets prestanda för att läsa detta certifikat. Detta kom som en överraskning för oss, eftersom det inte tog lång tid för honom att göra motstånd. Först skalade det linjärt, men efter 20 000 inkommande samtidiga anslutningar visade sig detta problem.
Pluggbar autentiseringsmetod är möjligheten att autentisera med inbyggda Lunux-verktyg. I PgBouncer är det implementerat på ett sådant sätt att det finns en separat tråd för att vänta på svar från PAM och det finns en PgBouncer-huvudtråd som servar den aktuella anslutningen och kan be dem att leva i PAM-tråden.
Vi implementerade inte detta av en enkel anledning. Vi har många trådar. Varför behöver vi detta?
Detta kan i slutändan skapa problem genom att om du har PAM-autentisering och icke-PAM-autentisering, kan en stor våg av PAM-autentisering avsevärt försena icke-PAM-autentiseringen. Det här är en av de saker som vi inte har fixat. Men om du vill fixa det kan du göra detta.
En annan rake var att vi har en tråd som accepterar alla inkommande anslutningar. Och sedan förs de över till arbetarpoolen, där TLS-handslaget kommer att äga rum.
Sammanfattningsvis, om du har en sammanhängande våg av 20 000 nätverksanslutningar, kommer de alla att accepteras. Och på klientsidan kommer libpq att börja rapportera timeouts. Som standard verkar det vara 3 sekunder.
Om de alla inte kan komma in i databasen samtidigt, kan de inte komma in i databasen, eftersom allt detta kan täckas av ett icke-exponentiellt försök.
Vi kom till slutsatsen att vi kopierade schemat från PgBouncer här med det faktum att vi har begränsat antalet TCP-anslutningar som vi accepterar.
Om vi ser att vi accepterar anslutningar, men de i slutändan inte har tid att handskaka, ställer vi dem i en kö så att de inte slösar CPU-resurser. Detta leder till att en samtidig handskakning kanske inte utförs för alla anslutningar som har kommit. Men åtminstone kommer någon in i databasen, även om belastningen är ganska tung.
färdplan
Vad skulle du vilja se i framtiden i Odyssey? Vad är vi redo att utveckla själva och vad förväntar vi oss av samhället?
Från och med augusti 2019.
Så här såg Odyssey-färdplanen ut i augusti:
- Vi ville ha SCRAM- och PAM-autentisering.
- Vi ville vidarebefordra läsförfrågningar till standby.
- Jag skulle vilja ha en online-omstart.
- Och möjligheten att pausa på servern.
Hälften av denna färdplan har slutförts, och inte av oss. Och det här är bra. Så låt oss diskutera vad som återstår och lägga till mer.
? Vi har kopior som helt enkelt kommer att värma luften utan att utföra förfrågningar. Vi behöver dem för att tillhandahålla failover och switchover. I händelse av problem i ett av datacenterna skulle jag vilja sysselsätta dem med lite användbart arbete. Eftersom vi inte kan konfigurera samma centrala processorer, samma minne annorlunda, eftersom replikering annars inte fungerar.
I princip, i Postgres, från 10, är det möjligt att ange session_attrs vid anslutning. Du kan lista alla databasvärdar i anslutningen och säga varför du går till databasen: skriv eller skrivskyddad. Och föraren själv kommer att välja den första värd i listan som han gillar bäst, som uppfyller kraven för session_attrs.
Men problemet med detta tillvägagångssätt är att det inte kontrollerar replikeringsfördröjningen. Du kan ha en kopia som har släpat efter under en oacceptabel tid för din tjänst. För att möjliggöra fullfjädrad exekvering av läsfrågor på en replik behöver vi i huvudsak stödja Odysseys förmåga att inte köras när den inte kan läsas.
Odyssey måste gå till databasen då och då och fråga efter replikeringsavståndet från den primära. Och om den har nått gränsvärdet, tillåt inte nya förfrågningar i databasen, berätta för klienten att den måste återuppta anslutningar och eventuellt välja en annan värd för att utföra förfrågningar. Detta gör att databasen snabbt kan återställa replikeringsfördröjningen och återvända för att svara med en begäran.
Det är svårt att ge en tidsram för implementering, eftersom det är öppen källkod. Men, hoppas jag, inte 2,5 år som mina kollegor från PgBouncer. Det här är funktionen jag skulle vilja se i Odyssey.
. Nu kan du skapa ett förberett uttalande på två sätt. Först kan du köra SQL-kommandot, nämligen "prepared". För att förstå detta SQL-kommando måste vi lära oss att förstå SQL på Bouncer-sidan. Detta skulle vara en overkill, eftersom det är overkill, eftersom vi behöver hela parsern. Vi kan inte analysera alla SQL-kommandon.
Men det finns ett förberett uttalande på meddelandeprotokollnivå på proto3. Och det här är platsen när informationen om att ett förberett uttalande skapas kommer i en strukturerad form. Och vi kunde stödja förståelsen att på någon serveranslutning bad klienten att skapa förberedda uttalanden. Och även om transaktionen är stängd behöver vi fortfarande upprätthålla anslutningen mellan servern och klienten.
Men här uppstår en diskrepans i dialogen, eftersom någon säger att du måste förstå vilken typ av förberedda uttalanden klienten skapade och dela serveranslutningen mellan alla klienter som skapade denna serverförbindelse, d.v.s. vem som skapade en sådan förberedd sats.
Andres Freund sa att om en klient kommer till dig som redan har skapat ett sådant förberett uttalande i en annan serveranslutning, skapa det åt honom. Men det verkar lite fel att köra frågor i databasen istället för klienten, men ur utvecklarens synvinkel som skriver protokollet för att interagera med databasen, skulle det vara bekvämt om han helt enkelt fick en nätverksanslutning där det finns en sådan förberedd fråga.
Och ytterligare en funktion som vi måste implementera. Vi har nu övervakning som är kompatibel med PgBouncer. Vi kan returnera den genomsnittliga exekveringstiden för frågor. Men den genomsnittliga tiden är medeltemperaturen på sjukhuset: vissa är kalla, andra är varma - i genomsnitt är alla friska. Det är inte sant.
Vi måste implementera stöd för percentiler, vilket skulle indikera att det finns långsamma frågor som slösar resurser och skulle göra övervakning mer acceptabel.
Det viktigaste är att jag vill ha version 1.0 (version 1.1 har redan släppts). Faktum är att Odyssey nu finns i version 1.0rc, dvs releasekandidat. Och alla problem som jag listade fixades med exakt samma version, förutom minnesläckan.
Vad kommer version 1.0 att betyda för oss? Vi rullar ut Odyssey till våra baser. Den körs redan på våra databaser, men när den når punkten 1 000 000 förfrågningar per sekund, då kan vi säga att detta är releaseversionen och det här är en version som kan kallas 1.0.
Flera personer i samhället har bett att version 1.0 ska innehålla paus och SCRAM. Men detta kommer att innebära att vi kommer att behöva rulla ut nästa version till produktion, eftersom varken SCRAM eller paus ännu har dödats. Men troligen kommer det här problemet att lösas ganska snabbt.
Jag väntar på din begäran. Jag skulle också vilja höra vilka problem du har med Bouncer. Låt oss diskutera dem. Kanske kan vi implementera några funktioner som du behöver.
Detta är slutet på min del, jag skulle vilja lyssna på dig. Tack!
frågor
Om jag ställer in mitt eget application_name, kommer det att vidarebefordras korrekt, inklusive i transaktionspoolning i Odyssey?
Odyssey eller Bouncer?
I Odyssey. I Bouncer kastas det.
Vi gör ett set.
Och om min riktiga anslutning hoppar på andra anslutningar, kommer den att överföras?
Vi kommer att göra en uppsättning av alla parametrar som är listade i listan. Jag kan inte avgöra om application_name finns i den här listan. Jag tror jag såg honom där. Vi kommer att ställa in alla samma parametrar. Med en begäran kommer setet att göra allt som installerades av klienten under uppstarten.
Tack, Andrey, för rapporten! Bra rapport! Jag är glad att Odyssey utvecklas snabbare och snabbare för varje minut. Jag vill fortsätta så här. Vi har redan bett dig att ha en multidatakälla-anslutning så att Odyssey kan ansluta till olika databaser samtidigt, d.v.s. en masterslav, och sedan automatiskt ansluta till en ny master efter failover.
Ja, jag verkar komma ihåg den här diskussionen. Nu finns flera förråd. Men det går inte att byta mellan dem. På vår sida måste vi fråga servern att den fortfarande är vid liv och förstå att en failover har inträffat, som kommer att anropa pg_recovery. Jag har ett standardsätt att förstå att vi inte kom till mästaren. Och ska vi förstå på något sätt av misstagen eller vad? Det vill säga idén är intressant, den diskuteras. Skriv fler kommentarer. Om du har arbetare som kan C, så är det bra.
Frågan om skalning över repliker är också av intresse för oss, eftersom vi vill göra införandet av replikerade kluster så enkelt som möjligt för applikationsutvecklare. Men här skulle jag vilja ha fler kommentarer, dvs exakt hur man gör, hur man gör det bra.
Frågan handlar också om repliker. Det visar sig att du har en mästare och flera repliker. Och det är tydligt att de går till repliken mer sällan än till mästaren för anslutningar, eftersom de kan ha skillnader. Du sa att skillnaden i uppgifterna kan vara sådan att den inte kommer att tillfredsställa din verksamhet och du kommer inte att åka dit förrän den replikeras. Samtidigt, om du inte åkte dit på länge och sedan började gå, kommer den information som behövs inte att vara tillgänglig omedelbart. Det vill säga, om vi ständigt går till mästaren, så värms cachen där upp, men i repliken släpar cachen lite.
Ja det är sant. PCache kommer inte att ha de datablock du vill ha, den riktiga cachen kommer inte att ha information om de tabeller du vill ha, planerna kommer inte att ha analyserade frågor, det kommer inte att finnas något alls.
Och när du har någon form av kluster, och du lägger till en ny replik där, då medan den startar, är allt dåligt i det, det vill säga det ökar sin cache.
Jag fick idén. Det korrekta tillvägagångssättet skulle vara att köra en liten andel av frågorna på repliken först, vilket skulle värma upp cachen. Grovt sett har vi ett villkor att vi inte får ligga efter mastern med högst 10 sekunder. Och detta villkor ingår inte i en våg, men smidigt för vissa kunder.
Ja, öka vikten.
Det här är en bra idé. Men först måste vi genomföra denna avstängning. Först måste vi stänga av och sedan fundera på hur vi slår på. Detta är en utmärkt funktion för att aktivera smidigt.
Nginx har det här alternativet slowly start i ett kluster för servern. Och han ökar gradvis belastningen.
Ja, bra idé, vi ska prova det när vi kommer runt.
Källa: will.com