A jelentésben Andrej Borodin beszámol arról, hogyan vették figyelembe a PgBouncer méretezésének tapasztalatait a csatlakozási pooler tervezésekor , hogyan vezették be a termelésbe. Emellett megvitatjuk, hogy milyen funkciókat szeretnénk látni az új verziókban: számunkra fontos, hogy ne csak a saját igényeinket elégítsük ki, hanem fejlesszük a felhasználói közösséget .
Videó:
Mindenkinek üdvözlet! Andrásnak hívnak.
A Yandexnél nyílt forráskódú adatbázisok fejlesztésével foglalkozom. Ma a csatlakozási pooler témájáról fogunk beszélni.
Ha tudod, hogyan kell oroszul nevezni a csatlakozási poolert, mondd el nekem. Nagyon szeretnék találni egy jó technikai kifejezést, amelynek meg kellene állapodnia a technikai irodalomban.
A téma meglehetősen bonyolult, mert sok adatbázisban a csatlakozási pooler beépített, és erről nem is kell tudni. Vannak bizonyos beállítások, persze mindenhol, de a Postgres esetében ez nem működik. Csak közben (a HighLoad++ 2019-en) Nikolaj Szamohvalov előadása folyik a Postgres lekérdezések beállításáról. Úgy értem, ide azok az emberek jöttek, akik már tökéletesen beállították a lekérdezéseket, és ezek olyan emberek, akik ritkább rendszerproblémákkal szembesülnek, amelyek a hálózattal és az erőforrások kihasználásával kapcsolatosak. Helyenként ez meglehetősen bonyolult lehetett, mert a problémák nem nyilvánvalóak.
A Yandexben van Postgres. A Yandex.Cloud-ban sok Yandex szolgáltatás él. Van néhány petabájt adatunk, amelyek másodpercenként legalább egymillió lekérdezést generálnak a Postgresben.
Elég tipikus klasztert biztosítunk minden szolgáltatás számára - ez az alap primer csomópont, szokásos két replikával (szinkron és aszinkron), biztonsági mentéssel, a lekérdezések skálázásával a replikán.
Minden klasztercsomópont egy Postgres, amelyen kívül, azon kívül, hogy Postgres és a rendszerfigyelés fut, még egy csatlakozási pooler is telepítve van. A csatlakozási poolert fencing célokra és alapvető céljának megfelelően használják.
Mi a csatlakozási pooler alapvető célja?
A Postgresnél a folyamatmodelt alkalmazzák az adatbázis kezelésénél. Ez azt jelenti, hogy egy csatlakozás egy folyamat, egy Postgres backend. És ebben a backendben nagyon sok különböző cache található, amelyeket meglehetősen költséges külön csatlakozásokra elvégezni.
Továbbá a Postgres kódjában van egy tömb, amelyet procArray-nak hívnak. Ez tartalmazza a hálózati kapcsolatok alapvető adatait. Szinte minden procArray feldolgozó algoritmus lineáris időbeli összetettséggel bír, végigfut az egész hálózati kapcsolatok tömbjén. Ez egy viszonylag gyors ciklus, de nagy számú bejövő hálózati kapcsolattal minden kicsit drágábbá válik. És amikor minden egy kicsit drágábbá válik, végül egy nagyon magas árat fizethet egy nagy számú hálózati kapcsolatért.
Három lehetséges megközelítés létezik:
- Alkalmazásoldalon.
- Adatbázis oldalon.
- És közöttük, azaz különböző kombinációk.
Sajnos az integrált pooler jelenleg fejlesztés alatt áll. A PostgreSQL Professional cégnél a barátok főként ezzel foglalkoznak. Amikor megjelenik, nehéz megmondani. Valójában az architektának két megoldása van: az alkalmazásoldali pool és a proxy pool.
Az alkalmazásoldali pool a legegyszerűbb megoldás. Szinte minden kliens driver módot kínál arra, hogy a milliónyi kapcsolódást a kódban néhány tucat adatbázis kapcsolatként mutassa be.
Felmerül a probléma, hogy bizonyos ponton skalázni szeretné a backendet, több virtuális gépre szeretné telepíteni.
Akkor még azt is észleli, hogy több elérhetőségi zónája van, több adatközpontja. Az ügyféloldali pooling megközelítés nagy számokhoz vezet. Nagy számok alatt körülbelül 10 000 kapcsolatot értünk. Ez a határ, ami normálisan működik.
Ha proxy poolerekről beszélünk, két olyan pooler létezik, amelyek sok mindent tudnak. Ezek nem csak poolerek. Ezek poolerek + egy kis extra funkciók. Ezek a következők: és .
De sajnos ez az extra funkció nem mindenkinek szükséges. Ezért az poolerek csak a sessziós poolingot támogatják, azaz egy bejövő kliens és egy kimenő kliens a adatbázishoz.
A mi feladatainkhoz ez nem igazán alkalmas, ezért a PgBouncerrt használjuk, amely tranzakciós poolingot valósít meg, azaz a szerver kapcsolatok a kliens kapcsolatokhoz csak a tranzakció idejére állnak párhuzamosan.
És a mi terhelésünknél - ez igaz. De van néhány probléma..
A problémák akkor kezdődnek, amikor diagnosztizálni szeretné a sessziót, mert minden bejövő kapcsolat helyi. Minden egy loopback-ről érkezett, és így a sesszió nyomozása nehézzé válik.
Természetesen használhatja az application_name_add_host-t. Ez egy módszer a Bouncer oldalán, hogy IP-címet adjon hozzá az application_name-hez. Az application_name azonban egy további kapcsolaton állítódik be.
Ez a grafikon azt mutatja, hogy a sárga vonal a valós kéréseket, míg a kék vonal a dolgok adatbázisába érkező kéréseket jelzi. Ez a különbség az application_name beállításából származik, amely csak a nyomkövetéshez szükséges, de egyáltalán nem ingyenes.
Ezen kívül a Bouncer nem korlátozhat egy pool-t, azaz a kapcsolatokat az adatbázishoz egy meghatározott felhasználóhoz, egy meghatározott adatbázishoz.
Hova vezet ez? Van egy túlterhelt szolgáltatás C++-ban, és valahol mellette egy apró szolgáltatás Node-ban, ami nem csinál semmi csúnyát az adatbázissal, de a drivere őrületbe kergeti. Megnyit 20 000 kapcsolatot, míg minden más várakozik. A kódja rendben van.
Természetesen írtunk egy kis javítást a Bouncer-hez, ami hozzáadta ezt a beállítást, azaz a kliensek korlátozását a pool-ra.
Ezt meg lehetett volna csinálni a Postgres oldalán is, azaz az adatbázis szerepeit a kapcsolatok számával korlátozni.
De akkor elveszíti a lehetőséget, hogy megértse, miért nincsenek kapcsolatai a szerverhez. A PgBouncer nem továbbítja a kapcsolat hibáját, mindig ugyanazt az információt adja vissza. És nem tudhatja, lehet, hogy megváltozott a jelszó, lehet, hogy egyszerűen az adatbázis megrogyott, lehet, hogy valami probléma van. De diagnosztika egyáltalán nincs. Ha egy session nem állítható be, sosem fogja megtudni, miért nem.
Egy adott pillanatban ránéz az alkalmazás grafikonjaira, és látja, hogy az alkalmazás nem működik.
Meghúzza a tetejet, és látja, hogy a Bouncer egy szálú. Ez a szolgáltatás életének fordulópontja. Rájön, hogy másfél évre készültek az adatbázis skálázására, de most a pooler skálázását kell elvégezniük.
Arra a következtetésre jutottunk, hogy szükségünk van több PgBouncer-ra.
Egy kicsit javítgattuk a Bouncert.
Úgy módosítottuk, hogy több Bouncer indítható legyen újrafelhasználva a TCP-portot. Az operációs rendszer automatikusan round-robin módon áthelyezi az összes bejövő TCP-kapcsolatot közöttük.
Ez átlátható a kliensek számára, azaz minden úgy néz ki, mintha csak egy Bouncer lenne, de a futó Bouncerek között az inaktív kapcsolatok fragmentálódnak.
És bizonyos pillanatokban észreveheti, hogy ezek a 3 Bouncer mind a saját magjának 100%-át felhasználja. Számos Bouncerre van szüksége. Miért?
Mert Önnek TLS-e van. Van titkosított kapcsolata. Ha tesztel egy Postgres-t TLS-sel és TLS nélkül, észre fogja venni, hogy a létesített kapcsolatok száma csaknem két nagyságrenddel csökken a titkosítás bekapcsolásával, mivel a TLS kézfogás CPU-erőforrást fogyaszt.
Fent sok kriptográfiai függvény látható, amelyek végrehajtásra kerülnek, amikor bejövő kapcsolatok hulláma érkezik. Mivel a primary-nk váltogathat a rendelkezésre állási zónák között, a bejövő kapcsolatok hulláma egy meglehetősen tipikus helyzet. Tehát valamilyen okból a régi primary nem volt elérhető, az összes terhelést egy másik adatközpontra küldték. Mindannyian egyszerre érkeznek, hogy üdvözöljék a TLS-t.
És a nagy számú TLS kézfogás már nem üdvözölheti a Bouncert, hanem szorítja a torkát. A timeout miatt a bejövő kapcsolatok hulláma megszakíthatatlanná válhat. Ha Ön újrapróbálkozást alkalmaz az adatbázisban exponenciális visszafordítás nélkül, ezek újra és újra, koherens hullámban fognak érkezni.
Íme egy példa 16 PgBouncerre, amelyek 16 magot 100%-ra terhelnek.
Eljutottunk a kaszkádos PgBouncerhez. Ez a legjobb konfiguráció, amelyet elérhetünk a Bouncerrel végzett terhelésünk alatt. A külső Bouncerek TCP kézfogásra szolgálnak, míg a belső Bouncerek tényleges poolingra, hogy ne fragmentálják túlzottan a külső kapcsolatokat.
Ilyen konfigurációval sima újraindítás lehetséges. Ezeket a 18 Bouncert egyenként újra lehet indítani. De az ilyen konfiguráció fenntartása meglehetősen nehéz. A rendszergazdák, a DevOps és azok, akik valójában felelősek ezért a szerverért, nem fognak örülni ennek a sémának.
Úgy tűnhet, hogy az összes fejlesztésünket open source-ba lehetne helyezni, de a Bouncer nem kap jó támogatást. Például azt a lehetőséget, hogy több PgBouncert indítsunk egy porton, egy hónappal ezelőtt commitálták. A pull request e funkcióval kapcsolatban pedig már évek óta aktív.
Vagy egy másik példa. A Postgresben megszakíthatja a futó lekérdezést, ha egy titkosítást küld egy másik kapcsolaton, felesleges hitelesítés nélkül. De néhány kliens egyszerűen TCP-resetet küld, azaz megszakítja a hálózati kapcsolatot. Mit fog tenni a Bouncer ebben az esetben? Semmit. Folytatni fogja a lekérdezés végrehajtását. Ha rengeteg kapcsolat érkezett, amelyek kis lekérdezésekkel megterhelték az adatbázist, akkor csak a kapcsolat Bouncerrel való megszakítása nem elegendő, be kell fejezni azokat a lekérdezéseket is, amelyek az adatbázisban futnak.
Ezt javították, de ezt a problémát még nem illesztették be a Bouncer upstream-be.
Így eljutottunk oda, hogy szükségünk van egy saját connection poolerre, amely fejlődni fog, javítani lehet a problémákat, és természetesen több szálon futhat.
A több szálas működést alapvető feladattá tettük. Jól kell kezelni az incoming TLS kapcsolatok áramlását.
Ehhez ki kellett fejlesztenünk egy külön könyvtárat, amely Machinariumnak hívják, és amely a hálózati kapcsolat gépi állapotait szekvenciális kódként írja le. Ha megnézi a libpq forráskódját, elég bonyolult hívásokat lát, amelyek visszaadhatják az eredményt, és azt mondják: "Hívj vissza később. Most éppen IO folyamatban van, de amikor az IO befejeződik, a CPU számára terhelést fogok elvégezni." És ez egy több szintű séma. A hálózati interakciót általában állapotgépként írják le, számos szabállyal, mint például: "Ha korábban kaptam egy N méretű csomag fejlécét, most N bájtot várok", "Ha SYNC csomagot küldtem, most a válaszmetaadat-csomagot várom." Ez egy eléggé nehezen érthető kódot hoz létre, mintha egy labirintust lineáris kiterjesztéssé alakítanának. Úgy alakítottuk, hogy ahelyett, hogy állapotgépként a programozó a fő interakciós útvonalat szokásos imperatív kódként írja le. Csak ebben az imperatív kódban be kell illeszteni azokat a helyeket, ahol a végrehajtás sorrendét meg kell szakítani, hogy várakozzunk a hálózottól érkezett adatokra, átadva a végrehajtási kontextust egy másik korutinak (zöld szálnak). Ez a megközelítés hasonló ahhoz, hogy a labirintusban a legvártabb útvonalat egymás után írom, majd ezt bővítem elágazásokkal.
Végül is van egy folyamatunk, amely TCP acceptál és körkörösen elosztja a TPC-kapcsolatokat több worker között.
Ezért minden klienskapcsolat mindig egy processzoron működik. Ez lehetővé teszi, hogy cache-barát legyen.
Ezen kívül egy kicsit finomítottuk a kis csomagok egy nagy csomagba való összegyűjtését, hogy tehermentesítsük a rendszer TCP-stack-jét.
Továbbá javítottuk a tranzakciós poolingot abban az értelemben, hogy az Odyssey a beállított konfigurációval képes CANCEL és ROLLBACK küldésére, ha a hálózati kapcsolat megszakad, vagyis ha senki nem várja a kérés eredményét, az Odyssey közli az adatbázissal, hogy ne pazarolja az értékes erőforrásokat.
Ha lehetséges, próbáljuk meg megőrizni a kapcsolatokat ugyanazzal a klienssel. Ez lehetővé teszi az application_name_add_host újratelepítésének elkerülését. Ha ez lehetséges, nincsenek további beállítási paraméterek, amelyek szükségesek a diagnózishoz.
A Yandex.Cloud érdekeit képviseljük. Ha managed PostgreSQL-t használsz és van connection pooler beállítva, létrehozhatsz logikai replikációt kifelé, vagyis eljuthatsz tőlünk, ha úgy döntesz, logikai replikációval. A Bouncer nem küldi tovább a logikai replikációs folyamot kifelé.
Ez egy példa a logikai replikáció beállítására.
Ezen kívül van lehetőségünk fizikai replikáció támogatására kifelé. A felhőben ez természetesen lehetetlen, mert akkor a klaszter túl sok információt adna magáról. De a te telepítéseidben, ha fizikai replikációra van szükséged a connection pooler segítségével az Odyssey-ban, ez lehetséges.
Az Odyssey teljesen kompatibilis monitorozást kínál a PgBouncer-rel. Ugyanazt a konzolt használjuk, amely majdnem minden ugyanazt a parancsot végrehajtja. Ha valami hiányzik, küldj egy pull request-et vagy legalább egy issue-t a GitHub-ra, dolgozunk a szükséges parancsokon. De a PgBouncer konzol fő funkciói már megvannak.
Természetesen van error forwarding is. Visszaadjuk a hibát, amelyet az adatbázis közölt. Információt kapsz arról, hogy miért nem jutsz be az adatbázisba, nem csak azt, hogy nem jutsz be.
Ez a lehetőség kikapcsolható, ha 100%-os kompatibilitásra van szükséged a PgBouncer-rel. Úgy is viselkedhetünk, mint a Bouncer, csak a biztonság kedvéért.
Fejlesztés
Néhány szó az Odyssey forráskódjáról.
Például vannak a „Szünet / Folytatás” parancsok. Ezeket általában az adatbázis frissítésére használják. Ha frissíteni szeretné a Postgres-t, akkor megállíthatja a connection pooler-ben, végrehajthatja a pg_upgrade-t, majd folytathatja. Az ügyfél oldala számára ez úgy fog kinézni, mintha az adatbázis csak lelassult volna. Ezt a funkciót a közösség tagjai hozták nekünk. Még nem került beolvasztásra, de hamarosan minden rendben lesz. (Már beolvasztva)
— már beolvasztva
Ezen kívül az egyik új funkció a PgBouncer-ben a SCRAM Authentication támogatása, amelyet szintén egy olyan ember hozott, aki nem dolgozik a Yandex.Cloud-nál. Mindkettő - ez egy bonyolult funkció és fontos.
Ezért szeretnénk beszélni az Odyssey felépítéséről, hátha Ön is szeretne egy kicsit kódot írni.
Van egy alap Odyssey adatbázisunk, amely két fő könyvtárra támaszkodik. A Kiwi könyvtár a Postgres üzenetprotokoll megvalósítása. Azaz a natív proto 3 a Postgres számára - ezek a standard üzenetek, amelyeket a frontendek és backendek cserélhetnek. Ezek a Kiwi könyvtárban kerültek megvalósításra.
A Machinarium könyvtár a szálak megvalósítását szolgálja. Ennek a Machinarium-nak egy kis része assembly nyelven íródott. De ne aggódjon, csupán 15 sor.
Az Odyssey architektúrája. Van egy fő gép, amelyben coroutines futnak. Ebben a gépben történik a bejövő TCP kapcsolat elfogadása és a munkásokra való elosztás.
Egy munkásen belül több ügyfél kezelője is működhet. Ezen kívül a fő szálban konzol és crone-feladatok kezelése zajlik, hogy eltávolítsa a poolból a már nem szükséges kapcsolatokat.
Az Odyssey teszteléséhez a Postgres standard tesztkészletét használjuk. Egyszerűen futtatjuk az install-check-et a Bouncer-en és az Odyssey-n, és nullás div-et kapunk. Vannak olyan tesztek, amelyek a dátumformátumokkal kapcsolatosak, és teljesen eltérően futnak a Bouncer-en és az Odyssey-n.
Ezen kívül számos olyan drivert is tesztelünk, amelyekhez saját tesztelési eljárásaik vannak. Ezeket a teszteket az Odyssey tesztelésére használjuk.
Továbbá, a kaszkád konfigurációnk miatt különböző párosításokat kell tesztelnünk: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, hogy megbizonyosodjunk arról, hogy ha az Odyssey valamelyik részében található a kaszkádban, az biztosan úgy működik, ahogy várjuk.
Rács
Az Odyssey-t használjuk a production-ben. Nem lenne fair, ha azt mondanám, hogy minden egyszerűen működik. Igen, de nem mindig. Például a production-ben minden egyszerűen működött, aztán jöttek a barátaink a PostgreSQL Professional-tól és mondták, hogy van egy memory leak-ünk. Valóban igazuk volt, azt kijavítottuk. De ez egyszerű volt.
Aztán felfedeztük, hogy a connection pooler-ben vannak bejövő TLS kapcsolatok és kimenő TLS kapcsolatok. A kapcsolatokhoz szükség van kliens- és szerver tanúsítványokra.
A Bouncer és az Odyssey szerver tanúsítványai újraolvassák a pcache-t, de a kliens tanúsítványokat nem kell újraolvasni a pcache-ből, mert a méretezhető Odyssey végül a tanúsítvány olvasási teljesítményébe ütközik. Ez meglepetésként ért minket, mert nem azonnal történt. Eleinte lineárisan méreteződött, de 20 000 bejövő egyidejű kapcsolódás után ez a probléma jelentkezett.
A Pluggable Authentication Method egy lehetőség, hogy a beépített linuxos eszközökkel autentikáljunk. A PgBouncer-ben úgy valósul meg, hogy külön szál van a PAM-tól érkező válasz várakozására, és van a PgBouncer fő szála, amely kezeli a jelenlegi kapcsolatot és kérheti, hogy éljenek a PAM szálban.
Ezt nem valósítottuk meg egy egyszerű ok miatt. Sok szálunk van. Minek nekünk ez?
Végül ez problémákat okozhat, mert ha van PAM autentikáció és nincs PAM autentikáció, akkor egy nagy PAM autentikációs hullám jelentősen késleltetheti a nem PAM autentikációt. Ez az egyik olyan dolog, amit nem javítottunk. De ha szeretné, javíthat ezen.
Egy másik probléma az volt, hogy van egy szálunk, ami fogad minden bejövő kapcsolatot. Aztán átadja őket a worker pool-nak, ahol történik a TLS handshake.
Végül, ha van egy koherens hullám 20 000 hálózati kapcsolattal, mindet befogják. Az ügyféloldalon a libpq elkezdi a timeout-ok számítását. Alapértelmezetten 3 másodperc állítólag be van állítva.
Ha mindannyian nem tudnak egyszerre belépni az adatbázisba, akkor nem tudnak belépni az adatbázisba, mert mindez a nem exponenciális újrapróbálkozással lefedhető.
Arra jutottunk, hogy itt a PgBouncer-ből átvettük a TCP kapcsolatok számának korlátozásának sémáját, amelyeket elfogadunk.
Ha azt látjuk, hogy a kapcsolatok elfogadása megtörténik, de végül nem tudnak kézfogni, akkor sorba állítjuk őket, hogy ne fogyasszanak központi processzort. Ez azt eredményezi, hogy nem minden kapcsolathoz lehet párhuzamos kézfogást végrehajtani. De legalább valaki be tud lépni az adatbázisba, még akkor is, ha a terhelés elég magas.
Roadmap
Mire szeretnénk látni az Odyssey-ben a jövőben? Mit vagyunk hajlandóak magunk fejleszteni, és mit várunk a közösségtől?
2019 augusztusában.
Ilyen volt az Odyssey útiterv augusztusban:
- SCRAM és PAM hitelesítést szerettünk volna.
- A kiváló olvasási kéréseket a standby-ra szerettük volna irányítani.
- Jó lenne online újraindítás.
- És lehetőség a szerver szüneteltetésére.
Ezeknek az útitervnek a fele megvalósult, és nem mi által. Ez jó. Ezért beszéljük meg, mi maradt, és adjunk hozzá többet.
? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.
Alapvetően a Postgres 10-től kezdődően lehetőség van a csatlakozások során a session_attrs megadására is. A kapcsolat során megnevezheted az összes adatbázis hosztot és megmondhatod, miért mész az adatbázisba: írni vagy csak olvasni. És a meghajtó automatikusan kiválasztja az első lista szerinti hosztot, amely a legjobban megfelel a session_attrs követelményeinek.
De ennek a megközelítésnek a problémája az, hogy nem ellenőrzi a replikációs késleltetést. Lehet, hogy van egy replikád, amely elfogadhatatlan időn belül elmaradt a szolgáltatásod számára. Ahhoz, hogy a replikán végrehajtható olvasási kérések teljes funkcionalitását támogassuk, lényegében meg kell támogatnunk az Odyssey-ben azt a lehetőséget, hogy ne működjön, amikor nem lehet olvasni.
Az Odyssey-nek időnként be kell lépnie az adatbázisba, és meg kell kérdeznie a replikációs távolságot a primary-tól. És ha ez elérte a határértéket, új kéréseket nem fogad el, és közölnie kell az ügyféllel, hogy újra be kell indítaniuk a kapcsolatokat, és esetleg másik hosztot kell választaniuk a kérések végrehajtásához. Ez lehetővé teszi az adatbázis számára, hogy gyorsabban helyreállítsa a replikációs késleltetést, és visszatérjen a válaszhoz.
A megvalósítás időpontját nehéz megmondani, mert ez nyílt forráskódú. De remélem, nem 2,5 év, mint a PgBouncer kollégáiként. Ezt a funkciót szeretnénk látni az Odyssey-ben.
Jelenleg két módon hozhat létre előkészített utasítást. Először is, végrehajthat egy SQL parancsot, nevezetesen az „előkezelt” utasítást. Ahhoz, hogy megértsük ezt az SQL parancsot, meg kell tanulnunk megérteni az SQL-t a Bouncer oldaláról. Ez feleslegesnek tűnik, mert teljes mértékben egy parszert igényel. Nem tudjuk minden SQL parancsot értelmezni.
De van üzenetprotokoll szintű előkészített utasítás a proto3-on. És ez az a hely, ahol információ érkezik arról, hogy miként jön létre az előkészített utasítás strukturált formában. Támogathatnánk annak megértését, hogy egy bizonyos szerverkapcsolaton a kliens kérte egy előkészített utasítás létrehozását. És még ha a tranzakció lezárul is, továbbra is meg kell tartanunk a szerver és a kliens összekapcsoltságát.
De itt ellentmondás merül fel a párbeszédben, mert valaki arról beszél, hogy meg kell értenünk, hogy a kliens pontosan milyen előkészített utasítást hozott létre, és el kell választanunk a szerverkapcsolatot minden kliens között, aki ezt a szerverkapcsolatot létrehozta, azaz aki így hozta létre az előkészített utasítást.
Andres Freund azt mondta, hogy ha egy kliens, aki már létrehozott egy ilyen előkészített utasítást egy másik szerverkapcsolaton, hozzád érkezik, akkor hozd létre helyette. De úgy tűnik, hogy ez nem teljesen helyes a kliens helyett adatbázisban végrehajtani a lekérdezéseket, de a fejlesztő szempontjából, aki az adatbázissal való interakciós protokollt írja, hasznos lenne, ha csak kapna egy hálózati kapcsolatot, amely tartalmaz egy ilyen előkészített lekérdezést.
És van még egy funkció, amit meg kell valósítanunk. Jelenleg van egy PgBouncer kompatibilis monitorunk. Vissza tudjuk adni a lekérdezés végrehajtásának átlagos idejét. De az átlagos idő olyan, mint a kórház átlaghőmérséklete: valaki hideg, valaki meleg – átlagosan mindenki egészséges. Ez nem igaz.
Támogatást kell megvalósítanunk a percentilisekhez, amelyek jelezni fogják, hogy vannak lassú lekérdezések, amelyek erőforrásokat fogyasztanak, és elfogadhatóbbá tennék a monitorozást.
A legfontosabb, hogy szeretném a 1.0-s verziót (A 1.1-es verzió már megjelent). Az a helyzet, hogy az Odyssey jelenleg 1.0rc verzióban van, azaz a kiadási jelöltben. Minden probléma, amit felsoroltam, pontosan e verzióban lett javítva, kivéve a memória szivárgást.
Mit mit jelent számunkra az 1.0-ás verzió? Az Odyssey-t bevezetjük a saját adatbázisainkba. Már most működik az adatbázisainkon, de amikor elérjük az 1 000 000 kérést másodpercenként, akkor azt mondhatjuk, hogy ez a kiadási verzió, és ezt nevezhetjük 1.0-nak.
A közösség néhány tagja kérte, hogy az 1.0-ás verzió tartalmazzon szünetet és SCRAM-ot is. De ez azt jelenti, hogy ki kell adni a következő verziót, mert sem SCRAM, sem a szünet nincs még összevonva. De valószínűleg ezt a kérdést gyorsan meg tudjuk oldani.
Várom a pull requestjeiteket. És szeretném hallani, hogy milyen problémáitok vannak a Bouncer-rel. Beszéljük meg őket. Talán meg tudunk valósítani olyan funkciókat, amelyek szükségesek számotokra.
Ezzel a részem befejeződött, szeretném hallani a véleményeteket. Köszönöm!
Kérdések
Ha beállítom az application_name-t, akkor az helyesen fog továbbítódni, beleértve a transaction poolingot az Odyssey-ban?
Az Odyssey-ban vagy a Bouncer-ben?
Az Odyssey-ban. A Bouncer-ben továbbítódik.
A szettet megcsináljuk.
És ha a valódi kapcsolatom ugrál más kapcsolatok között, akkor az át lesz adva?
Minden paramétert beállítunk, ami a listán szerepel. Nem tudom megmondani, hogy az application_name benne van-e a listában. Úgy tűnik, hogy láttam. Az összes paramétert ugyanúgy fogjuk beállítani. Egy kérés keretében minden be lesz állítva, amit az ügyfél a startup során megadott.
Köszönöm, Andrei, a prezentációt! Jó előadás! Örülök, hogy az Odyssey minden percben egyre gyorsabban fejlődik. Kívánom, hogy folytassátok így tovább. Már kértünk tőletek egy multi data-source kapcsolódást, hogy az Odyssey egyszerre több adatbázishoz tudjon csatlakozni, azaz master-slave, majd automatikusan a failover után csatlakozzon az új masterhez.
Igen, úgy tűnik, emlékszem erre a vitára. Jelenleg van néhány tároló. De váltás közöttük nincs. A saját oldalunkon kell lekérdeznünk a szervert, hogy még él-e, és meg kell értenünk, hogy történt-e a failover, ki hívja meg a pg_recovery-t. Van egy standard módszerem, hogy megértsük, hogy nem a masterre érkeztünk. És meg kell értenünk, hogy valahogy hibákból vagy hogyan? Tehát az ötlet érdekes, beszélgetünk róla. Írjatok több megjegyzést. Ha van olyan munkatársatok, aki ismeri a C-t, akkor az remek.
A replikák skálázásával kapcsolatos kérdés minket is érdekel, mivel azt szeretnénk, hogy a replikált klaszterek elfogadása a lehető legegyszerűbb legyen az alkalmazásfejlesztők számára. De itt több megjegyzést szeretnénk, azaz hogyan lehet megvalósítani, hogyan lehet jól megcsinálni.
A kérdés szintén a replikákról szól. Tehát van egy mester és több replikája. És nyilvánvaló, hogy ritkábban fordulunk a replikához, mint a mesterszerverhez a kapcsolatok miatt, mert lehet eltérés. Azt mondtad, hogy az adatok eltérése olyan lehet, hogy nem felel meg az üzletednek, és nem fogsz oda látogatni, amíg nem replikálódik vissza. Ugyanakkor, ha hosszú ideig nem látogattad, majd elkezdesz oda járni, akkor azok az adatok, amikre szükséged van, nem lesznek azonnal elérhetőek. Azaz, ha folyamatosan a mesterhez megyünk, ott a gyorsítótár fel van melegítve, míg a replikában a gyorsítótár kicsit le van maradva.
Igen, ez igaz. A pcache-ben nem lesznek azok az adatok, amikre szükség van, a real cache-ben nem lesz információ a táblákról, amikre szükség van, a tervekben nem lesznek elemzett lekérdezések, tulajdonképpen semmi sem lesz.
És amikor van egy klasztered, és új replikát adsz hozzá, addig, amíg az elindul, minden rosszul van benne, azaz növeli a gyorsítótárát.
Én megértettem az ötletet. A helyes megközelítés az lenne, hogy először egy kis százalékát a lekérdezéseknek a replikára irányítsuk, hogy felmelegedjen a gyorsítótár. Durván szólva, van egy feltételünk, miszerint legfeljebb 10 másodperccel kell lemaradnunk a mestertől. Ezt a feltételt nem egy hullámban, hanem fokozatosan kellene bevezetni néhány kliens számára.
Igen, növelni a súlyt.
Ez jó ötlet. De először ezt a kikapcsolást kell megvalósítani. Először ki kell kapcsolni, és aztán gondolkodunk, hogyan lehet bekapcsolni. Ez egy nagyszerű funkció, hogy fokozatosan bekapcsolódjunk.
Az nginx-nek van egy ilyen lehetősége lassan indul a server klaszterében. És fokozatosan növeli a terhelést.
Igen, nagyszerű ötlet, kipróbáljuk, amikor odáig jutunk.
Forrás: habr.com
