V správe Andrej Borodin objasní, ako zohľadnili skúsenosti so škálovaním PgBouncer pri navrhovaní connection poolera , ako ho nasadili do produkcie. Okrem toho prediskutujeme funkcie, ktoré by sme chceli vidieť v nových verziách: pre nás je dôležité nielen uspokojovať naše potreby, ale aj rozvíjať komunitu používateľov .
Video:
Ahojte! Volám sa Andrej.
V Yandexe sa zaoberám vývojom open source databáz. A dnes máme tému o connection pooler.
Ak viete, ako sa povie connection pooler po slovensky, dajte mi vedieť. Veľmi chcem nájsť dobrý technický termín, ktorý by sa mal etablovať v technickej literatúre.
Téma je pomerne zložitá, pretože v mnohých databázach je connection pooler zabudovaný a ani o ňom netreba vedieť. Samozrejme, nejaké nastavenia sú všade, ale v Postgres to tak nefunguje. A súbežne (na HighLoad++ 2019) má prednášku Nikolaj Samohvalov o optimalizácii dotazov v Postgres. A chápem, že sem prišli ľudia, ktorí už dotazy nastavili ideálne, a to sú ľudia, ktorí čelili zriedkavým systémovým problémom spojeným so sieťou a využívaním zdrojov. A miestami to mohlo byť dosť zložité v tom zmysle, že problémy sú nejasné.
V Yandexe máme Postgres. V Yandex.Cloud žije množstvo služieb Yandexu. A máme niekoľko petabajtov dát, ktoré generujú nie menej ako milión dotazov za sekundu v Postgres.
A poskytujeme dosť typický klaster všetkým službám – to je hlavný primárny uzol, bežné dve repliky (synchronná a asynchronná), zálohovanie, škálovanie čítacích dotazov na replike.
Každý uzol klastru je Postgres, na ktorom okrem Postgres a systémov monitorovania je ešte nainštalovaný connection pooler. Connection pooler sa používa na fencing a pre jeho základnú funkciu.
Čo je základná funkcia connection poolera?
V Postgres je prijatý procesný model pri práci s databázou. To znamená, že jedno pripojenie – to je jeden proces, jeden backend Postgres. A v tomto backende je veľmi veľa rôznych cache, ktoré sú dosť nákladné, aby sa robili rôzne pre rôzne pripojenia.
Okrem toho obsahuje kód Postgres pole nazvané procArray. Obsahuje základné údaje o sieťových pripojeniach. A takmer všetky algoritmy spracovania procArray majú lineárnu zložitost, prechádzajú celým poľom sieťových pripojení. To je celkom rýchly cyklus, ale s veľkým počtom prichádzajúcich sieťových pripojení sa to všetko stáva trochu drahšie. A keď všetko trochu zdražie, nakoniec môžete zaplatiť veľmi vysokú cenu za veľké množstvo sieťových pripojení.
Existujú 3 možné prístupy:
- Na strane aplikácie.
- Na strane databázy.
- A medzi nimi, t. j. rôzne kombinácie.
Bohužiaľ, vstavaný pooler sa momentálne nachádza vo fáze vývoja. Priatelia v spoločnosti PostgreSQL Professional sa týmto väčšinou zaoberajú. Keď sa objaví, ťažko predvídať. A skutočne máme na výber dve riešenia. Je to application-side pool a proxy pool.
Application-side pool je najjednoduchší spôsob. A takmer všetky klientské ovládače vám poskytujú spôsob, ako predstaviť milióny vašich pripojení v kóde ako niekoľko desiatok pripojení v databáze.
Vzniká problém, že v určitom momente chcete škálovať backend, chcete ho nasadiť na množstvo virtuálnych strojov.
Následne si ešte uvedomíte, že máte niekoľko dostupných zón, niekoľko dátových centier. A prístup s client side pooling vedie k vysokým číslam. Vysoké – to znamená okolo 10 000 pripojení. To je kraj, ktorý môže normálne fungovať.
Pokiaľ ide o proxy poolers, existujú dva poolers, ktoré zvládajú veľa vecí. Nie sú to len poolers. Sú to poolers + ďalšia skvelá funkcionalita. To sú a .
Bohužiaľ, táto dodatočná funkcionalita nie je pre všetkých potrebná. A vedie to k tomu, že poolers podporujú iba session pooling, t. j. jeden prichádzajúci klient, jeden odchádzajúci klient do databázy.
Pre naše úlohy to nie je veľmi vhodné, preto používame PgBouncer, ktorý implementuje transaction pooling, t. j. serverové pripojenia sú priradené klientským pripojeniam iba na čas transakcie.
A pri našej záťaži – to je pravda. Ale existuje niekoľko problémov..
Problémy začínajú, keď chcete diagnostikovať reláciu, pretože všetky prichádzajúce pripojenia sú lokálne. Všetky prišli z loopback a nejakým spôsobom trasovanie relácie sa stáva ťažkým.
Samozrejme, môžete použiť application_name_add_host. Je to spôsob, ako na strane Bouncer pridať IP adresu do application_name. Ale application_name sa nastavuje pomocou ďalšieho pripojenia.
Na tomto grafe, kde žltá čiara predstavuje skutočné požiadavky a modrá reprezentuje požiadavky, ktoré prichádzajú do databázy. A tento rozdiel je práve nastavenie application_name, ktoré je potrebné iba na sledovanie, ale nie je úplne bezplatné.
Okrem toho v Bouncer nie je možné obmedziť jeden pool, t. j. počet pripojení k databáze pre určitého používateľa, na určitú databázu.
K čomu to vedie? Máte preťaženú službu napísanú v C++ a niekde blízko je malá služba na nód, ktorá nerobí nič hrozného s databázou, ale jej ovládač sa zblázni. Otvára 20 000 pripojení a všetko ostatné počká. Váš kód môže byť normálny.
Samozrejme, napísali sme malú opravu pre Bouncer, ktorá pridala toto nastavenie, t. j. obmedzenie klientov na pool.
Mohlo by sa to spraviť na strane Postgres, t. j. obmedziť role v databáze počtom pripojení.
Ale potom strácate možnosť pochopiť, prečo nemáte pripojenia k serveru. PgBouncer nepreposiela chybu pripojenia, vždy vráti tú istú informáciu. A nemôžete pochopiť: možno sa zmenilo vaše heslo, možno jednoducho databáza spadla, možno je niečo inak. Ale žiadna diagnostika nie je. Ak sa relácia nedá vytvoriť, nezistíte, prečo to nie je možné.
V určitom momente sa pozeráte na grafy aplikácie a vidíte, že aplikácia nefunguje.
Pozeráte sa do top a vidíte, že Bouncer je jednovláknový. Toto je rozhodujúci moment v živote služby. Uvedomujete si, že ste sa pripravovali na škálovanie databázy o rok a pol, a potrebujete škálovať pooler.
Dospeli sme k tomu, že potrebujeme viac PgBouncer’ov.
Trochu sme opravili Bouncer.
A urobili sme to tak, že môže byť spustených niekoľko Bouncerov s opätovným využitím TCP-portu. A operačný systém automaticky prerovnáva prichádzajúce TCP-pripojenia medzi nimi pomocou round-robin.
Je to transparentné pre klientov, t. j. všetko vyzerá tak, akoby ste mali jeden Bouncer, ale máte fragmentáciu idle-pripojení medzi spustenými Bouncermi.
A v určitom momente si môžete všimnúť, že týchto 3 Bouncerov využíva každé svoje jadro na 100 %. Potrebujete dosť veľa Bouncerov. Prečo?
Pretože máte TLS. Máte šifrované pripojenie. A ak benchmarkujete Postgres s TLS a bez TLS, zistíte, že počet nadviazaných pripojení sa pri zapnutí šifrovania zníži takmer o dva poriadky, pretože TLS handshake spotrebováva zdroje centrálneho procesora.
A na vrchu môžete vidieť množstvo kryptografických funkcií, ktoré sa vykonávajú pri vlne prichádzajúcich pripojení. Keďže náš primary môže prechádzať medzi zónami dostupnosti, vlna prichádzajúcich pripojení je celkom typická situácia. T. j. z nejakého dôvodu starý primary nebol dostupný, všetka záťaž bola presunutá do iného dátového centra. Všetky prichádzajú zároveň, aby sa pozdravili s TLS.
A veľké množstvo TLS handshake sa už nemusí pozdraviť s Bouncerom, ale môže mu stiahnuť krk. Z dôvodu timeoutu sa vlna prichádzajúcich pripojení môže stať nekončiacou. Ak máte retry do databázy bez exponential backoff, prichádzajú stále znova a znova ako koherentná vlna.
Tu je príklad 16 PgBouncerov, ktoré zaťažujú 16 jadier na 100 %.
Dostali sme sa k kaskádovému PgBounceru. Toto je najlepšia konfigurácia, ktorú môžeme dosiahnuť na našej záťaži s Bouncerom. Externé Bounceri slúžia na TCP handshake, zatiaľ čo interné Bounceri slúžia na reálne poolovanie, aby sa vonkajšie pripojenia príliš nezfragmentovali.
V takejto konfigurácii je možné hladké reštartovanie. Môžete reštartovať všetkých 18 Bouncerov po jednom. Ale udržiavať takúto konfiguráciu je dosť ťažké. Systémoví administrátori, DevOps a ľudia, ktorí sú skutočne zodpovední za tento server, nebudú veľmi nadšení z takého schémy.
Zdalo by sa, že všetky naše vylepšenia môžeme propagovať ako open source, ale Bouncer sa príliš dobre nepodporuje. Napríklad funkcia spustenia viacerých PgBouncerov na jednom porte bola pridaná pred mesiacom. A pull request s touto funkciou bol pred niekoľkými rokmi.
Alebo ďalší príklad. V Postgres môžete zrušiť vykonávajúci sa dotaz tým, že pošlete príkaz cez iné spojenie bez zbytočnej autentifikácie. Niektorí klienti však jednoducho posielajú TCP-reset, t.j. prerušujú sieťové spojenie. Čo urobí Bouncer? Nič. Pokračuje v vykonávaní dotazu. Ak ste dostali obrovské množstvo spojení, ktoré menšími dotazmi zaťažili databázu, jednoducho odtrhnúť spojenie od Bouncer nebude stačiť, potrebujete tiež ukončiť tie dotazy, ktoré bežia v databáze.
Toto bolo opravené a tento problém ešte nebol zlúčený do upstream Bouncer-a.
A tak sme sa dostali k tomu, že potrebujeme svoj vlastný connection pooler, ktorý sa bude rozvíjať, opravovať, v ktorom bude možné rýchlo vyriešiť problémy a ktorý, samozrejme, musí byť vícerozmenný.
Vícerozmennosť sme si stanovili ako hlavný cieľ. Musíme dobre zvládať nápor prichádzajúcich TLS-spojení.
Na to sme museli vyvinúť osobitnú knižnicu, ktorá sa nazýva Machinarium, a ktorá je určená na opis strojových stavov sieťového spojenia ako sekvenčného kódu. Ak sa pozriete do zdrojového kódu libpq, uvidíte celkom zložité volania, ktoré vám môžu vrátiť výsledok a povedať: 'Zavolaj ma o chvíľu. Teraz mám IO, ale keď IO prejde, bude pre mňa zaťažujúce'. A to je viacúrovňový plán. Sieťová interakcia sa zvyčajne opisuje ako stroj stavov. Množstvom pravidiel typu 'Ak som predtým dostal hlavičku paketu veľkosti N, teraz čakám N bajtov', 'Ak som poslal paket SYNC, teraz čakám paket s metadátami výsledku'. Vzniká tak dosť ťažký, kontraintuitívny kód, akoby sa labyrint transformoval na priame rozloženie. Spravili sme to tak, že namiesto stroja stavov programátor opisuje hlavnú cestu interakcie ako bežný imperatívny kód. V tomto imperatívnom kóde len treba vložiť miesta, kde treba prerušiť sekvenciu vykonávania čakaním na dáta zo siete, pričom sa predá kontext vykonávania inej korutine (green threadu). Tento prístup je podobný tomu, ako najčastejšiu cestu v labyrinte zapisujeme po sebe a potom k nej pridávame odbočky.
Na výsledok máme jeden tok, ktorý vykonáva TCP accept a round-robin posiela množstvu pracovníkov TPC pripojenie.
Každé klientské pripojenie pritom vždy pracuje na jednom procesore. To umožňuje, aby bol jeho cache-friendly.
A navyše, trochu sme vylepšili zhromažďovanie malých paketov do jedného veľkého paketu, aby sme odľahčili systémový TCP-stack.
Okrem toho sme zlepšili transakčné poolovanie v tom zmysle, že Odyssey pri nastavenej konfigurácii môže poslať CANCEL a ROLLBACK v prípade prerušenia sieťového pripojenia, t. j. ak nikto nečaká na dopyt, Odyssey povie databáze, aby sa nesnažila vykonať dopyt, ktorý môže plytvať cennými zdrojmi.
A ak je to možné, uchovávame pripojenia pre rovnakého klienta. To zabraňuje opätovnému nastavovaniu application_name_add_host. Ak je to možné, nemáme žiadne dodatočné nastavenia potrebné na diagnostiku.
Pracujeme v záujme Yandex.Cloud. A ak používate managed PostgreSQL a máte nastavený connection pooler, môžete vytvoriť logickú replikáciu von, t. j. môžete sa od nás odpojiť, ak to chcete, prostredníctvom logickej replikácie. Bouncer von neprenesie tok logickej replikácie.
Toto je príklad nastavenia logickej replikácie.
Okrem toho máme podporu fyzickej replikácie von. V cloude to samozrejme nie je možné, pretože by vám klaster poskytol príliš veľa informácií o sebe. Ale vo vašich inštaláciách, ak potrebujete fyzickú replikáciu cez connection pooler v Odyssey, je to možné.
V Odyssey je plne kompatibilný monitoring s PgBouncer. Máme takú istú konzolu, ktorá vykonáva takmer všetky rovnaké príkazy. Ak niečo chýba, pošlite pull request alebo aspoň issue na GitHub, budeme dopĺňať potrebné príkazy. Ale základná funkčnosť konzoly PgBouncer už existuje.
A samozrejme, máme chybové preposielanie. Vrátime tú chybu, ktorú oznámila databáza. Získate informácie, prečo sa nedostanete do databázy, a nie iba to, že sa do nej nedostanete.
Táto funkcia sa vypína v prípade, ak potrebujete 100%-nú kompatibilitu s PgBouncer. Môžeme sa správať rovnako ako Bouncer, len pre istotu.
Vývoj
Návrh pár slov o zdrojovom kóde Odyssey.
Napríklad existujú príkazy „Pozastaviť / Obnoviť“. Tieto príkazy sa zvyčajne používajú na aktualizáciu databázy. Ak potrebujete aktualizovať Postgres, môžete ho pozastaviť v connection pooler, vykonať pg_upgrade a potom ho obnoviť. Z pohľadu klienta to vyzerá, akoby databáza len spomalila. Túto funkčnosť nám priniesli ľudia z komunity. Ešte nie je zlúčená, ale čoskoro bude. (Už zlúčená)
— už zlúčená
Okrem toho, jedna z nových funkcií v PgBouncer je podpora SCRAM Authentication, ktorú nám tiež priniesol človek, ktorý nepracuje v Yandex.Cloud. Obe tieto funkčnosti sú zložitými a dôležitými.
Preto by som chcel povedať, z čoho je zložený Odyssey, možno aj vy teraz chcete trošku zapísať kód.
Máte pôvodnú databázu Odyssey, ktorá sa opiera o dve hlavné knižnice. Knižnica Kiwi je implementácia Postgres protokolu správ. T. j. natívny proto 3 v Postgres – to sú štandardné správy, ktorými si front-endy a back-endy môžu vymieňať. Tieto sú implementované v knižnici Kiwi.
Knižnica Machinarium je knižnica implementácie tokov. Malý fragment tejto knižnice Machinarium je napísaný v asembleri. Ale nebojte sa, má len 15 riadkov.
Architektúra Odyssey. Existuje hlavný stroj, v ktorom sú spustené coroutines. V tomto stroji sa realizuje akceptácia prichádzajúcich TCP pripojení a rozdelenie prác medzi workers.
Vo vnútri jedného worker môže bežať spracovateľ viacerých klientov. A tiež v hlavnom vlákne beží konzola a spracovanie crone úloh na odstránenie pripojení, ktoré už nie sú potrebné v pool.
Na testovanie Odyssey používame štandardnú sadu testov Postgres. Jednoducho spustíme install-check cez Bouncer a cez Odyssey, dostaneme nulový div. Niekoľko testov súvisiacich s formátovaním dát prechádza úplne rovnako v Bouncer a v Odyssey.
Okrem toho existuje množstvo ovládačov, ktoré majú svoje vlastné testovanie. A ich testy používame na testovanie Odyssey.
Okrem toho, kvôli našej kaskádovej konfigurácii musíme testovať rôzne kombinácie: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, aby sme si boli istí, že ak sa Odyssey ocitne v niektorej časti kaskády, stále funguje tak, ako očakávame.
Hrebene
Používame Odyssey v produkcii. A nebolo by fér povedať, že všetko len tak funguje. Nie, t. j. áno, ale nie vždy. Napríklad, v produkcii to jednoducho fungovalo, potom prišli naši priatelia z PostgreSQL Professional a povedali, že máme memory leak. Skutočne tam boli, opravili sme ich. Ale to bolo len tak.
Následne sme zistili, že v connection pooleri sú prichádzajúce TLS pripojenia a odchádzajúce TLS pripojenia. A na pripojeniach sú potrebné klientské certifikáty a serverové certifikáty.
Serverové certifikáty Bouncer a Odyssey načítavajú svoju pcache, ale klientské certifikáty nie je potrebné z pcache znova načítať, pretože náš škálovateľný Odyssey nakoniec narazí na systémový výkon pri čítaní tohto certifikátu. Toto bolo pre nás prekvapením, pretože sa to neprejavilo hneď. Najprv sa škáloval lineárne, ale po 20 000 prichádzajúcich súčasných pripojeniach sa tento problém objavil.
Pluggable Authentication Method je možnosť autentifikovať sa pomocou zabudovaných linuxových prostriedkov. V PgBouncer je to implementované tak, že existuje samostatný vlákno na čakanie na odpoveď od PAM a existuje hlavné vlákno PgBouncer, ktoré obsluhuje aktuálne pripojenie a môže ich požiadať, aby počkali vo vlákne PAM.
Toto sme nezrealizovali z jedného jednoduchého dôvodu. Veď máme veľa vlákien. Na čo nám to je potrebné?
Nakoniec to môže spôsobovať problémy, pretože ak máte PAM autentifikáciu a ne-PAM autentifikáciu, veľká vlna PAM autentifikácie môže podstatne spomaliť ne-PAM autentifikáciu. Toto je jedna z tých vecí, ktoré sme neopravili. Ale ak to chcete opraviť, môžete sa týmto zaoberať.
Ďalší problém bol, že máme jedno vlákno, ktoré prijíma všetky prichádzajúce pripojenia. A potom ich odovzdáva do pracovného poolu, kde prebehne TLS handshake.
Nakoniec, ak máte koherentnú vlnu z 20 000 sieťových pripojení, všetky budú prijaté. A na strane klienta libpq začne odpočítavanie timeoutov. Podľa predpokladov tam je nastavený 3-sekundový timeout.
Ak všetky nemôžu zároveň vstúpiť do databázy, nemôžu vstúpiť do databázy, pretože všetko môže byť pokryté neexponenciálnym retry.
Dospeli sme k tomu, že sme tu skopírovali schému z PgBouncer, kde máme throttling počtu TCP pripojení, ktorým prijímame.
Ak vidíme, že akceptujeme pripojenia, ale nakoniec sa im nedarí naplniť handshake, zaradíme ich do frontu, aby nevyužívali zdroje centrálnych procesorov. To vedie k tomu, že súčasný handshake sa nemusí vykonávať pre všetky pripojenia, ktoré prišli. Ale aspoň niekto sa pripojí do databázy, aj keď je záťaž dosť silná.
Plán
Čo by sme chceli vidieť v budúcnosti v Odyssey? Čo sme pripravení vyvíjať sami a čo očakávame od komunity?
Na august 2019.
Takto vyzeral plán Odyssey v auguste:
- Chceli sme SCRAM a PAM autentifikáciu.
- Chceli sme prenos čítacích požiadaviek na záložný server.
- Bolo by fajn mať online-reštart.
- A možnosť pozastaviť server.
Polovica tohto plánu je splnená, a to dokonca nie našou prácou. A to je dobre. Takže diskutujme o tom, čo zostáva a pridajme ďalšie.
? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.
V Postgres, počnúc verziou 10, existuje možnosť pri pripojení uviesť aj session_attrs. Môžete v pripojení vymenovať všetky databázové hosty a povedať, prečo idete do databázy: zapisovať alebo iba čítať. A ovládač si sám vyberie prvý hosť v zozname, ktorý mu vyhovuje a splní požiadavky session_attrs.
Problémom tohto prístupu je, že nekontroluje oneskorenie replikácie. Môže byť nejaká replika, ktorá zaostáva na neprijateľný čas pre vašu službu. Aby sme mohli funkčne vykonávať čítacie požiadavky na replike, potrebujeme v Odyssey zabezpečiť, aby nefungoval, keď nie je možné čítať.
Odyssey by mal čas od času vstúpiť do databázy a opýtať sa na replikáciu od primárneho servera. A ak dosiahne kritickú hodnotu, novým požiadavkám do databázy by nemal dovoliť prístup, mal by klientovi povedať, aby znova inicioval pripojenia a možno si vybrať iného hostiteľa na vykonávanie požiadaviek. To umožní databáze rýchlejšie obnoviť replikáciu a znovu začať odpovedať na požiadavky.
Časové rámce realizácie sa ťažko nazývajú, pretože ide o open source. Ale dúfam, že nie 2,5 roka ako u kolegov z PgBouncer. Túto funkciu by som chcel vidieť v Odyssey.
Teraz môžete vytvoriť pripravený statement dvoma spôsobmi. Po prvé, môžete vykonať SQL príkaz, konkrétne „prepared“. Aby sme pochopili tento SQL príkaz, musíme sa naučiť rozumieť SQL na strane Bouncer. To by bolo nadmerné, pretože potrebujeme celý parser. Nemôžeme analyzovať každý SQL príkaz.
Existuje však pripravený statement na úrovni protokolu správ na proto3. A to je to miesto, kde informácie o tom, že sa vytvára pripravený statement, prichádzajú v štruktúrovanej forme. Mohli by sme podporiť pochopenie toho, že na nejakom serverovom spojení klient požiadal o vytvorenie pripravených statementov. A aj keď sa transakcia uzavrela, musíme naďalej udržiavať súvislosť servera a klienta.
Tu však vzniká rozpor v dialógu, pretože niekto hovorí o tom, že je potrebné pochopiť, ktorý presne pripravený statement vytvoril klient a rozdeľovať serverové spojenie medzi všetkými klientmi, ktorí vytvorili toto serverové spojenie, t.j. ktorí vytvorili taký pripravený statement.
Andres Freund povedal, že ak k vám prišiel klient, ktorý už vytvoril v inom serverovom spojení taký pripravený statement, vytvorte ho za neho. Ale zdá sa, že je to trochu nesprávne vykonávať požiadavky v databáze namiesto klienta, ale z pohľadu vývojára, ktorý píše protokol interakcie s databázou, by bolo pohodlné, keby mu jednoducho dali sieťové spojenie, v ktorom je takýto pripravený dotaz.
A ešte jedna funkcia, ktorú musíme implementovať. Momentálne máme monitorovanie kompatibilné s PgBouncer. Môžeme vrátiť priemerný čas vykonania dotazu. Ale priemerný čas je priemerná teplota v nemocnici: niekto je studený, niekto teplý – v priemere sú všetci zdraví. To nie je pravda.
Musíme implementovať podporu percentilov, ktoré by ukazovali na to, že existujú pomalé dotazy, ktoré spotrebúvajú zdroje, a urobili by monitorovanie akceptovateľnejším.
Najdôležitejšie je, že chceme verziu 1.0 (už vyšla verzia 1.1). Faktom je, že teraz je Odyssey vo verzii 1.0rc, t.j. release candidate. A všetky problémy, ktoré som uviedol, boli opravené presne v tejto verzii, okrem úniku pamäte.
Čo pre nás bude znamenať verzia 1.0? Spúšťame Odyssey na našich databázach. Už teraz funguje na našich základoch, ale keď dosiahne bod 1 000 000 požiadaviek za sekundu, môžeme povedať, že to je verzia určená na vydanie a že to je verzia, ktorú môžeme nazvať 1.0.
V komunite niekoľko ľudí požiadalo, aby verzia 1.0 obsahovala aj pauzu a SCRAM. Ale to by znamenalo, že budeme musieť v produkčnom prostredí nasadiť už ďalšiu verziu, pretože ani SCRAM, ani pauza zatiaľ nie sú zlúčené. Ale pravdepodobne bude tento problém dostatočne rýchlo vyriešený.
Čakám na vaše pull requesty. A tiež by som rád počul, aké máte problémy s Bouncerom. Poďme ich prediskutovať. Možno budeme môcť implementovať niektoré funkcie, ktoré potrebujete.
Na tomto končím svoju časť, rád by som vás počul. Ďakujem!
Otázky
Ak nastavím svoje application_name, správne sa prenesie, vrátane transakčného poolingu v Odyssey?
V Odyssey alebo v Bouncerovi?
V Odyssey. V Bouncerovi sa prenáša.
Set spravíme.
A ak bude moje skutočné spojenie preskakovať na iné spojenia, bude sa prenášať?
Urobíme set všetkých parametrov uvedených v zozname. Neviem, či je v tomto zozname application_name. Zdá sa, že som ho tam videl. Nastavíme všetky tie isté parametre. Jedným dopytom sa tam set robí všetko, čo bolo nastavené klientom pri štarte.
Ďakujem, Andrej, za prezentáciu! Dobrý prejav! Rád vidím, že Odyssey sa s každou minútou vyvíja rýchlejšie a rýchlejšie. Prajem vám, aby ste pokračovali takýmto tempom. Už sme sa na vás obracali s prosbou o multi data-source pripojenie, aby sa Odyssey mohol pripojiť súčasne k rôznym databázam, t. j. master-slave, a potom sa automaticky po failoveri pripojiť k novému masterovi.
Áno, zdá sa, že si pamätám túto diskusiu. Momentálne existuje niekoľko úložísk. Ale medzi nimi nie je prechádzanie. Musíme na svojej strane kontrolovať server, či je ešte živý a pochopiť, že došlo k failoveru, kto vyvolá pg_recovery. Mám štandardný spôsob, ako zistiť, že sme sa nepripojili k masterovi. A musíme to nejak pochopiť z chýb alebo ako? T. j. myšlienka je zaujímavá, je predmetom diskusie. Píšte viac komentárov. Ak máte pracovné sily, ktoré ovládajú C, tak to je vôbec úžasné.
Otázka škálovania pomocou replikácií nás tiež zaujíma, pretože chceme, aby adopcia replikovaných klastrov bola pre vývojárov aplikácií čo najjednoduchšia. Chceli by sme však viac komentárov, t. j. ako presne to implementovať, ako to spraviť dobre.
Otázka tiež týka replikácií. Máte master a niekoľko replik. A je jasné, že do replik sa pristupuje menej často ako k masteru, pretože môžu mať odchýlky. Hovorili ste, že rozdiel v údajoch môže byť taký, že nebude vyhovovať vášmu podnikaniu a nebudete tam pristupovať, kým nebude replikácia dokončená. Ak ste tam dlho nechodili a potom začnete, údaje, ktoré potrebujete, nebudú ihneď dostupné. T. j. ak neustále chodíme do mastera, tam je vyhriaty cache, zatiaľ čo v replikách cache trochu zaostáva.
Áno, to je pravda. V pcache nebudú bloky údajov, ktoré chcete, v real cache nebude informácia o tabuľkách, ktoré chcete, v plánoch nebudú spracované požiadavky, proste tam nebude nič.
A keď máte nejaký klaster a pridáte doň novú replikáciu, tak pokiaľ sa spúšťa, je na tom zle, t. j. buduje si svoj cache.
Rozumiem nápadu. Správny prístup by bol spustiť malý percentuálny podiel požiadaviek najprv na replikáciu, aby sa vyhrial cache. Vo voľnom preklade, máme podmienku, že musíme byť maximálne 10 sekúnd za masterom. A túto podmienku je potrebné zaviesť nie jednou vlnou, ale postupne pre niektorých klientov.
Áno, zvyšovať váhu.
To je dobrý nápad. Ale najprv je potrebné implementovať toto odpojenie. Najprv sa musíme vypnúť a potom premyslieť, ako sa zapnúť. Je to skvelá funkcia, aby sme sa mohli zapnúť plynulo.
V nginx je takáto voľba slowly start pre server v klastri. A postupne zvyšuje záťaž.
Áno, skvelý nápad, pokúsime sa to, keď sa k tomu dostaneme.
Zdroj: habr.com
