PostgreSQL Streaming Replication vs Logická replikace

Považuji se tak trochu za průzkumníka. V určitých věcech ano. Obvykle si vždy objednám stejné jídlo ze známé restaurace, protože strach ze zklamání převáží moje obavy vyzkoušet něco nového.

A hladový člověk má samozřejmě tendenci jíst správně?

Přesto, pokud jde o technologie, zejména SQL (PostgreSQL), mám tendenci narazit plnou rychlostí (má definice zkoumání) do často neznámých oblastí s nadějí, že se to naučím. Jaký lepší způsob učení než zkušenost?

Co má tedy sakra toto nesourodé spojení s logickou a streamovací replikací v PostgreSQL?

V těchto oblastech jsem úplný nováček s nulovými znalostmi. Ano, v této oblasti Postgresu mám asi tolik pochopení jako v astrofyzice.

Zmínil jsem se, že nemám žádné znalosti?

Proto se v tomto blogovém příspěvku pokusím strávit rozdíly v těchto typech replikace. Bez praktických zkušeností z reálného světa vám nemohu slíbit „Be all end all ' rukopis pro replikaci.

Pravděpodobně by tento příspěvek na blogu prospěl i ostatním méně zběhlým v této konkrétní oblasti (jako jsem já).

Zkušení uživatelé a vývojáři s vámi, doufám, že se uvidíme v komentářích níže.

Pár základních definic

Co v širokém slova smyslu znamená replikace?

Replikace, jak je definována ve Wikislovníku, má toto říkat:

"Proces, kterým lze objekt, osobu, místo nebo nápad zkopírovat, napodobit nebo reprodukovat."

Přesto je 5. uvedená položka více použitelná pro tento blogový příspěvek a mám pocit, že bychom se na ni měli také podívat:

"(výpočetní technika) Proces častého kopírování elektronických dat z jedné databáze v jednom počítači nebo serveru do databáze v jiném, takže všichni uživatelé sdílejí stejnou úroveň informací. Používá se ke zlepšení odolnosti systému proti chybám."

Nyní je tu něco, do čeho se můžeme dostat. Zmínka o kopírování dat z jednoho serveru nebo databáze na druhý? Nyní jsme na známém území...

Když tedy přidáme to, co víme z této definice, jaké jsou definice streamovací replikace a logické replikace?

Podívejme se, co PostgreSQL Wiki nabízí:

Streaming Replication:"poskytuje schopnost nepřetržitě dodávat a aplikovat záznamy WAL XLOG na určitý počet záložních serverů, aby byly stále aktuální."

A dokumentace PostgreSQL má tuto definici logické replikace:

"Logická replikace je metoda replikace datových objektů a jejich změn na základě jejich replikační identity (obvykle primárního klíče). Termín logická používáme na rozdíl od fyzické replikace, která využívá přesné blokové adresy a replikaci bajt po bajtu. "

Kapitola 19.6 Replikace z oficiální dokumentace je také plná vychytávek, takže se ujistěte a navštivte tento zdroj.

Níže se pokusím vyjádřit rozdíly laicky. (Pamatujte si, že pokud klopýtnu, jsem nováček.) Toto je extrémní přehled „na vysoké úrovni“.

Logická replikace

"Zdrojová" databáze vytvoří PUBLIKACI pomocí příkazu CREATE PUBLICATION. (Představuji si to jednoduše jako 'odesílatel'.)

Dokumentace jej označuje jako vydavatele.

Tato databáze vydavatelů obsahuje data, která chceme replikovat. Přesto musíme mít něco, co bychom mohli replikovat, a to je místo, kde přichází na řadu protějšek vydavatele. „Předplatitel“. Všimněte si, že jsem použil alternativní tvar množného čísla, protože z toho, co jsem našel online vyhledáváním, je praktické mít více odběratelů.

„Předplatitel“ (může být také považován za repliku databáze) vytvoří PŘEDPLATNÉ do „zdrojové“ databáze (vydavatele) definující informace o připojení a jakékoli publikace, které odebírá.

Předplatitel může být zároveň vydavatelem a vytvořit si vlastní PUBLIKACI, kterou si ostatní předplatitelé mohou předplatit.

Co se stane teď?

Jakékoli změny dat, ke kterým dojde u vydavatele, jsou odeslány odběrateli. Což je vše, ale lze jej nakonfigurovat nebo omezit na určité operace (např. INSERT, UPDATE nebo DELETE).

Příklad vysoké úrovně:

Předpokládejme, že aktualizujeme řádek nebo více řádků v konkrétní tabulce ve vydavateli, tyto aktualizace a změny jsou replikovány na instanci odběratele nebo na více odběratelů, pokud je implementován tento typ konfigurace.

Zde je několik věcí k zapamatování, o kterých jsem se cítil hodný zmínit:

• Konfigurace databáze vydavatelů wal_level musí být nastavena na logickou.
• Logická replikace nemá žádné příkazy DDL (Data Definition Language).
• Ze stránky Konflikty v dokumentaci:"Logická replikace se chová podobně jako normální operace DML v tom, že data budou aktualizována, i když byla změněna lokálně v uzlu odběratele. Pokud příchozí data poruší jakákoli omezení, replikace se zastaví. To se označuje jako konflikt. Při replikaci operací UPDATE nebo DELETE nezpůsobí chybějící data konflikt a takové operace budou jednoduše přeskočeny."
• Tabulky vydavatelů musí mít způsob, jak se identifikovat (tzv. „totožnost repliky“), aby mohly správně replikovat operace DML (UPDATE a DELETE) v jakékoli replice (replikách) pro dotčené řádky. Pokud má tabulka primární klíč, je to výchozí (připadá mi to jako volba zvuku), ale v případě absence primárního klíče jsou k dispozici další možnosti konfigurace. Celý řádek lze použít, pokud neexistuje žádný jiný kandidátský klíč (označovaný jako "plný"), ačkoliv dokumentace uvádí, že to obvykle není efektivní řešení. (Popis na nižší úrovni, jak ji nastavit, naleznete v části IDENTITA REPLICE v dokumentech.)

