Spolehlivost ve službě Azure Database for PostgreSQL

Azure Database for PostgreSQL je plně spravovaná databázová služba, která poskytuje podrobnou kontrolu a flexibilitu nad funkcemi správy databáze 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 různý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žby. Popisuje také, jak můžete použít zálohy k zotavení z jiných typů problémů a zvýrazní klíčové informace o smlouvě o úrovni služeb (SLA) Azure Database for PostgreSQL.

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

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

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 s 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ází, které nasazujete na server.

Servery můžete nasadit v několika výpočetních úrovních: Burstable, General Purpose a Memory Optimized. Každá úroveň je optimalizovaná 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 Azure Database for PostgreSQL přehledu.

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 Azure Storage uchovává datové soubory a uchovává tři místně redundantní synchronní kopie databázových souborů, aby se zajistila stálost dat.

• Vysoká dostupnost: Na serveru můžete povolit konfiguraci s vysokou dostupností. Když povolíte konfiguraci vysoké dostupnosti, služba zřídí a udržuje záložní pohotovostní server. Primární server synchronně replikuje změny dat 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ě, aby služba správně zvládla různé typy selhání. Kvůli vyšší odolnosti můžete servery rozložit mezi zóny dostupnosti.

  

  Diagram znázorňující architekturu s vysokou dostupností pro Azure Database for PostgreSQL Dva servery jsou vedle sebe. Vlevo je pole označené primárním serverem a uvnitř daného pole je virtuální počítač a disk. Vpravo je odpovídající box označený pohotovostním serverem, který obsahuje také virtuální počítač a disk. Vodorovná šipka směřuje z primárního serveru vlevo k záložnímu serveru vpravo a je označena jako streaming replication, což značí jednosměrný vztah, kdy změny dat proudí z primárního serveru do záložního serveru.

  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í.

  Při provádění operací, jako je zastavení, spuštění a restartování, dochází na primárních i pohotovostních databázových serverech současně. 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í:

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.

Vyberte typ podpory zóny dostupnosti prostřednictvím konfigurace vysoké dostupnosti. Když povolíte vysokou dostupnost, služba nasadí pohotovostní server společně s vaším primárním serverem. Tento model s vysokou dostupností pomáhá zajistit, aby se během selhání nikdy neztratila potvrzená data. Bez ohledu na to, který model nasazení s vysokou dostupností váš server používá, synchronně potvrdí data na primární i pohotovostní servery. Pokud dojde k přerušení primárního serveru, server se automaticky přepne na pohotovostní server.

Každá zóna dostupnosti ukládá datové soubory a protokoly write-ahead log (WAL) na prémiových spravovaných discích s místně redundantním úložištěm (LRS), které v rámci každé zóny automaticky ukládá tři kopie dat.

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á výpočetní výkon, úložiště a konfiguraci sítě, která je podobná konfiguraci primárního serveru. 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í.

  

  Diagram znázorňující zónově redundantní konfiguraci služby Azure Database for PostgreSQL rozprostřenou napříč zónami dostupnosti. V horní části jsou uvedené tři zóny: zóna dostupnosti 1, zóna dostupnosti 2 a zóna dostupnosti 3. V zóně dostupnosti 1 je box označený jako primární server a uvnitř tohoto pole je virtuální počítač a disk, který ukazuje, že primární server se skládá z výpočetních prostředků a úložiště. V zóně dostupnosti 2 je k dispozici odpovídající pohotovostní server označený jako box, který obsahuje také virtuální počítač a disk. Mezi těmito dvěma servery je šipka směřující doprava označená jako streamingová replikace, která ukazuje, že změny dat proudí z primárního serveru vlevo na záložní server vpravo. Rozložení vyjadřuje odolnost napříč zónami: primární a záložní instance jsou rozmístěny do dvou různých zón dostupnosti, zatímco třetí zóna dostupnosti zůstává nevyužitá.

  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ě.

  

  Diagram znázorňující zónové nasazení Azure Database for PostgreSQL v jedné zóně dostupnosti. Zobrazí se tři zóny: zóna dostupnosti 1, zóna dostupnosti 2 a zóna dostupnosti 3. V zóně dostupnosti 1 jsou dva rámečky vedle sebe. Pole na levé straně je označeno primárním serverem a uvnitř daného pole je virtuální počítač a disk. Pole vpravo je označeno pohotovostním serverem a uvnitř daného pole je virtuální počítač a disk. Mezi těmito dvěma servery je šipka směřující doprava označená jako streamingová replikace, která ukazuje, že změny dat proudí z primárního serveru vlevo na záložní server vpravo. Oba servery jsou ve stejné zóně dostupnosti. Zóna dostupnosti 2 a zóna dostupnosti 3 se nepoužívají.

  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 potom je automaticky 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).

  Umístění serverů do stejné zóny může snížit latenci zápisu do aplikací, které nasadíte ve stejné zóně.

  Pokud jsou servery ve stejné zóně, je možné snížit latenci zápisu do aplikací, které nasazujete 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í: Azure Database for PostgreSQL podporuje konfigurace zón dostupnosti v různých Azure oblastech. Úplný seznam oblastí a typy podpory zóny dostupnosti a všechny konkrétní aspekty pro každou oblast najdete v Azure oblastech.

• Ú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:

  Výpočetní úroveň	Zonálně redundantní	Zónové (stejnozónové)
  Roztahovatelný	Nepodporováno	Nepodporováno
  Pro obecné účely	Podporováno	Podporováno
  Optimalizováno pro Paměť	Podporováno	Podporováno

