Vysoká dostupnost (spolehlivost) ve službě Azure Database for PostgreSQL

Tento článek popisuje vysokou dostupnost ve službě Azure Database for PostgreSQL, která zahrnuje zóny dostupnosti a obnovení mezi oblastmi a provozní kontinuitu. Podrobnější přehled spolehlivosti v Azure najdete v tématu Spolehlivost Azure.

Azure Database for PostgreSQL podporuje vysokou dostupnost zřizováním fyzicky oddělených primárních a pohotovostních replik, a to buď ve stejné zóně dostupnosti (zónově), nebo napříč zónami dostupnosti (zónově redundantní). Tento model vysoké dostupnosti je navržený tak, aby se během selhání nikdy neztratila potvrzená data. Při nastavení vysoké dostupnosti (HA) se data synchronně zapíší na primární i pohotovostní servery. Model je navržený tak, aby se databáze nestala jediným bodem selhání ve vaší softwarové architektuře. Další informace o podpoře vysoké dostupnosti a zóny dostupnosti najdete v tématu Podpora zón dostupnosti.

Podpora zón dostupnosti

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

Azure Database for PostgreSQL podporuje zónově redundantní i zónové modely pro konfigurace s vysokou dostupností. Obě konfigurace vysoké dostupnosti umožňují automatické přepnutí při selhání s nulovou ztrátou dat během plánovaných i neplánovaných událostí.

• Zónově redundantní. Zónově redundantní vysoká dostupnost nasadí záložní repliku do jiné zóny s automatickou funkcí převzetí při selhání. Redundance zón poskytuje nejvyšší úroveň dostupnosti, ale potřebujete nakonfigurovat redundanci aplikace napříč zónami. Z tohoto důvodu zvolte redundanci zóny, pokud chcete ochranu před selháními na úrovni zóny dostupnosti a kdy je latence napříč zónami dostupnosti přijatelná. I když může mít latence vliv na zápisy a potvrzení kvůli synchronní replikaci, nemá to vliv na dotazy na čtení. Tento dopad je specifický pro vaše úlohy, typ skladové položky, který vyberete, a oblast.

  Pro primární i pohotovostní servery můžete zvolit oblast a zóny dostupnosti. Server pohotovostní repliky je zřízený ve zvolené zóně dostupnosti ve stejné oblasti s podobným výpočetním výkonem, úložištěm a konfigurací sítě jako primární server. Datové soubory a soubory transakčních protokolů (protokoly s předstihem, označované také jako WAL) se ukládají do místně redundantního úložiště (LRS) v rámci každé zóny dostupnosti a automaticky ukládají tři kopie dat. Zónově redundantní konfigurace poskytuje fyzickou izolaci celé vrstvy mezi primárními a záložními servery.

  

Zónově redundantní možnost je dostupná jenom v oblastech, které mají podporu zón dostupnosti.

Zónová redundance není podporována pro:

• Elasticní výpočetní vrstva

• Oblasti s dostupností s jednou zónou

• Zonální. Vyberte zónové nasazení, pokud chcete dosáhnout nejvyšší úrovně dostupnosti v rámci jedné zóny dostupnosti, ale s nejnižší latencí sítě. Pro nasazení primárního databázového serveru můžete zvolit oblast a zónu dostupnosti. Pohotovostní server repliky se automaticky zřizuje a spravuje ve stejné zóně dostupnosti – s podobným výpočetním prostředím, úložištěm a konfigurací sítě – jako primární server. Zónová konfigurace chrání databáze před selháními na úrovni uzlu a pomáhá také snížit výpadky aplikace během plánovaných a neplánovaných výpadků. Data z primárního serveru se replikují do pohotovostní repliky v synchronním režimu. pokud dojde k přerušení primárního serveru, server automaticky přepne na pohotovostní repliku.

  

Možnost zónového nasazení je dostupná ve všech oblastech Azure , kde můžete nasadit flexibilní server.

Poznámka:

