Replikace (replication)

Příklady z praxe

1. 01

   Logická replikace objednávek

   E-shop má tabulku objednávek v PostgreSQL a potřebuje posílat změny do analytické databáze bez ručního exportu. Primární databáze publikuje změny vybrané tabulky a cílová databáze je odebírá. Analytické dotazy potom nezatěžují produkční zápisy, ale cílová kopie může být o několik sekund pozadu.

   -- primární databáze
   CREATE PUBLICATION app_pub FOR TABLE orders;
   
   -- cílová databáze
   CREATE SUBSCRIPTION app_sub
   CONNECTION 'host=primary.example dbname=shop user=repl password=secret'
   PUBLICATION app_pub;

2. 02

   Čtení z geograficky blízké kopie

   Služba běží ve dvou regionech a čte uživatelské profily z nejbližší repliky MongoDB. Výpadek evropského uzlu přesměruje provoz do druhého regionu, takže aplikace zůstane dostupná. Uživatel ale může krátce vidět starší profilovou fotografii, pokud poslední změna ještě nedorazila do vzdálené kopie.

Časté omyly

MýtusReplikace je totéž co záloha.

Ve skutečnostiReplikace drží aktuální nebo téměř aktuální kopii, takže pomáhá hlavně s dostupností. Záloha drží obnovitelný historický stav a chrání před chybou, která se do replik také přenese.

MýtusKdyž máme tři repliky, data jsou automaticky vždy stejná.

Ve skutečnostiRepliky mohou být zpožděné, odpojené nebo v konfliktu podle zvoleného režimu. Stejný počet kopií neříká nic o tom, zda aplikace zaručuje silnou konzistenci.

Časté dotazy

Stačí replikace místo pravidelného backupu?

Replikace nestačí jako náhrada pravidelného backupu, protože replikace obvykle přenáší i nežádoucí změny. Smazaná data, poškozené záznamy nebo škodlivý zápis se mohou rychle objevit ve všech kopiích. Backup drží starší stav, ke kterému se dá vrátit. Pro kritická data se proto replikace používá společně se zálohami, snapshoty a ověřeným postupem obnovy.

Kdy dává smysl synchronní replikace?

Synchronní replikace dává smysl tam, kde je důležitější potvrzená odolnost zápisu než nejnižší latence. Typickým příkladem jsou finanční transakce, objednávky nebo evidence, u které by ztráta potvrzeného zápisu byla horší než pomalejší odpověď. Synchronní režim ale závisí na síti a dostupnosti druhého uzlu, takže může snížit propustnost nebo blokovat zápisy při poruše.

Co znamená replication lag a proč bolí uživatele?

Replication lag znamená zpoždění mezi stavem primárního uzlu a stavem repliky. Uživatel může například uložit změnu profilu, aplikace vzápětí čte z repliky a vrátí ještě starou hodnotu. Lag se řeší volbou místa čtení, monitorováním zpoždění, omezením těžkých dotazů na replikách nebo návrhem aplikace, která po citlivém zápisu čte z primárního uzlu.

Proč replikace někdy komplikuje zápisy?

Replikace komplikuje zápisy hlavně tehdy, když systém dovolí upravovat stejná data na více uzlech. Dvě změny mohou vzniknout současně a síť je doručí v jiném pořadí. Databáze nebo aplikace pak musí rozhodnout, která verze platí, případně jak změny sloučit. Čím větší geografické rozdělení a autonomie uzlů, tím důležitější je promyšlená strategie konfliktů.

Zdroje

1. High Availability, Load Balancing, and Replication(otevře se v novém okně)PostgreSQL Global Development Group
2. Replication(otevře se v novém okně)MongoDB, Inc.
3. Replication(otevře se v novém okně)Redis Ltd.

Související pojmy

• API GatewayAPI Gateway je vstupní vrstva mezi klientem a sadou backendových služeb, která přijímá požadavky, směruje je na správné API, vynucuje bezpečnostní pravidla a často řeší limity, logování nebo transformace odpovědí. Pomáhá skrýt vnitřní strukturu systému a sjednotit chování pro web, mobilní aplikaci i partnery.
• CommitCommit je zapsání skupiny změn tak, aby se staly trvalou a nedělitelnou součástí systému. Ve verzovacím systému jako Git jde o snímek obsahu repozitáře s odkazem na předchozí commit, autorem a popisem. V databázi commit uzavírá transakci a potvrzuje všechny její zápisy najednou.
• Connection poolConnection pool je sada předem otevřených spojení k databázi nebo jiné službě, kterou aplikace sdílí mezi požadavky místo toho, aby pro každý požadavek navazovala nové spojení. Požadavek si spojení vypůjčí, provede dotaz a vrátí ho zpět do fondu. Šetří se tím čas na TCP handshake, autentizaci a vznik procesu na straně serveru.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Archivace dokumentůArchivace dokumentů je řízené ukládání dokumentů, které už nejsou běžně používány, ale musí zůstat čitelné, dohledatelné a prokazatelné po určenou dobu. V praxi spojuje pravidla retence, metadata, oprávnění, ochranu před změnou a postup pro bezpečné vyřazení po skončení právního nebo obchodního důvodu.
• Automatické škálováníAutomatické škálování je řízení výpočetní kapacity služby podle aktuální nebo očekávané zátěže bez ručního zásahu operátora. Systém přidává či odebírá instance, kontejnery, vlákna nebo jiné prostředky podle metrik a pravidel, aby aplikace zvládla špičky, neplatila zbytečnou rezervu a zůstala stabilní.
• BackpressureBackpressure je mechanismus, kterým pomalejší část systému dává rychlejší části najevo, že má zpomalit, počkat nebo zahodit část práce. Používá se u streamů, front, sítí a event-driven aplikací, aby se nekonečně nehromadila data v paměti a aby přetížení nespadlo až na celý proces.
• Bezpečnostní politikaBezpečnostní politika je závazný dokument organizace, který stanovuje pravidla, odpovědnosti a přijatelnou míru rizika při práci s informacemi a IT systémy. Určuje, kdo má k čemu přístup, jak se nakládá s hesly, daty a incidenty, a co se stane při porušení pravidel. Schvaluje ji vedení a doplňují ji navazující směrnice a technická opatření.