Andrey Borodin előadásában elmeséli, hogyan vették figyelembe a PgBouncer skálázás tapasztalatait a kapcsolati pooler tervezése során , hogyan terjesztették ki a gyártásban. Ezen kívül megvitatjuk, hogy a pooler milyen funkcióit szeretnénk látni az új verziókban: fontos számunkra, hogy ne csak az igényeinket fedezzük, hanem a felhasználói közösség fejlesztését is .
videók:
Sziasztok! A nevem Andrew.
A Yandexnél nyílt forráskódú adatbázisokat fejlesztek. És ma van egy témánk a Connection Pooler kapcsolatokról.
Ha tudja, hogyan kell oroszul hívni a connection poolert, akkor mondja meg. Nagyon szeretnék egy jó szakkifejezést találni, amelyet a szakirodalomban meg kell határozni.
A téma elég bonyolult, mert sok adatbázisban be van építve a connection pooler, és nem is kell róla tudni. Néhány beállítás természetesen mindenhol megtalálható, de a Postgresben ez nem működik. Ezzel párhuzamosan (a HighLoad++ 2019-ben) megjelenik Nikolai Samokhvalov jelentése a Postgres lekérdezések beállításáról. És megértem, hogy olyanok jöttek ide, akik már tökéletesen konfigurálták a kéréseket, és ezek olyan emberek, akik ritkább rendszerproblémákkal szembesülnek a hálózattal, erőforrás-kihasználással kapcsolatban. És bizonyos helyeken ez elég nehéz lehet abból a szempontból, hogy a problémák nem nyilvánvalóak.
A Yandex rendelkezik Postgres-szel. Számos Yandex szolgáltatás a Yandex.Cloudban található. És több petabájtnyi adatunk van, amelyek másodpercenként legalább egymillió kérést generálnak a Postgresben.
És egy meglehetősen tipikus fürtöt biztosítunk minden szolgáltatáshoz - ez a csomópont fő elsődleges csomópontja, a szokásos két replika (szinkron és aszinkron), biztonsági mentés, olvasási kérések skálázása a replikán.
Mindegyik fürtcsomópont Postgres, amelyre a Postgres és a figyelőrendszerek mellett egy kapcsolati gyűjtő is telepítve van. A Connection pooler kerítésre és fő céljára szolgál.
Mi a kapcsolati pooler fő célja?
A Postgres egy folyamatmodellt alkalmaz az adatbázisokkal való munkavégzéshez. Ez azt jelenti, hogy egy kapcsolat egy folyamat, egy Postgres háttérrendszer. És nagyon sok különböző gyorsítótár található ebben a háttérrendszerben, amelyeket meglehetősen költséges a különböző kapcsolatokhoz különböző módon elkészíteni.
Ezenkívül a Postgres kódban van egy procArray nevű tömb. Alapvető adatokat tartalmaz a hálózati kapcsolatokról. És szinte minden procArray feldolgozó algoritmus lineáris összetettségű, a hálózati kapcsolatok teljes tömbjén fut végig. Ez egy elég gyors ciklus, de több bejövő hálózati kapcsolattal a dolgok egy kicsit drágábbak lesznek. És amikor a dolgok egy kicsit drágulnak, akkor a végén nagyon magas árat kell fizetnie nagyszámú hálózati kapcsolatért.
3 lehetséges megközelítés létezik:
- Az alkalmazás oldalán.
- Az adatbázis oldalán.
- És a között, vagyis az összes lehetséges kombináció között.
Sajnos a beépített pooler jelenleg fejlesztés alatt áll. Leginkább a PostgreSQL Professional barátai csinálják ezt. Hogy mikor jelenik meg, nehéz megjósolni. És valójában két megoldásunk van az építész kiválasztására. Ezek az alkalmazásoldali készlet és a proxykészlet.
Az alkalmazásoldali medence a legegyszerűbb módja. És szinte az összes kliens-illesztőprogram lehetőséget biztosít Önnek: több millió kapcsolatát a kódban az adatbázishoz fűződő néhány tucat kapcsolatként ábrázolhatja.
Probléma van azzal a ténnyel, hogy egy bizonyos ponton méretezni szeretné a háttérrendszert, és sok virtuális gépre szeretné telepíteni.
Aztán mégis rájössz, hogy van még több rendelkezésre állási zóna, több adatközpont. Az ügyféloldali pooling megközelítés pedig nagy számokhoz vezet. A nagyok körülbelül 10 000 kapcsolattal rendelkeznek. Ez egy olyan él, amely jól működik.
Ha a proxy poolerekről beszélünk, akkor van két pooler, akik sok mindenre képesek. Nem csak poolozók. Ezek poolerek + több menő funkció. Ez и .
De sajnos nem mindenkinek van szüksége erre a kiegészítő funkcióra. És ez oda vezet, hogy a poolerek csak a session pooling-et támogatják, azaz egy bejövő klienst, egy kimenő klienst az adatbázisba.
Ez nem nagyon alkalmas a mi feladatainkra, ezért a PgBouncer-t használjuk, amely tranzakciós poolingot valósít meg, azaz a szerverkapcsolatok csak a tranzakció idejére vannak leképezve kliens kapcsolatokra.
És a mi terhünkön – ez igaz. De van több probléma is.
A problémák akkor kezdődnek, amikor egy munkamenetet diagnosztizálni szeretne, mivel minden bejövő kapcsolat helyi. Mindenki loopback-el érkezett, és valahogy nehéz lesz nyomon követni a munkamenetet.
Természetesen használhatja az application_name_add_host parancsot. Ez a Bouncer oldali módja annak, hogy IP-címet adjon az alkalmazásnévhez. De az alkalmazás_nevet egy további kapcsolat állítja be.
Ezen a diagramon, ahol a sárga vonal a valós kéréseket jelzi, a kék vonal pedig az adatbázisba berepülő kéréseket. Ez a különbség pedig éppen az alkalmazás_neve beállítása, ami csak a nyomkövetéshez szükséges, de egyáltalán nem ingyenes.
Ezenkívül a Bouncer nem korlátozhat egy készletet, azaz a felhasználónkénti adatbázis-kapcsolatok számát adatbázisonként.
Mihez vezet ez? Van egy betöltött szolgáltatás C ++-ban, és valahol a közelben egy kis szolgáltatás egy csomóponton, amely nem csinál semmi szörnyűt az alappal, de a meghajtója megőrül. 20 000 kapcsolatot nyit meg, és minden más várni fog. Még a kódod is helyes.
Természetesen írtunk egy kis javítást a Bouncerhez, amely hozzáadta ezt a beállítást, azaz korlátozta a klienseket a készletben.
Ezt a Postgres oldalon lehetne megtenni, vagyis korlátozni a szerepeket az adatbázisban a kapcsolatok számára.
Ekkor azonban elveszíti a képességét, hogy megértse, miért nincs kapcsolata a szerverrel. A PgBouncer nem dob csatlakozási hibát, mindig ugyanazt az információt adja vissza. És nem értheti: talán megváltozott a jelszava, lehet, hogy az adatbázis egyszerűen leállt, lehet, hogy valami nincs rendben. De nincs diagnózis. Ha a munkamenetet nem lehet létrehozni, akkor nem fogja tudni, hogy miért nem lehet megtenni.
Egy bizonyos ponton megnézi az alkalmazás grafikonjait, és azt látja, hogy az alkalmazás nem működik.
Nézze meg a tetejét, és nézze meg, hogy a Bouncer egyszálú. Ez egy fordulópont a szolgáltatás életében. Megérti, hogy másfél év alatt készült az adatbázis méretezésére, és skáláznia kell a poolert.
Arra a következtetésre jutottunk, hogy több PgBouncerre van szükségünk.
A Bouncer kissé foltozva lett.
És megcsinálták, hogy a TCP port újrafelhasználásával több Bouncer is nevelhető legyen. És már az operációs rendszer automatikusan továbbítja közöttük a bejövő TCP kapcsolatokat kör-robin'om segítségével.
Ez átlátható a kliensek számára, vagyis úgy tűnik, hogy egy Bouncer van, de a futó Bouncer-ok közötti tétlen kapcsolatok töredezettek.
És egy ponton észreveheti, hogy ez a 3 kidobó 100%-ban megeszi a magját. Jó néhány kidobó kell hozzá. Miért?
Mert TLS-ed van. Titkosított kapcsolata van. Ha pedig összehasonlítja a Postgres-t TLS-sel és anélkül, azt tapasztalhatja, hogy a létrehozott kapcsolatok száma majdnem két nagyságrenddel csökken, ha a titkosítás engedélyezve van, mivel a TLS kézfogás CPU-erőforrásokat fogyaszt.
A tetején pedig jó néhány kriptográfiai funkciót láthat, amelyek a bejövő kapcsolatok hulláma során futnak le. Mivel elsődlegesünk képes váltani a rendelkezésre állási zónák között, a bejövő kapcsolatok hulláma meglehetősen tipikus helyzet. Vagyis valamiért a régi elsődleges nem volt elérhető, a teljes terhelés egy másik adatközpontba került. Mindannyian egyszerre jönnek köszönni a TLS-nek.
A nagyszámú TLS-kézfogás pedig már nem is köszönti Bouncert, hanem összeszorítja a torkát. A bejövő kapcsolatok hulláma csillapítatlanná válhat az időtúllépés miatt. Ha exponenciális visszalépés nélkül próbálkozik újra az alappal, akkor nem jönnek vissza újra és újra egy koherens hullámban.
Íme egy példa 16 PgBouncerre, amelyek 16 magot töltenek be 100%-osan.
Megérkeztünk a lépcsőzetes PgBouncer-hoz. Ez a legjobb konfiguráció, amit a Bouncer terhelésünkön elérhetünk. Külső kidobóink a TCP-kézfogást szolgálják, a belső kidobóink pedig a valódi poolingot szolgálják, hogy a külső kapcsolatokat ne törjék szét nagymértékben.
Ebben a konfigurációban lehetséges a lágy újraindítás. Egyenként újraindíthatja ezt a 18 kidobót. De egy ilyen konfiguráció fenntartása meglehetősen nehéz. A rendszergazdák, a DevOps és azok az emberek, akik valóban felelősek ezért a szerverért, nem lesznek nagyon elégedettek ezzel a sémával.
Úgy tűnik, hogy minden fejlesztésünket elő lehet mozdítani nyílt forráskódban, de a Bouncer nem támogatja túl jól. Például egy hónapja engedélyezték több PgBouncer futtatásának lehetőségét ugyanazon a porton. Néhány évvel ezelőtt volt egy lehívási kérelem ezzel a funkcióval.
Vagy még egy példa. A Postgresben törölhet egy futó kérést, ha elküldi a titkot egy másik kapcsolatnak, extra hitelesítés nélkül. Néhány kliens azonban egyszerűen TCP-reset-et küld, azaz megszakítja a hálózati kapcsolatot. Mit fog ezzel kezdeni Bouncer? Nem tesz semmit. Továbbra is végrehajtja a kérést. Ha nagyszámú kapcsolatot kapott, amelyek kis kérésekkel alapozták meg, akkor nem lesz elég egyszerűen leválasztani a kapcsolatot a Bouncer-ról, továbbra is teljesítenie kell azokat a kéréseket, amelyek az adatbázisban futnak.
Ezt kijavították, és a probléma még mindig nincs beolvasztva a Bouncer upstream rendszerébe.
És így arra a következtetésre jutottunk, hogy szükségünk van egy saját connect-poolerre, amit fejlesztenek, foltoznak, amiben gyorsan lehet majd javítani a problémákat és aminek természetesen többszálasnak kell lennie.
Fő feladatként a többszálas megoldást tűztük ki. Jól kell tudnunk kezelni a bejövő TLS-kapcsolatok hullámát.
Ehhez külön könyvtárat kellett kifejlesztenünk Machinarium néven, amely egy hálózati kapcsolat gépállapotait hivatott leírni soros kódként. Ha megnézi a libpq forráskódját, meglehetősen összetett hívásokat fog látni, amelyek visszaadhatják az eredményt, és azt mondják: "Hívjon egy kicsit később. Jelenleg IO-m van, de amikor az IO átmegy, leterhelem a processzort. És ez egy többszintű rendszer. A hálózati interakciót általában egy állapotgép írja le. Rengeteg szabály, mint például: "Ha korábban N méretű csomag fejlécet kaptam, akkor most N bájtra várok", "Ha SYNC csomagot küldtem, akkor most egy eredmény metaadatokkal rendelkező csomagot várok." Kiderült, hogy egy meglehetősen nehéz, intuitív, ellentétes kód, mintha a labirintust vonalszkenneléssé alakították volna át. Megcsináltuk, hogy az állapotgép helyett a programozó a fő interakciós útvonalat közönséges felszólító kód formájában írja le. Ebben a kötelező kódban olyan helyeket kell beszúrni, ahol a végrehajtási szekvenciát meg kell szakítani azáltal, hogy várakozik a hálózatról érkező adatokra, és átadja a végrehajtási környezetet egy másik korutinnak (zöld szál). Ez a megközelítés hasonlít ahhoz, hogy a labirintusban a leginkább elvárt utat sorban felírjuk, majd ágakat adunk hozzá.
Ennek eredményeként van egy szálunk, amely elfogadja a TCP-t, és a kör-robin átadja a TPC-kapcsolatot sok dolgozónak.
Ebben az esetben minden ügyfélkapcsolat mindig egy processzoron fut. Ez pedig lehetővé teszi, hogy gyorsítótár-baráttá tegye.
Ezenkívül kissé javítottuk a kis csomagok egyetlen nagy csomaggá történő gyűjtését, hogy tehermentesítsük a rendszer TCP-veremét.
Ezen túlmenően továbbfejlesztettük a tranzakciós összegyűjtést abban az értelemben, hogy az Odyssey, ha be van állítva, küldhet CANCEL és ROLLBACK parancsot hálózati kapcsolat meghibásodása esetén, azaz ha senki sem várja a kérést, az Odyssey közli az adatbázissal, hogy ne próbálja meg teljesíteni. a kérés, amely értékes erőforrásokat veszíthet el.
És amikor csak lehetséges, ugyanahhoz az ügyfélhez tartjuk a kapcsolatot. Ezzel elkerülhető, hogy újra telepítse az application_name_add_host. Ha lehetséges, akkor nincs lehetőségünk a diagnosztikához szükséges paraméterek további visszaállítására.
A Yandex.Cloud érdekében dolgozunk. Ha pedig felügyelt PostgreSQL-t használ, és telepítve van egy kapcsolat-gyűjtő, akkor létrehozhat kifelé irányuló logikai replikációt, azaz ha akarja, hagyjon minket a logikai replikáció használatával. A logikai replikáció folyamán kívüli kidobó nem ad.
Ez egy példa a logikai replikáció beállítására.
Ezenkívül támogatjuk a fizikai replikációt is. A Felhőben persze ez lehetetlen, mert akkor a klaszter túl sok információt ad magáról. De az Ön telepítéseiben, ha fizikai replikációra van szüksége az Odyssey kapcsolattárolóján keresztül, ez lehetséges.
Az Odyssey teljes mértékben kompatibilis a PgBouncer felügyelettel. Ugyanaz a konzolunk van, amely szinte az összes ugyanazt a parancsot hajtja végre. Ha valami hiányzik, küldjön lehívási kérelmet, vagy legalábbis probléma van a GitHubon, mi teljesítjük a szükséges parancsokat. De már megvan a PgBouncer konzol fő funkciója.
És természetesen van hibatovábbításunk is. A bázis által jelentett hibát visszaküldjük. Információkat kapsz arról, hogy miért nem vagy a bázison, nem csak arról, hogy nem vagy benne.
Ez a funkció le van tiltva, ha 100%-os kompatibilitásra van szüksége a PgBouncer-rel. Úgy viselkedhetünk, mint a Bouncer, minden esetre.
tervezés
Néhány szó az Odyssey forráskódjáról.
Például vannak "Szünet / Folytatás" parancsok. Általában az adatbázis frissítésére használják őket. Ha frissítenie kell a Postgres-t, szüneteltetheti azt a kapcsolattárolóban, végrehajthat egy pg_upgrade-et, majd folytathatja. A kliens oldalról pedig úgy tűnik, mintha az adatbázis lelassult volna. Ezt a funkciót a közösségből származó emberek hozták nekünk. Még nem halt meg, de hamarosan minden meglesz. (már halott)
- már halott
Ráadásul a PgBouncer egyik újdonsága a SCRAM Authentication támogatás, amit szintén egy olyan személy hozott el hozzánk, aki nem a Yandex.Cloudban dolgozik. Mindkettő összetett funkció és fontos.
Ezért szeretném elmondani, hogy miből van az Odyssey, hátha te is szeretnél most valami kódot írni.
Megvan az eredeti Odyssey bázis, amely két fő könyvtárra támaszkodik. A Kiwi könyvtár a Postgres üzenetprotokoll megvalósítása. Vagyis a Postgres natív proto 3 szabványos üzenetek, amelyeket a frontendek és a háttérrendszerek cserélhetnek. Ezeket a Kiwi könyvtárban valósítják meg.
A Machinarium könyvtár egy szál megvalósítási könyvtár. Ennek a Machinariumnak egy kis töredéke assemblerben van írva. De ne aggódj, csak 15 sor van.
Odyssey építészet. Van egy fő gép, amely korutinokat futtat. Ez a gép a bejövő TCP-kapcsolatok fogadását és a dolgozók közötti elosztást valósítja meg.
Egy dolgozón belül több ügyfél kezelője is dolgozhat. És a főszálban is pörög a konzol és a crone feladatok feldolgozása a készletben már nem szükséges kapcsolatok eltávolítására.
Az Odyssey tesztelése a szabványos Postgres tesztkészlettel történik. Csak futtatjuk az install-check-et a Bounceren és az Odyssey-n keresztül, kapunk egy null div-t. Számos teszt kapcsolódik a dátum formázásához, amelyek pontosan ugyanúgy kudarcot vallanak a Bouncer és az Odyssey esetében.
Ezen kívül számos illesztőprogram rendelkezik saját teszteléssel. És az ő teszteiket használjuk az Odyssey tesztelésére.
Ezenkívül a lépcsőzetes konfigurációnk miatt különböző csomagokat kell tesztelnünk: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, hogy megbizonyosodjunk arról, hogy ha az Odyssey a kaszkád valamelyik részében van, akkor is a várt módon működik. .
gereblye
A gyártás során az Odyssey-t használjuk. És nem lenne igazságos, ha azt mondanám, hogy minden működik. Nem, azaz igen, de nem mindig. Például a termelésben minden működött, aztán jöttek a PostgreSQL Professional barátaink és közölték, hogy memóriaszivárgás történt. Tényleg azok voltak, kijavítottuk őket. De egyszerű volt.
Ezután azt találtuk, hogy a kapcsolattárolónak vannak bejövő TLS-kapcsolatai és kimenő TLS-kapcsolatai. A kapcsolatokhoz pedig ügyféltanúsítványok és szervertanúsítványok szükségesek.
A Bouncer és Odyssey szervertanúsítványokat a pcache újraolvassa, de az ügyféltanúsítványokat nem kell újraolvasni a pcache-ből, mert a méretezhető Odyssey-nk végül a tanúsítvány beolvasásának rendszerteljesítményén múlik. Ez meglepetésként ért minket, mert nem pihent azonnal. Eleinte lineárisan skálázott, majd 20 000 bejövő egyidejű kapcsolat után ez a probléma megmutatkozott.
A Pluggable Authentication Method a beépített lunux eszközökkel történő hitelesítés képessége. A PgBouncerben ez úgy van megvalósítva, hogy van egy külön szál, amely a PAM válaszára vár, és van egy fő PgBouncer szál, amely kiszolgálja az aktuális kapcsolatot, és megkérheti őket, hogy éljenek a PAM szálban.
Ezt egyetlen egyszerű okból nem hajtottuk végre. Sok patakunk van. Miért van rá szükségünk?
Ennek eredményeként ez problémákat okozhat, mivel ha rendelkezik PAM hitelesítéssel és nem PAM hitelesítéssel, akkor a PAM hitelesítés nagy hulláma jelentősen késleltetheti a nem PAM hitelesítést. Ez az egyik olyan dolog, amit nem javítottunk ki. De ha meg akarja javítani, megteheti.
Egy másik rakás az volt, hogy van egy szálunk, amely minden bejövő kapcsolatot elfogad. Ezután átkerülnek a dolgozói csoportba, ahol a TLS kézfogásra kerül sor.
Ennek eredményeként, ha van egy 20 000 hálózati kapcsolatból álló koherens hullám, akkor mindegyiket elfogadjuk. A kliens oldalon pedig a libpq elkezdi jelenteni az időtúllépéseket. Alapértelmezés szerint 3 másodperc van ott.
Ha nem léphetnek be egyszerre mind a bázisra, akkor nem léphetnek be a bázisra, mert mindezt egy nem exponenciális újrapróbálkozás fedheti le.
Végül a PgBouncer sémát másoltuk ide, hogy korlátozzuk az elfogadott TCP-kapcsolatok számát.
Ha azt látjuk, hogy fogadunk kapcsolatokat, de a végén nincs idejük kézfogásra, akkor sorba tesszük őket, hogy ne fogyasztják a CPU erőforrásokat. Ez azt eredményezi, hogy egyidejű kézfogás nem hajtható végre minden megérkezett kapcsolatnál. De legalább valaki belép az adatbázisba, még akkor is, ha elég erős a terhelés.
ütemterv
Mit szeretnél látni a jövőben az Odüsszeában? Miben vagyunk készek magunkat fejleszteni, és mit várunk el a közösségtől?
2019 augusztusára.
Így nézett ki az Odüsszea útiterve augusztusban:
- SCRAM és PAM hitelesítést akartunk.
- Az olvasási kérelmeket készenléti állapotba akartuk továbbítani.
- Online újraindítást szeretnék.
- És a szünet lehetőség a szerveren.
Ennek az ütemtervnek a fele elkészült, és nem mi. És ez jó. Tehát beszéljük meg, mi maradt, és adjunk hozzá még többet.
? Vannak olyan másolataink, amelyek a kérések teljesítése nélkül egyszerűen felmelegítik a levegőt. Szükségünk van rájuk a feladat- és átállás biztosításához. Valamelyik adatközpontban felmerülő probléma esetén hasznos munkával szeretném felvenni. Ugyanazokat a központi processzorokat, memóriát nem tudjuk másképp konfigurálni, mert a replikáció egyébként nem fog működni.
Elvileg a Postgres-ben 10-től kezdve lehetőség van a session_attrs megadására csatlakozáskor. Felsorolhatja a kapcsolat összes adatbázis-állomását, és elmondhatja, miért megy az adatbázisba: írás vagy csak olvasható. Az illesztőprogram pedig maga választja ki a listából a számára legjobban tetsző első gazdagépet, amely megfelel a session_attrs követelményeinek.
Ezzel a megközelítéssel azonban az a probléma, hogy nem szabályozza a replikációs késést. Előfordulhat, hogy olyan másolata van, amely a szolgáltatása számára elfogadhatatlan idő miatt elmaradt. Annak érdekében, hogy egy replikán teljes értékű olvasási kérelmet hajthassunk végre, valójában támogatnunk kell az Odyssey-ben azt a képességet, hogy ne működjön, amikor az olvasás lehetetlen.
Az Odyssey-nek időnként fel kell lépnie az adatbázisba, és meg kell kérdeznie az elsődlegestől való replikációs távolságot. És ha elérte a korlátot, ne engedjen be új kéréseket az adatbázisba, mondja meg az ügyfélnek, hogy újra kell kezdeményeznie a kapcsolatokat, és esetleg válasszon másik gazdagépet a kérések végrehajtásához. Ez lehetővé teszi az adatbázis számára, hogy gyorsan visszaállítsa a replikációs késést, és ismét visszatérjen, hogy válaszoljon egy lekérdezéssel.
A megvalósítás dátumait nehéz megnevezni, mert nyílt forráskódú. De remélem, nem 2,5 év, mint a PgBouncer kollégái. Ezt a funkciót szeretném látni az Odysseyben.
. Most kétféleképpen hozhat létre előkészített kimutatást. Először is végrehajthat egy SQL parancsot, nevezetesen a "prepared" parancsot. Ahhoz, hogy megértsük ezt az SQL-parancsot, meg kell tanulnunk az SQL megértését a Bouncer oldalon. Ez túlzás lenne, mert túlzás, mivel szükségünk van a teljes elemzőre. Nem tudunk minden SQL parancsot elemezni.
De van egy előkészített utasítás üzenetprotokoll szinten a proto3-on. És ez az a hely, amikor strukturált formában érkezik az információ, hogy az elkészített kimutatás készül. És támogathatnánk annak megértését, hogy bizonyos szerverkapcsolaton a kliens előkészített utasítások létrehozását kérte. És még ha a tranzakció lezárul is, továbbra is kapcsolatban kell maradnunk a szerverrel és a klienssel.
De itt van egy eltérés a párbeszédben, mert valaki azt mondja, hogy meg kell érteni, hogy a kliens mely előkészített kimutatásokat hozott létre, és meg kell osztani a szerverkapcsolatot az összes kliens között, akik létrehozták ezt a szerverkapcsolatot, azaz kik készítettek ilyen előkészített kimutatást.
Andres Freund azt mondta, hogy ha olyan ügyfél érkezik hozzád, aki már készített ilyen előkészített nyilatkozatot egy másik szerverkapcsolaton, akkor hozd létre neki. Kicsit hibásnak tűnik azonban a lekérdezéseket az adatbázisban végrehajtani a kliens helyett, de az adatbázissal való interakció protokollját író fejlesztő szempontjából kényelmes lenne, ha egyszerűen hálózati kapcsolatot adna neki. akinek ilyen előkészített kérése van.
És még egy funkció, amelyet végre kell hajtanunk. Mostantól kompatibilis a monitorozás a PgBouncer-rel. Visszaadhatjuk a lekérdezés átlagos végrehajtási idejét. De az átlagos idő a kórházi átlaghőmérséklet: valaki fázik, valaki meleg - átlagosan mindenki egészséges. Ez nem igaz.
Be kell vezetnünk a percentilisek támogatását, ami azt jelezné, hogy vannak lassú kérések, amelyek erőforrásokat fogyasztanak, és elfogadhatóbbá tennék a monitorozást.
A legfontosabb, hogy 1.0-s verziót szeretnék (az 1.1-es verzió már megjelent). Az tény, hogy most az Odyssey az 1.0rc verzióban van, azaz kiadásjelöltben. És az összes rake, amit felsoroltam, pontosan ugyanazzal a verzióval lett javítva, kivéve a memóriaszivárgást.
Mit jelent számunkra az 1.0-s verzió? Az Odyssey-t kigurítjuk bázisainkra. Már fut az adatbázisainkon, de amikor eléri a másodpercenkénti 1 000 000 kérést, akkor azt mondhatjuk, hogy ez egy kiadási verzió, és ez egy 1.0-s verzió.
A közösségben többen több szünetet és SCRAM-ot kértek az 1.0-s verzióban. Ez azonban azt jelenti, hogy a következő verziót élesre kell terjesztenünk, mert sem a SCRAM-ot, sem a pause-t még nem egyesítették. De valószínűleg ez a probléma meglehetősen gyorsan megoldódik.
Várom a kérését. És azt is szeretném hallani, hogy milyen problémái vannak a Bouncerrel. Beszéljük meg őket. Talán megvalósíthatunk néhány funkciót, amire szüksége van.
Ezzel befejezem a részem, szeretném hallani a véleményedet. Köszönöm!
kérdések
Ha megadom a saját application_name-emet, akkor helyesen lesz dobva, beleértve az Odyssey tranzakciós összevonását is?
Odyssey vagy Bouncer?
Az Odüsszeában. A Bouncer dobott.
Készítünk egy készletet.
És ha a valós kapcsolatom átugrik más kapcsolatokon, akkor átküldik?
Készítünk egy készletet az összes felsorolt paraméterből. Nem tudom megmondani, hogy az alkalmazás_neve szerepel-e ebben a listában. Úgy tűnik, ott látta őt. Ugyanazokat a paramétereket állítjuk be. Egy kéréssel a készlet mindent megtesz, amit az ügyfél az indításkor telepített.
Köszönöm Andrey a beszámolót! Jó beszámolót! Örülök, hogy az Odyssey percről percre gyorsabban és gyorsabban fejlődik. Ugyanezt szeretném folytatni. Már kértük, hogy legyen több adatforrású kapcsolat, hogy az Odyssey egyszerre tudjon csatlakozni különböző adatbázisokhoz, azaz a slave masterhez, majd egy feladatátvétel után automatikusan csatlakozzon az új masterhez.
Igen, úgy tűnik, emlékszem arra a vitára. Most több tároló is van. De nincs közöttük váltás. A mi oldalunkon le kell kérdeznünk a szervert, hogy még mindig életben van-e, és meg kell értenünk, hogy feladatátvétel történt, aki meghívja a pg_recovery-t. Van egy standard módja annak megértésére, hogy nem a mesterhez jöttünk. És meg kell értenünk valahogy a hibákból, vagy hogyan? Vagyis az ötlet érdekes, megbeszélés alatt áll. Írj több megjegyzést. Ha olyan dolgozó kezei vannak, amelyek ismerik a C-t, akkor ez általában csodálatos.
A replikák közötti skálázás kérdése azért is érdekel bennünket, mert szeretnénk a replikált fürtök átvételét a lehető legegyszerűbbé tenni az alkalmazásfejlesztők számára. De itt több hozzászólást kérnék, vagyis hogyan kell csinálni, hogyan kell jól csinálni.
A kérdés a replikákra is vonatkozik. Kiderült, hogy van egy mestere és több másolata. És egyértelmű, hogy a replikához ritkábban mennek, mint a masterhez a kapcsolatokért, mert lehet, hogy van különbség. Ön azt mondta, hogy az adatok közötti különbség akkora lehet, hogy az Ön vállalkozása nem fogja kielégíteni, és addig nem megy oda, amíg meg nem replikálják. Ugyanakkor, ha hosszú ideig nem járt oda, majd elkezdett menni, akkor a szükséges adatok nem lesznek azonnal elérhetőek. Vagyis ha állandóan a masterhez megyünk, akkor ott felmelegszik a gyorsítótár, és a gyorsítótár kicsit lemarad a replikában.
Igen ez igaz. A pcache-ben nem lesznek olyan adatblokkok, amelyeket akarsz, a valódi gyorsítótárban nem lesz információ a kívánt táblákról, nem lesznek elemzett lekérdezések a tervekben, semmi.
És amikor van valami fürt, és oda adsz egy új replikát, akkor amíg elindul, minden rossz benne, vagyis növeli a gyorsítótárát.
Megkaptam az ötletet. A helyes megközelítés az lenne, ha először a lekérdezések egy kis százalékát futtatnánk a replikán, ami felmelegítené a gyorsítótárat. Nagyjából egy feltételünk van, hogy legfeljebb 10 másodperccel maradjunk le a mestertől. Ezt a feltételt pedig nem egy hullámba kellene beletenni, hanem simán egyes ügyfeleknél.
Igen, növeld a súlyt.
Ez egy jó ötlet. De először végre kell hajtania ezt a leállítást. Először ki kell kapcsolnunk, majd átgondoljuk, hogyan kapcsoljuk be. Ez egy nagyszerű funkció a zökkenőmentes bekapcsoláshoz.
nginx rendelkezik ezzel a lehetőséggel slowly start a szerver fürtjében. És fokozatosan növeli a terhelést.
Igen, remek ötlet, kipróbáljuk, ha ráérünk.
Forrás: will.com