Jak replikovat data PostgreSQL na vzdálené weby

V rušném databázovém prostředí s databázemi větší velikosti je potřeba replikace dat v reálném čase běžným jevem. Aplikace často potřebují, aby byla produkční data replikována v reálném čase na vzdálená pracoviště pro účely analýzy a dalších kritických obchodních operací.

DBA také musí zajistit, aby byla data nepřetržitě replikována na vzdálená místa, aby splňovala různé požadavky. Tyto požadavky však nemusí vždy spočívat v replikaci celé databáze; může také existovat potřeba replikovat pouze podmnožinu dat (jako je tabulka nebo sada tabulek nebo data z více tabulek pomocí SQL pro analýzy, vytváření sestav atd.)

V tomto blogu se zaměříme na to, jak replikovat tabulky do vzdálených databází v reálném čase.

Co je replikace na úrovni tabulky?

Replikace na úrovni tabulky je mechanismus replikace dat určité tabulky nebo sady tabulek z jedné databáze (zdroje) do jiné databáze (cílové) hostované vzdáleně v distribuovaném prostředí. Replikace na úrovni tabulky zajišťuje, že data tabulky jsou distribuována nepřetržitě a zůstávají konzistentní napříč replikovanými (cílovými) weby.

Proč používat replikaci na úrovni tabulky?

Replikace na úrovni tabulky je nezbytnou potřebou ve větších, komplexních a vysoce distribuovaných prostředích. Podle mých zkušeností bylo vždy potřeba replikovat sadu tabulek z produkční databáze do datového skladu pro účely výkaznictví. Data je třeba neustále replikovat, aby bylo zajištěno, že přehledy získávají nejnovější data. V kritických prostředích nelze tolerovat zastaralost dat, takže změny dat, ke kterým dochází v produkci, musí být okamžitě replikovány na cílové místo. To může být skutečný problém pro DBA, kteří musí předpovídat různé faktory, aby zajistili efektivní a hladkou replikaci tabulek.

Podívejme se na některé požadavky, které řeší replikace na úrovni tabulky:

• Sestavy mohou běžet v databázi v jiném než produkčním prostředí, jako je datové sklady
• Prostředí distribuované databáze s distribuovanými aplikacemi extrahujícími data z více míst. V případě distribuovaných webových nebo mobilních aplikací by kopie stejných dat měla být dostupná na více místech, aby posloužila různým potřebám aplikací, pro které by replikace na úrovni tabulky mohla být dobrým řešením
• Mzdové aplikace vyžadující, aby data z různých databází umístěných v různých geograficky distribuovaných datových centrech nebo cloudových instancích byly dostupné v centralizované databázi

Různé faktory ovlivňující replikaci na úrovni tabulky – co hledat

Jak jsme zmínili výše, správci databází musí vzít v úvahu různé komponenty a faktory v reálném čase, aby navrhli a implementovali efektivní systém replikace na úrovni tabulky.

Struktura tabulky

Typ datové tabulky, který je vhodný, má velký vliv na výkon replikace. Pokud tabulka pojme sloupec BYTEA s binárními daty větší velikosti, může dojít k narušení výkonu replikace. Dopad replikace na síť, CPU a disk musí být pečlivě vyhodnocen.

Velikost dat

Pokud je tabulka, která má být migrována, příliš velká, pak by počáteční migrace dat zabrala zdroje a čas, správci databází musí zajistit, aby nebyla ovlivněna produkční databáze.

Zdroje infrastruktury

Infrastruktura musí mít odpovídající zdroje, aby bylo možné vybudovat spolehlivý a stabilně fungující replikační systém. Jaké součásti infrastruktury je třeba vzít v úvahu?

CPU

Replikace dat do značné míry závisí na CPU. Při replikaci z produkce se CPU nesmí vyčerpat, což může ovlivnit výkon produkce.

Síť

Je rozhodující pro výkon replikace. Latence sítě mezi zdrojovou a cílovou databází (databázemi) musí být posouzena zátěžovým testováním, aby bylo zajištěno, že je k dispozici dostatečná šířka pásma pro rychlejší replikaci. Stejnou síť by také mohly využívat jiné procesy nebo aplikace. Zde je tedy nutné plánovat kapacitu.

Paměť

