Sdílet prostřednictvím

Přehled provozní kontinuity u jednoho serveru Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Azure Database for PostgreSQL – Jednoúčelový server

Důležité

Jednoúčelový server Azure Database for PostgreSQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for PostgreSQL. Další informace o migraci na flexibilní server Azure Database for PostgreSQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for PostgreSQL?

Tento přehled popisuje možnosti, které azure Database for PostgreSQL poskytuje pro provozní kontinuitu a zotavení po havárii. Přečtěte si informace o možnostech zotavení z rušivých událostí, které by mohly způsobit ztrátu dat nebo způsobit nedostupnost databáze a aplikace. Zjistěte, co dělat, když chyba uživatele nebo aplikace ovlivňuje integritu dat, oblast Azure má výpadek nebo vaše aplikace vyžaduje údržbu.

Funkce, které můžete použít k zajištění kontinuity podnikových procesů

Při vývoji plánu provozní kontinuity musíte pochopit maximální přijatelnou dobu, než se aplikace plně obnoví po rušivé události – jedná se o plánovanou dobu obnovení (RTO). Musíte také pochopit maximální množství nedávných aktualizací dat (časový interval), které může aplikace tolerovat ztrátu při obnovení po rušivé události – jedná se o cíl bodu obnovení (RPO).

Azure Database for PostgreSQL poskytuje funkce pro kontinuitu podnikových procesů, které zahrnují geograficky redundantní zálohy s možností iniciovat geografické obnovení a nasazení replik pro čtení v jiné oblasti. Jednotlivé funkce mají různé vlastnosti týkající se doby potřebné k obnovení a potenciální ztráty dat. Pomocí funkce geografického obnovení se vytvoří nový server pomocí zálohovaných dat replikovaných z jiné oblasti. Celková doba potřebná k obnovení a zotavení závisí na velikosti databáze a množství protokolů k obnovení. Celková doba potřebná ke zřízení serveru se může lišit od několika minut až po několik hodin. U replik pro čtení se transakční protokoly z primární repliky asynchronně streamují do repliky. V případě výpadku primární databáze kvůli selhání na úrovni zóny nebo oblasti poskytuje převzetí služeb při selhání repliky kratší plánovanou dobu obnovení a snížení ztráty dat.

Poznámka:

Prodleva mezi primárním serverem a replikou závisí na latenci mezi lokalitami, množství dat, která se mají přenášet, a hlavně na úloze zápisu primárního serveru. Úlohy s velkým počtem zápisů můžou generovat významnou prodlevu.

Vzhledem k asynchronní povaze replikace používané pro repliky pro čtení by se neměly považovat za řešení s vysokou dostupností (HA), protože vyšší prodlevy můžou znamenat vyšší rto a cíl bodu obnovení. Pouze u úloh, u kterých prodleva zůstává menší přes špičku a ne špičku úlohy, můžou repliky pro čtení fungovat jako alternativa pro vysokou dostupnost. V opačném případě jsou repliky pro čtení určené pro skutečné škálování pro čtení pro náročné úlohy a scénáře zotavení po havárii (zotavení po havárii).

Následující tabulka porovnává plánovanou dobu obnovení a cíl bodu obnovení (RPO) v typickém scénáři úloh :

Schopnost Basic Obecné použití Optimalizované pro paměť
Obnovení k určitému bodu v čase ze zálohy Jakýkoli bod obnovení v rámci doby uchovávání
RTO – liší se
RPO < 15 min		 Jakýkoli bod obnovení v rámci doby uchovávání
RTO – liší se
RPO < 15 min		 Jakýkoli bod obnovení v rámci doby uchovávání
RTO – liší se
RPO < 15 min
Geografické obnovení z geograficky replikovaných záloh Nepodporováno RTO – liší se
RPO < 1 h		 RTO – liší se
RPO < 1 h
Čtení replik RTO – minuty*
RPO < 5 min*		 RTO – minuty*
RPO < 5 min*		 RTO – minuty*
RPO < 5 min*

* RtO a RPO mohou být v některých případech mnohem vyšší v závislosti na různých faktorech, mezi které patří latence mezi lokalitami, objem přenášených dat a důležité úlohy zápisu do primární databáze.

Obnovení serveru po chybě uživatele nebo aplikace

Zálohy služby můžete použít k obnovení serveru z různých rušivých událostí. Uživatel může omylem odstranit některá data, neúmyslně odstranit důležitou tabulku nebo dokonce odstranit celou databázi. Aplikace může omylem přepsat dobrá data chybnými daty kvůli vadě aplikace atd.

Pokud chcete vytvořit kopii serveru do známého dobrého bodu v čase, můžete provést obnovení k určitému bodu v čase. Tento bod v čase musí spadat do období uchovávání záloh, které jste pro svůj server nakonfigurovali. Po obnovení dat na nový server můžete původní server nahradit nově obnoveným serverem nebo zkopírovat potřebná data z obnoveného serveru do původního serveru.

Doporučujeme použít zámek prostředků Azure, abyste zabránili náhodnému odstranění serveru. Pokud jste server omylem odstranili, můžete ho obnovit, pokud k odstranění došlo během posledních 5 dnů. Další informace najdete v tématu Obnovení vyřazeného serveru Azure Database for PostgreSQL.

Zotavení z výpadku datacentra Azure

Přestože je taková situace výjimečná, i u datového centra Azure může dojít k výpadku. Když dojde k výpadku, způsobí přerušení firmy, které může trvat jenom několik minut, ale může trvat několik hodin.

Jednou z možností je počkat, až se server vrátí do online režimu, když dojde k výpadku datového centra. To funguje pro aplikace, které si můžou dovolit, aby byl server po určitou dobu offline, například pro vývojové prostředí. Pokud dojde k výpadku datového centra, nevíte, jak dlouho může výpadek trvat, takže tato možnost funguje jenom v případě, že server nějakou dobu nepotřebujete.

Geografické obnovení

Funkce geografického obnovení obnoví server pomocí geograficky redundantních záloh. Zálohy se hostují ve spárované oblasti vašeho serveru. Z těchto záloh můžete provést obnovení do jakékoli jiné oblasti. Geografické obnovení vytvoří nový server s daty ze záloh. Další informace o geografickém obnovení najdete v článku o konceptech zálohování a obnovení.

Důležité

Geografické obnovení je možné pouze v případě, že jste server zřídili s geograficky redundantním úložištěm zálohování. Pokud chcete přepnout z místně redundantního na geograficky redundantní zálohy pro existující server, musíte provést výpis paměti pomocí pg_dump stávajícího serveru a obnovit ho na nově vytvořený server nakonfigurovaný s geograficky redundantními zálohami.

Repliky pro čtení mezi oblastmi

Repliky pro čtení mezi oblastmi můžete použít k vylepšení provozní kontinuity a plánování zotavení po havárii. Repliky pro čtení se aktualizují asynchronně pomocí technologie fyzické replikace PostgreSQL a mohou zpožďovat primární replikaci. Přečtěte si další informace o replikách pro čtení, dostupných oblastech a o tom, jak převzít služby při selhání z článku konceptů replik pro čtení.

Často kladené dotazy

Kde Azure Database for PostgreSQL ukládá zákaznická data?

Azure Database for PostgreSQL ve výchozím nastavení nepřesouvá ani neukládá zákaznická data z oblasti, ve které jsou nasazená. Zákazníci ale můžou volitelně povolit geograficky redundantní zálohy nebo vytvořit repliku pro čtení mezi oblastmi pro ukládání dat v jiné oblasti.

Další kroky