Omezení

Dokumentace v části 31.4. Omezení obsahuje několik klíčových připomenutí omezení, které budu ignorovat. Ujistěte se a zkontrolujte výše uvedenou odkazovanou stránku, kde najdete přesnou mnohomluvnost.

• Schéma databáze a žádné příkazy DDL nejsou v replikaci podporovány. Navrhuje se, že zpočátku by se možná dalo použít pg_dump, ale přesto byste museli sami aktualizovat jakékoli další změny a pokroky ve schématu na všechny repliky.
• Data ve sloupcích sekvence budou replikována. Ale samotná sekvence by odrážela pouze počáteční hodnotu. Pro čtení je to v pořádku. Ale pokud toto je váš cíl pro převzetí služeb při selhání, budete muset sami AKTUALIZOVAT na aktuální hodnotu. Dokumenty zde doporučují pg_dump.
• Zkrácení zatím není podporováno.
• Replikace velkých objektů není podporována.
• Zobrazení, materializovaná zobrazení, kořenové tabulky oddílů ani cizí tabulky nejsou podporovány ani u vydavatele, ani u odběratele.

Hlášené případy běžného použití

• Zajímají vás pouze určitá data a změny dat, které skutečně replikujete, oproti pouhé replikaci celé databáze.
• Když potřebujete repliky pro operace pouze pro čtení, jako je scénář analýzy.
• Umožňuje uživatelům nebo různým podskupinám uživatelů omezený nebo monitorovaný přístup k datům.
• Distribuce dat.
• Kompatibilita s ostatními verzemi PostgreSQL.

Streamování replikace

Při zkoumání, čtení a studiu Streaming Replication, jedna věc, kterou jsem shromáždil hned dopředu, je výběr nastavení buď asynchronní (výchozí) nebo synchronní replikace.

Ach, další neznámé pojmy, co?

Zde je moje „vysoká“ definice obou:

U asynchronní replikace po potvrzení transakce na primárním místě dojde k mírnému zpoždění, když je stejná transakce potvrzena a zapsána do repliky. U tohoto typu konfigurace existuje možnost ztráty dat.

• Zaprvé, předpokládejme, že se hlavní modul zhroutí.
• Za druhé, repliky jsou tak daleko za předlohou, že zahodila potřebná data a informace, aby repliky byly dokonce „aktuální“.

Při synchronní replikaci se však žádná transakce nepovažuje za dokončenou, dokud ji nepotvrdí hlavní i replikovaný server (servery). Což zapíše potvrzení do WAL obou serverů.

Pokud tomu rozumím, znamená to, že zápisy na předlohu byly také potvrzeny a zapsány na replice.

Zde je oficiální vysvětlení ze sekce 26.2.8. Synchronní replikace v oficiální dokumentaci:

„Při požadavku na synchronní replikaci bude každé potvrzení transakce zápisu čekat, dokud nebude přijato potvrzení, že potvrzení bylo zapsáno do protokolu pro zápis na disk primárního i záložního serveru. “

Další pasáž z dokumentace má pěkné shrnutí toho, co musí být (podle mého názoru), obrovský přínos:"Jediná možnost, že může dojít ke ztrátě dat, je, pokud dojde k selhání primárního i záložního zdroje současně."

I když nic není nemožné, stále je to docela dobrá záruka, že nezůstanete bez kopie svých dat.

Dobře, víme, že musíme vybrat jednu z těchto konfigurací nastavení, ale jaká je celková podstata?

Stručně řečeno, Streaming Replication odesílá a aplikuje soubory WAL (Write Ahead Log) z jednoho databázového serveru (hlavního nebo primárního) na „repliku“ (přijímající databázi).

Je zde ale jedno upozornění, které je třeba mít na paměti. Soubory WAL z hlavního serveru mohou být potenciálně recyklovány dříve, než je získá standy. Jedním ze způsobů, jak to zmírnit, je zvýšit nastavení wal_keep_segments na vyšší hodnotu.

Body na replikaci streamování

• Ve výchozím nastavení je streamovaná replikace asynchronní, což znamená, že mezi potvrzenými transakcemi na hlavním serveru a jejich viditelností v replice je zpoždění (možná malé).
• Repliky se připojují k hlavní jednotce prostřednictvím síťového připojení.
• Dejte si pozor na ověřování. Viz zde z dokumentace:"Je velmi důležité, aby byla přístupová oprávnění pro replikaci nastavena tak, aby stream WAL mohli číst pouze důvěryhodní uživatelé, protože je snadné z něj extrahovat privilegované informace"

Kdy použít replikaci streamování

• Běžné použití (zejména v analýze) poskytuje repliku „pouze pro čtení“, která snižuje zátěž primárního serveru.
• Potřebujete prostředí s vysokou dostupností.
• Užitečné nastavení pro převzetí služeb při selhání na server v horkém pohotovostním režimu, pokud primární selže.