• Úroveň služby: Oba typy vysoké dostupnosti vyžadují úrovně Pro obecné účely nebo Optimalizováno pro paměť.

Ú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 účtuje se stejnou sazbou 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, nakonfigurujte 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í serveru Azure Database for PostgreSQL.

• Změna konfigurace zóny dostupnosti pro existující servery: Změňte konfiguraci zóny dostupnosti pro existující servery změnou nastavení vysoké dostupnosti. Podrobný postup najdete v tématu Povolení vysoké dostupnosti pro existující servery.

  Zónu použitou pro primární nebo pohotovostní server nemůžete změnit. Server je potřeba znovu vytvořit.

  Návod

  Než změníte konfiguraci vysoké dostupnosti, doporučujeme 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ž nakonfigurujete servery s podporou vysoké dostupnosti a 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 primární server v primární zóně dostupnosti zpracovává všechna připojení a dotazy databáze. Pohotovostní server během normálního provozu neobsluhuje klientský provoz.

• Replikace dat mezi zónami: Primární server synchronně replikuje změny na pohotovostní server. Transakce se nepovažují za úplné, dokud primární i pohotovostní servery nepotvrdí zápis.

  Když aplikace zapíše a potvrdí data, PostgreSQL nejprve zaznamená změnu v WAL na primárním serveru. Primární server streamuje tyto protokoly do pohotovostního serveru pomocí protokolu streamování PostgreSQL. Jakmile pohotovostní server trvale ukládá WAL, primární server potvrdí zápis. 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. U většiny aplikací je dodatečná latence 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 nemůžete použít k zotavení z těchto druhů chyb a je nutné provést obnovení k určitému bodu v čase 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ž nakonfigurujete servery s podporou vysoké dostupnosti a zóny dostupnosti a dojde k výpadku zóny dostupnosti.

• 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.

  Pokud zóna dostupnosti selže, chování se 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 monitorování stavu vysoké dostupnosti (HA). 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 v 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. Sledujte klíčové metriky, jako je stav připojení, stav přepnutí při selhání a stav replikace dat, abyste mohli proaktivně řešit potíže a pomohli zachovat vysokou dostupnost a výkon databáze.

  Podrobný průvodce konfigurací a interpretací stavu vysoké dostupnosti najdete v tématu Monitorování stavu vysoké dostupnosti (HA).

• 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 předem 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í. Aby nedošlo k zbytečnému přerušení, služba nepřesune primární roli automaticky zpět do původní zóny. 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í.

• Výpadek zóny: I když nemůžete simulovat úplný výpadek zóny, můžete simulovat nedostupnost serveru způsobem podobným 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í. Různé typy převzetí služeb při selhání mohou být vhodné podle toho, 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.

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 jen 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 nezbytných nastavení po převzetí služeb při 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: Proces asynchronní replikace vyžaduje prodlevu replikace, která se může lišit v závislosti na mnoha faktorech. Když je prodleva replikace 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ší faktory týkající se procesu povýšení, které je potřeba vzít v úvahu, najdete v tématu Důležité informace.

Náklady

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

Nakonfigurujte podporu pro 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 můžete 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 koncový bod virtuálního endpointu jen pro čtení, směruje provoz na tu 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 mnoha faktorech, 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 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: Proces povýšení přeruší všechna aktivní připojení k primárnímu regionu. Po dokončení procesu povýšení musí aplikace zkusit znovu vytvořit připojení k povýšené 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 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 u ní není povolena konfigurace 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 povýšení replik pro čtení, abyste měli jistotu, že vaše postupy fungují správně a že systémové možnosti splňují požadavky na cíl doby obnovení (RTO) a cíl bodu obnovení (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 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í. Plánované povýšení se však řídí jiným procesem než povýšení během výpadku oblasti, takže nemusí odrážet chování během skutečného výpadku oblasti.

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

V rámci své 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 zálohuje vaše data. Tyto zálohy 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. Microsoft plně spravuje zálohy. Nepřeruší dostupnost serveru a zahrnují úplné zálohy i zálohy transakčních protokolů.

• Úložiště zálohování: Pokud nasadíte server v oblasti se zónami dostupnosti, služba ukládá zálohy v zónově redundantním úložišti (ZRS) bez ohledu na konfiguraci vysoké dostupnosti serveru. Pro servery nasazené v oblastech bez zón dostupnosti ukládá služba zálohy v místně redundantním úložišti (LRS).

  V Azure oblastech s dvojicemi můžete při vytváření serveru nakonfigurovat geograficky redundantní úložiště zálohování tak, aby replikovala zálohy do Azure spárované oblasti kvůli dodatečné ochraně před selháními oblastí. Služba replikuje zálohy asynchronně.

  Výchozí doba uchovávání záloh je sedm dní, ale uchovávání můžete prodloužit 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. Nový server můžete použít as-is nebo z něj kopí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í:

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 v závislosti na konfiguraci serveru:

• Servery nakonfigurované se zónově redundantní vysokou dostupností nabízejí dostupnost 99,99 % garantovanou v SLA.
• Servery nakonfigurované se zónovou vysokou dostupností nabízejí SLA s garantovanou dostupností 99,95 %.
• Servery nakonfigurované bez vysoké dostupnosti nabízejí garantovanou dostupnost SLA 99,9%.

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
• Skripty Terraformu pro implementaci principů odolnosti a obnovitelnosti