Spolehlivost ve službě Azure Database for PostgreSQL

Azure Database for PostgreSQL je plně spravovaná databázová služba navržená tak, aby vám poskytla podrobnou kontrolu a flexibilitu nad funkcemi správy databází a nastavením konfigurace. Služba poskytuje možnosti vysoké dostupnosti a zotavení po havárii na základě vašich požadavků.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost služby Azure Database for PostgreSQL vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti, výpadků oblastí a údržby služeb. Popisuje také, jak můžete použít zálohy k zotavení z jiných typů problémů a zvýrazní některé klíčové informace o smlouvě o úrovni služeb (SLA) služby Azure Database for PostgreSQL.

Doporučení pro nasazení do produkčního prostředí

Další informace o nasazení služby Azure Database for PostgreSQL pro podporu požadavků na spolehlivost vašeho řešení a o tom, jak spolehlivost ovlivňuje další aspekty vaší architektury, najdete v tématu Osvědčené postupy architektury pro Azure Database for PostgreSQL v architektuře Azure Well-Architected Framework.

Přehled architektury spolehlivosti

Tato část popisuje některé důležité aspekty fungování služby, které jsou z hlediska spolehlivosti nejrelevantní. Tato část představuje logickou architekturu, která obsahuje některé prostředky a funkce, které nasazujete a používáte. Popisuje také fyzickou architekturu, která poskytuje podrobnosti o tom, jak služba funguje v zákulisí.

Logická architektura

Při práci se službou Azure Database for PostgreSQL nasadíte server, který představuje výpočetní prostředky a prostředky úložiště potřebné k podpoře databázového serveru. Na server nasadíte jednu nebo více databází .

Servery je možné nasadit ve více úrovních výpočetních prostředků: pružné, obecné účely a paměťově optimalizované, z nichž každá je optimalizována pro různé druhy úloh. V některých oblastech Azure můžete nasadit servery s využitím důvěrného výpočetního prostředí Azure.

Další informace o obecné architektuře služeb a modelech nasazení najdete v tématu Co je Azure Database for PostgreSQL?

Fyzická architektura

• Oddělení výpočetních prostředků a úložiště: Azure Database for PostgreSQL využívá architekturu oddělení výpočetních prostředků a úložiště k zajištění vysoké dostupnosti. Databázový stroj běží na virtuálním počítači s Linuxem, zatímco datové soubory jsou uložené v úložišti Azure, které udržují tři místně redundantní synchronní kopie databázových souborů, aby se zajistila stálost dat.

• Vysoká dostupnost: Volitelně můžete na serveru povolit konfiguraci vysoké dostupnosti . Když povolíte konfiguraci vysoké dostupnosti, služba zřídí a udržuje záložní pohotovostní server. Změny dat na primárním serveru se synchronně replikují na pohotovostní server, aby se zajistila nulová ztráta dat během selhání primárního serveru.

  Architektura odděluje výpočetní vrstvu od vrstvy úložiště a umožňuje službě správně zpracovávat různé typy selhání. Kvůli vyšší odolnosti můžete servery rozložit mezi zóny dostupnosti.

  

  Pohotovostní server se nasadí ve stejné konfiguraci virtuálního počítače jako primární server, včetně virtuálních jader, úložiště a nastavení sítě.

  Přepínat mezi servery můžete provedením převzetí služeb při selhání. Existují dva typy převzetí služeb při selhání: vynucené převzetí služeb při selhání, které se používají při selhání primárního serveru, a plánované převzetí služeb při selhání, které se používají během některých operací údržby a v jiných scénářích, kdy potřebujete minimalizovat výpadky aplikace během převzetí služeb při selhání.

  Operace jako zastavení, spuštění a restartování se na primárním i pohotovostním databázovém serveru provádějí zároveň. Plánované události, jako je škálování výpočetních prostředků a škálování úložiště, probíhají nejprve v pohotovostním režimu a pak na primárním serveru. Momentálně server neprovádí převzetí pro tyto plánované operace.

  Další informace najdete v tématu Vysoká dostupnost ve službě Azure Database for PostgreSQL.

• Zálohy: Azure Database for PostgreSQL automaticky vytváří zálohy serveru. Další informace najdete v tématu Zálohování a obnovení.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly postupovat podle Azure pokynů pro zpracování přechodných chyb, když komunikují s libovolnými rozhraními API, databázemi a dalšími komponentami hostovanými v cloudu. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Vaše aplikace musí zpracovávat přechodné chyby připojení, ke kterým může dojít během údržby, operací škálování nebo přerušení sítě. Postupujte podle těchto doporučení:

• Když ve vaší aplikaci dojde k přechodným chybám, zkuste operaci zopakovat pomocí exponenciálního zpomalování. Zvyšte prodlevu mezi opakovanými pokusy a omezte počet pokusů. Pokud operace po maximálním počtu opakování stále selže, považuje se za selhání.
• Pokud je to možné, použijte klientské knihovny (označované také jako ovladače), které automaticky zpracovávají opakování.
• Přechodné chyby, ke kterým dochází během operací zápisu, vyžadují pečlivější pozornost. Zvažte nastavení idempotentních operací zápisu, aby se mohly bezpečně spouštět několikrát.

Další informace najdete v tématu Zpracování přechodných chyb připojení ve službě Azure Database for PostgreSQL.

Odolnost proti chybám zóny dostupnosti

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Typ podpory pro zóny dostupnosti můžete vybrat prostřednictvím konfigurace vysoké dostupnosti. Povolení vysoké dostupnosti nasadí záložní server vedle vašeho primárního serveru. Tento model vysoké dostupnosti pomáhá zajistit, aby se během selhání nikdy neztratila potvrzená data. Podle toho, který model nasazení s vysokou dostupností váš server používá, se data synchronně zapíší na primární i pohotovostní servery. Pokud dojde k přerušení primárního serveru, server se automaticky přepne na pohotovostní server.

Datové soubory a záznamové protokoly (WALy) se ukládají na prémiových spravovaných discích v rámci každé zóny dostupnosti s místně redundantním úložištěm (LRS), které automaticky ukládá tři kopie dat v každé zóně.

Azure Database for PostgreSQL podporuje dva typy konfigurace zóny dostupnosti při použití vysoké dostupnosti:

• Zónově redundantní vysoká dostupnost: Redundance zón poskytuje nejvyšší úroveň odolnosti zón nasazením primárního serveru do jedné zóny dostupnosti a pohotovostního serveru v jiné zóně dostupnosti. Pohotovostní server používá podobné výpočetní prostředky, úložiště a konfiguraci sítě jako primární server. Zónově redundantní konfigurace poskytuje fyzickou izolaci celé vrstvy mezi primárními a záložními servery.

  Můžete buď vybrat zóny dostupnosti pro primární a pohotovostní servery, nebo je nechat Microsoft zvolit.

  Pro produkční servery doporučujeme zónově redundantní nasazení.

  

  Operace zápisu mohou zaznamenat malý nárůst latence potvrzení, protože služba synchronně replikuje data na záložní server. Vliv se liší podle úloh, vybraných skladových položek a oblastí.

• Vysoká dostupnost v rámci stejné zóny: Primární a záložní servery používají stejnou zónu dostupnosti. Pokud dojde k přerušení primárního serveru, ale zóna je stále v pořádku, server se automaticky přepne na pohotovostní server. Zónové nasazení poskytuje vysokou dostupnost v rámci jedné zóny dostupnosti. Chrání vás před selháními na úrovni uzlu a také pomáhá snížit výpadky aplikace během plánovaných a neplánovaných výpadků. Nechrání se ale před výpadkem v této zóně.

  

  Vysoká dostupnost zón (stejné zóny) je dostupná pouze v následujících situacích:

  • Oblast nepodporuje zóny dostupnosti. Oblast efektivně funguje jako jedna zóna, takže jedinou konfigurací vysoké dostupnosti, kterou můžete vybrat, je stejná zóna.
  • Pokud oblast nemá dostatečnou kapacitu pro zónově redundantní nasazení, může služba nejprve umístit oba servery do stejné zóny dostupnosti a automaticky je migrovat do samostatných zón, jakmile bude kapacita dostupná. Tato možnost je dostupná, když k nasazení serveru použijete Azure Portal nebo Azure CLI. Další informace najdete v tématu Konfigurace možností pro důležité obchodní informace (vysoká dostupnost).

  Vzhledem k tomu, že jsou servery ve stejné zóně, může snížit latenci zápisu do aplikací, které nasadíte ve stejné zóně.

Pokud nakonfigurujete server bez vysoké dostupnosti, spustí se na jednom serveru. Pokud tento server nebo jeho zóna zmizí, server není dostupný. Další informace najdete v tématu Konfigurace bez zón dostupnosti.

Požadavky

