PostgreSQL přichází s vynikající sadou funkcí, které nemají v open-source RDBMS prostoru obdoby. Většinou se snadno učí a používá, zejména pro vývojáře aplikací. Některé části však nejsou jednoduché. Vyžadují práci k nastavení a správnému nastavení a jsou také obvykle kritické.
Správa připojení
PostgreSQL spouští nový proces, nazvaný proces backend , abyste zvládli každé připojení. To je v kontrastu s moderními architekturami pro zpracování připojení založených na událostech/vláknech, které se nacházejí v jiném srovnatelném serverovém softwaru. Vytvoření celého procesu vyžaduje více času a prostředků a projevuje se zvýšenou latencí dotazů v aplikacích, kde se spojení otevírají a zavírají vysokou rychlostí.
Ve většině nasazení je na určité úrovni vyžadováno sdružování připojení. Na úrovni aplikace to může být použití funkcí vašeho programovacího jazyka/knihovny. Například sql/DB.SetMaxIdleConns lze použít ke zvýšení opětovného použití připojení z jediné aplikace Go.
Často však budete muset použít sdružování připojení nebo řešení pro vyrovnávání zátěže od třetí strany. Sdružení připojení udržují fond nečinných připojení k nadřazenému serveru Postgres, která jsou přiřazena a proxy k příchozím připojením klientů. Obvykle analyzují SQL zaslané klienty, aby rozpoznali hranice transakcí a DML upravující data, aby implementovali funkce, jako je sdružování připojení na úrovni transakce a repliky čtení.
PgBouncer je populární, odlehčený, single-binaryconnection pooler a často běží spolu s PostgreSQL ve stejném systému.
PgPool je všestrannější než PgBouncer. Může také například provádět vyrovnávání zátěže a replikaci.
Sdružování připojení však přináší svou vlastní sadu bolestí hlavy. Za prvé, je to další pohyblivá část, která byla udržována ve vašem nasazení. Nastavení autentizace je také nepříjemné, pokud máte klienty, kteří používají různá pověření nebo autentizační mechanismy. Některé funkce na úrovni připojení, jako je LISTEN/NOTIFY, připravené příkazy, dočasné tabulky a podobně, mohou vyžadovat zvláštní konfiguraci nebo změny na straně klienta, aby fungovaly.
Nulový výpadek upgradů
Upgrade PostgreSQL mezi menšími verzemi (13.x -> 13.y) zahrnuje instalaci nového balíčku a restartování serveru. I když restartování procesu serveru nutně naruší všechny připojené klienty, je to stále rozumný požadavek, vzhledem k tomu, že výpadek je vázán na dobu trvání restartu služby.
Upgrade mezi hlavními verzemi (12.x -> 13.y) je však mnohem větší problém. Obvykle platí, že čím více dat je, tím bolestnější je proces.
Nejjednodušší metodou, která funguje pouze pro malé množství dat (řekněme desítky GB), je vypsat data ze staré verze a obnovit je na server nové verze. Další možností je použít pg_upgrade, což vyžaduje organizovaný tanec. zahrnující binární soubory obou verzí Postgres.
V obou případech by databáze byly mimo provoz na značnou dobu.
V ideálním případě by mělo být možné replikovat na server nové verze a propagovat server nové verze jako primární. Není však možné provádět streamovanou replikaci na záložní server s jinou hlavní verzí. Logická replikace, i když vypadá pro tuto úlohu jako vhodná, má určité problémy, které je třeba obejít, aby byla zajištěna úplná replikace.
Většina řešení HA pro Postgres spoléhá na streamovací replikaci, a proto nemůžete upgradovat uzly v clusteru jeden po druhém.
Současný stav techniky by spočíval v použití logické replikace, přičemž by se dalo obejít omezení logické replikace a případně zahrnovat omezení funkcí, které mohou aplikace používat (jako DDL) během fáze upgradu.
Vysoká dostupnost
PostgreSQL přichází se všemi nízkoúrovňovými funkcemi potřebnými k vytvoření HAsolution:replikace se zpětnou vazbou, kaskádová replikace, synchronní replikace, pohotovostní režimy, horké pohotovostní režimy, podpora pohotovostního režimu a tak dále. Ve skutečnosti však neposkytuje řešení HA ihned po vybalení. Existují noframeworks nebo nástroje pro monitorování stavu a automatické převzetí služeb při selhání do pohotovostního režimu. Neexistuje žádná představa o víceuzlovém HA clusteru.
Budete muset nastavit a spustit řešení třetí strany pro vytváření vysoce dostupných nasazení Postgres. Aktuální oblíbení jsoupg_auto_failover a Patroni. Zatímco Patroni spoléhá na existující vysoce dostupný konfigurační obchod, jako je ZooKeeper nebo etcd, pg_auto_failover si vystačí i bez něj.
Vyhodnocení, nasazení a testování jednoho z nich v produkci vyžaduje čas a úsilí. Je třeba nastavit a udržovat příručky pro monitorování, upozornění a operace.
Správa nadbytku
Architektura MVCC PostgreSQL znamená, že žádná data nejsou nikdy přepsána – úprava řádku má za následek pouze zápis nové verze řádku na disk. Smazání řádku znamená pouze zaznamenání toho, že řádek je pro budoucí transakce neviditelný. Když je řádková verze nepřístupná z jakýchkoli probíhajících nebo budoucích transakcí, již není k ničemu a nazývá se „nadut“. Proces shromažďování tohoto odpadu se nazývá „vakuum“.
Bloat je pro aplikace neviditelný a stává se z něj pouze bolest hlavy DBA. U tabulek náročných na aktualizace je monitorování a správa nadýmání netriviální záležitostí. Proces autovakuování hodně pomáhá, ale jeho prahové hodnoty bude možná nutné vyladit na globální nebo per- tablelevel, abyste zajistili, že velikosti tabulek nenarostou neovladatelně velké.
Indexy jsou také ovlivněny nadýmáním a autovakuum zde nepomáhá. Odstranění řádků a aktualizace indexovaných sloupců vede k mrtvým položkám v indexech. Náročné aktualizace s aktualizacemi indexovaných sloupců mohou vést k neustále rostoucím a neefektivním indexům. Pro indexy neexistuje ekvivalent vakua. Jediným řešením je přestavět celý index pomocí REINDEX nebo použít VACUUM FULL na stole.
Kromě jediné hodnoty na tabulku (pg_stat_all_tables.n_dead_tup), Postgres nenabízí nic, co by stálo v cestě k odhadu nadýmání v tabulce, a vůbec nic pro indexy. Nejpraktičtějším způsobem stále zůstává provedení děsivě vyhlížejícího dotazu z check_postgres.
pgmetrics zahrnuje dotaz z check_postgres a dokáže vytvořit výstup ve formátu JSON a CSV, který obsahuje informace o velikosti a nafouknutí pro všechny tabulky a indexy; které mohou být vloženy do monitorovacích nebo automatizačních nástrojů.
pg_repack je oblíbená alternativa k VACUUM FULL – zvládne stejnou práci, ale bez zámků. Pokud jste nuceni pravidelně provádět VACUUM FULL, je to nástroj, který musíte prozkoumat.
zheap je nový úložný modul pro Postgres, který se vyvíjel roky a který slibuje snížení blotu prostřednictvím aktualizací na místě.
Správa plánu dotazů
Core PostgreSQL nabízí v tomto prostoru pouze dva základní nástroje:
- pg_stat_statements rozšíření pro analýzu dotazů – poskytuje celkový a průměrný čas plánování a provádění dotazů, využití disku a paměti
- auto_explain rozšíření, které může tisknout plány provádění dotazů do cílového umístění protokolu Postgres
Zatímco statistiky poskytované pg_stat_statements jsou tak akorát k tomu, abyste se dostali, pomocí auto_explain vnutit plány do protokolových souborů a poté extrahovat je ve skutečnosti není víc než hack, zvláště ve srovnání s komerčními konkurenty Postgres, kteří nabízejí historii plánu, základní linii a funkce správy.
Současný stav techniky s Postgresem je těžit protokolový soubor pro plány dotazování a ukládat je jinde. Ale možná největším handicapem je nemožnost spojit plán dotazů s odpovídající analytikou z pg_stat_statements. Způsob, jakým to pgDash dělá, je analyzovat jak texty SQL dotazu z pg_stat_statements, tak výstup auto_explain, upravit pro mandlování provedené pg_stat_statements a pokusit se je porovnat. Vyžaduje úplný analyzátor SQL dialektu PostgreSQL.
Baselining, nastavení zásad pro výběr plánu atd. prostě v současné době v základním PostgreSQL není možné.
Existuje několik rozšíření, která jsou v podstatě vylepšenými verzemi pg_stat_statements, ale další kroky spojené s používáním rozšíření třetí strany z něj dělají problém pro většinu lidí, zvláště pokud používají spravovaného poskytovatele Postgres.
Ladění
PostgreSQL má nepřeberné množství možností ladění, počínaje nastavením under-configured-by-defaultshared_buffersetting. Některé jsou snadno pochopitelné a nastavitelné, například počet paralelních pracovníků pro různé operace (max_worker_processes, max_parallel_* atd.). Ostatní oblasti jsou trochu nejasné (wal_compression, random_page_cost atd.), ale obecně jsou přínosné. Nejvíce znepokojující jsou však ty, které potřebují kvantifikovatelné informace o pracovní zátěži.
Například pokud work_mem je příliš nízká, dotazy mohou používat dočasné soubory na disku; pokud jsou příliš vysoké a existuje dostatek současných dotazů, mohou být backendprocesy Postgresu zničeny OOM. Jak tedy zjistíte, jaké číslo jej nastavit?
Prakticky, zejména s pracovní zátěží OLTP a pracovní zátěží webových aplikací, je nemožné předpovědět, jaká bude špičková paměťová náročnost pro dotazy. Nejlepším řešením je nastavit mu přiměřenou hodnotu a poté sledovat dotazy, abyste zjistili, zda některý z nich mohl mít prospěch z vyšší hodnoty work_mem.
a jak to děláš? Budete si muset pořídit rozšíření auto_explain Chcete-li protokolovat plány provádění dotazů každého dotazu, extrahujte je ze souborů protokolu Postgres, prozkoumejte každý plán dotazu, abyste zjistili, zda používá externí sloučení na disku nebo skenování bitmapové haldy se ztrátovými bloky haldy.
Není to nemožné, jen těžké.