Musí být k dispozici dostatečná paměť, aby bylo zajištěno, že je v mezipaměti dostatek dat pro rychlejší replikaci.

Aktualizace zdrojové tabulky

Pokud jsou změny dat ve zdrojové tabulce těžké, pak musí mít replikační systém schopnost synchronizovat změny se vzdálenými lokalitami co nejdříve. Replikace skončí odesláním velkého počtu požadavků na synchronizaci do cílové databáze, což může být náročné na zdroje.

Typ infrastruktury (datová centra nebo cloud) může také ovlivnit výkon replikace a může představovat problémy. Problémem může být také implementace monitorování. Pokud dojde ke zpoždění a některá data v cílové databázi chybí, může být obtížné ji monitorovat a nemůže být synchronní

Jak implementovat replikaci tabulky

Replikaci na úrovni tabulky v PostgreSQL lze implementovat pomocí různých externích nástrojů (komerčních nebo open-source), které jsou dostupné na trhu, nebo pomocí vlastních vytvořených datových toků.

Pojďme se podívat na některé z těchto nástrojů, jejich funkce a možnosti...

Slony

Slony je jedním z nejpopulárnějších nástrojů používaných k asynchronní replikaci konkrétní jednotlivé tabulky nebo tabulek v reálném čase z jedné databáze PostgreSQL do jiné. Jedná se o nástroj založený na Perlu, který provádí replikaci datových změn tabulky (nebo sady tabulek) z databáze na jednom místě na jiné na základě spouštěče. Je poměrně spolehlivý a má za sebou roky vývoje. Přestože je vysoce spolehlivý, protože se jedná o nástroj založený na spouštěči, může být řízení nastavení replikace složité.

Podívejme se na některé schopnosti Slony...

Výhody používání Slony

• Podporuje metodologii replikace master to slave nebo více slave, což pomáhá zlepšit horizontální škálovatelnost čtení. Jinými slovy, otroci nejsou zapisovatelní
• Konfigurace více podřízených zařízení na jeden hlavní server je možná a také podporuje metodu kaskádové replikace
• Podporuje mechanismy přepnutí a převzetí služeb při selhání
• Velký počet tabulek lze paralelně replikovat ve skupinách
• Umíme se replikovat mezi různými hlavními verzemi instancí PostgreSQL, díky čemuž je Slony skvělou volbou pro upgrade databáze
• Jednoduchá instalace

Nevýhody používání Slony

• Nepodporuje replikaci DDL
• Některé změny schématu mohou replikaci přerušit
• Události replikace se zaznamenávají do databáze ve specifických tabulkách protokolu Slony, což může představovat režii údržby.
• Pokud má být replikováno velké množství tabulek s velkými soubory dat, může výkon a údržba představovat vážné problémy
• Vzhledem k tomu, že se jedná o replikaci založenou na spouštěči, může být ovlivněn výkon

Bucardo

Bucardo je další open-source replikační systém založený na perlu pro PostgreSQL, který podporuje asynchronní replikaci specifických dat tabulky mezi dvěma nebo více instancemi PostgreSQL. Bucardo se od Slony liší tím, že také podporuje multi-master replikaci.

Podívejme se na různé typy replikačních mechanismů, které bucardo pomáhá implementovat...

• Multimaster replikace:Tabulky lze replikovat v obou směrech mezi dvěma nebo více instancemi PostgreSQL a transakční data budou synchronizována obousměrně
• Master-slave:Data z tabulek v masteru budou replikována do slave asynchronně a slave je dostupná pro operace čtení
• Režim úplného kopírování (Master-Slave):Bucardo -/replikuje všechna data z hlavního do podřízeného uzlu odstraněním všech dat z podřízeného uzlu

Výhody používání Bucardo

• Jednoduchá instalace
• Podporuje režimy replikace multi-master, master-slave a plné kopie
• Lze jej použít k upgradu databází
• Replikaci lze provádět mezi různými verzemi PostgreSQL

Nevýhody používání Bucardo

• Vzhledem k tomu, že jde o replikaci založenou na spouštěči, může být výkon náročný
• Změny schématu jako DDL mohou replikaci přerušit
• Replikace velkého počtu tabulek může představovat režii údržby
• Prostředky infrastruktury musí být optimalizovány pro dobře fungující replikaci, jinak nelze dosáhnout konzistence.