Zónově i zónově redundantní modely nasazení se chovají stejně. Různé diskuze v následujících částech platí pro obě, pokud není uvedeno jinak.

Konfigurace zónové odolnosti na portálu

Vysokou dostupnost (HA) můžete nakonfigurovat dvěma způsoby: zónově redundantní vysokou dostupnost, která umístí pohotovostní server do jiné zóny dostupnosti pro zajištění maximální odolnosti nebo vysokou dostupnost stejné zóny, která nasadí pohotovostní server do stejné zóny jako primární server, aby se minimalizovala latence.

Pro zjednodušení konfigurace a zajištění zónové odolnosti portál nabízí možnost Zonal Resiliency se dvěma přepínači: Povoleno a Zakázáno. Výběrem možnosti Povoleno se pokusíte vytvořit pohotovostní server v jiné zóně dostupnosti (zónově redundantní režim vysoké dostupnosti). Pokud oblast nepodporuje zónově redundantní HA, můžete zaškrtnout políčko záložního nastavení (zvýrazněné na následujícím obrázku) pro povolení vysoké dostupnosti ve stejné zóně.

Když zaškrtnete záložní políčko, systém vytvoří pohotovostní server ve stejné zóně. Pokud bude později k dispozici zónová kapacita, Azure vás upozorní, abyste se mohli rozhodnout migrovat na zónově redundantní konfiguraci vysoké dostupnosti pomocí pitr nebo replik pro čtení. Pokud nezaškrtnete políčko a zónová kapacita není dostupná, povolení vysoké dostupnosti selže. Tento návrh uplatňuje zónově redundantní vysokou dostupnost jako výchozí a současně poskytuje řízené řešení pro případ poruchy ve stejné zóně, čímž zajišťuje, že pracovní zatížení nakonec dosáhnou úplné odolnosti zón bez ručního zásahu.

Funkce vysoké dostupnosti

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

• Můžete přidat podporu zóny dostupnosti pro existující databázový server.

• Pohotovostní repliku můžete odebrat zakázáním vysoké dostupnosti.

• Pro zónově redundantní dostupnost můžete zvolit zóny dostupnosti pro primární a pohotovostní databázové servery.

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

• V zónově redundantních a zónových modelech primární databázový server pravidelně provádí automatické zálohování. Pohotovostní replika současně průběžně archivuje protokoly transakcí v úložišti záloh. Pokud oblast podporuje zóny dostupnosti, ukládají se zálohovaná data v zónově redundantním úložišti (ZRS). V oblastech, které nepodporují zóny dostupnosti, se zálohovaná data ukládají v místním redundantním úložišti (LRS).

• Klienti se vždy připojují ke koncovému názvu hostitele primárního databázového serveru.

• Všechny změny parametrů serveru se použijí také na pohotovostní repliku.

• Server můžete restartovat, aby se projevily všechny změny statických parametrů serveru.

• Pravidelné údržbové aktivity, jako mírné aktualizace verze, jsou nejprve provedeny na záložním systému. 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.

Poznámka:

Abyste zajistili správné fungování vysoké dostupnosti, nakonfigurujte hodnoty parametrů serveru pro max_replication_slots a max_wal_senders. Vysoká dostupnost vyžaduje čtyři jednotky každého typu pro zvládnutí převzetí služeb při selhání a plynulé upgrady. Pro nastavení vysoké dostupnosti s pěti replikami pro čtení a 12 sloty logické replikace nastavte hodnoty parametrů max_replication_slotsmax_wal_senders na hodnotu 21. Tato konfigurace je nezbytná, protože každá replika pro čtení a slot logické replikace vyžaduje jednu z nich a čtyři potřebné pro správné fungování vysoké dostupnosti. Další informace o parametrech max_replication_slots a max_wal_senders najdete v dokumentaci.