• Podpora oblastí: Podpora konfigurace zón dostupnosti ve službě Azure Database for PostgreSQL se mezi oblastmi Azure liší. Úplný seznam oblastí a typy podpory zóny dostupnosti a všechny konkrétní aspekty pro danou oblast najdete v oblastech Azure.

• Úroveň výpočetních prostředků: Následující tabulka uvádí podporu výpočetní úrovně pro každý typ podpory zóny dostupnosti:

  Cenová úroveň	Zone-redundant	Zónové (stejnozónové)
  Roztahovatelný	Nepodporováno	Podporováno
  Pro obecné účely	Podporováno	Podporováno
  Optimalizováno pro Paměť	Podporováno	Podporováno

• Úroveň služby: Redundance zón vyžaduje úrovně Pro obecné účely nebo Optimalizováno pro paměť.

  Nasazení ve stejné zóně jsou podporována na všech cenových úrovních.

Úvahy

Kapacita oblasti: Pokud oblast nemá dostatečnou kapacitu pro zónově redundantní nasazení, může služba nejprve umístit oba servery do stejné zóny dostupnosti a automaticky je migrovat do samostatných zón, jakmile bude kapacita dostupná. Tato možnost je dostupná, když k nasazení serveru použijete Azure Portal nebo Azure CLI. Další informace najdete v tématu Konfigurace možností pro důležité obchodní informace (vysoká dostupnost).

Náklady

Když povolíte vysokou dostupnost, vytvoří se pohotovostní server a fakturuje se stejným tempem jako primární server. Konfigurace zóny dostupnosti nemá vliv na náklady. Za replikaci dat v rámci zón dostupnosti ani mezi zónami dostupnosti se neúčtují žádné poplatky. V závislosti na objemu úložiště záloh vám může být také účtováno za úložiště záloh. Podrobné informace o cenách najdete v tématu o cenách služby Azure Database for PostgreSQL.

Konfigurujte podporu zón dostupnosti

Pokud chcete nakonfigurovat podporu zóny dostupnosti pro server, nakonfigurujete nastavení vysoké dostupnosti.

• Vytvoření zónově redundantního serveru: Informace o vytvoření serveru s vysokou dostupností a povolenou redundancí zón najdete v tématu Rychlý start: Vytvoření služby Azure Database for PostgreSQL na webu Azure Portal.

• Změna konfigurace zóny dostupnosti pro existující servery: Konfiguraci zóny dostupnosti pro existující servery můžete změnit změnou nastavení vysoké dostupnosti. Podrobný postup najdete v tématu Povolení vysoké dostupnosti pro existující servery.

  Po vytvoření není možné změnit zónu použitou pro primární nebo pohotovostní server. Musíte server vytvořit znovu.

  Návod

  Před změnou konfigurace vysoké dostupnosti je vhodné počkat, až bude aktivita serveru nízká.

• Zakažte vysokou dostupnost: Zakázání vysoké dostupnosti odebere pohotovostní server, takže server není odolný vůči výpadkům ve své zóně dostupnosti. Další informace najdete v tématu Zakázání vysoké dostupnosti.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když jsou servery nakonfigurované s vysokou dostupností a podporou zóny dostupnosti a všechny zóny dostupnosti jsou funkční.

• Operace napříč zónami: Klientské aplikace PostgreSQL se připojují k primárnímu serveru pomocí názvu databázového serveru. Azure Database for PostgreSQL používá konfiguraci aktivní/pasivní, kde se všechna připojení a dotazy databáze zpracovávají primárním serverem v primární zóně dostupnosti. Pohotovostní server během normálního provozu neobsluhuje klientský provoz.