Logická replikace PostgreSQL

Logická replikace je revoluční vestavěná funkce PostgreSQL, která pomáhá replikovat jednotlivé tabulky prostřednictvím záznamů WAL. Tím, že jde o replikaci založenou na WAL (podobně jako Streaming Replication), pg logická vyniká ve srovnání s jinými nástroji pro replikaci tabulek. Replikace dat prostřednictvím záznamů WAL je vždy nejspolehlivější a nejvýkonnější způsob replikace dat v síti. Téměř všechny nástroje na trhu poskytují replikaci založenou na spouštěči kromě logické replikace.

Výhody použití PostgreSQL Logical Replication

• Nejlepší možnost, když chcete replikovat jednu tabulku nebo sadu tabulek
• Je to dobrá volba, pokud je požadavkem migrace konkrétních tabulek z různých databází do jediné databáze (např. datové sklady nebo databáze hlášení) pro účely hlášení nebo analýzy
• Žádné potíže se spouštěči

Nevýhody použití PostgreSQL logické replikace

• Špatná správa souborů WAL / archivních souborů WAL může představovat problémy pro logickou replikaci
• Nemůžeme replikovat tabulky bez primárního nebo jedinečného klíče
• DDL a TRUNCATE se nereplikují
• Prodleva replikace by se mohla zvýšit, pokud budou odstraněny WAL. To znamená, že replikace a správa WAL se musí vzájemně doplňovat, aby se zajistilo, že se replikace nepřeruší
• Velké objekty nelze replikovat

Zde je několik dalších zdrojů, které vám pomohou lépe porozumět logické replikaci PostgreSQL a rozdílům mezi ní a streamovanou replikací.

Zahraniční obaly dat

Zatímco Foreign Data Wrappers ve skutečnosti data nereplikují, chtěl jsem zdůraznit tuto funkci PostgreSQL, protože může správcům databází pomoci dosáhnout něčeho podobného replikaci, aniž by data skutečně replikovali. To znamená, že data se nereplikují ze zdroje do cíle a k datům mohou přistupovat aplikace z cílové databáze. Cílová databáze má pouze tabulkovou strukturu s odkazem obsahujícím hostitelské a databázové detaily zdrojové tabulky, a když se aplikace dotazuje na cílovou tabulku, data jsou natažena ze zdrojové databáze do cílové databáze podobně jako Database Links. Pokud vám FDW mohou pomoci, můžete se zcela vyhnout režii replikace dat po síti. Mnohokrát se dostáváme do situace, kdy lze sestavy spouštět na vzdálené cílové databázi, aniž by bylo potřeba, aby byla data fyzicky přítomna.

FDW jsou skvělou volbou v následujících situacích -

• Pokud máte ve zdrojové databázi malé a statické tabulky, nemá cenu replikovat data.
• Může být opravdu přínosné, pokud máte ve zdrojové databázi opravdu velké tabulky a v cílové databázi spouštíte souhrnné dotazy.

Výhody používání cizích datových obalů

• Zcela se lze vyhnout replikaci dat, což může ušetřit čas a zdroje
• Jednoduchá implementace
• Převzaté údaje jsou vždy nejnovější
• Žádná náročná údržba

Nevýhody používání cizích datových obalů

• Strukturální změny ve zdrojové tabulce mohou ovlivnit funkčnost aplikace v cílové databázi
• Velmi se spoléhá na síť a může mít značnou režii sítě v závislosti na typu spouštěných přehledů
• Režie výkonu se očekává, když jsou dotazy provedeny několikrát, protože pokaždé, když je dotaz vykonán, musí být data načtena přes síť ze zdrojové databáze a také může představovat režii výkonu ve zdrojové databázi.
• Jakékoli zatížení zdroje může ovlivnit výkon aplikací v cílové databázi

Závěr

• Replikace tabulek může sloužit různým kritickým účelům pro podnikání
• Může podporovat distribuované paralelní dotazování v distribuovaných prostředích
• Implementace synchronního je téměř nemožná
• Infrastruktura musí být dostatečně kapacitní, což zahrnuje náklady
• Skvělá možnost vybudovat integrovanou centralizovanou databázi pro reportovací a analytické účely