Monitorování stavu vysoké dostupnosti

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. Tato funkce monitorování používá architekturu kontroly stavu prostředků Azure (RHC) k detekci a upozorňování na všechny problémy, které můžou ovlivnit připravenost na převzetí služeb při selhání vaší databáze nebo celkovou dostupnost. Posouzením klíčových metrik, jako je stav připojení, stav převzetí služeb při selhání a stav replikace dat, umožňuje monitorování stavu vysoké dostupnosti proaktivní řešení potíží a pomáhá udržovat dobu provozu a výkon vaší databáze.

Monitorování zdravotního stavu v rámci vysoké dostupnosti umožňuje:

• Získejte přehled o stavu primárních i pohotovostních replik v reálném čase s indikátory stavu, které odhalí potenciální problémy, jako je snížení výkonu nebo blokování sítě.
• Nastavte upozornění na včasná oznámení o jakýchkoli změnách stavu vysoké dostupnosti, abyste mohli okamžitě reagovat na potenciální přerušení.
• Optimalizujte připravenost na převzetí služeb tím, že identifikujete a řešíte problémy dříve, než ovlivní databázové operace.

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.

Omezení pro vysokou dostupnost

• Vzhledem k synchronní replikaci na pohotovostní server, zejména s zónově redundantní konfigurací, můžou aplikace zaznamenat zvýšenou latenci zápisu a potvrzení.

• Pro dotazy pro čtení nemůžete použít záložní repliku.

• Podle pracovní zátěže a aktivity na primárním serveru může proces přepnutí při selhání trvat déle než 120 sekund, protože záložní replika se musí před povýšením zotavit.

• Pohotovostní server obvykle obnovuje soubory WAL na 40 MB/s. U větších verzí se tato rychlost může zvýšit až na 200 MB/s. Pokud vaše pracovní zátěž překročí tento limit, může dojít k prodloužení doby potřebné k dokončení procesu obnovy při přepnutí služeb při selhání nebo po zřízení nové záložní kopie.

• Restartováním primárního databázového serveru se restartuje také pohotovostní replika.

• Nemůžete nakonfigurovat pohotovostní režim navíc.

• Během časového období spravované údržby nemůžete plánovat úlohy správy iniciované zákazníkem.

• 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. V současné době server neprovádí přepnutí při selhání pro tyto plánované operace.

• Pokud nakonfigurujete logické dekódování nebo logickou replikaci na flexibilním serveru s podporou vysoké dostupnosti:

  • V PostgreSQL 16 a starších verzích se na pohotovostním serveru po přepnutí při poruše standardně nezachovají sloty logické replikace.
  • Pokud chcete zajistit, aby logická replikace po převzetí služeb při selhání fungovala, musíte povolit pg_failover_slots rozšíření a nakonfigurovat podpůrná nastavení, jako je hot_standby_feedback = on.
  • Počínaje PostgreSQL 17 se nativně podporuje synchronizace slotů. Pokud povolíte správné konfigurace PostgreSQL (sync_replication_slots, hot_standby_feedback), sloty logické replikace se automaticky zachovají po selhání systému a nevyžaduje se žádné rozšíření.
  • V dokumentaci k rozšíření PG_Failover_Slots najdete postup instalace a požadavky.

• Konfigurace zón dostupnosti mezi privátními (virtuálními sítěmi) a veřejným přístupem s privátními koncovými body se nepodporuje. Je nutné nakonfigurovat zóny dostupnosti ve virtuální síti (rozložené mezi zónami dostupnosti v rámci oblasti) nebo veřejný přístup s privátními koncovými body.

• Zóny dostupnosti můžete konfigurovat pouze v rámci jedné oblasti. Zóny dostupnosti nemůžete konfigurovat napříč oblastmi.

SLA

• Zonální model nabízí dobu provozuschopnosti v rámci SLA zhruba 99,95%.

• Model zónové redundance nabízí dobu provozu pro smlouvu SLA přibližně 99,99%.

Vytvoření služby Azure Database for PostgreSQL s povolenou zónou dostupnosti

