Usnadnění správy produkční databáze PostgreSQL

V posledních několika letech jsme zaznamenali rostoucí osvojení PostgreSQL. PostgreSQL je úžasná relační databáze. Pokud jde o funkce, je tam nahoře s nejlepšími, ne-li nejlepšími. Miluji na něm mnoho věcí – PL/PG SQL, chytrá výchozí nastavení, replikace (která ve skutečnosti funguje hned po vybalení) a aktivní a pulzující open source komunita. Kromě funkcí však existují další důležité aspekty databáze, které je třeba vzít v úvahu. Pokud plánujete vybudovat velký 24/7 provoz, velmi důležitým faktorem se stává možnost snadného ovládání databáze, jakmile je v produkci. V tomto ohledu PostgreSQL příliš neobstojí. V tomto příspěvku na blogu podrobně popíšeme některé z těchto provozních problémů s PostgreSQL. Zde není nic zásadně neopravitelného, ​​jen otázka priorit. Doufejme, že dokážeme vyvolat dostatečný zájem v komunitě open source, abychom upřednostnili tyto funkce.

1. Žádná automatická detekce přepnutí při selhání hlavního klienta

Klientský ovladač PostgreSQL automaticky nezjistí, kdy došlo k hlavnímu převzetí služeb při selhání (a byl zvolen nový hlavní server). Aby to mohli správci obejít, musí nasadit vrstvu proxy na straně serveru. Oblíbené možnosti jsou mapování DNS, mapování virtuálních IP, PgPool a HAProxy. Všechny tyto možnosti lze nastavit tak, aby dobře fungovaly, ale vyžaduje to značné dodatečné učení a úsilí správce. V případě, že je v datové cestě zaveden proxy, má to také značný dopad na výkon. Jedná se o standardní vestavěnou funkci v mnoha nových NoSQL databázích a PostgreSQL by bylo skvělé, kdyby z nich vytrhl list, pokud jde o operace.

2. Žádné vestavěné automatické přepnutí při selhání mezi hlavním a pohotovostním režimem

Když hlavní server PostgreSQL selže, je třeba zvolit jeden z pohotovostních serverů jako hlavní server. Tento mechanismus není zabudován do PostgreSQL. K řešení tohoto scénáře se obvykle používají softwarové nástroje třetích stran, jako je Patroni, Pacemaker atd. Proč to nezabudovat do serveru? Tyto nástroje třetích stran vypadají zdánlivě jednoduše, ale vyžaduje to značné úsilí, znalosti a testování ze strany administrátora, aby to bylo správně. Zabudováním tohoto do databáze uděláte obrovskou laskavost svému správci databáze.

3. Žádná velká aktualizace s nulovým výpadkem

Vaši databázi PostgreSQL není možné upgradovat z jedné hlavní verze na druhou bez výpadku. V podstatě musíte vypnout všechny své servery a pomocí pg_upgrade upgradovat svá data na novější verzi. Prostoje nejsou velké, protože se nejedná o kopírování dat, ale stále dochází k prostojům. Pokud provozujete 24/7 provoz, tato možnost pro vás nemusí být vhodná.

S vydáním logické replikace máme alternativní možnost online upgradu.

1. Sestavte si s novou verzí zcela nové nastavení PostgreSQL Master-Standby.
2. Nastavte logickou replikaci pro replikaci ze starší verze na novější.
3. Až budete připraveni, změňte svůj připojovací řetězec tak, aby ukazoval ze staršího nastavení na nové nastavení.

Opět to může fungovat, ale režie je obrovská. V ideálním případě je zde potřeba způsob, jak upgradovat na místě v průběžném režimu přes hlavní pohotovostní nastavení. Upgrade MySQL vám umožní upgradovat vaše slave na místě na novou verzi a poté spustit převzetí služeb při selhání.

4. Není na místě VACUUM FULL

Automatické vakuování/VACUUM je velmi užitečné a pomáhá tento problém do určité míry řešit. Měli byste pravidelně kontrolovat nafouknutí na stole, abyste se ujistili, že nastavení automatického vakua je vhodné a pro váš stůl funguje dobře. Automatické vakuování však neproběhne úplně – ve skutečnosti neskončí sloučením a odstraněním stránek. Pokud máte velké množství aktualizací, vkládání a odstraňování úloh, vaše stránky budou fragmentované, což ovlivní váš výkon. Jediný způsob, jak to obejít, je spustit VACUUM FULL, což v podstatě přestaví všechny stránky, aby se eliminovala fragmentace. Tento proces však lze provést pouze s prostojem – váš stůl je mimo provoz po dobu VACUUM FULL. U velkých souborů dat to může trvat několik hodin a není to praktická alternativa, pokud chcete provozovat 24/7.

Poznámka:Komunita již začala pracovat na modulu úložiště Zheap, který toto omezení překonává.

Pokud existují další vylepšení, o kterých si myslíte, že by byla užitečná, neváhejte zanechat komentář.