Andrey Borodin vám vo svojej prednáške povie, ako zohľadnili skúsenosti so škálovaním PgBouncer pri navrhovaní pooleru pripojení , ako to rozbehli vo výrobe. Okrem toho si povieme, aké funkcie poolera by sme chceli vidieť v nových verziách: je pre nás dôležité nielen pokryť naše potreby, ale aj rozvíjať komunitu používateľov .
Video:
Ahojte všetci! Volám sa Andrew.
V Yandex vyvíjam open source databázy. A dnes tu máme tému o pripojeniach pooleru.
Ak viete, ako nazvať pripojenie pooler v ruštine, povedzte mi to. Naozaj chcem nájsť dobrý odborný termín, ktorý by sa mal zaviesť v odbornej literatúre.
Téma je to dosť komplikovaná, pretože v mnohých databázach je pooler pripojení zabudovaný a ani o ňom nemusíte vedieť. Niektoré nastavenia sú samozrejme všade, ale v Postgres to nefunguje. A paralelne (na HighLoad++ 2019) existuje správa Nikolaja Samokhvalova o nastavovaní dopytov v Postgres. A chápem, že sem prišli ľudia, ktorí už dokonale nakonfigurovali požiadavky, a to sú ľudia, ktorí čelia zriedkavejším systémovým problémom súvisiacim so sieťou, využívaním zdrojov. A na niektorých miestach to môže byť dosť ťažké v tom zmysle, že problémy nie sú zjavné.
Yandex má Postgres. Mnoho služieb Yandex žije v Yandex.Cloud. A máme niekoľko petabajtov údajov, ktoré generujú v Postgrese najmenej milión požiadaviek za sekundu.
A poskytujeme pomerne typický klaster pre všetky služby - to je hlavný primárny uzol uzla, obvyklé dve repliky (synchrónna a asynchrónna), zálohovanie, škálovanie požiadaviek na čítanie na replike.
Každý uzol klastra je Postgres, na ktorom je okrem Postgresu a monitorovacích systémov nainštalovaný aj pooler pripojení. Pripojovací bazén sa používa na oplotenie a na svoj hlavný účel.
Aký je hlavný účel združovania pripojení?
Postgres prijíma procesný model pre prácu s databázou. To znamená, že jedno pripojenie je jeden proces, jeden backend Postgres. A v tomto backende je veľa rôznych vyrovnávacích pamätí, ktorých vytvorenie rôzne pre rôzne pripojenia je dosť drahé.
V kóde Postgres je tiež pole s názvom procArray. Obsahuje základné údaje o sieťových pripojeniach. A takmer všetky algoritmy spracovania procArray majú lineárnu zložitosť, prechádzajú celým radom sieťových pripojení. Je to dosť rýchly cyklus, ale s väčším počtom prichádzajúcich sieťových pripojení sa veci trochu predražia. A keď sa veci trochu predražia, nakoniec zaplatíte veľmi vysokú cenu za veľký počet sieťových pripojení.
Sú 3 možné prístupy:
- Na strane aplikácie.
- Na strane databázy.
- A medzi tým, teda všetky možné kombinácie.
Bohužiaľ, vstavaný pooler je momentálne vo vývoji. Priatelia v PostgreSQL Professional to robia väčšinou. Kedy sa objaví, je ťažké predpovedať. A vlastne máme dve riešenia výberu architekta. Ide o fond na strane aplikácie a fond proxy.
Bazén na strane aplikácie je najjednoduchší spôsob. A takmer všetky klientske ovládače vám poskytujú spôsob: reprezentovať milióny vašich pripojení v kóde ako niekoľko desiatok pripojení k databáze.
Je tu problém s tým, že v určitom bode chcete backend škálovať, chcete ho nasadiť na veľa virtuálnych strojov.
Potom si stále uvedomujete, že máte niekoľko ďalších zón dostupnosti, niekoľko dátových centier. A prístup združovania na strane klienta vedie k veľkým číslam. Veľké sú asi 10 000 spojení. Toto je hrana, ktorá môže fungovať dobre.
Ak hovoríme o proxy pooleroch, potom sú dvaja pooleri, ktorí dokážu veľa vecí. Nie sú to len pooleri. Sú to poolery + viac cool funkcionality. Toto и .
Ale, bohužiaľ, nie každý potrebuje túto dodatočnú funkciu. A vedie to k tomu, že poolery podporujú len session pooling, teda jedného prichádzajúceho klienta, jedného odchádzajúceho klienta do databázy.
To nie je príliš vhodné pre naše úlohy, preto používame PgBouncer, ktorý implementuje združovanie transakcií, t. j. serverové spojenia sú mapované na pripojenia klientov iba počas trvania transakcie.
A na našom náklade - je to pravda. Problémov je však viacero.
Problémy začínajú, keď chcete diagnostikovať reláciu, pretože všetky prichádzajúce pripojenia sú lokálne. Každý prišiel so spätnou slučkou a nejako je ťažké vysledovať reláciu.
Samozrejme môžete použiť application_name_add_host. Toto je bočný spôsob, ako pridať IP adresu do application_name. Názov_aplikácie je však nastavený ďalším pripojením.
Na tomto grafe, kde žltá čiara sú skutočné požiadavky a modrá čiara sú požiadavky, ktoré lietajú do databázy. A týmto rozdielom je práve nastavenie application_name, ktoré je potrebné len na sledovanie, no nie je vôbec zadarmo.
Okrem toho Bouncer nemôže obmedziť jeden fond, t. j. počet databázových pripojení na používateľa a databázu.
K čomu to vedie? Máte načítanú službu napísanú v C ++ a niekde nablízku malú službu na uzle, ktorá so základňou nič nepokazí, ale jej ovládač sa zblázni. Otvára 20 000 spojení a všetko ostatné počká. Dokonca aj váš kód je správny.
Samozrejme, napísali sme malý patch pre Bouncer, ktorý pridal toto nastavenie, t. j. obmedzenie klientov na pool.
Bolo by to možné urobiť na strane Postgres, teda obmedziť roly v databáze na počet spojení.
Potom však stratíte schopnosť pochopiť, prečo nemáte žiadne spojenie so serverom. PgBouncer nevyhodí chybu pripojenia, vždy vráti rovnakú informáciu. A vy tomu nerozumiete: možno sa vaše heslo zmenilo, možno práve vypadla databáza, možno niečo nie je v poriadku. Ale neexistuje žiadna diagnóza. Ak sa relácia nedá nadviazať, nebudete vedieť, prečo sa to nedá.
V určitom bode sa pozriete na grafy aplikácie a zistíte, že aplikácia nefunguje.
Pozrite sa na vrch a uvidíte, že Bouncer je jednovláknový. Toto je zlomový bod v živote služby. Chápete, že ste sa pripravovali na škálovanie databázy za rok a pol a potrebujete škálovať pooler.
Dospeli sme k záveru, že potrebujeme viac PgBouncerov.
Vyhadzovač bol mierne opravený.
A urobili to tak, že niekoľko vyhadzovačov môže byť zdvihnutých pomocou opätovného použitia TCP portu. A operačný systém už medzi nimi automaticky prenáša prichádzajúce TCP spojenia pomocou round-robin'om.
Toto je transparentné pre klientov, t. j. vyzerá to, že máte jedného Bouncera, ale medzi spustenými Bouncermi máte fragmentáciu nečinných spojení.
A v určitom okamihu si môžete všimnúť, že títo 3 vyhadzovači jedia svoje jadro o 100%. Potrebujete pomerne málo vyhadzovačov. prečo?
Pretože máte TLS. Máte šifrované pripojenie. A ak porovnáte Postgres s TLS a bez neho, zistíte, že počet vytvorených spojení klesne takmer o dva rády so zapnutým šifrovaním, pretože TLS handshake spotrebúva zdroje CPU.
A v hornej časti môžete vidieť niekoľko kryptografických funkcií, ktoré sa vykonávajú počas vlny prichádzajúcich spojení. Keďže náš primár dokáže prepínať medzi zónami dostupnosti, vlna prichádzajúcich pripojení je pomerne typická situácia. To znamená, že z nejakého dôvodu bola stará primárna časť nedostupná, celá záťaž bola odoslaná do iného dátového centra. Všetci naraz prídu pozdraviť TLS.
A veľké množstvo TLS handshake už nemusí Bouncera pozdraviť, ale stlačiť mu hrdlo. Vlna prichádzajúcich pripojení môže byť v dôsledku časového limitu netlmená. Ak máte opakovaný pokus na základňu bez exponenciálneho ustúpenia, nebudú sa vracať znova a znova v súvislej vlne.
Tu je príklad 16 PgBouncerov, ktoré zaťažujú 16 jadier na 100%.
Dorazili sme ku kaskádovému PgBounceru. Toto je najlepšia konfigurácia, ktorú môžeme dosiahnuť pri zaťažení nášho Bouncer. Naše externé vyhadzovače slúžia na TCP handshake a interné vyhadzovače slúžia na skutočné združovanie, aby sa príliš neroztrieštili externé spojenia.
V tejto konfigurácii je možný mäkký reštart. Všetkých týchto 18 vyhadzovačov môžete reštartovať jeden po druhom. Ale udržiavať takúto konfiguráciu je dosť ťažké. Správcovia systému, DevOps a ľudia, ktorí sú skutočne zodpovední za tento server, nebudú s touto schémou veľmi spokojní.
Zdalo by sa, že všetky naše vylepšenia môžu byť propagované v open source, ale Bouncer nepodporuje veľmi dobre. Napríklad možnosť spustiť viacero PgBouncerov na rovnakom porte bola spáchaná pred mesiacom. Požiadavka na stiahnutie s touto funkciou bola pred niekoľkými rokmi.
Alebo ešte jeden príklad. V Postgrese môžete zrušiť prebiehajúcu požiadavku odoslaním tajného kľúča inému pripojeniu bez dodatočnej autentifikácie. Niektorí klienti však jednoducho pošlú TCP-reset, t.j. prerušia sieťové pripojenie. Čo s tým urobí Bouncer? Neurobí nič. Bude pokračovať vo vykonávaní požiadavky. Ak ste dostali veľké množstvo pripojení, ktoré položili základ s malými požiadavkami, potom jednoduché odpojenie pripojenia od Bouncer nebude stačiť, musíte tiež dokončiť tie požiadavky, ktoré sú spustené v databáze.
Toto bolo opravené a problém stále nie je začlenený do upstreamu Bouncer.
A tak sme prišli na to, že potrebujeme vlastný pooler pripojení, ktorý sa bude vyvíjať, záplatovať, v ktorom bude možné rýchlo opravovať problémy a ktorý samozrejme musí byť viacvláknový.
Ako hlavnú úlohu sme si stanovili multithreading. Musíme byť schopní dobre zvládnuť vlnu prichádzajúcich TLS pripojení.
Aby sme to dosiahli, museli sme vyvinúť samostatnú knižnicu s názvom Machinarium, ktorá je navrhnutá tak, aby popisovala stavy stroja sieťového pripojenia ako sériový kód. Ak sa pozriete na zdrojový kód libpq, uvidíte dosť zložité volania, ktoré vám môžu vrátiť výsledok a povedať: „Zavolajte mi o niečo neskôr. Momentálne mám zatiaľ IO, ale keď IO prejde, mám zaťažený procesor. A toto je viacúrovňová schéma. Sieťovú interakciu zvyčajne popisuje stavový automat. Veľa pravidiel ako „Ak som predtým dostal hlavičku paketu veľkosti N, tak teraz čakám N bajtov“, „Ak som odoslal paket SYNC, tak teraz čakám na paket s metadátami výsledku.“ Ukázalo sa, že ide o pomerne zložitý protiintuitívny kód, ako keby sa bludisko premenilo na riadkové skenovanie. Urobili sme to tak, že namiesto stavového automatu programátor popisuje hlavnú cestu interakcie vo forme obyčajného imperatívneho kódu. Práve v tomto imperatívnom kóde musíte vložiť miesta, kde je potrebné prerušiť postupnosť vykonávania čakaním na údaje zo siete, odovzdaním kontextu vykonávania inej korutíne (zelené vlákno). Tento prístup je podobný tomu, že najočakávanejšiu cestu v bludisku zapíšeme za sebou a potom k nej pridáme vetvy.
Výsledkom je, že máme jedno vlákno, ktoré umožňuje akceptovať TCP a cyklicky odovzdáva pripojenie TPC mnohým pracovníkom.
V tomto prípade každé pripojenie klienta beží vždy na jednom procesore. A to vám umožňuje, aby bol priateľský k vyrovnávacej pamäti.
A okrem toho sme mierne vylepšili zhromažďovanie malých paketov do jedného veľkého, aby sme odbremenili systémový zásobník TCP.
Okrem toho sme zlepšili združovanie transakcií v tom zmysle, že Odyssey, keď je nakonfigurovaný, môže poslať CANCEL a ROLLBACK v prípade zlyhania sieťového pripojenia, t.j. ak nikto nečaká na požiadavku, Odyssey povie databáze, aby sa nepokúšala splniť žiadosť, ktorá môže plytvať vzácnymi zdrojmi.
A vždy, keď je to možné, udržiavame spojenie s rovnakým klientom. Vyhnete sa tak nutnosti preinštalovania application_name_add_host. Ak je to možné, nemáme dodatočný reset parametrov, ktoré sú potrebné na diagnostiku.
Pracujeme v záujme Yandex.Cloud. A ak používate spravovaný PostgreSQL a máte nainštalovaný pooler pripojení, môžete vytvoriť logickú replikáciu smerom von, t. j. nechať nás, ak chcete, pomocou logickej replikácie. Bouncer mimo toku logickej replikácie nedá.
Toto je príklad nastavenia logickej replikácie.
Okrem toho máme podporu pre fyzickú replikáciu smerom von. V Cloude je to samozrejme nemožné, pretože potom vám klaster o sebe poskytne priveľa informácií. Ale vo vašich inštaláciách, ak potrebujete fyzickú replikáciu cez pooler pripojení v Odyssey, je to možné.
Odyssey má plne kompatibilný monitoring s PgBouncer. Máme rovnakú konzolu, ktorá vykonáva takmer všetky rovnaké príkazy. Ak niečo chýba, pošlite požiadavku na stiahnutie alebo aspoň problém na GitHub, doplníme potrebné príkazy. Ale už tu máme hlavnú funkcionalitu konzoly PgBouncer.
A samozrejme máme preposielanie chýb. Chybu nahlásenú základňou vrátime. Dostanete informácie, prečo nie ste v base, nielen to, že v nej nie ste.
Táto funkcia je zakázaná v prípade, že potrebujete 100% kompatibilitu s PgBouncer. Pre každý prípad sa môžeme správať ako vyhadzovač.
dizajn
Pár slov o zdrojovom kóde Odyssey.
Existujú napríklad príkazy „Pozastaviť / Obnoviť“. Zvyčajne sa používajú na aktualizáciu databázy. Ak potrebujete aktualizovať Postgres, môžete ho pozastaviť v zdieľaní pripojení, vykonať pg_upgrade a potom pokračovať. A zo strany klienta to bude vyzerať, akoby sa databáza len spomalila. Túto funkcionalitu nám priniesli ľudia z komunity. Ešte nezomrela, ale čoskoro bude všetko. (už mŕtvy)
- už mŕtvy
Navyše jednou z noviniek v PgBouncer je podpora SCRAM Authentication, ktorú nám priniesol aj človek, ktorý nepracuje v Yandex.Cloud. Obe funkcie sú komplexné a dôležité.
Preto by som vám rád povedal, z čoho sa skladá Odyssey, ak by ste teraz chceli napísať aj nejaký kód.
Máte pôvodnú základňu Odyssey, ktorá sa spolieha na dve hlavné knižnice. Knižnica Kiwi je implementáciou protokolu správ Postgres. To znamená, že natívny proto 3 Postgresu sú štandardné správy, ktoré si frontendy a backendy môžu vymieňať. Sú implementované v knižnici Kiwi.
Knižnica Machinarium je knižnica na implementáciu vlákien. Malý fragment tohto Machinarium je napísaný v assembleri. Ale nebojte sa, existuje len 15 riadkov.
Architektúra Odyssey. Je tu hlavný stroj, ktorý beží korutíny. Tento stroj implementuje prijímanie prichádzajúcich pripojení TCP a distribúciu medzi pracovníkov.
V rámci jedného pracovníka môže pracovať handler pre viacerých klientov. A tiež v hlavnom vlákne sa točí konzola a spracovanie úloh crone na odstránenie spojení, ktoré už nie sú potrebné v bazéne.
Odyssey sa testuje pomocou štandardného testovacieho balíka Postgres. Len spustíme install-check cez Bouncer a cez Odyssey, dostaneme null div. Existuje niekoľko testov súvisiacich s formátovaním dátumu, ktoré v Bouncer a Odyssey zlyhajú úplne rovnako.
Okrem toho existuje veľa ovládačov, ktoré majú svoje vlastné testovanie. A ich testy používame na testovanie Odyssey.
Tiež kvôli našej kaskádovej konfigurácii musíme otestovať rôzne balíčky: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, aby sme si boli istí, že ak je Odyssey v niektorej z častí kaskády, stále funguje podľa očakávania. .
hrable
Pri výrobe používame Odyssey. A nebolo by fér, keby som povedal, že všetko funguje. Nie, teda áno, ale nie vždy. Napríklad vo výrobe všetko fungovalo, potom prišli naši priatelia z PostgreSQL Professional a povedali, že máme únik pamäte. Naozaj boli, opravili sme ich. Ale bolo to jednoduché.
Potom sme zistili, že fond pripojení má prichádzajúce pripojenia TLS a odchádzajúce pripojenia TLS. A pripojenia potrebujú klientske certifikáty a serverové certifikáty.
Certifikáty servera Bouncer a Odyssey sa znovu čítajú pomocou pcache, ale klientske certifikáty nie je potrebné znova načítať z pcache, pretože naša škálovateľná Odyssey nakoniec spočíva na výkone systému pri čítaní tohto certifikátu. To nás prekvapilo, pretože si hneď neoddýchol. Najprv sa to lineárne škálovalo a po 20 000 prichádzajúcich simultánnych spojeniach sa tento problém prejavil.
Pluggable Authentication Method je schopnosť autentifikácie pomocou vstavaných lunuxových nástrojov. V PgBouncer je implementovaný tak, že existuje samostatné vlákno čakajúce na odpoveď z PAM a hlavné vlákno PgBouncer, ktoré obsluhuje aktuálne pripojenie a môže ich požiadať, aby žili vo vlákne PAM.
Toto sme nezaviedli z jednoduchého dôvodu. Máme veľa prúdov. Prečo to potrebujeme?
V dôsledku toho to môže spôsobiť problémy v tom, že ak máte autentifikáciu PAM a autentifikáciu bez PAM, veľká vlna autentifikácie PAM môže výrazne oddialiť autentifikáciu bez PAM. Je to jedna z vecí, ktoré sme nevyriešili. Ale ak to chcete opraviť, môžete to urobiť.
Ďalšie hrablo bolo s tým, že máme jedno vlákno, ktoré akceptuje všetky prichádzajúce spojenia. Potom sa presunú do skupiny pracovníkov, kde sa uskutoční podanie ruky TLS.
Výsledkom je, že ak máte súvislú vlnu 20 000 sieťových pripojení, všetky budú akceptované. A na strane klienta začne libpq hlásiť časové limity. Štandardne sú tam tak 3 sekundy.
Ak nemôžu všetci vstúpiť do základne súčasne, potom nemôžu vstúpiť do základne, pretože to všetko možno pokryť neexponenciálnym opakovaním.
Nakoniec sme tu skopírovali schému PgBouncer, aby sme znížili počet pripojení TCP, ktoré akceptujeme.
Ak vidíme, že prijímame pripojenia, no nestihnú si nakoniec potriasť rukou, zaradíme ich do frontu, aby nespotrebovali CPU zdroje. To vedie k tomu, že súčasné podanie ruky nemusí byť vykonané pre všetky spojenia, ktoré prišli. Ale aspoň niekto vstúpi do databázy, aj keď je záťaž dostatočne silná.
plán
Čo by ste chceli vidieť v budúcnosti v Odyssey? Čo sme pripravení sami rozvíjať a čo očakávame od komunity?
Za august 2019.
Takto vyzeral plán Odyssey v auguste:
- Chceli sme overenie SCRAM a PAM.
- Chceli sme preposlať požiadavky na čítanie do pohotovostného režimu.
- Chcel by som reštartovať online.
- A možnosť pozastaviť sa na serveri.
Polovica tohto plánu je hotová a nie my. A toto je dobré. Poďme teda diskutovať o tom, čo zostalo, a pridať ďalšie.
? Máme repliky, ktoré bez splnenia požiadaviek jednoducho ohrejú vzduch. Potrebujeme ich na zabezpečenie zlyhania a prepnutia. V prípade problémov v niektorom z dátových centier by som ich rád zamestnal nejakou užitočnou prácou. Pretože nemôžeme nakonfigurovať rovnaké centrálne procesory, rovnakú pamäť iným spôsobom, pretože replikácia nebude fungovať inak.
V zásade je v Postgrese od 10 možné pri pripájaní zadať session_attrs. Môžete uviesť zoznam všetkých hostiteľov databázy v pripojení a povedať, prečo idete do databázy: iba na zápis alebo na čítanie. A samotný ovládač si vyberie prvého hostiteľa zo zoznamu, ktorý sa mu najviac páči a ktorý spĺňa požiadavky session_attrs.
Problémom tohto prístupu je však to, že nekontroluje oneskorenie replikácie. Môžete mať nejaký druh repliky, ktorá je pozadu o neprijateľný čas pre vašu službu. Aby bolo možné vykonať plnohodnotné vykonávanie požiadaviek na čítanie na replike, v skutočnosti musíme v Odyssey podporovať schopnosť nefungovať, keď nie je možné čítať.
Odyssey musí z času na čas prejsť do databázy a opýtať sa na vzdialenosť replikácie od primára. A ak dosiahne limit, nevpúšťajte nové požiadavky do databázy, povedzte klientovi, že musíte znova iniciovať pripojenia a prípadne vyberte iného hostiteľa na vykonanie požiadaviek. To umožní databáze rýchlo obnoviť oneskorenie replikácie a znova sa vrátiť, aby odpovedala dotazom.
Je ťažké pomenovať dátumy implementácie, pretože ide o open source. Ale dúfam, že nie 2,5 roka ako kolegovia z PgBouncer. Toto je funkcia, ktorú by som chcel vidieť v Odyssey.
. Teraz môžete vytvoriť pripravený výpis dvoma spôsobmi. Najprv môžete vykonať príkaz SQL, konkrétne „pripravený“. Aby sme porozumeli tomuto SQL príkazu, musíme sa naučiť porozumieť SQL na strane Bouncer. Bolo by to prehnané, pretože je to prehnané, pretože potrebujeme celý syntaktický analyzátor. Nemôžeme analyzovať každý príkaz SQL.
Existuje však pripravené vyhlásenie na úrovni protokolu správ na proto3. A práve tu prichádza v štruktúrovanej podobe informácia, že pripravovaný výpis vzniká. A mohli by sme podporiť pochopenie, že na nejakom serverovom pripojení klient požiadal o vytvorenie pripravených výpisov. A aj keď je transakcia uzavretá, stále musíme udržiavať pripojenie servera a klienta.
Tu však vzniká rozpor v dialógu, pretože niekto hovorí, že musíte pochopiť, ktoré pripravené príkazy klient vytvoril a zdieľať serverové spojenie medzi všetkými klientmi, ktorí vytvorili toto serverové spojenie, t. j. kto vytvoril takýto pripravený výpis.
Andres Freund povedal, že ak za vami príde klient, ktorý už takýto pripravený výpis vytvoril v inom serverovom spojení, tak mu ho vytvorte. Zdá sa však, že je trochu nesprávne vykonávať dopyty v databáze namiesto klienta, ale z pohľadu vývojára, ktorý píše protokol na interakciu s databázou, by bolo vhodné, keby dostal jednoducho sieťové pripojenie ktorá má takúto pripravenú požiadavku.
A ešte jedna funkcia, ktorú musíme implementovať. Teraz máme monitorovanie kompatibilné s PgBouncer. Môžeme vrátiť priemerný čas vykonania dotazu. Ale priemerný čas je priemerná teplota v nemocnici: niekomu je zima, niekomu je teplo - v priemere sú všetci zdraví. Nie je to pravda.
Musíme implementovať podporu pre percentily, čo by naznačovalo, že existujú pomalé požiadavky, ktoré spotrebúvajú zdroje, a monitorovanie by bolo prijateľnejšie.
Najdôležitejšie je, že chcem verziu 1.0 (verzia 1.1 už bola vydaná). Faktom je, že Odyssey je teraz vo verzii 1.0rc, teda kandidát na vydanie. A všetky rake, ktoré som uviedol, boli opravené presne tou istou verziou, s výnimkou úniku pamäte.
Čo pre nás bude znamenať verzia 1.0? Rozmiestňujeme Odyssey na naše základne. Už beží na našich databázach, ale keď dosiahne hranicu 1 000 000 požiadaviek za sekundu, môžeme povedať, že toto je verzia vydania a toto je verzia, ktorú možno nazvať 1.0.
Niekoľko ľudí v komunite požiadalo o väčšiu pauzu a SCRAM vo verzii 1.0. To však bude znamenať, že budeme musieť spustiť ďalšiu verziu do výroby, pretože zatiaľ nebol začlenený ani SCRAM, ani pauza. S najväčšou pravdepodobnosťou sa však tento problém vyrieši pomerne rýchlo.
Čakám na vašu žiadosť o stiahnutie. A tiež by som chcel počuť, aké máte problémy s Bouncerom. Poďme o nich diskutovať. Možno môžeme implementovať niektoré funkcie, ktoré potrebujete.
Týmto končím svoju časť, rád by som počul váš názor. Ďakujem!
otázky
Ak vložím svoj vlastný názov_aplikácie, bude to správne vyvolané, vrátane združovania transakcií v Odyssey?
Odyssey alebo Bouncer?
V Odyssey. Vyhadzovač je hodený.
Urobíme súpravu.
A ak moje skutočné spojenie preskočí cez iné spojenia, bude sa to prenášať?
Urobíme sadu všetkých parametrov, ktoré sú uvedené. Nemôžem povedať, či application_name je v tomto zozname. Zdá sa, že ho tam videl. Nastavíme všetky rovnaké parametre. Na jednu požiadavku sada spraví všetko, čo si klient pri štarte nainštaloval.
Ďakujem Andrey za správu! Dobrá správa! Som rád, že Odyssey sa každou minútou vyvíja rýchlejšie a rýchlejšie. Chcel by som pokračovať rovnako. Už sme vás požiadali o pripojenie s viacerými zdrojmi údajov, aby sa Odyssey mohol súčasne pripojiť k rôznym databázam, t. j. k podriadenému master, a potom sa po výpadku automaticky pripojiť k novému masteru.
Áno, spomínam si na túto diskusiu. Teraz existuje niekoľko skladov. Medzi nimi však nedochádza k prepínaniu. Na našej strane sa musíme spýtať servera, že je stále nažive, a pochopiť, že došlo k prepnutiu, ktorý zavolá pg_recovery. Mám štandardný spôsob, ako pochopiť, že sme neprišli k pánovi. A musíme to nejako pochopiť z chýb alebo ako? To znamená, že myšlienka je zaujímavá, diskutuje sa o nej. Napíšte ďalšie komentáre. Ak máte pracujúce ruky, ktoré poznajú C, potom je to vo všeobecnosti úžasné.
Otázka škálovania naprieč replikami nás tiež zaujíma, pretože chceme vývojárom aplikácií čo najviac zjednodušiť adopciu replikovaných klastrov. Ale tu by som chcel viac komentárov, teda ako to urobiť, ako to urobiť dobre.
Otázka sa týka aj replík. Ukazuje sa, že máte predlohu a niekoľko replík. A je jasné, že do repliky chodia na spoje menej často ako do mastera, pretože môžu mať rozdiel. Povedali ste, že rozdiel v údajoch môže byť taký, že váš biznis nebude uspokojovať a nepôjdete tam, kým sa to nezreplikuje. Zároveň, ak ste tam dlho nešli a potom ste začali chodiť, údaje, ktoré potrebujete, nebudú okamžite k dispozícii. To znamená, že ak neustále chodíme k majstrovi, keška sa tam zahrieva a keška je v replike trochu pozadu.
Áno, je to pravda. V pcache nebudú žiadne dátové bloky, ktoré chcete, v skutočnej cache nebudú žiadne informácie o tabuľkách, ktoré chcete, v plánoch nebudú žiadne parsované dotazy, vôbec nič.
A keď máte nejaký zhluk, a pridáte tam novú repliku, tak kým sa spustí, je v ňom všetko zlé, teda rozrastá si vyrovnávaciu pamäť.
Dostal som nápad. Správnym prístupom by bolo spustiť najprv malé percento dopytov na repliku, čo by zahrialo vyrovnávaciu pamäť. Zhruba povedané, máme podmienku, že nesmieme zaostávať za majstrom viac ako 10 sekúnd. A táto podmienka by nemala byť zaradená v jednej vlne, ale u niektorých klientov plynule.
Áno, zvýšiť váhu.
To je dobrý nápad. Najprv však musíte implementovať toto vypnutie. Najprv musíme vypnúť a potom premýšľame o tom, ako zapnúť. Je to skvelá funkcia na plynulé zapnutie.
nginx má túto možnosť slowly start v klastri pre server. A postupne si vytvára záťaž.
Áno, skvelý nápad, vyskúšame to, keď sa k tomu dostaneme.
Zdroj: hab.com