Informace o vytvoření služby Azure Database for PostgreSQL pro zajištění vysoké dostupnosti pomocí zón dostupnosti najdete v rychlém startu: Vytvoření služby Azure Database for PostgreSQL na webu Azure Portal.

Přenesení a migrace zóny dostupnosti

Informace o povolení nebo zakázání konfigurace vysoké dostupnosti na flexibilním serveru v zónově redundantních i zónových modelech nasazení najdete v tématu Správa vysoké dostupnosti na flexibilním serveru.

Komponenty a pracovní postup s vysokou dostupností

Dokončování transakcí

Transakce aplikace vyvolá zápis a potvrzení, které se nejprve zaznamená do WAL 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í. Tato další doba odezvy zvyšuje latenci vaší aplikace. Procento dopadu závisí na aplikaci. Tento proces uznání nečeká, až se protokoly použijí na záložní server. Pohotovostní server setrvává v režimu obnovení, dokud není povýšen.

Kontrola stavu

Monitorování stavu flexibilního serveru 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.

Režimy převzetí služeb při selhání

Flexibilní server podporuje dva režimy převzetí služeb při selhání, plánované převzetí služeb při selhání a neplánované převzetí služeb při selhání. V obou režimech, jakmile dojde k přerušení replikace, záložní server spustí obnovení před povýšením na primární server a otevře se pro operace čtení a zápisu. S automatickými položkami DNS aktualizovanými pomocí nového koncového bodu primárního serveru se aplikace můžou k serveru připojit pomocí stejného koncového bodu. Na pozadí se vytvoří nový pohotovostní server, aby vaše aplikace zachovala připojení.

Stav vysoké dostupnosti

Systém nepřetržitě monitoruje stav primárních a pohotovostních serverů. Provede vhodné akce k opravě problémů, včetně aktivace převzetí služeb při selhání na záložní server. Následující tabulka uvádí možné stavy vysoké dostupnosti:

Stav	Description
Inicializace	V procesu vytvoření nového pohotovostního serveru.
Replikace dat	Jakmile se vytvoří záloha, dohání primární server.
Zdravý	Replikace je ve stabilním stavu a v pořádku.
Převzetí služeb při selhání	Databázový server přepíná na záložní server.
Odebírání pohotovostního režimu	V procesu odstraňování pohotovostního serveru.
Nepovoleno	Vysoká dostupnost není povolená.

Poznámka:

Vysokou dostupnost můžete povolit při vytváření serveru nebo později. Pokud povolíte nebo zakážete vysokou dostupnost během fáze po vytvoření, udělejte to, když je aktivita primárního serveru nízká.

Operace se stabilním stavem

Klientské aplikace PostgreSQL se připojují k primárnímu serveru pomocí názvu databázového serveru. Primární server přímo obsluhuje čtení aplikací. Aplikace současně obdrží potvrzení potvrzení a zápisy až po zachování dat protokolu na primárním serveru i v pohotovostní replice. Kvůli této dodatečné komunikaci můžou aplikace očekávat zvýšenou latenci při zápisu do paměti a potvrzování operací. Stav vysoké dostupnosti můžete monitorovat na portálu.

1. Klienti se připojují k flexibilnímu serveru a provádějí operace zápisu.
2. Změny jsou replikovány do záložní lokality.
3. Primární obdrží potvrzení.
4. Zápisy a potvrzení jsou potvrzeny.

Obnovení serverů s vysokou dostupností do určitého bodu v čase

Pro flexibilní servery nakonfigurované s vysokou dostupností systém replikuje data protokolů v reálném čase na pohotovostní server. Všechny chyby uživatelů na primárním serveru , například náhodné vyřazení tabulky nebo nesprávné aktualizace dat, se replikují do pohotovostní repliky. Pohotovostní režim tedy nemůžete použít k zotavení z takových logických chyb. Aby bylo možné se z těchto chyb zotavit, musíte provést obnovení ze zálohy k určitému časovému bodu. Pomocí funkce obnovení k určitému bodu v čase flexibilního serveru můžete provést obnovení k času před výskytem chyby. Nový databázový server se obnoví jako flexibilní server s jednou zónou s novým uživatelským názvem serveru pro databáze nakonfigurované s vysokou dostupností. Obnovený server můžete použít pro několik případů použití:

• Použijte obnovený server pro produkční prostředí a volitelně povolte vysokou dostupnost s pohotovostní replikou v jedné zóně nebo jiné zóně ve stejné oblasti.

• Pokud chcete obnovit objekt, exportujte ho z obnoveného databázového serveru a naimportujte ho do produkčního databázového serveru.

• Pokud chcete naklonovat databázový server pro účely testování a vývoje nebo provést obnovení pro jakékoli jiné účely, můžete provést obnovení k určitému bodu v čase.

Informace o tom, jak provést obnovení flexibilního serveru k určitému bodu v čase, najdete v tématu Obnovení flexibilního serveru k určitému bodu v čase.

Podpora převzetí služeb při selhání

Plánovaný failover

Plánované výpadky zahrnují pravidelné aktualizace softwaru Azure a upgrady podverze. Plánované převzetí služeb při selhání můžete použít pro vrácení primárního serveru do preferované zóny dostupnosti. Při konfiguraci vysoké dostupnosti se tyto operace nejprve použijí na pohotovostní repliku, zatímco aplikace nadále přistupují k primárnímu serveru. Jakmile proces aktualizuje pohotovostní repliku, vyprázdní připojení primárního serveru a aktivuje převzetí služeb při selhání, které aktivuje pohotovostní repliku jako primární server se stejným názvem databázového serveru. Klientské aplikace se znovu připojí se stejným názvem databázového serveru k novému primárnímu serveru a můžou pokračovat v operacích. Proces vytvoří nový pohotovostní server ve stejné zóně jako původní primární server.

V případě jiných operací iniciovaných uživatelem, jako je škálování výpočetních prostředků nebo škálování úložiště, proces nejprve použije změny v pohotovostním režimu a pak primární. V současné době nedochází k přepnutí služby na záložní systém. Zatímco operace škálování běží na primárním serveru, aplikace narazí na krátký výpadek.

Tuto funkci můžete použít také k převzetí služeb při selhání na pohotovostní server s omezenou prostojem. Váš primární server může být například v jiné zóně dostupnosti než aplikace po neplánovaném přepnutí při selhání. Chcete vrátit primární server zpět do předchozí zóny, aby byla uložena spolu s vaší aplikací.

Když tuto funkci spustíte, proces nejprve připraví záložní server, aby zajistil, že se vyrovná s nedávnými transakcemi, což aplikaci umožní pokračovat ve čtení a zápisu. Tento proces podporuje pohotovostní režim a odděluje připojení k primárnímu serveru. Aplikace může pokračovat v zápisu na primární server, zatímco proces na pozadí vytvoří nový pohotovostní server. Následující tabulka popisuje kroky spojené s plánovaným přepnutím:

krok	Description	Byl očekáváný výpadek aplikace?
1	Počkejte, až se pohotovostní server dočká primárního serveru.	Ne
2	Interní monitorovací systém zahájí proces selhání.	Ne
3	Zápisy aplikací se zablokují, když je pohotovostní server blízko primárního pořadového čísla protokolu (LSN).	Ano
4	Pohotovostní server je povýšen na nezávislý server.	Ano
5	Záznam DNS se aktualizuje o IP adresu nového pohotovostního serveru.	Ano
6	Aplikace se znovu připojí a obnoví čtení a zápis se svým primárním serverem.	Ne
7	Vytvoří se nový pohotovostní server v jiné zóně.	Ne
8	Pohotovostní server začne obnovovat protokoly (z Azure Blob), které během svého nastavení zmeškal.	Ne
9	Vytvoří se stabilní stav mezi primárním a pohotovostním serverem.	Ne
10	Proces plánovaného převzetí služeb při selhání je dokončený.	Ne