• Replikace dat mezi zónami: Změny dat se replikují synchronně mezi primárními a pohotovostními servery. Transakce se nepovažují za úplné, dokud primární i pohotovostní servery nepotvrdí zápis.

  Zápis aktivovaný transakcí aplikace a potvrzení prvního protokolového záznamu do WALu na primárním serveru. Primární server streamuje tyto protokoly do pohotovostního serveru pomocí protokolu streamování Postgres. Když pohotovostní úložiště serveru zachová protokoly, primární server potvrdí dokončení zápisu. Aplikace potvrdí svou transakci až po tomto potvrzení. Tento proces uznání nečeká, až se protokoly použijí na záložní server.

  Účinky replikace se liší v závislosti na konfiguraci zóny dostupnosti, kterou váš server používá:

  • Zónově redundantní: Vzhledem k tomu, že servery jsou v samostatných zónách, zajišťuje tento přístup nulovou ztrátu dat během selhání zóny. Tato situace se také někdy označuje jako dosažení cíle bodu obnovení (RPO) s hodnotou nula při selhání zóny.

    Replikace mezi zónami ale může představovat malou latenci navíc. Dopad latence závisí na aplikaci a u většiny aplikací je zanedbatelný.

  • Zonální: Protože oba servery jsou ve stejné zóně, nedochází k replikaci provozu mezi zónami.

  Poznámka:

  Systém replikuje data protokolu v reálném čase na pohotovostní server. Všechny chyby uživatelů na primárním serveru, jako je náhodné vyřazení tabulky nebo nesprávné aktualizace dat, se replikují na pohotovostní server. Pohotovostní režim tedy nelze použít k zotavení z těchto typů chyb a je nutné provést bodové obnovení ze zálohy. Další informace najdete v tématu Zálohování a obnovení.

Chování při selhání zóny

Tato část popisuje, co očekávat, když jsou servery nakonfigurované pro vysokou dostupnost s podporou zón dostupnosti a dojde k výpadku v jedné z těchto zón.

• Detekce a odpověď: Azure pravidelně kontroluje stav primárních i pohotovostních serverů. Pokud sledování stavu po několika příkazech ping zjistí, že hlavní server není dostupný, služba zahájí automatické převzetí služeb při selhání na záložní server. Algoritmus monitorování stavu používá více datových bodů, aby se zabránilo falešně pozitivním situacím.

  V případě selhání zóny se chování liší v závislosti na konfiguraci zóny dostupnosti, kterou váš server používá:

  • Zónově redundantní: Azure Database for PostgreSQL automaticky detekuje selhání zón dostupnosti. Pokud chcete zobrazit možné typy stavu vysoké dostupnosti, podívejte se na typy stavu Vysoká dostupnost. Když dojde k selhání zóny, Azure vynuceně převezme na pohotovostní server, aniž byste museli zasahovat.

  • Zonální: Pokud zóna dostupnosti, která je hostitelem zónového serveru, přestane být dostupná, primární i pohotovostní servery nebudou k dispozici. V tomto scénáři služba neposkytuje automatické převzetí služeb při selhání. Zodpovídáte za zjištění výpadku zóny a provádění akcí obnovení, jako je obnovení zónově redundantních záloh na samostatný server v jiné zóně dostupnosti nebo oblasti.

• Oznámení: Monitorování stavu vysoké dostupnosti (HA) ve službě Azure Database for PostgreSQL poskytuje nepřetržitý přehled o stavu a připravenosti instancí s podporou vysoké dostupnosti. Funkce monitorování je založená na službě Azure Resource Health a dokáže detekovat a upozorňovat na všechny problémy, které můžou ovlivnit připravenost vaší databáze na převzetí služeb při selhání nebo celkovou dostupnost. Vyhodnoťte klíčové metriky, jako je stav připojení, stav převzetí služeb při selhání a zdraví replikace dat, abyste mohli proaktivně řešit problémy a pomáhat udržovat dostupnost a výkon vaší databáze.

  Podrobný průvodce konfigurací a interpretací stavu vysoké dostupnosti najdete v tématu Monitorování stavu vysoké dostupnosti (HA) pro Službu Azure Database for PostgreSQL.

• Aktivní požadavky: Když se zóna dostupnosti stane nedostupnou, můžou se ukončit všechny probíhající požadavky na servery v ovlivněné zóně. Aplikace musí tyto požadavky opakovat. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

• Očekávaná ztráta dat: Velikost ztráty dat závisí na konfiguraci zóny dostupnosti, kterou váš server používá.

  • Zónově redundantní: Očekává se nulová ztráta dat při selhání zóny díky synchronní replikaci mezi primárními a záložními servery v různých zónách.

  • Zonální: Data na serverech v ovlivněné zóně nejsou k dispozici, dokud se zóna nezotaví.

• Očekávaný výpadek: Velikost výpadků závisí na konfiguraci zóny dostupnosti, kterou váš server používá.

  • Zónově redundantní: Převzetí služeb při selhání se obvykle dokončí během 60 až 120 sekund. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

  • Zonální: Servery v ovlivněné zóně nejsou dostupné, dokud se zóna dostupnosti neobnoví.

