Vysoká dostupnost PostgreSQL s architekturami Master-Slave a Master-Master

Níže je úryvek z našeho whitepaperu „PostgreSQL Management and Automation with ClusterControl“, který si můžete zdarma stáhnout.

Poznámka k revizi: Mějte na paměti, že výrazy použité v tomto blogu Master-Slave jsou synonymem výrazů Master-Standby používaných PostgreSQL. Používáme Master-Slave, abychom zachovali paralelismus s ostatními technologiemi.

Pro konfiguraci HA můžeme mít několik architektur, ale základní by byly architektury master-slave a master-master. Databázové servery mohou spolupracovat a umožnit druhému serveru rychle převzít řízení, pokud primární server selže (vysoká dostupnost ), nebo umožnit několika počítačům obsluhovat stejná data (vyrovnávání zátěže).

Architektury Master-Slave PostgreSQL

Tyto architektury nám umožňují udržovat hlavní databázi s jedním nebo více záložními servery připravenými převzít operace, pokud primární server selže. Tyto rezervní databáze zůstanou synchronizované (nebo téměř synchronizované) s hlavní.

Replikaci mezi masterem a slave lze provést pomocí příkazů SQL (logické pohotovostní režimy) nebo prostřednictvím úprav interní datové struktury (fyzické pohotovostní režimy). PostgreSQL používá proud záznamů protokolu WAL (write-ahead) k udržení synchronizace rezervních databází. Pokud hlavní server selže, pohotovostní režim obsahuje téměř všechna data hlavního serveru a lze jej rychle změnit na nový hlavní databázový server. To může být synchronní nebo asynchronní a lze to provést pouze pro celý databázový server.

Nastavení streamingové replikace je úkol, který vyžaduje důkladné provedení některých kroků. Tyto kroky a další informace o tomto tématu naleznete v části:Staňte se PostgreSQL DBA – Jak nastavit replikaci streamování pro vysokou dostupnost.

Od verze 10 PostgreSQL obsahuje možnost nastavení logické replikace.

Logická replikace umožňuje databázovému serveru odeslat proud úprav dat na jiný server. Logická replikace PostgreSQL vytváří proud logických modifikací dat z WAL. Logická replikace umožňuje replikovat změny dat z jednotlivých tabulek. Nevyžaduje, aby byl určitý server označen jako hlavní server nebo replika, ale umožňuje tok dat více směry.

Více informací o logické replikaci můžete najít:Blog:Přehled logické replikace v PostgreSQL.

K efektivnímu zajištění vysoké dostupnosti nestačí mít architekturu master-slave. Potřebujeme také povolit nějakou automatickou formu převzetí služeb při selhání, takže pokud něco selže, můžeme mít co nejmenší zpoždění při obnovení normální funkčnosti. PostgreSQL nezahrnuje automatický mechanismus převzetí služeb při selhání, který by identifikoval selhání na hlavní databázi a informoval salve, aby převzal vlastnictví, takže to bude vyžadovat trochu práce na straně DBA. Měli byste pracovat na skriptu, který obsahuje příkaz pg_ctl promotion, který povýší slave na nového mastera. Pro tuto automatizaci existují také nástroje třetích stran. Existuje mnoho takových nástrojů a jsou dobře integrovány s prostředky operačního systému, které jsou vyžadovány pro úspěšné převzetí služeb při selhání, jako je migrace IP adres.

Poté, co dojde k převzetí služeb při selhání, musíte aplikaci odpovídajícím způsobem upravit, aby fungovala s novým hlavním serverem. Budete také mít funkční pouze jeden server, takže je třeba provést znovu vytvoření architektury master-slave, abychom se dostali zpět do stejné normální situace, jakou jsme měli před problémem.

Master-Master Architectures PostgreSQL

Tato architektura poskytuje způsob, jak minimalizovat dopad chyby v jednom z uzlů, protože druhý uzel se může postarat o veškerý provoz, možná mírně ovlivní výkon, ale nikdy neztratí funkčnost. Používá se také k dosažení (a možná je to ještě zajímavější bod) horizontální škálovatelnosti (scale-out), na rozdíl od konceptu vertikální škálovatelnosti, kdy přidáváme více zdrojů na server (scale-up).

Pro implementaci této architektury budete muset použít externí nástroje, protože tato funkce není (zatím) nativně podporována PostgreSQL.

Při výběru řešení pro implementaci master-master musíte být velmi opatrní, protože existuje mnoho různých produktů. Mnoho z nich je stále „zelených“, s několika vážnými uživateli nebo úspěšnými případy. Některé další projekty byly na druhou stranu opuštěny, protože zde nejsou žádní aktivní správci.

Další informace o dostupných nástrojích naleznete na:Blog:Nejlepší řešení PG Clustering HA pro PostgreSQL.

Vyrovnávání zátěže a sdružování připojení

Existuje několik nástrojů pro vyrovnávání zatížení, které lze použít ke správě provozu z vaší aplikace, abyste získali co nejvíce z architektury databáze. Stejně tak existují některé další, které vám mohou pomoci spravovat způsob, jakým se aplikace připojuje k databázi, tím, že tato připojení sdruží a znovu je použijí mezi různými požadavky.

Existují některé produkty, které se používají pro oba účely, jako je dobře známý pgpool, a některé další, které se zaměřují pouze na jednu z těchto funkcí, jako je pgbouncer (sdružování připojení) a HAProxy (používané pro vyrovnávání zátěže).