Výpadek aplikace začíná v kroku 3 a může pokračovat v operaci po kroku 5. Zbývající kroky probíhají na pozadí, aniž by to mělo vliv na zápisy a potvrzení aplikace.

Návod

S flexibilním serverem můžete volitelně naplánovat aktivity údržby iniciované Platformou Azure tak, že zvolíte 60minutové časové období v den, kdy se očekává, že budou aktivity v databázích nízké. Úlohy údržby Azure, jako jsou zásahy nebo aktualizace menších verzí, se provádějí v tomto časovém rámci. Pokud nevyberete vlastní okno, systém pro váš server přidělí jednohodinový interval mezi 11:00 a 7:00 místního času. Tyto údržbové aktivity iniciované službou Azure se také provádějí na pohotovostní replice pro flexibilní servery, které jsou nakonfigurovány se zónami dostupnosti.

Seznam možných plánovaných výpadků najdete v tématu Plánované výpadky.

Neplánovaný failover

Neplánované výpadky můžou nastat v důsledku nepředvídatelných přerušení, jako jsou selhání hardwaru, problémy se sítí a chyby softwaru. Pokud databázový server nakonfigurovaný s vysokou dostupností neočekávaně klesne, proces aktivuje pohotovostní repliku a klienti můžou pokračovat v provozu. Pokud nenakonfigurujete vysokou dostupnost (HA) a pokus o restartování selže, proces automaticky zřídí nový databázový server. I když se neplánovaný výpadek nedá vyhnout, flexibilní server pomáhá zmírnit výpadky tím, že automaticky provádí operace obnovení bez nutnosti zásahu člověka.

Informace o neplánovaném přechodu při selhání a výpadku, včetně možných scénářů, si přečtěte v tématu Zmírnění neplánovaných výpadků.

Testování převzetí služeb při selhání (vynucené převzetí služeb při selhání)

Při vynuceném převzetí služeb při selhání můžete simulovat neplánovaný výpadek během provozu produkční úlohy a sledovat, jaký dopad má na dostupnost vaší aplikace. Vynucený přechod můžete použít také, když primární server přestane reagovat.

Vynucené převzetí služeb při selhání zprovozní primární server a zahájí pracovní postup převzetí služeb při selhání, ve kterém se provádí operace pohotovostního povýšení. Jakmile záložní server dokončí proces obnovy až do posledního potvrzeného data, je povýšen na primární server. Aktualizují se záznamy DNS a vaše aplikace se může připojit k povýšenému primárnímu serveru. Vaše aplikace může pokračovat v zápisu na primární server, zatímco se nový pohotovostní server nastavuje na pozadí, což neovlivňuje dostupnost.

Následující tabulka popisuje kroky během vynuceného přepnutí při selhání:

krok	Description	Byl očekáváný výpadek aplikace?
1	Primární server se krátce po přijetí žádosti o převzetí zastaví.	Ano
2	Aplikace narazí na výpadky, protože primární server je mimo provoz.	Ano
3	Interní monitorovací systém zjistí selhání a zahájí převzetí služeb při selhání na záložní server.	Ano
4	Pohotovostní server přejde do režimu obnovení před úplným povýšení jako nezávislý server.	Ano
5	Proces převzetí služeb při selhání čeká na dokončení pohotovostního obnovení.	Ano
6	Jakmile je server vzhůru, proces aktualizuje záznam DNS se stejným názvem hostitele, ale použije IP adresu pohotovostního režimu.	Ano
7	Aplikace se může znovu připojit k novému primárnímu serveru a pokračovat v operaci.	Ne
8	V upřednostňované zóně je zřízen pohotovostní server.	Ne
9	Pohotovostní server začne obnovovat protokoly (z Azure Blob), které během svého nastavení zmeškal.	Ne
10	Vytvoří se stabilní stav mezi primárním a pohotovostním serverem.	Ne
11	Proces vynuceného převzetí služeb při selhání je dokončen.	Ne