• Přerozdělování: Chování přesměrování provozu závisí na konfiguraci zóny dostupnosti, kterou váš server používá.

  • Zónově redundantní: Po přepnutí po selhání se bývalý pohotovostní server stane novým primárním serverem a začne přijímat nová připojení. Azure po obnovení automaticky vytvoří nový pohotovostní server v původní primární zóně. Úplné podrobnosti najdete v tématu Vynucené převzetí služeb při selhání.

  • Zonální: Pokud je zóna nedostupná, server není k dispozici. Pokud máte samostatný server, který jste vytvořili v jiné zóně nebo oblasti dostupnosti, zodpovídáte za přesměrování provozu na tento server.

Obnovení zóny

Chování obnovení zóny závisí na konfiguraci zóny dostupnosti, kterou váš server používá.

• Zónově redundantní: Když se zóna dostupnosti obnoví, Azure Database for PostgreSQL automaticky znovu sestaví pohotovostní server v obnovené zóně a synchronizuje ho s aktuální primární. Obnovená zóna pak slouží jako pohotovostní umístění. Služba nepřesune primární roli automaticky zpět do původní zóny, aby nedošlo k zbytečnému přerušení. Pokud chcete vrátit primární server do původní zóny, můžete ručně zahájit plánovaný přechod na zálohu.

• Zonální: Jakmile je zóna v pořádku, budou servery v zóně opět dostupné. Zodpovídáte za všechny postupy obnovení zóny a synchronizaci dat, které vaše úlohy vyžadují.

Testování poruch zón

Možnosti pro testování selhání zón závisí na konfiguraci zóny dostupnosti, kterou vaše instance používá.

• Zónově redundantní: Odolnost aplikace vůči převzetí služeb při selhání můžete otestovat spuštěním vynuceného převzetí služeb při selhání. Vynucené převzetí služeb při selhání umožňuje simulovat neplánovaný scénář výpadku při spuštění úlohy a sledovat výpadky aplikace. Doporučujeme spouštět simulace v neprodukčním prostředí nebo v tichém čase. Další informace najdete v tématu Zahájení vynuceného převzetí služeb při selhání.

• Zonální: I když nemůžete simulovat úplný výpadek zóny, můžete simulovat nedostupnost serveru podobným způsobem jako při výpadku zóny. Další informace najdete v tématu Zastavení výpočtů serveru.

Odolnost proti selháním v celé oblasti

Azure Database for PostgreSQL podporuje repliky pro čtení mezi oblastmi, které můžete použít k zachování synchronizované kopie databáze v jiné oblasti pro rychlejší obnovení.

K zajištění obnovení mezi oblastmi můžete použít také geograficky redundantní zálohy v podporovaných oblastech. Zálohování ale obvykle zahrnuje větší výpadek a ztrátu dat než replikace. Další informace najdete v tématu Zálohování a obnovení.

Repliky pro čtení napříč regiony

Repliky pro čtení můžete nasadit pro ochranu databází před selháním na úrovni oblasti. Každá replika pro čtení je samostatný server Azure Database for PostgreSQL. Když umístíte repliku pro čtení do druhé oblasti Azure, může databázový server zajistit odolnost vůči problému v celé oblasti. Můžete nasadit až pět replik pro čtení, které můžou být volitelně v různých oblastech Azure. Technologie fyzické replikace PostgreSQL aktualizuje repliky pro čtení asynchronně a může zpožďovat primární repliky. Mezioblasti repliky pro čtení mohou volitelně obsluhovat úlohy určené pouze pro čtení, aby přispěly ke snížení latence pro globálně distribuované aplikace nebo k přenesení zátěže čtení z primárního serveru. Další informace o funkcích a aspektech čtení replik najdete v tématu Repliky pro čtení.

Virtuální koncové body poskytují koncové body pro čtení a zápis a jen pro čtení a automaticky přesměrují provoz při propagaci repliky, což pomáhá minimalizovat výpadky během událostí převzetí služeb při selhání. Důrazně doporučujeme používat virtuální koncové body s replikami pro čtení mezi oblastmi, aby se zlepšila odolnost aplikací. Další informace najdete v tématu Virtuální koncové body pro repliky pro čtení ve službě Azure Database for PostgreSQL.

