Andrey Borodin vám ve své zprávě prozradí, jak vzali v úvahu zkušenosti se škálováním PgBouncer při navrhování pooleru připojení , jak to zavedli do výroby. Kromě toho probereme, jaké funkce stahováku bychom rádi viděli v nových verzích: je pro nás důležité nejen vyhovět našim potřebám, ale také rozvíjet komunitu uživatelů .
Video:
Ahoj všichni! Jmenuji se Andrew.
V Yandexu vyvíjím open source databáze. A dnes tu máme téma o připojení pooleru připojení.
Pokud víte, jak v ruštině zavolat připojení pooler, řekněte mi to. Opravdu chci najít dobrý odborný termín, který by měl být zaveden v odborné literatuře.
Téma je to poměrně složité, protože v mnoha databázích je pooler připojení vestavěný a ani o něm nemusíte vědět. Samozřejmě, všude jsou nějaká nastavení, ale v Postgresu to tak nefunguje. A paralelně (na HighLoad++ 2019) existuje zpráva Nikolaje Samokhvalova o nastavení dotazů v Postgresu. A pokud tomu dobře rozumím, přišli sem lidé, kteří již dokonale nakonfigurovali své dotazy, a to jsou lidé, kteří se potýkají se vzácnějšími systémovými problémy souvisejícími se sítí a využitím zdrojů. A v některých místech by to mohlo být docela obtížné v tom smyslu, že problémy nejsou zřejmé.
Yandex má Postgres. Mnoho služeb Yandex žije v Yandex.Cloud. A máme několik petabajtů dat, která v Postgresu generují nejméně milion požadavků za sekundu.
A poskytujeme celkem standardní cluster pro všechny služby - to je hlavní primární uzel uzlu, obvyklé dvě repliky (synchronní a asynchronní), zálohování, škálování požadavků na čtení na replice.
Každý uzel clusteru je Postgres, na kterém je kromě Postgresu a monitorovacích systémů nainstalován i pooler připojení. Připojení pooler se používá pro oplocení a pro svůj hlavní účel.
Jaký je hlavní účel sdružování připojení?
Postgres při práci s databází přebírá procesní model. To znamená, že jedno připojení je jeden proces, jeden backend Postgres. A v tomto backendu je spousta různých mezipamětí, jejichž vytvoření různé pro různá připojení je poměrně drahé.
Kód Postgres má navíc pole nazvané procArray. Obsahuje základní údaje o síťových připojeních. A téměř všechny algoritmy pro zpracování procArray mají lineární složitost; běží přes celé pole síťových připojení. Je to docela rychlý cyklus, ale s větším počtem příchozích síťových připojení se věci trochu prodraží. A když se věci trochu zdraží, můžete nakonec zaplatit velmi vysokou cenu za spoustu síťových připojení.
Existují 3 možné přístupy:
- Na straně aplikace.
- Na straně databáze.
- A mezi tím, tedy všelijakými kombinacemi.
Vestavěný pooler je bohužel v současné době ve vývoji. Naši přátelé v PostgreSQL Professional to většinou dělají. Kdy se objeví, je těžké předvídat. A vlastně máme pro architekta na výběr dvě řešení. Jedná se o fond na straně aplikace a fond proxy.
Nejjednodušší způsob je bazén na straně aplikace. A téměř všechny klientské ovladače vám poskytují způsob: prezentovat miliony vašich připojení v kódu jako několik desítek připojení k databázi.
Problém, který vyvstává, je, že v určitém okamžiku chcete škálovat backend, chcete jej nasadit na mnoho virtuálních strojů.
Pak si uvědomíte, že máte několik dalších zón dostupnosti, několik datových center. A přístup sdružování na straně klienta vede k většímu počtu. Velké jsou asi 10 000 spojení. To je hrana, která může normálně fungovat.
Pokud mluvíme o proxy poolerech, pak existují dva pooleři, kteří umí spoustu věcí. Nejsou to jen pooleři. Jsou to poolery + více cool funkčnosti. Tento и .
Ale bohužel ne každý potřebuje tuto další funkci. A vede to k tomu, že poolery podporují pouze session pooling, tedy jeden příchozí klient, jeden odchozí klient do databáze.
To není pro naše účely příliš vhodné, proto používáme PgBouncer, který implementuje sdružování transakcí, tj. připojení k serveru se přiřazují ke klientským připojením pouze po dobu trvání transakce.
A v našem pracovním vytížení to platí. Je tu ale pár problémů.
Problémy začínají, když chcete diagnostikovat relaci, protože všechna vaše příchozí připojení jsou lokální. Všichni přišli se zpětnou smyčkou a nějak je obtížné vysledovat relaci.
Samozřejmě můžete použít application_name_add_host. Toto je způsob, jak na straně Bouncer přidat IP adresu do application_name. Název_aplikace je však nastaven dalším připojením.
Na tomto grafu, kde žlutá čára jsou skutečné požadavky a kde modrá čára jsou požadavky, které létají do databáze. A tímto rozdílem je právě instalace application_name, která je potřeba pouze pro trasování, ale není vůbec zadarmo.
V Bouncer navíc nemůžete omezit jeden fond, tedy počet databázových připojení na konkrétního uživatele, na konkrétní databázi.
K čemu to vede? Máte načtenou službu napsanou v C++ a někde poblíž malou službu na uzlu, která s databází nedělá nic hrozného, ale její ovladač se zbláznil. Otevře 20 000 spojení a vše ostatní počká. I váš kód je normální.
Samozřejmě jsme napsali malý patch pro Bouncer, který přidal toto nastavení, tedy omezení klientů na pool.
Bylo by to možné udělat na straně Postgres, tedy omezit role v databázi počtem připojení.
Ale pak ztratíte schopnost pochopit, proč nemáte připojení k serveru. PgBouncer nevyhodí chybu připojení, vždy vrátí stejnou informaci. A vy tomu nerozumíte: možná se vaše heslo změnilo, možná se databáze právě ztratila, možná je něco špatně. Ale žádná diagnóza neexistuje. Pokud relaci nelze navázat, nebudete vědět, proč ji nelze navázat.
V určitém okamžiku se podíváte na grafy aplikace a zjistíte, že aplikace nefunguje.
Podívejte se nahoru a uvidíte, že Bouncer je jednovláknový. Jedná se o zlomový okamžik v životě služby. Uvědomujete si, že jste se připravovali na škálování databáze za rok a půl a potřebujete škálovat pooler.
Došli jsme k závěru, že potřebujeme více PgBouncerů.
Bouncer byl trochu opraven.
A udělali to tak, že několik Bouncerů bylo možné vyvolat opětovným použitím TCP portu. A operační systém mezi nimi automaticky přenáší příchozí TCP spojení pomocí round-robin.
To je pro klienty transparentní, což znamená, že to vypadá, že máte jeden Bouncer, ale mezi běžícími Bouncery máte fragmentaci nečinných spojení.
A v určitém okamžiku si můžete všimnout, že tito 3 vyhazovači sežerou své jádro o 100%. Potřebujete několik vyhazovačů. Proč?
Protože máte TLS. Máte šifrované připojení. A pokud srovnáte Postgres s TLS a bez něj, zjistíte, že počet navázaných spojení klesne téměř o dva řády se zapnutým šifrováním, protože TLS handshake spotřebovává zdroje CPU.
A nahoře můžete vidět několik kryptografických funkcí, které se provádějí, když je vlna příchozích spojení. Vzhledem k tomu, že náš primární může přepínat mezi zónami dostupnosti, je vlna příchozích připojení poměrně typickou situací. To znamená, že z nějakého důvodu byla stará primární jednotka nedostupná, celá zátěž byla odeslána do jiného datového centra. Všichni přijdou zároveň pozdravit TLS.
A velké množství TLS handshake už nemusí Bouncerovi pozdravit, ale bude mu svírat hrdlo. Kvůli vypršení časového limitu může dojít k tomu, že vlna příchozích spojení nebude tlumená. Pokud se znovu pokusíte o základnu bez exponenciálního couvání, nebudou přicházet znovu a znovu v koherentní vlně.
Zde je příklad 16 PgBouncerů, které zatěžují 16 jader na 100 %.
Došli jsme ke kaskádě PgBouncer. Toto je nejlepší konfigurace, které lze dosáhnout na našem nákladu s Bouncerem. Naše externí vyhazovače se používají pro TCP handshake a interní vyhazovači se používají pro skutečné sdružování, aby příliš nefragmentovaly externí připojení.
V této konfiguraci je možný hladký restart. Všech těchto 18 Bouncerů můžete restartovat jeden po druhém. Udržet takovou konfiguraci je ale docela obtížné. Sysadmins, DevOps a lidé, kteří jsou ve skutečnosti zodpovědní za tento server, nebudou s tímto uspořádáním příliš spokojeni.
Zdálo by se, že všechna naše vylepšení lze povýšit na open source, ale Bouncer není příliš podporován. Například schopnost spustit několik PgBouncerů na jednom portu byla potvrzena před měsícem. Před několika lety se objevil požadavek na stažení této funkce.
Nebo ještě jeden příklad. V Postgresu můžete zrušit probíhající požadavek odesláním tajného klíče na jiné připojení bez zbytečného ověřování. Někteří klienti však jednoduše pošlou reset TCP, tj. přeruší síťové připojení. Co udělá Bouncer? Neudělá nic. Bude pokračovat v provádění požadavku. Pokud jste obdrželi velké množství připojení, která vytvořila databázi s malými požadavky, pak nebude stačit pouhé odpojení připojení od Bouncer, musíte také dokončit ty požadavky, které běží v databázi.
Toto bylo opraveno a tento problém ještě nebyl začleněn do upstreamu Bouncer.
A tak jsme došli k závěru, že potřebujeme vlastní pooler připojení, který se bude vyvíjet, záplatovat, ve kterém lze rychle opravovat problémy a který samozřejmě musí být vícevláknový.
Jako hlavní úkol jsme nastavili multithreading. Musíme umět dobře zvládnout vlnu příchozích TLS spojení.
K tomu jsme museli vyvinout samostatnou knihovnu nazvanou Machinarium, která je navržena tak, aby popisovala stavy stroje síťového připojení jako sekvenční kód. Pokud se podíváte na zdrojový kód libpq, uvidíte několik docela složitých volání, která vám mohou vrátit výsledek a říci: „Zavolejte mi později. Momentálně mám IO, ale když IO odejde, budu mít zátěž na procesoru.“ A toto je víceúrovňové schéma. Síťová komunikace je obvykle popsána stavovým automatem. Spousta pravidel jako „Pokud jsem dříve obdržel hlavičku paketu o velikosti N, nyní čekám na N bajtů“, „Pokud jsem odeslal paket SYNC, nyní čekám na paket s metadaty výsledku.“ Výsledkem je poměrně obtížný, neintuitivní kód, jako by bludiště bylo převedeno na řádkové skenování. Udělali jsme to tak, že místo stavového automatu programátor popisuje hlavní cestu interakce ve formě běžného imperativního kódu. Jde jen o to, že v tomto imperativním kódu musíte vložit místa, kde je třeba přerušit sekvenci provádění čekáním na data ze sítě, předáním kontextu provádění do jiné korutiny (zelené vlákno). Tento přístup je podobný tomu, že zapisujeme nejočekávanější cestu v bludišti za sebou a pak k ní přidáváme větve.
Výsledkem je, že máme jedno vlákno, které TCP akceptuje a opakovaně předává připojení TPC mnoha pracovníkům.
V tomto případě každé klientské připojení běží vždy na jednom procesoru. A to vám umožňuje, aby byl přátelský ke cache.
A navíc jsme mírně vylepšili shromažďování malých paketů do jednoho velkého, abychom odlehčili systémovému TCP stacku.
Kromě toho jsme vylepšili transakční sdružování v tom smyslu, že Odyssey, když je nakonfigurován, může odeslat CANCEL a ROLLBACK v případě selhání síťového připojení, tj. pokud nikdo nečeká na požadavek, Odyssey řekne databázi, aby se nepokoušela splnit požadavek, který může plýtvat drahocennými zdroji.
A kdykoli je to možné, udržujeme spojení se stejným klientem. Vyhnete se tak nutnosti přeinstalování application_name_add_host. Pokud je to možné, pak nemusíme dodatečně přenastavovat parametry, které jsou potřebné pro diagnostiku.
Pracujeme v zájmu Yandex.Cloud. A pokud používáte spravovaný PostgreSQL a máte nainstalovaný pooler připojení, můžete vytvořit logickou replikaci směrem ven, tj. nechat nás, pokud chcete, pomocí logické replikace. Bouncer neuvolní tok logické replikace venku.
Toto je příklad nastavení logické replikace.
Kromě toho máme podporu pro fyzickou replikaci směrem ven. V Cloudu je to samozřejmě nemožné, protože pak vám o sobě cluster poskytne příliš mnoho informací. Ale ve vašich instalacích, pokud potřebujete fyzickou replikaci prostřednictvím pooleru připojení v Odyssey, je to možné.
Odyssey má plně kompatibilní monitorování s PgBouncer. Máme stejnou konzoli, která spouští téměř všechny stejné příkazy. Pokud něco chybí, pošlete pull request nebo alespoň problém na GitHubu a my potřebné příkazy dokončíme. Ale už tu máme hlavní funkcionalitu konzole PgBouncer.
A samozřejmě máme přeposílání chyb. Chybu nahlášenou databází vrátíme. Dostanete informaci, proč nejste zařazeni do databáze, a nejen to, že v ní nejste.
Tato funkce je zakázána v případě, že potřebujete 100% kompatibilitu s PgBouncer. Můžeme se pro jistotu chovat stejně jako Bouncer.
Vývoj
Pár slov o zdrojovém kódu Odyssey.
Existují například příkazy „Pauza / Pokračovat“. Obvykle se používají k aktualizaci databáze. Pokud potřebujete aktualizovat Postgres, můžete jej pozastavit v pooleru připojení, provést pg_upgrade a poté pokračovat. A ze strany klienta to bude vypadat, jako by se databáze prostě zpomalovala. Tuto funkcionalitu nám přinesli lidé z komunity. Ještě není zmrzlá, ale brzy bude všechno. (již zamrzlé)
- již zamrzlé
Jednou z novinek v PgBouncer je navíc podpora SCRAM Authentication, kterou nám také přinesl člověk, který nepracuje v Yandex.Cloud. Oba jsou komplexní a důležité.
Proto bych vám rád řekl, z čeho se Odyssey skládá, pro případ, že byste si nyní také chtěli napsat malý kód.
Máte zdrojovou základnu Odyssey, která se opírá o dvě hlavní knihovny. Knihovna Kiwi je implementací protokolu zpráv Postgres. To znamená, že nativní proto 3 Postgresu jsou standardní zprávy, které si front-endy a back-endy mohou vyměňovat. Jsou implementovány v knihovně Kiwi.
Knihovna Machinarium je knihovna pro implementaci vláken. Malý fragment tohoto Machinaria je napsán v assembleru. Ale nelekejte se, je tam jen 15 řádků.
Architektura Odyssey. Existuje hlavní stroj, na kterém běží korutiny. Tento stroj implementuje přijímání příchozích TCP spojení a jejich distribuci mezi pracovníky.
V rámci jednoho pracovníka může pracovat handler pro více klientů. Hlavní vlákno také spouští konzolu a zpracovává úlohy crone za účelem odstranění připojení, která již nejsou ve fondu potřebná.
Odyssey se testuje pomocí standardní testovací sady Postgres. Prostě spustíme install-check přes Bouncer a přes Odyssey, dostaneme null div. Existuje několik testů souvisejících s formátováním data, které neprojdou úplně stejně v Bouncer a v Odyssey.
Kromě toho existuje mnoho ovladačů, které mají své vlastní testování. A používáme jejich testy k testování Odyssey.
Navíc kvůli naší kaskádové konfiguraci musíme otestovat různé balíčky: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, abychom měli jistotu, že pokud Odyssey skončí v některém z dílů kaskády, také stále funguje jak očekáváme.
Hrábě
Při výrobě používáme Odyssey. A nebylo by fér, kdybych řekl, že všechno prostě funguje. Ne, tedy ano, ale ne vždy. Například ve výrobě prostě všechno fungovalo, pak přišli naši přátelé z PostgreSQL Professional a řekli, že máme únik paměti. Opravdu byly, opravili jsme je. Ale bylo to jednoduché.
Pak jsme zjistili, že sdružovač připojení má příchozí připojení TLS a odchozí připojení TLS. A připojení vyžadují klientské certifikáty a certifikáty serveru.
Certifikáty serveru Bouncer a Odyssey jsou znovu čteny pomocí jejich pcache, ale klientské certifikáty není nutné znovu číst z pcache, protože naše škálovatelné Odyssey nakonec narazí na výkon systému při čtení tohoto certifikátu. To nás překvapilo, protože netrvalo dlouho, než odolal. Zpočátku se škáloval lineárně, ale po 20 000 příchozích simultánních připojeních se tento problém projevil.
Pluggable Authentication Method je schopnost autentizace pomocí vestavěných nástrojů Lunux. V PgBouncer je implementován tak, že existuje samostatné vlákno, které čeká na odpověď od PAM, a hlavní vlákno PgBouncer, které obsluhuje aktuální připojení a může je požádat, aby žily ve vláknu PAM.
Toto jsme nezavedli z jednoho prostého důvodu. Máme spoustu vláken. Proč tohle potřebujeme?
To může v konečném důsledku způsobit problémy v tom, že pokud máte autentizaci PAM a autentizaci bez PAM, pak velká vlna autentizace PAM může výrazně zpozdit autentizaci bez PAM. To je jedna z věcí, kterou jsme nevyřešili. Ale pokud to chcete opravit, můžete to udělat.
Další výhodou bylo, že máme jedno vlákno, které přijímá všechna příchozí spojení. A pak jsou přeneseni do workpoolu, kde proběhne TLS handshake.
Sečteno a podtrženo, pokud máte koherentní vlnu 20 000 síťových připojení, budou přijata všechna. A na straně klienta libpq začne hlásit časové limity. Ve výchozím nastavení se zdá, že jsou 3 sekundy.
Pokud všichni nemohou vstoupit do databáze současně, pak nemohou vstoupit do databáze, protože to vše lze pokrýt neexponenciálním opakováním.
Došli jsme k závěru, že jsme sem zkopírovali schéma z PgBouncer s tím, že máme omezující počet TCP spojení, na které přijímáme.
Pokud vidíme, že přijímáme připojení, ale nakonec nemají čas na handshake, zařadíme je do fronty, aby neplýtvali prostředky CPU. To vede k tomu, že současné podání ruky nemusí být provedeno pro všechna spojení, která dorazila. Ale aspoň někdo vstoupí do databáze, i když je zátěž docela velká.
plán
Co byste v Odyssey chtěli v budoucnu vidět? Co jsme připraveni sami rozvíjet a co očekáváme od komunity?
Od srpna 2019.
Takto vypadal plán Odyssey v srpnu:
- Chtěli jsme autentizaci SCRAM a PAM.
- Chtěli jsme předávat požadavky na čtení do pohotovostního režimu.
- Chtěl bych restart online.
- A možnost pauzy na serveru.
Polovina tohoto plánu byla dokončena a ne my. A to je dobré. Pojďme tedy diskutovat o tom, co zbývá, a přidat další.
? Máme repliky, které jednoduše ohřejí vzduch bez provádění požadavků. Potřebujeme je k zajištění převzetí služeb při selhání a přepnutí. V případě problémů v některém z datových center bych je rád zaměstnal nějakou užitečnou prací. Protože nemůžeme konfigurovat stejné centrální procesory, stejnou paměť jinak, protože jinak replikace nebude fungovat.
V Postgresu je v zásadě od 10 možné zadat session_attrs při připojování. Můžete vypsat všechny databázové hostitele v připojení a říci, proč do databáze přecházíte: zápis nebo pouze čtení. A řidič sám vybere prvního hostitele ze seznamu, který se mu nejvíce líbí a který splňuje požadavky session_attrs.
Ale problém s tímto přístupem je, že neřídí zpoždění replikace. Je možné, že máte nějakou repliku, která pro vaši službu zaostává nepřijatelně dlouho. Abychom umožnili plnohodnotné provádění čtecích dotazů na replice, musíme v podstatě podporovat schopnost Odyssey nespouštět se, když ji nelze číst.
Odyssey musí čas od času zajít do databáze a zeptat se na vzdálenost replikace od primární. A pokud dosáhl limitní hodnoty, nepovolovat nové požadavky do databáze, sdělit klientovi, že potřebuje znovu inicializovat připojení a případně vybrat jiného hostitele pro provádění požadavků. To umožní databázi rychle obnovit zpoždění replikace a znovu se vrátit, aby odpověděla požadavkem.
Je těžké dát časový rámec pro implementaci, protože je to open source. Ale doufám, že ne 2,5 roku jako moji kolegové z PgBouncer. To je funkce, kterou bych rád viděl v Odyssey.
. Nyní můžete vytvořit připravený výpis dvěma způsoby. Nejprve můžete provést příkaz SQL, konkrétně "připraveno". Abychom porozuměli tomuto SQL příkazu, musíme se naučit rozumět SQL na straně Bouncer. To by bylo přehnané, protože je to přehnané, protože potřebujeme celý analyzátor. Nemůžeme analyzovat každý příkaz SQL.
Existuje však připravené prohlášení na úrovni protokolu zpráv na proto3. A právě zde přichází ve strukturované podobě informace o tom, že vzniká připravený výpis. A mohli bychom podpořit pochopení, že na nějakém připojení k serveru klient požádal o vytvoření připravených příkazů. A i když je transakce uzavřena, stále musíme udržovat konektivitu mezi serverem a klientem.
Zde ale vzniká rozpor v dialogu, protože někdo říká, že je třeba rozumět tomu, jaké připravené příkazy klient vytvořil, a sdílet serverové připojení mezi všemi klienty, kteří toto připojení k serveru vytvořili, tedy kdo takový připravený výpis vytvořil.
Andres Freund řekl, že pokud k vám přijde klient, který již takto připravený výpis vytvořil v jiném připojení k serveru, tak mu ho vytvořte. Zdá se ale trochu špatné provádět dotazy v databázi místo klienta, ale z pohledu vývojáře, který píše protokol pro interakci s databází, by bylo vhodné, kdyby mu bylo jednoduše přiděleno síťové připojení, ve kterém existuje takový připravený dotaz.
A ještě jedna funkce, kterou musíme implementovat. Nyní máme monitorování kompatibilní s PgBouncer. Můžeme vrátit průměrnou dobu provádění dotazu. Ale průměrná doba je průměrná teplota v nemocnici: někomu je zima, někomu teplo – v průměru jsou všichni zdraví. To není pravda.
Potřebujeme implementovat podporu pro percentily, které by naznačovaly, že existují pomalé dotazy, které plýtvají zdroji, a učinily monitorování přijatelnějším.
Nejdůležitější je, že chci verzi 1.0 (verze 1.1 již vyšla). Faktem je, že Odyssey je nyní ve verzi 1.0rc, tedy kandidát na vydání. A všechny problémy, které jsem uvedl, byly opraveny přesně stejnou verzí, s výjimkou úniku paměti.
Co pro nás bude verze 1.0 znamenat? Rozjíždíme Odyssey na naše základny. Již běží na našich databázích, ale když dosáhne bodu 1 000 000 požadavků za sekundu, pak můžeme říci, že toto je verze vydání a toto je verze, kterou lze nazvat 1.0.
Několik lidí v komunitě požádalo, aby verze 1.0 obsahovala pauzu a SCRAM. To ale bude znamenat, že budeme muset uvést do produkce další verzi, protože SCRAM ani pauza ještě nebyly zabity. Ale s největší pravděpodobností bude tento problém vyřešen poměrně rychle.
Čekám na vaši žádost o stažení. Také bych rád slyšel, jaké máte problémy s Bouncerem. Pojďme o nich diskutovat. Možná můžeme implementovat některé funkce, které potřebujete.
Toto je konec mé části, rád bych si vás poslechl. Děkuji!
otázky
Pokud nastavím svůj vlastní název_aplikace, bude správně předán, včetně sdružování transakcí v Odyssey?
Odyssey nebo Bouncer?
V Odyssey. V Bounceru se to hází.
Uděláme sadu.
A pokud moje skutečné spojení naskočí na jiná spojení, bude to přenášeno?
Uděláme sadu všech parametrů, které jsou uvedeny v seznamu. Nemohu říci, zda je název_aplikace v tomto seznamu. Myslím, že jsem ho tam viděl. Všem nastavíme stejné parametry. Na jeden požadavek sada udělá vše, co si klient při startu nainstaloval.
Děkuji, Andrey, za zprávu! Dobrá zpráva! Jsem rád, že se Odyssey každou minutou vyvíjí rychleji a rychleji. Chci takto pokračovat. Již jsme vás požádali o připojení k více zdrojům dat, aby se Odyssey mohla připojit k různým databázím současně, tedy k master slave, a poté se automaticky připojit k novému masteru po převzetí služeb při selhání.
Ano, zdá se, že si tuto diskuzi pamatuji. Nyní existuje několik úložišť. Mezi nimi ale nedochází k přepínání. Na naší straně se musíme dotázat serveru, že je stále naživu, a pochopit, že došlo k převzetí služeb při selhání, který zavolá pg_recovery. Mám standardní způsob, jak pochopit, že jsme nepřišli k pánovi. A máme z chyb nějak rozumět nebo co? Čili myšlenka je zajímavá, diskutuje se o ní. Napište další komentáře. Pokud máte pracovníky, kteří znají C, pak je to skvělé.
Problematika škálování napříč replikami nás také zajímá, protože chceme vývojářům aplikací co nejvíce zjednodušit přijetí replikovaných clusterů. Ale tady bych chtěl více komentářů, tedy jak přesně to udělat, jak to udělat dobře.
Otázka se týká i replik. Ukázalo se, že máte předlohu a několik replik. A je jasné, že do repliky chodí pro spoje méně často než do mastera, protože mohou mít rozdíly. Řekl jste, že rozdíl v datech může být takový, že neuspokojí vaše podnikání a nepůjdete tam, dokud nebudou replikovány. Zároveň, pokud jste tam dlouho nechodili a pak začali chodit, pak nebudou potřebná data okamžitě k dispozici. To znamená, že pokud neustále chodíme k masteru, pak je tam keš zahřátá, ale v replice keš trochu pokulhává.
Ano, je to pravda. pcache nebude mít bloky dat, které chcete, skutečná cache nebude mít informace o tabulkách, které chcete, plány nebudou mít parsované dotazy, nebude tam vůbec nic.
A když máš nějaký cluster, a přidáš tam novou repliku, tak když se spustí, tak je v něm všechno špatně, tedy zvětšuje si cache.
Dostal jsem nápad. Správným přístupem by bylo spustit nejprve malé procento dotazů na replice, což by zahřívalo mezipaměť. Zhruba řečeno, máme podmínku, že za mistrem nesmíme zaostávat o více než 10 sekund. A tato podmínka není zařazena v jedné vlně, ale u některých klientů plynule.
Ano, zvýšit váhu.
To je dobrý nápad. Nejprve ale musíme toto vypnutí implementovat. Nejprve musíme vypnout a pak přemýšlíme o tom, jak zapnout. To je skvělá funkce, která umožňuje plynule.
Nginx má tuto možnost slowly start v clusteru pro server. A postupně zvyšuje zátěž.
Ano, skvělý nápad, vyzkoušíme, až se k tomu dostaneme.
Zdroj: www.habr.com