Výpadek aplikace se spustí po kroku 1 a pokračuje až do dokončení kroku 6. Další kroky se spouštějí na pozadí, aniž by to ovlivnilo zápisy a potvrzení aplikace.

Důležité

Kompletní proces převzetí služeb při selhání zahrnuje (a) převod na záložní server po selhání primárního serveru a (b) zprovoznění nového záložního serveru ve stabilním stavu. Vzhledem k tomu, že u vaší aplikace dochází k výpadkům, dokud nedojde k převzetí služeb při selhání do pohotovostního režimu, změřte výpadek z hlediska vaší aplikace nebo klienta místo celkového kompletního procesu převzetí služeb při selhání.

Důležité informace o provádění vynucených převzetí služeb při selhání

• Celková doba provozu od začátku do konce může být delší než skutečný výpadek, který aplikace skutečně zaznamenala.

  Důležité

  Vždy sledujte výpadky z pohledu aplikace.

• Neprovádějte okamžité ani po sobě následující převzetí služeb při selhání. Počkejte alespoň 15 až 20 minut mezi procesy při selhání, aby bylo možné plně nastavit nový záložní server.

• Během období nízké aktivity proveďte vynucené převzetí, aby se snížil výpadek.

Osvědčené postupy pro statistiky PostgreSQL po převzetí služeb při selhání

Po převzetí služeb při selhání PostgreSQL vyžaduje udržování optimálního výkonu databáze pochopení jednotlivých rolí tabulky pg_statistic a tabulek pg_stat_*. Tabulka pg_statistic ukládá statistiky optimalizátoru, které jsou pro plánovač dotazů zásadní. Tyto statistiky zahrnují distribuce dat v tabulkách a zůstávají nedotčené po selhání, což zajišťuje, že plánovač dotazů může i nadále efektivně optimalizovat provádění dotazů na základě přesných historických informací o distribuci dat.

Naproti tomu se tabulky pg_stat_*, které zaznamenávají statistiky aktivit, jako je počet skenů, čtení n-tic a aktualizace, při převzetí služeb při selhání resetují. Příkladem takové tabulky je pg_stat_user_tables, který sleduje aktivitu pro uživatelem definované tabulky. Tento reset přesně odráží provozní stav nového primárního serveru, ale také znamená ztrátu historických metrik činností, které by mohly být využity k informování procesu automatického úklidu a zlepšení dalších provozních efektivit.

Vzhledem k tomuto rozdílu spusťte ANALYZE po přepnutí po selhání PostgreSQL. Tato akce aktualizuje pg_stat_* tabulky, například jako je pg_stat_user_tables, s čerstvými statistikami aktivit, pomáhá procesu automatického úklidu a zajišťuje optimální výkon databáze ve své nové roli. Tento proaktivní krok překlenuje mezeru mezi zachováním základních statistik optimalizátoru a aktualizací metrik aktivit tak, aby odpovídal aktuálnímu stavu databáze.

Zážitek zklidnění zóny

Zónové: Pokud se chcete zotavit ze selhání na úrovni zóny, můžete provést obnovení k určitému bodu v čase pomocí zálohy. Pokud chcete obnovit nejnovější data, můžete zvolit vlastní bod obnovení s nejnovějším časem. Nový flexibilní server se nasadí v jiné nefikované zóně. Doba potřebná k obnovení závisí na předchozím zálohování a objemu transakčních protokolů, které se mají obnovit.

Další informace o obnovení k určitému bodu v čase najdete v tématu Zálohování a obnovení ve službě Azure Database for PostgreSQL-Flexible Server.

Zónově redundantní: Flexibilní server automaticky přepne na pohotovostní server během 60 až 120 sekund s nulovou ztrátou dat.

Konfigurace bez zón dostupnosti