Pokud vaše primární oblast selže, můžete aktivovat povýšení tak, aby se sekundární replika stala primární. Existují různé typy převzetí služeb při selhání, které můžete aktivovat v závislosti na tom, jak používáte repliky pro čtení. Pokud používáte repliky pro čtení k zajištění odolnosti vůči selháním oblastí, obvykle použijete přístup povýšit na primární server, který aktualizuje váš virtuální koncový bod. Během výpadku oblasti je potřeba provést vynucené povýšení, což může vést ke ztrátě některých dat kvůli neplicitovaným datům. V plánovaných scénářích, ve kterých je primární oblast v pořádku, můžete provést plánované povýšení, aby nedošlo ke ztrátě dat. Další informace najdete v tématu Zvýšení úrovně replik pro čtení ve službě Azure Database for PostgreSQL.

Poznámka:

Tato část shrnuje některé důležité informace o tom, jak repliky pro čtení můžou podporovat odolnost proti selháním v celé oblasti. Repliky pro čtení můžete také použít ke zlepšení výkonu a podpoře geograficky distribuovaných uživatelských bází ve velkém měřítku. Další informace viz Read replicas.

Požadavky

• Podpora oblastí: Repliky pro čtení mezi oblastmi můžete vytvořit v libovolné oblasti, které podporují Službu Azure Database for PostgreSQL. Nejste omezeni na spárované oblasti Azure.

• Úrovně výpočetní techniky: Úrovně výpočtů obecného účelu a optimalizované pro paměť podporují čtecí repliky. Úroveň Burstable nepodporuje repliky pro čtení.

Úvahy

• Rozdíly v konfiguraci: Repliky pro čtení nemusí dědit všechna nastavení konfigurace z primárního serveru. Naplánujte konfiguraci nutných nastavení po selhání. Primární server a repliky by měly být symetrické, což znamená, že pro některá nastavení musí mít stejné úrovně, velikosti úložiště a hodnoty. Při výpadcích v oblastech může být požadavek na symetrický server zrušen pro vynucené povýšení, ale je vhodné mít symetrickou konfiguraci, aby se předešlo neočekávaným problémům. Další informace naleznete v tématu Správa konfigurace.

• Monitorování prodlevy replikace: Asynchronní proces replikace vyžaduje prodlevu replikace, která se může lišit v závislosti na řadě faktorů. Když je prodleva replikace velmi vysoká, může na vašem serveru docházet k problémům. Je důležité monitorovat prodlevu replikace, abyste před eskalacem mohli zmírnit problémy. Další informace najdete v tématu Monitorování replikace.

• Vysoká dostupnost: Repliky pro čtení nemají povolenou vysokou dostupnost, a když jsou povýšeny, nemají rovněž vysokou dostupnost. Po povýšení jedné z replik máte na starosti konfiguraci vysoké dostupnosti.

Další úvahy týkající se procesu povýšení najdete v tématu Povýšení replik pro čtení ve službě Azure Database for PostgreSQL – Úvahy.

Náklady

Repliky pro čtení souvisejí s náklady na výpočetní prostředky a úložiště, a také poplatky za přenos dat mezi regiony kvůli replikaci. Podrobné informace o cenách najdete v tématu Ceny služby Azure Database for PostgreSQL a ceny šířky pásma.

Konfigurace podpory více oblastí

• Vytvoření repliky pro čtení: Informace o tom, jak vytvořit repliku pro čtení, najdete v tématu Vytvoření repliky pro čtení. Repliky je možné nakonfigurovat po vytvoření primárního serveru, pokud je primární server spuštěný a přístupný.

  Pokud chcete vytvořit virtuální koncový bod, přečtěte si téma Vytvoření virtuálních koncových bodů.

• Odstranění repliky pro čtení: Informace o tom, jak odstranit repliku pro čtení, najdete v tématu Odstranění repliky pro čtení.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když je server nakonfigurovaný s replikou pro čtení v jiné oblasti a virtuálním koncovém bodu a všechny oblasti jsou funkční:

• Směrování provozu mezi oblastmi: V normálních operacích váš virtuální koncový bod směruje provoz koncového bodu pro čtení i zápis na primární server v primární oblasti. Pokud také používáte virtuální koncový bod pro čtení, pak směruje provoz na libovolnou repliku, kterou nakonfigurujete.

• Replikace dat mezi oblastmi: Repliky čtení mezi oblastmi používají asynchronní replikaci k minimalizaci dopadu na výkon primárního serveru. Prodleva replikace závisí na řadě faktorů, včetně zatížení zápisu a latence mezi primárním serverem a replikami. Prodleva replikace je obvykle nejméně několik minut, ale může být mnohem delší. Další informace najdete v tématu Monitorování replikace.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když je server nakonfigurovaný s replikou pro čtení v jiné oblasti a virtuálním koncovým bodem a v primární oblasti dojde k výpadku:

• Detekce a odpověď: Zodpovídáte za zjištění výpadku v primární oblasti a ruční propagaci repliky pro čtení, aby se stala novým primárním serverem. Během výpadku oblasti musíte provést vynucené povýšení, což vede ke ztrátě všech neplicitovaných dat.

  Důležité

  Zodpovídáte za aktivaci povýšení. Azure nezvyšuje repliky pro čtení automaticky, i když dojde k selhání oblasti.

  Podrobné kroky pro zahájení povýšení najdete v tématu Přepnutí repliky pro čtení na primární.

• Oznámení: Microsoft vás při výpadku oblasti automaticky neoznámí. Můžete ale použít Azure Service Health, abyste porozuměli celkovému stavu služby, včetně jakýchkoli selhání oblastí, a můžete nastavit upozornění služby Služba Health, která vás upozorní na problémy.

• Aktivní požadavky: Všechna aktivní připojení k primární oblasti jsou ukončena. Aplikace musí po dokončení procesu povýšení zkusit znovu vytvořit připojení k upřednostněné replice.

• Očekávaná ztráta dat: Během výpadku oblasti musíte provést vynucené povýšení, což vede k trvalé ztrátě všech neplicitovaných dat.

  Velikost ztráty dat závisí na prodlevě replikace v době výpadku. Prodleva replikace je obvykle nejméně několik minut, ale může být mnohem delší. Další informace najdete v tématu Monitorování replikace.

• Očekávaný výpadek: Vynucené povýšení se obvykle dokončí během 1 až 3 minut od aktivace. Aplikace se také můžou muset znovu připojit ke správnému koncovému bodu. Virtuální koncové body se aktualizují v rámci procesu vynuceného povýšení. Aplikace by měly dodržovat hodnotu TTL (Time to Live) záznamů DNS koncového bodu, aby se po dokončení povýšení rychle znovu připojily ke správné replice.

• Přesměrování provozu: Virtuální koncový bod serveru automaticky přesměruje provoz aplikace na novou primární repliku.

  Poznámka:

  Po povýšení repliky pro čtení na primární server nemá povolenou konfiguraci vysoké dostupnosti. Konfiguraci vysoké dostupnosti musíte povolit ručně nebo ji přidat do vlastních procesů automatizace.

Obnovení oblasti

Když použijete virtuální koncové body, po obnovení primární oblasti se starý primární server automaticky nakonfiguruje jako replika pro čtení. Pokud chcete vrátit primární operace do upřednostňované primární oblasti, můžete provést další povýšení.

Testování selhání regionů

Pravidelně testujte postupy propagace read replica, abyste měli jistotu, že vaše procesy jsou platné a že možnosti splňují požadavky RTO a RPO.

Repliku pro čtení můžete kdykoli povýšit na primární server, i když jsou všechny oblasti v pořádku. Pro testování:

• Můžete provést testování nuceného povýšení. Tyto testy doporučujeme provést v neprodukčním prostředí, protože to může vést ke ztrátě dat. Vynucené testování povýšení pomáhá simulovat chování, které vidíte při výpadku oblasti.
• V případě plánované údržby nebo testovacích scénářů, ve kterých chcete zabránit ztrátě dat, použijte místo toho plánované povýšení. Mějte na paměti, že plánované povýšení se řídí jiným procesem než povýšení během výpadku oblasti.

Podrobné pokyny najdete v tématu Přepnutí repliky pro čtení na primární.

V rámci strategie obnovy po havárii pravidelně provádějte kompletní cvičení obnovy. Tyto postupy by měly zahrnovat ověření dat, testování funkčnosti aplikace a zdokumentované postupy vrácení zpět.

Zálohování a obnovení

Azure Database for PostgreSQL automaticky provádí zálohy, které poskytují možnosti obnovení k určitému bodu v čase a pomáhají chránit vás před náhodným poškozením a odstraněním dat. Zálohy jsou plně spravované Microsoftem, nepřerušují dostupnost serveru a zahrnují úplné zálohy i zálohy transakčních protokolů.

