Nová funkce Hot Standby v připravovaném PostgreSQL 9.0 umožňuje spouštění dotazů proti pohotovostním uzlům, které dříve nedělaly nic jiného než prováděly proces obnovy. Dvě běžná očekávání, která jsem slyšel od uživatelů, kteří očekávají tuto funkci, jsou, že umožní buď distribuci krátkých dotazů přes oba uzly, nebo umožní spouštění dlouhých sestav v pohotovostním režimu bez použití prostředků na hlavním serveru. Obojí je možné provést právě teď, ale pokud nerozumíte kompromisům v tom, jak funguje Hot Standby, může zde dojít k neočekávanému chování.
Standardní dlouhodobé dotazy
Jedním z tradičních problémů v databázi využívající MVCC, jako je PostgreSQL, je to, že dlouhotrvající dotaz musí udržovat otevřený zdroj – označovaný jako snímek v aktuální implementaci Postgres – aby zabránil databázi v odstranění dat, která dotaz potřebuje. fungovat. Například jen proto, že jiný klient odstranil řádek a potvrdil, pokud již běžící dotaz potřebuje tento řádek dokončit, nemůžete ve skutečnosti vymazat bloky fyzického disku související s tímto řádkem. Musíte počkat, dokud nebudou k dispozici žádné otevřené dotazy, které očekávají, že bude daný řádek viditelný.
Omezení aktivního pohotovostního režimu
Pokud máte dlouhotrvající dotaz, který chcete, aby Hot Standby provedl, existuje několik typů špatných věcí, které se mohou stát, když proces obnovy aplikuje aktualizace. Ty jsou podrobně popsány v dokumentaci Hot Standby. Některé z těchto špatných věcí způsobí, že dotazy běžící v pohotovostním režimu budou zrušeny z důvodů, které nemusí být intuitivně zřejmé:
- Dorazí HOT aktualizace nebo aktualizace související s VACUUM, aby smazala něco, co dotaz očekává, že bude viditelné
- Objeví se smazání B-stromu
- Mezi spuštěným dotazem a tím, jaké zámky jsou nutné pro zpracování aktualizace, je problém se zamykáním.
Situaci zámku je obtížné řešit, ale není velmi pravděpodobné, že se v praxi stane tak dlouho, pokud v pohotovostním režimu spouštíte pouze dotazy pouze pro čtení, protože ty budou izolovány prostřednictvím MVCC. Na další dva není těžké narazit. Základní věcí je pochopit, že jakýkoli UPDATE nebo DELETE na masteru může vést k přerušení jakéhokoli dotazu v pohotovostním režimu; nezáleží na tom, zda se změny vůbec týkají toho, co dotaz dělá.
Dobré, rychlé, levné:vyberte si dva
V zásadě existují tři věci, které by lidé mohli chtít upřednostnit:
- Vyhněte se omezování hlavního:Umožněte xid a souvisejícím snímkům neomezený postup na hlavní, takže VACUUM a podobné čištění nebude zdržováno tím, co dělá pohotovostní režim
- Neomezený počet dotazů:Spouštějte dotazy v pohotovostním režimu po libovolně dlouhou dobu
- Aktuální obnova:Udržujte proces obnovy v pohotovostním režimu aktuální s tím, co se děje na hlavním serveru, což umožňuje rychlé převzetí služeb při selhání pro HA
V jakékoli situaci s Hot Standby je doslova nemožné mít všechny tři najednou. Můžete si vybrat pouze svůj kompromis. Dostupné laditelné parametry vám již umožňují optimalizovat několika způsoby:
- Zakázáním všech těchto nastavení zpoždění/odložení se optimalizuje vždy aktuální obnovení, ale pak zjistíte, že dotazy budou zrušeny s větší pravděpodobností, než byste čekali.
- max_standby_delay optimalizuje pro delší dotazy na úkor zachování aktuální obnovy. Jakmile se objeví aktualizace, která způsobí problém (HOT, VACUUM, odstranění B-stromu atd.), zpozdí se tím použití aktualizací do pohotovostního režimu.
- vacuum_defer_cleanup_age a některé snapshot hacky mohou zavést nějaké hlavní omezení, aby se zlepšily další dva problémy, ale se slabým uživatelským rozhraním. Vacuum_defer_cleanup_age je v jednotkách ID transakcí. Musíte mít určitou představu o průměrném množství odchodu xid ve vašem systému za jednotku času, abyste změnili způsob, jakým lidé přemýšlejí o tomto problému („odložit alespoň o 1 hodinu, aby se mé zprávy spustily“), na nastavení této hodnoty. Míra spotřeby xid prostě není běžná nebo dokonce rozumná věc, kterou lze měřit/předvídat. Alternativně můžete před spuštěním dlouhotrvajícího dotazu v pohotovostním režimu otevřít snímek na primárním zařízení. dblink je navržen v dokumentaci Hot Standby jako způsob, jak toho dosáhnout. Teoreticky by mohl být démon v pohotovostním režimu napsán v uživatelském prostředí, žijícím na primárním zařízení, aby se tento problém také vyřešil (Simon má pro jednoho základní návrh). V zásadě spustíte řadu procesů, z nichž každý získá snímek a poté po určitou dobu uspí, než jej uvolní. Rozložením toho, jak dlouho každý spal, můžete zajistit, aby se snímky xid nikdy neposunuly dopředu příliš rychle na hlavní. Už by to mělo znít jasně, jak moc by to byl hrozný hack.
Potenciální vylepšení
Jediný z nich, se kterým můžete skutečně něco udělat, je zpřísnění a vylepšení uživatelského rozhraní pro hlavní omezení. Tím se z toho stává tradiční problém, který se již v databázi vyskytuje:dlouhotrvající dotaz zadržuje otevřený snímek (nebo alespoň omezuje předávání ID transakcí souvisejících s viditelností) na hlavním serveru, čímž brání hlavnímu serveru odstranit věci potřebné pro tento dotaz. kompletní. Můžete si to alternativně představit jako automatické ladění Vacuum_defer_cleanup_age.
Otázkou je, jak udělat primární respektovat potřeby dlouhotrvajících dotazů v pohotovostním režimu . To by mohlo být možné, pokud by bylo masteru sdíleno více informací o požadavcích na viditelnost transakcí v pohotovostním režimu. Provedení tohoto druhu výměny by bylo pro novou implementaci replikace streamování skutečně vhodnější ke sdílení. Způsob poskytování jednoduchého serveru Hot Standby neposkytuje žádnou zpětnou vazbu směrem k hlavnímu serveru vhodnému pro výměnu těchto dat, kromě přístupů, jako je již zmíněný dblink hack.
S PostgreSQL 9.0, který právě dosáhl čtvrtého alfa vydání, může ještě před vydáním 9.0 je čas vidět nějaká vylepšení v této oblasti. Bylo by hezké vidět Hot Standby a Streaming Replication skutečně integrované dohromady způsobem, který dosahuje věcí, které ani jeden z nich není plně schopen dělat sám, než kódování v tomto vydání zcela zamrzne.