I když se nedoporučuje, můžete flexibilní server nakonfigurovat bez povolené vysoké dostupnosti. Pro flexibilní servery nakonfigurované bez vysoké dostupnosti poskytuje služba místně redundantní úložiště se třemi kopiemi dat, zónově redundantním zálohováním (v oblastech, kde je podporováno) a integrovanou odolnost serveru k automatickému restartování chybového serveru a přemístění serveru do jiného fyzického uzlu. Tato konfigurace nabízí SLA dostupnosti 99,9%. Pokud server selže během plánovaného nebo neplánovaného převzetí provozu, služba zajišťuje dostupnost serverů následujícím automatizovaným postupem:

1. Zřídí se nový výpočetní virtuální počítač s Linuxem.
2. Úložiště s datovými soubory se mapuje na nový virtuální počítač.
3. Databázový stroj PostgreSQL je na novém virtuálním počítači online.

Následující obrázek ukazuje přechod mezi selháním virtuálního počítače a úložištěm.

Zotavení po havárii napříč oblastmi a provozní kontinuita

Pokud dojde k havárii v celé oblasti, Azure může poskytnout ochranu před regionálními nebo velkými zeměpisnými katastrofami s zotavením po havárii pomocí jiné oblasti. Další informace o architektuře zotavení po havárii Azure najdete v tématu Architektura zotavení Azure pro Azure.

Flexibilní server poskytuje funkce, které chrání data a snižují výpadky pro důležité databáze během plánovaných a neplánovaných výpadků. Flexibilní server založený na infrastruktuře Azure, která nabízí robustní odolnost a dostupnost, nabízí funkce provozní kontinuity, které poskytují ochranu proti chybám, řeší požadavky na dobu obnovení a snižují riziko ztráty dat. Při navrhování aplikací zvažte odolnost proti výpadkům – cíl doby obnovení (RTO) a vystavení ztráty dat – cíl bodu obnovení (RPO). Například vaše databáze pro důležité obchodní informace vyžaduje přísnější dobu provozu než testovací databáze.

Zotavení po havárii v geografické oblasti s více oblastmi

Geograficky redundantní zálohování a obnovení

Geograficky redundantní zálohování a obnovení vám umožní obnovit server v jiné oblasti, pokud dojde k havárii. Poskytuje také alespoň 99,99999999999999 % (16 devítek) trvanlivost zálohovaných objektů během ročního období.

Geograficky redundantní zálohování můžete nakonfigurovat pouze při vytváření serveru. Při konfiguraci serveru s geograficky redundantním zálohováním se záložní data a transakční protokoly kopírují do spárované oblasti asynchronně prostřednictvím replikace úložiště.

Další informace o geograficky redundantním zálohování a obnovení najdete v tématu geograficky redundantní zálohování a obnovení.

Čtení replik

Repliky pro čtení mezi oblastmi můžete nasadit za účelem ochrany databází před selháními na úrovni oblasti. Repliky pro čtení se aktualizují asynchronně pomocí technologie fyzické replikace PostgreSQL a můžou zpožďovat primární replikaci. Úrovně výpočetních prostředků pro obecné použití a optimalizované pro paměť podporují repliky čtení.

Další informace o funkcích a aspektech čtení replik najdete v tématu Repliky pro čtení.

Detekce výpadků, oznámení a správa

Pokud nakonfigurujete server s geograficky redundantním zálohováním, můžete provést geografické obnovení ve spárované oblasti. Nový server se zřídí a obnoví podle posledních dostupných dat, která byla zkopírována do této oblasti.

Můžete také použít repliky pro čtení mezi oblastmi. Pokud dojde k selhání oblasti, můžete provést operaci zotavení po havárii povýšením repliky pro čtení na samostatný server pro čtení i zápis. Očekává se, že RPO (cíl bodu obnovení) bude až 5 minut (je možná ztráta dat), kromě případů při závažném regionálním selhání, kdy může být RPO blízko prodlevy replikace v době selhání.

Další informace o zmírnění neplánovaných výpadků a zotavení po regionální havárii najdete v tématu Zmírnění neplánovaných výpadků.

Související obsah

• Dokumentace ke službě Azure Database for PostgreSQL
• Spolehlivost v Azure