• Úložiště zálohování: Pokud je server nakonfigurovaný s zónově redundantní vysokou dostupností, zálohy se ukládají v zónově redundantním úložišti (ZRS). Pro servery nakonfigurované bez vysoké dostupnosti nebo s vysokou dostupností zón (s jednou zónou) se zálohy ukládají v místně redundantním úložišti (LRS).

  V oblastech Azure s dvojicemi můžete při vytváření serveru nakonfigurovat geograficky redundantní úložiště zálohování (GRS) tak, aby replikovala zálohy do spárované oblasti Azure pro další ochranu proti selháním oblasti. Zálohy se replikují asynchronně.

  Výchozí doba uchovávání záloh je 7 dnů a možnost prodloužit uchovávání až na 35 dnů. Azure Backup můžete také použít k dlouhodobému ukládání ručních záloh až po dobu 10 let. Všechny zálohy jsou šifrované.

• Obnovení: Obnovení k určitému bodu v čase umožňuje obnovit databázi v libovolném okamžiku v rámci doby uchovávání záloh. Proces obnovení vytvoří nový databázový server s novým uživatelským názvem serveru, ze kterého pak můžete použít as-is nebo zkopírovat data.

  Když obnovíte geograficky redundantní zálohu, vytvoříte nový server ve spárované oblasti.

  Tato funkce je užitečná pro zotavení z náhodných úprav dat, chyb aplikací nebo testovacích scénářů.

U většiny řešení byste se neměli spoléhat výhradně na zálohy. Místo toho využijte další funkce popsané v tomto průvodci k podpoře vašich požadavků na odolnost. Zálohy ale chrání před některými riziky, která jiné přístupy nechrání. Další informace najdete v tématu Co jsou redundance, replikace a zálohování?.

Další informace najdete v tématu Zálohování a obnovení ve službě Azure Database for PostgreSQL.

Odolnost vůči údržbě služeb

Azure Database for PostgreSQL automaticky zpracovává důležité úlohy údržby, včetně oprav základního hardwaru, operačního systému a databázového stroje. Tato služba zahrnuje aktualizace zabezpečení, aktualizace softwaru a upgrady menší verze jako součást plánované údržby.

Pokud chcete zajistit, aby váš server zůstal během údržby dostupný, postupujte podle těchto doporučení:

• Povolení vysoké dostupnosti: Během údržby může být nutné server restartovat v rámci procesu aktualizace. Pokud máte povolenou vysokou dostupnost, operace údržby obvykle používají kumulativní aktualizace k minimalizaci výpadků. Pravidelné činnosti údržby, jako jsou upgrady minoritních verzí, probíhají nejprve na záložní replice. Aby se snížil výpadek, je pohotovostní režim povýšen na primární, aby úlohy mohly zůstat zapnuté, zatímco úlohy údržby se použijí na zbývajícím uzlu. Toto sekvencování platí bez ohledu na to, jestli váš server používá zónově redundantní nebo zónovou vysokou dostupnost.

  U serverů bez povolené vysoké dostupnosti počítejte s krátkými výpadky během operací údržby. S povolenou vysokou dostupností se operace údržby obvykle dokončí s minimálním nebo žádným výpadkem.

• Konfigurace vlastních časových období údržby: Plán údržby můžete nakonfigurovat tak, aby byl spravovaný systémem, nebo můžete definovat vlastní časové období údržby, abyste minimalizovali dopad na vaše obchodní operace. Naplánujte údržbu během období s nízkou aktivitou, abyste minimalizovali obchodní dopad. Další informace naleznete v tématu Plánování údržby.

• Implementace logiky opakování: Zajistěte, aby vaše aplikace zvládly krátké přerušení připojení, ke kterým může dojít při restartování údržby. Pokud chcete, aby vaše aplikace byly odolné vůči těmto typům problémů, přečtěte si pokyny k odolnosti proti přechodným chybám .

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Azure Database for PostgreSQL poskytuje různé smlouvy SLA dostupnosti na základě konfigurace serveru:

• Servery nakonfigurované s zónově redundantní vysokou dostupností
• Servery nakonfigurované pro zonální (jednozónovou) vysokou dostupnost.
• Servery nakonfigurované bez vysoké dostupnosti

Související obsah

• Spolehlivost Azure
• Osvědčené postupy architektury pro Azure Database for PostgreSQL
• Přehled kontinuity podnikových procesů se službou Azure Database for PostgreSQL
• Geografické zotavení po havárii ve službě Azure Database for PostgreSQL
• Akcelerátor řešení odolnosti Azure Database for PostgreSQL – skripty Terraformu pro implementaci mnoha principů odolnosti a obnovitelnosti popsané v tomto článku.