I rapporten berÀttar Andrei Borodin hur de tog hÀnsyn till erfarenheterna av att skala PgBouncer vid utformningen av en anslutningspoolare , hur de rullade ut det i produktion. Dessutom kommer vi att diskutera vilka funktioner i poolaren vi skulle vilja se i nya versioner: det Àr viktigt för oss att inte bara tÀcka vÄra egna behov, utan ocksÄ att utveckla anvÀndarsamhÀllet .
Video:
Hej alla! Jag heter Andrei.
PÄ Yandex arbetar jag med utveckling av open source-databaser. Och idag har vi Àmnet angÄende connection pooler.
Om du vet hur man benÀmner connection pooler pÄ svenska, sÄ sÀg gÀrna till mig. Jag vill verkligen hitta en bra teknisk term som borde etableras i den tekniska litteraturen.
Ămnet Ă€r ganska komplext, eftersom mĂ„nga databaser har inbyggda connection poolers och man ens inte behöver kĂ€nna till dem. Det finns sĂ„klart konfigurationer som Ă€r gemensamma, men det fungerar inte pĂ„ samma sĂ€tt i Postgres. Samtidigt (pĂ„ HighLoad++ 2019) hĂ„lls en presentation av Nikolay Samokhvalov om att optimera frĂ„gor i Postgres. Jag förstĂ„r att hĂ€r har kommit personer som redan har optimerat sina frĂ„gor perfekt, och dessa personer stĂ€lls inför mer sĂ€llsynta systemproblem kopplade till nĂ€tverk och resursutnyttjande. Ibland kan det vara ganska svĂ„rt eftersom problemen Ă€r otydliga.
PÄ Yandex finns Postgres. I Yandex.Cloud lever mÄnga av Yandex tjÀnster. Vi har flera petabyte data som genererar minst en miljon frÄgor per sekund i Postgres.
Och vi tillhandahĂ„ller en ganska typisk kluster för alla tjĂ€nster â det Ă€r den primĂ€ra noden, vanliga tvĂ„ repliker (synkron och asynkron), backup, och skalning av lĂ€sfrĂ„gor pĂ„ repliken.
Varje nod i klustret Àr en Postgres som förutom Postgres och systemövervakning ocksÄ har en connection pooler installerad. Connection poolern anvÀnds för fencing och i sitt grundlÀggande syfte.
Vad Àr det grundlÀggande syftet med connection poolern?
I Postgres anvÀnds en processmodell för att arbeta med databasen. Det betyder att en anslutning Àr en process, en Postgres-backend. Och i denna backend finns det mÄnga olika cachar som Àr ganska dyra att skapa olika för olika anslutningar.
Dessutom finns det en array i Postgres-koden som kallas procArray. Den innehÄller grundlÀggande data om nÀtverksanslutningar. NÀstan alla algoritmer för att bearbeta procArray har linjÀr komplexitet, de gÄr igenom hela arrayen av nÀtverksanslutningar. Det Àr en ganska snabb loop, men med ett stort antal inkommande nÀtverksanslutningar blir det lite dyrare. Och nÀr allt blir lite dyrare kan man till slut betala ett mycket högt pris för ett stort antal nÀtverksanslutningar.
Det finns tre möjliga tillvÀgagÄngssÀtt:
- PĂ„ applikationssidan.
- PĂ„ databasens sida.
- Och emellan, det vill sÀga alla möjliga kombinationer.
TyvÀrr Àr den inbyggda poolern just nu under utveckling. VÀnner pÄ företaget PostgreSQL Professional arbetar frÀmst med detta. NÀr den Àr klar Àr svÄrt att förutsÀga. Och det finns i sjÀlva verket tvÄ lösningar pÄ arkitektens val. Det Àr application-side pool och proxy pool.
Application-side pool Àr det enklaste sÀttet. NÀstan alla klientdrivrutiner ger dig möjlighet att representera miljontals av dina anslutningar i koden som ett antal dussintals anslutningar till databasen.
Problemet uppstÄr nÀr du pÄ ett visst sÀtt vill skala bakÄten, du vill distribuera det pÄ mÄnga virtuella maskiner.
Sedan inser du ocksÄ att du har flera tillgÀnglighetszoner, flera datacenter. Och tillvÀgagÄngssÀttet med klientbaserad poolning leder till stora siffror. Stora Àr omkring 10 000 anslutningar. Det Àr grÀnsen för vad som kan fungera normalt.
NÀr det kommer till proxy-poolers finns det tvÄ poolers som kan mycket. De Àr inte bara poolers. De Àr poolers + ytterligare fantastisk funktionalitet. Det Àr och .
Men tyvÀrr behövs inte denna extra funktionalitet av alla. Och det leder till att poolers bara stöder sessionspoolning, det vill sÀga en inkommande klient, en utgÄende klient till databasen.
För vÄra uppgifter fungerar det inte sÄ bra, dÀrför anvÀnder vi PgBouncer, som implementerar transaktionspoolning, det vill sÀga serveranslutningar kopplas till klientanslutningar endast under transaktionen.
Och vid vÄr belastning Àr det faktiskt sant. Men det finns nÄgra problem.
Problemen börjar nÀr du vill diagnostisera en session, eftersom alla inkommande anslutningar Àr lokala. Alla kom frÄn loopback och att pÄ nÄgot sÀtt spÄra sessionen blir svÄrt.
SjÀlvklart kan du anvÀnda application_name_add_host. Det Àr ett sÀtt för Bouncer att lÀgga till en IP-adress i application_name. Men application_name stÀlls in med en extra anslutning.
I den hÀr grafen Àr den gula linjen verkliga förfrÄgningar, medan den blÄ linjen Àr förfrÄgningar som kommer in i databasen. Skillnaden hÀr Àr just instÀllningen av application_name, som behövs endast för spÄrning, men den Àr absolut inte kostnadsfri.
Dessutom kan man inte begrÀnsa en pool i Bouncer, dvs. antalet anslutningar till databasen för en viss anvÀndare, för en viss databas.
Vad leder detta till? Du har en belastad tjÀnst skriven i C++ och nÄgonstans i nÀrheten en liten tjÀnst pÄ Node som inte gör nÄgot farligt mot databasen, men dess drivrutin blir galen. Den öppnar 20 000 anslutningar, medan allt annat fÄr vÀnta. Du har till och med en normal kod.
Vi har givetvis skrivit en liten patch för Bouncer som lade till denna instÀllning, dvs. begrÀnsning av klienter till en pool.
Det skulle kunna göras pÄ Postgres-sidan, dvs. att roller i databasen begrÀnsas till ett visst antal anslutningar.
Men dÄ förlorar du möjligheten att förstÄ varför du inte har nÄgra anslutningar till servern. PgBouncer vidarebefordrar inte anslutningsfel, det returnerar alltid samma information. Och du kan inte förstÄ: kanske har ditt lösenord Àndrats, kanske har bara databasen fallit, kanske Àr nÄgot fel. Men det finns ingen diagnos. Om en session inte kan upprÀttas fÄr du inte veta varför det inte gÄr.
Vid en viss tidpunkt ser du pÄ applikationens grafer och ser att applikationen inte fungerar.
Du tittar pÄ toppen och ser att Bouncer Àr entrÄdad. Det Àr en vÀndpunkt i tjÀnstens liv. Du inser att du har förberett dig för att skalera databasen om ett och ett halvt Är, men du behöver skala poolern.
Vi har kommit fram till att vi behöver fler PgBouncer.
Vi har gjort en liten patch av Bouncer.
Och vi har gjort sÄ att flera Bouncers kan startas med ÄteranvÀndning av TCP-porten. Och operativsystemet omfördelar automatiskt inkommande TCP-anslutningar mellan dem med round-robin.
Detta Àr transparent för kunderna, dvs. allt ser ut som om du har en Bouncer, men du har en fragmentering av idle-anslutningar mellan de startade Bouncers.
Vid en viss tidpunkt kan du mÀrka att dessa tre Bouncers anvÀnder 100 % av sina kÀrnor. Du behöver ganska mÄnga Bouncers. Varför?
För att du har TLS. Du har en krypterad anslutning. Om du benchmarkar Postgres med TLS och utan TLS, kommer du att upptÀcka att antalet etablerade anslutningar minskar nÀstan tvÄ ordningar med kryptering aktiverad, eftersom TLS-handshake anvÀnder CPU-resurser.
Och i toppen kan du se ganska mÄnga kryptografiska funktioner som utförs under en vÄg av inkommande anslutningar. Eftersom vÄr primary kan vÀxla mellan tillgÀnglighetszoner Àr vÄgen av inkommande anslutningar en ganska typisk situation. D.v.s. av nÄgon anledning var den gamla primary otillgÀnglig, och hela lasten skickades till ett annat datacenter. De kommer alla samtidigt för att hÀlsa pÄ med TLS.
Och ett stort antal TLS-handshake kanske inte hÀlsar pÄ Bouncer lÀngre, utan istÀllet kvÀver honom. PÄ grund av timeout kan vÄgen av inkommande anslutningar bli oÀndlig. Om du har retry i databasen utan exponential backoff kommer de att komma tillbaka om och om igen pÄ ett koherenta sÀtt.
HÀr Àr ett exempel pÄ 16 PgBouncer som belastar 16 kÀrnor till 100 %.
Vi har kommit till den kaskad PgBouncer. Detta Àr den bÀsta konfigurationen vi kan uppnÄ med vÄr belastning pÄ Bouncer. Yttre Bouncers anvÀnds för TCP-handshake, medan inre Bouncers anvÀnds för verklig pooling, för att inte fragmentera externa anslutningar alltför mycket.
I en sÄdan konfiguration Àr en smidig omstart möjlig. Du kan omstarta alla dessa 18 Bouncers en och en. Men att underhÄlla en sÄdan konfiguration Àr ganska svÄrt. Systemadministratörer, DevOps och de som verkligen ansvarar för denna server kommer inte att vara sÀrskilt glada över ett sÄdant upplÀgg.
Det verkar som om vi skulle kunna föra alla vÄra förbÀttringar till open source, men Bouncer fÄr inte sÄ bra stöd. Till exempel kom möjligheten att köra flera PgBouncers pÄ en port in för en mÄnad sedan. Och pull requesten med den funktionen var för flera Är sedan.
Ett annat exempel. I Postgres kan du avbryta en pÄgÄende begÀran genom att skicka en hemlighet över en annan anslutning utan extra autentisering. Men vissa klienter skickar helt enkelt en TCP-reset, det vill sÀga de bryter nÀtverksanslutningen. Vad gör Bouncer i detta fall? Ingenting. Den fortsÀtter att utföra begÀran. Om du har fÄtt en stor mÀngd anslutningar som med smÄ begÀrningar har belastat databasen, rÀcker det inte bara att koppla bort anslutningen frÄn Bouncer; du behöver Àven avsluta de begÀrningar som körs i databasen.
Detta har blivit patchat, men problemet har fortfarande inte mergats in i upstream Bouncer.
SÄ vi har kommit fram till att vi behöver vÄr egen connection pooler som kommer att utvecklas, patchas, dÀr vi snabbt kan ÄtgÀrda problem och som sjÀlvklart mÄste vara flertrÄdad.
FlertrÄdning har vi satt som huvudmÄl. Vi behöver kunna hantera en hög vÄg av inkommande TLS-anslutningar effektivt.
För detta var vi tvungna att utveckla ett separat bibliotek som heter Machinarium, vilket Àr avsett för att beskriva maskinstatusarna för nÀtverksanslutningen som sekventiell kod. Om du ser i kÀllkoden till libpq, sÄ kommer du att se ganska komplicerade anrop som kan returnera ett resultat och sÀga: 'Anropa mig senare. Just nu har jag IO, men nÀr IO Àr klart kommer jag att ha belastning för processorn'. Och detta Àr en flerdimensionell struktur. NÀtverksinteraktion beskrivs vanligtvis som en tillstÄndsmaskin. Med mÄnga regler som 'Om jag tidigare fick en paketheader av storlek N, dÄ vÀntar jag nu pÄ N byte', 'Om jag skickade en SYNC-paket, dÄ vÀntar jag nu pÄ ett paket med metadata för resultatet'. Det blir ganska svÄrfattad, kontraproduktiv kod, som om en labyrint omvandlas till en linjÀr utformning. Vi har gjort sÄ att istÀllet för en tillstÄndsmaskin beskriver programmeraren den primÀra interaktionsvÀgen i form av vanlig imperativ kod. I denna imperativa kod mÄste man helt enkelt infoga stÀllen dÀr sekvensen av exekvering ska avbrytas för att vÀnta pÄ data frÄn nÀtverket, genom att överföra exekveringskontexten till en annan korutin (green thread). Denna metod liknar att vi skriver ner den mest förvÀntade vÀgen i labyrinten i följd och sedan lÀgger till avsnitt.
I slutÀndan har vi en ström som gör TCP-accept och rundrobin överför flera TPC-anslutningar till arbetare.
Dessutom fungerar varje klientanslutning alltid pÄ en processor. Detta gör att den blir cache-vÀnlig.
Och dessutom har vi förbÀttrat sammanslagningen av smÄ paket till ett stort paket för att avlasta det systemiska TCP-stacket.
Vidare har vi förbÀttrat den transaktionella poolningen, sÄ att Odyssey med rÀtt instÀllning kan skicka CANCEL och ROLLBACK i hÀndelse av ett nÀtverksavbrott. Det vill sÀga, om ingen vÀntar pÄ en förfrÄgan, kommer Odyssey att meddela databasen att den inte ska försöka utföra den begÀran som kan slösa vÀrdefulla resurser.
Vi försöker ocksÄ spara anslutningar för samma klient. Detta gör att vi inte behöver Äterinstallera application_name_add_host. Om möjligt har vi inga extra installationer av de parametrar som behövs för diagnostik.
Vi arbetar för Yandex.Cloud. Om du anvÀnder managed PostgreSQL och har en installerad connection pooler kan du skapa logisk replikation utÄt, det vill sÀga du kan lÀmna oss om du vill, genom logisk replikation. Bouncer kommer inte att skicka ut den logiska replikationsströmmen.
Detta Àr ett exempel pÄ instÀllning av logisk replikation.
Dessutom har vi stöd för fysisk replikation utÄt. I Cloud Àr det sjÀlvklart inte möjligt, eftersom det skulle ge din kluster för mycket information om sig sjÀlv. Men i era installationer, om ni behöver fysisk replikation genom connection pooler i Odyssey, Àr det möjligt.
I Odyssey har vi fullstÀndig överensstÀmmelse med PgBouncer övervakning. Vi har en liknande konsol som utför nÀstan alla samma kommandon. Om nÄgot saknas, skicka gÀrna ett pull request eller Ätminstone en issue pÄ GitHub, sÄ kommer vi att lÀgga till de nödvÀndiga kommandona. Men den grundlÀggande funktionaliteten i PgBouncer-konsolen finns redan hos oss.
Och sjÀlvklart har vi error forwarding. Vi kommer att returnera det fel som databasen rapporterade. Du fÄr information om varför du inte nÄr databasen, istÀllet för bara att du inte nÄr den.
Denna funktion kan stÀngas av om du behöver 100%-ig kompatibilitet med PgBouncer. Vi kan bete oss som Bouncer, bara för sÀkerhets skull.
Utveckling
NÄgra ord om kÀllkoden för Odyssey.
Till exempel finns det kommandon som "Pause /Resume". De anvÀnds vanligtvis för att uppdatera databasen. Om du behöver uppdatera Postgres kan du pausa den i connection poolern, göra pg_upgrade, och sedan Äteruppta den. För klienten kommer det att se ut som att databasen bara var lÄngsam. Denna funktionalitet har kommit frÄn communityn. Den Àr Ànnu inte sammanfogad, men snart kommer allt att vara klart. (Redan sammanfogad)
â redan sammanfogad
Dessutom Àr en av de nya funktionerna i PgBouncer stöd för SCRAM-autentisering, vilket ocksÄ har kommit frÄn en person som inte arbetar pÄ Yandex.Cloud. BÄda dessa funktioner Àr komplexa och viktiga.
DÀrför vill jag berÀtta om vad Odyssey Àr byggt av, kanske du ocksÄ vill skriva lite kod nu.
Du har en grundlÀggande version av Odyssey som bygger pÄ tvÄ huvudbibliotek. Biblioteket Kiwi Àr en implementation av Postgres meddelandeprotokoll. Det vill sÀga, den inbyggda proto 3 i Postgres bestÄr av standardmeddelanden som front-end och back-end kan utbyta. De Àr implementerade i biblioteket Kiwi.
Biblioteket Machinarium Àr ett bibliotek för implementering av trÄdar. En liten del av denna Machinarium Àr skriven i assembler. Men oroa dig inte, det handlar bara om 15 rader.
Odyssey-arkitektur. Det finns en huvudmaskin dÀr coroutines körs. I denna maskin hanteras inkommande TCP-anslutningar och distribueras till workers.
Inuti en worker kan en hanterare arbeta med flera klienter. Dessutom körs konsolen och hanteringen av schemalagda uppgifter för att ta bort anslutningar som inte lÀngre behövs i poolen i huvudtrÄden.
För testning av Odyssey anvÀnds en standarduppsÀttning tester frÄn Postgres. Vi kör bara install-check via Bouncer och via Odyssey, och fÄr en nulldiv. Det finns flera tester kopplade till datumformat som inte gÄr igenom pÄ exakt samma sÀtt i Bouncer och i Odyssey.
Dessutom finns det mÄnga drivrutiner som har sina egna tester. Och deras tester anvÀnder vi för att testa Odyssey.
Dessutom, pÄ grund av vÄr kaskadkonfiguration, mÄste vi testa olika kombinationer: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey för att vara sÀkra pÄ att, om Odyssey befinner sig i nÄgon del av kaskaden, det fortfarande fungerar som vi förvÀntar oss.
RĂ€fsor
Vi anvÀnder Odyssey i produktion. Det skulle vara orÀttvist att sÀga att allt bara fungerar. Nej, det gör det inte alltid. Till exempel, i produktion fungerade allt bra, men sedan kom vÄra vÀnner frÄn PostgreSQL Professional och berÀttade att vi hade en minneslÀcka. De hade verkligen rÀtt, och vi ÄtgÀrdade det. Men det var en överraskning.
Sedan upptÀckte vi att det finns inkommande och utgÄende TLS-anslutningar i connection poolern. Och för anslutningarna behövs bÄde klientcertifikat och servercertifikat.
Servercertifikaten för Bouncer och Odyssey lÀser om sin pcache, men klientcertifikaten behöver inte lÀsas om frÄn pcache eftersom vÄr skalbara Odyssey till slut krockar med systemets lÀsprestanda för detta certifikat. Detta var en överraskning för oss, eftersom det inte blev en begrÀnsning direkt. Först skalar det linjÀrt, men efter 20 000 samtidiga inkommande anslutningar upptrÀdde problemet.
Pluggable Authentication Method Àr en möjlighet att autentisera med inbyggda linux-verktyg. I PgBouncer Àr det implementerat sÄ att det finns en separat trÄd för att vÀnta pÄ svar frÄn PAM, och det finns en huvudtrÄd i PgBouncer som hanterar den aktuella anslutningen och kan be dem vÀnta i PAM-trÄden.
Vi valde att inte implementera detta av en enkel anledning. Vi har mÄnga trÄdar. Varför skulle vi behöva det?
Slutligen kan detta skapa problem med att om du har PAM-autentisering och icke-PAM-autentisering, kan en stor vÄg av PAM-autentisering avsevÀrt fördröja icke-PAM-autentiseringen. Det hÀr Àr en av de saker vi inte har ÄtgÀrdat. Men om du vill ÄtgÀrda det kan du ta dig an detta.
Ytterligare ett problem var att vi har en trÄd som accepterar alla inkommande anslutningar. Och dÀrefter vidarebefordras de till arbetspoolen, dÀr TLS-handshake kommer att ske.
I slutÀndan, om du har en kohÀrent vÄg av 20 000 nÀtverksanslutningar, kommer alla att accepteras. Och pÄ klientsidan börjar libpq att rÀkna ned tidsavbrott. Som standard verkar det vara 3 sekunder dÀr.
Om de alla inte kan komma in i databasen samtidigt, kan de inte komma in i databasen, eftersom allt detta kan tÀckas av en icke-exponentiell omprövning.
Vi kom fram till att vi kopierade schemat frÄn PgBouncer dÀr vi har dÀmpning av antalet TCP-anslutningar som vi gör accept pÄ.
Om vi ser att vi accepterar anslutningar men de har svÄrt att genomföra handskakningen, placerar vi dem i kö för att de inte ska anvÀnda CPU-resurser. Detta innebÀr att samtidig handskakning kanske inte kan genomföras för alla anslutningar som kommit in. Men Ätminstone fÄr nÄgon person i databasen Ätkomst, Àven om belastningen Àr ganska hög.
Roadmap
Vad skulle vi vilja se i framtiden i Odyssey? Vad Àr vi redo att utveckla sjÀlva och vad förvÀntar vi oss frÄn gemenskapen?
I augusti 2019.
SÄ hÀr sÄg roadmapen för Odyssey ut i augusti:
- Vi ville ha SCRAM och PAM autentisering.
- Vi ville ha framÄtriktade lÀsfrÄgor pÄ standby.
- Vi skulle vilja ha online-restart.
- Och möjligheten att pausa servern.
HÀlften av denna roadmap Àr genomförd, och det Àr inte vi som har gjort det. Och det Àr bra. SÄ lÄt oss diskutera det som ÄterstÄr och lÀgga till mer.
? ĐŁ ĐœĐ°Ń Đ”ŃŃŃ ŃДплОĐșĐž, ĐșĐŸŃĐŸŃŃĐ” бДз ĐČŃĐżĐŸĐ»ĐœĐ”ĐœĐžŃ Đ·Đ°ĐżŃĐŸŃĐŸĐČ Đ±ŃĐŽŃŃ ĐżŃĐŸŃŃĐŸ ĐłŃĐ”ŃŃ ĐČĐŸĐ·ĐŽŃŃ . ĐĐœĐž ĐœĐ°ĐŒ ĐœĐ”ĐŸĐ±Ń ĐŸĐŽĐžĐŒŃ ĐŽĐ»Ń ĐŸĐ±Đ”ŃпДŃĐ”ĐœĐžŃ failover Đž switchover. Đ ŃĐ»ŃŃĐ°Đ” ĐżŃĐŸĐ±Đ»Đ”ĐŒ ĐČ ĐŸĐŽĐœĐŸĐŒ Оз ĐŽĐ°ŃĐ°-ŃĐ”ĐœŃŃĐ” Ń ĐŸŃĐ”Đ»ĐŸŃŃ Đ±Ń ĐžŃ Đ·Đ°ĐœŃŃŃ ĐșĐ°ĐșĐŸĐč-ŃĐŸ ĐżĐŸĐ»Đ”Đ·ĐœĐŸĐč ŃĐ°Đ±ĐŸŃĐŸĐč. ĐĐŸŃĐŸĐŒŃ ŃŃĐŸ ŃĐ” жД ŃĐ°ĐŒŃĐ” ŃĐ”ĐœŃŃĐ°Đ»ŃĐœŃĐ” ĐżŃĐŸŃĐ”ŃŃĐŸŃŃ, ŃŃ Đ¶Đ” ŃĐ°ĐŒŃŃ ĐżĐ°ĐŒŃŃŃ ĐŒŃ ĐœĐ” ĐŒĐŸĐ¶Đ”ĐŒ ŃĐșĐŸĐœŃОгŃŃĐžŃĐŸĐČĐ°ŃŃ ĐżĐŸ-ĐŽŃŃĐłĐŸĐŒŃ, ĐżĐŸŃĐŸĐŒŃ ŃŃĐŸ ĐžĐœĐ°ŃĐ” ĐœĐ” бŃĐŽĐ”Ń ŃĐ°Đ±ĐŸŃĐ°ŃŃ ŃДплОĐșĐ°ŃĐžŃ.
I princip, i Postgres, frÄn version 10, finns det möjlighet att ange session_attrs vid anslutningen. Du kan lista alla databashostar i anslutningen och ange varför du besöker databasen: för att skriva eller bara lÀsa. Och drivrutinen vÀljer sjÀlv den första hosten i listan som passar bÀst, som uppfyller kraven pÄ session_attrs.
Men problemet med detta angreppssÀtt Àr att det inte kontrollerar replikationsfördröjningen. Du kan ha en replik som Àr försenad pÄ ett oacceptabelt sÀtt för din tjÀnst. För att möjliggöra fullstÀndig utförande av lÀsfrÄgor pÄ replik mÄste vi i princip stödja i Odyssey att det inte fungerar nÀr det inte Àr möjligt att lÀsa.
Odyssey bör dÄ och dÄ frÄga databasen om replikationsavstÄndet frÄn primÀr. Och om det nÄr en grÀns, bör nya förfrÄgningar till databasen blockeras, informera klienten om att de mÄste Äterinitiera anslutningarna och eventuellt vÀlja en annan host för att utföra förfrÄgningarna. Detta kommer att möjliggöra för databasen att snabbare ÄterhÀmta replikationsfördröjningen och Äterkomma för att svara pÄ förfrÄgningar.
Tidsramen för genomförande Àr svÄr att ange eftersom det Àr öppen kÀllkod. Men jag hoppas att det inte tar 2,5 Är som för kollegorna pÄ PgBouncer. Vi skulle vilja se denna funktion i Odyssey.
Nu kan du skapa en prepared statement pÄ tvÄ sÀtt. För det första kan du utfö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. Det skulle vara överdrivet, eftersom vi behöver en fullstÀndig parser. Vi kan inte parsa varje SQL-kommando.
Men det finns prepared statement pÄ meddelandeprotokollets nivÄ i proto3. Och det Àr dÀr informationen om att en prepared statement skapas kommer i strukturerad form. Vi skulle kunna stödja förstÄelsen av att en klient har begÀrt att skapa prepared statements pÄ en viss serveranslutning. Och Àven om transaktionen har stÀngts, behöver vi fortfarande stödja kopplingen mellan server och klient.
Men hÀr uppstÄr en diskrepans i dialogen, eftersom nÄgon talar om att förstÄ vilken specifik prepared statement klienten har skapat och att separera serveranslutningen mellan alla klienter som har skapat den serveranslutningen, det vill sÀga som har skapat en sÄdan prepared statement.
Andres Freund sa att om en klient kommer som redan har skapat en sÄdan prepared statement i en annan serveranslutning, bör du skapa den för honom. Men det verkar lite fel att utföra databaskommandon istÀllet för klienten, men ur ett utvecklarperspektiv, som skriver protokoll för databaskommunikation, skulle det vara praktiskt om han bara fick en nÀtverksanslutning dÀr det finns en sÄn preparerad frÄga.
Och Ă€n en funktion som vi behöver implementera. Vi har nu övervakning som Ă€r kompatibel med PgBouncer. Vi kan Ă„terge den genomsnittliga körningstiden för en frĂ„ga. Men den genomsnittliga tiden Ă€r som den genomsnittliga temperaturen pĂ„ sjukhuset: nĂ„gra Ă€r kalla, nĂ„gra Ă€r varma â i genomsnitt Ă€r alla friska. Det Ă€r en lögn.
Vi behöver implementera stöd för percentiler som skulle visa att det finns lÄngsamma frÄgor som förbrukar resurser, och göra övervakningen mer acceptabel.
Det viktigaste Àr att vi vill ha version 1.0 (version 1.1 har redan slÀppts). Faktum Àr att Odyssey just nu Àr i version 1.0rc, det vill sÀga release candidate. Och alla de problem jag nÀmnde har ÄtgÀrdats i just den versionen, förutom minneslÀckorna.
Vad betyder version 1.0 för oss? Vi lanserar Odyssey pÄ vÄra databaser. Den fungerar redan nu pÄ vÄra databaser, men nÀr den nÄr punkten av 1 000 000 förfrÄgningar per sekund kan vi sÀga att detta Àr en releaseversion och det Àr en version vi kan kalla 1.0.
I communityt har flera personer bett om att version 1.0 ska inkludera paus och SCRAM. Men det skulle innebÀra att vi behöver lansera nÀsta version i produktion, eftersom varken SCRAM eller paus Ànnu har blivit integrerade. Men förmodligen kommer denna frÄga att lösas ganska snabbt.
Jag vÀntar pÄ era pull requests. Jag skulle ocksÄ gÀrna vilja höra vilka problem ni har med Bouncer. LÄt oss diskutera dem. Kanske kan vi implementera nÄgra funktioner som ni behöver.
Min del Àr nu avslutad, jag skulle gÀrna vilja höra er. Tack!
FrÄgor
Om jag sÀtter min application_name, kommer det att skickas korrekt, inklusive i transaction pooling i Odyssey?
I Odyssey eller i Bouncer?
I Odyssey. I Bouncer skickas det.
Vi kommer att göra en set.
Och om min verkliga anslutning hoppar mellan andra anslutningar, kommer den dÄ att överföras?
Vi kommer att göra en set av alla parametrar som anges i listan. Jag kan inte sÀga om application_name finns med i den listan. Det verkar som att jag sÄg den dÀr. Vi kommer att stÀlla in alla samma parametrar. Med en förfrÄgan gör setet allt som har stÀllts in av klienten vid start.
Tack, Andrey, för presentationen! Bra presentation! Jag Àr glad att Odyssey utvecklas snabbare och snabbare för varje minut. Jag önskar att vi ska kunna fortsÀtta sÄ hÀr. Vi har redan kontaktat er med en förfrÄgan om att ha multi data-source-anslutning, sÄ att Odyssey kan ansluta till olika databaser samtidigt, det vill sÀga master-slave, och sedan automatiskt efter failover ansluta till den nya master.
Ja, jag tror att jag minns den diskussionen. Just nu finns det flera lagringslösningar. Men det finns ingen vÀxling mellan dem. Vi mÄste pÄ vÄr sida frÄga servern om den fortfarande Àr aktiv och förstÄ att en failover har intrÀffat, vem som kommer att Äkalla pg_recovery. Jag har ett standardiserat sÀtt att förstÄ att vi inte har kommit till master. Och vi mÄste förstÄ detta pÄ nÄgot sÀtt genom felmeddelanden eller hur? Det vill sÀga, idén Àr intressant och den diskuteras. Skriv fler kommentarer. Om ni har arbetskraft som kan C, dÄ Àr det verkligen fantastiskt.
FrÄgan om skalning av repliker intresserar oss ocksÄ, eftersom vi vill göra adoption av replikerade kluster sÄ enkelt som möjligt för applikationsutvecklare. Men hÀr skulle jag vilja ha fler kommentarer, det vill sÀga hur man exakt gör det bra.
FrÄgan handlar ocksÄ om repliker. Det verkar som att ni har en master och flera repliker. Och det Àr klart att man ofta gÄr till master istÀllet för repliker nÀr det gÀller anslutningar, eftersom det kan finnas skillnader. Ni nÀmnde att skillnaderna i data kan vara sÄdana att det inte skulle tillfredsstÀlla ert företag och att ni inte skulle gÄ dit förrÀn den har replikats helt. Om ni inte har gÄtt dit pÄ lÀnge och sedan börjar, sÄ kommer de data ni behöver kanske inte vara omedelbart tillgÀngliga. Det vill sÀga, om vi hela tiden gÄr till master sÄ Àr cachen dÀr uppvÀrmd, medan cachen i repliken ligger lite efter.
Ja, det stÀmmer. I pcache kommer det inte finnas block av data som ni vill ha, i real cache kommer det inte finnas information om tabellerna som ni vill ha, i planerna kommer det inte finnas parserade frÄgor, överhuvudtaget ingenting.
Och nÀr ni har ett kluster och lÀgger till en ny replik, sÄ medan den startar, Àr den inte i bra skick, det vill sÀga den bygger upp sin cache.
Jag förstod idén. Den rÀtta metoden skulle vara att först köra en liten procentandel av förfrÄgningarna pÄ repliken, vilket skulle vÀrma upp cachen. Grovt sagt har vi en förutsÀttning att vi inte fÄr vara mer Àn 10 sekunder efter master. Och detta villkor ska inte aktiveras pÄ en gÄng, utan mjukt för vissa kunder.
Ja, öka vikten.
Det Àr en bra idé. Men först behöver vi implementera denna avstÀngning. Först mÄste vi stÀnga av, och sedan tÀnker vi pÄ hur vi ska slÄ pÄ det. Det Àr en utmÀrkt funktion för att mjukt slÄ pÄ.
I nginx finns det ett sÄdant alternativ slowly start för serverklustret. Och den gradvis ökar belastningen.
Ja, utmÀrkt idé, vi ska prova nÀr vi nÄr dit.
KĂ€lla: habr.com
