Sdílet prostřednictvím

Geografická replikace na flexibilním serveru Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Repliku pro čtení je možné vytvořit ve stejné oblasti jako primární server a v jiné oblasti. Geografická replikace může být užitečná pro scénáře, jako je plánování zotavení po havárii nebo přiblížení dat uživatelům.

Primární server můžete mít v libovolné oblasti flexibilního serveru Azure Database for PostgreSQL. Primární server může mít také repliky v jakékoli globální oblasti Azure, která podporuje flexibilní server Azure Database for PostgreSQL. Kromě toho podporujeme speciální oblasti Azure Government a Microsoft Azure provozované společností 21Vianet. Nyní jsou podporovány speciální oblasti:

  • Oblasti Azure Government:

    • US Gov – Arizona
    • US Gov – Texas
    • US Gov – Virginie

  • Microsoft Azure provozované oblastmi 21Vianet:

    • Čína – sever 3
    • Čína – východ 3

Poznámka:

Virtuální koncové body a povýšení na funkce primárního serveru – nejsou aktuálně podporované ve speciálních oblastech uvedených výše.

Spárované oblasti pro účely zotavení po havárii

I když je možné vytvářet repliky v jakékoli podporované oblasti, existují důležité výhody při volbě replik ve spárovaných oblastech, zejména při navrhování pro účely zotavení po havárii:

  • Pořadí obnovení oblastí: V případě výpadku v celé geografické oblasti je obnovení jedné oblasti z každé spárované sady prioritní a zajišťuje, aby aplikace ve spárovaných oblastech měly vždy urychlenou oblast pro obnovení.

  • Sekvenční aktualizace: Aktualizace spárovaných oblastí jsou chronologicky rozložené a minimalizují riziko výpadků problémů souvisejících s aktualizacemi.

  • Fyzická izolace: Mezi datovými centry ve spárovaných oblastech se udržuje minimální vzdálenost 300 mil, což snižuje riziko souběžných výpadků z významných událostí.

  • Rezidence dat: S několika výjimkami se oblasti ve spárované sadě nacházejí ve stejné zeměpisné oblasti, které splňují požadavky na rezidenci dat.

  • Výkon: Spárované oblasti obvykle nabízejí nízkou latenci sítě, což zvyšuje přístupnost dat a uživatelské prostředí, nemusí být vždy oblastmi s absolutní nejnižší latencí. Pokud je primárním cílem obsluhovat data blíže uživatelům, a ne stanovit prioritu zotavení po havárii, je důležité vyhodnotit všechny dostupné oblasti kvůli latenci. V některých případech může neprůkazná oblast vykazovat nejnižší latenci. Pokud chcete získat komplexní znalosti, můžete na údaje latence odezvy Azure odkazovat, abyste se mohli informovaně rozhodnout.

Podrobnější pochopení výhod spárovaných oblastí najdete v dokumentaci Azure k replikaci mezi oblastmi.

Regionální selhání a obnovení

Zařízení Azure napříč různými oblastmi jsou navržená tak, aby byla vysoce spolehlivá. Za výjimečných okolností ale může být celá oblast nepřístupná z důvodu selhání sítě až po závažné scénáře, jako jsou přírodní katastrofy. Možnosti Azure umožňují vytvářet aplikace distribuované napříč několika oblastmi a zajistit tak, aby selhání v jedné oblasti nemělo vliv na ostatní.

Příprava na regionální havárie

Příprava na potenciální regionální havárie je důležitá k zajištění nepřerušovaného provozu vašich aplikací a služeb. Pokud zvažujete robustní plán nepředvídaných událostí pro instanci flexibilního serveru Azure Database for PostgreSQL, tady jsou klíčové kroky a aspekty:

  1. Vytvoření geograficky replikované repliky pro čtení: Je nezbytné nastavit repliku pro čtení v samostatné oblasti od primární repliky. Tím se zajistí kontinuita v případě výpadku primární oblasti.
  2. Zajistěte symetrii serveru: Akce "Zvýšit na primární server" je nejvhodnější pro zpracování oblastních výpadků, ale obsahuje požadavek na symetrii serveru. To znamená, že primární i replikované servery musí mít identické konfigurace konkrétních nastavení. Mezi výhody použití této akce patří:
    • Pokud používáte virtuální koncové body, nemusíte upravovat připojovací řetězec aplikací.
    • Poskytuje bezproblémový proces obnovení, kdy jakmile je ovlivněná oblast opět online, původní primární server automaticky obnoví svou funkci, ale v nové roli repliky.
  3. Nastavení virtuálních koncových bodů: Virtuální koncové body umožňují hladký přechod aplikace do jiné oblasti, pokud dojde k výpadku. Eliminují potřebu jakýchkoli změn v připojovací řetězec vaší aplikace.
  4. Nakonfigurujte repliku pro čtení: Ne všechna nastavení z primárního serveru se replikují na repliku pro čtení. Je důležité zajistit, aby všechny potřebné konfigurace a funkce (například PgBouncer) byly správně nastavené na vaší replice pro čtení. Další informace najdete v části Správa konfigurace.
  5. Příprava na vysokou dostupnost(HA):Pokud vaše nastavení vyžaduje vysokou dostupnost, nebude automaticky povolená pro upřednostněnou repliku. Připravte se na jeho aktivaci po povýšení. Zvažte automatizaci tohoto kroku, abyste minimalizovali výpadky.
  6. Pravidelné testování: Pravidelně simulujte regionální scénáře havárie, abyste ověřili stávající prahové hodnoty, cíle a konfigurace. Během těchto testovacích scénářů se ujistěte, že vaše aplikace reaguje podle očekávání.
  7. Postupujte podle obecných pokynů Azure: Azure poskytuje komplexní pokyny k spolehlivosti a připravenosti na havárii. Je velmi přínosné poradit se s těmito prostředky a integrovat osvědčené postupy do plánu připravenosti.

Proaktivní a připravované na regionální havárie zajišťují odolnost a spolehlivost vašich aplikací a dat.

Když výpadky ovlivní vaši smlouvu SLA

V případě dlouhodobého výpadku flexibilního serveru Azure Database for PostgreSQL v konkrétní oblasti, která ohrožuje smlouvu o úrovni služeb vaší aplikace (SLA), mějte na paměti, že obě níže uvedené akce nejsou řízené službami. Zásah uživatele se vyžaduje pro oba. Osvědčeným postupem je co nejvíce automatizovat celý proces a mít robustní monitorování. Další informace o tom, jaké informace se poskytují během výpadku, najdete na stránce Výpadek služby. V případě výpadku oblasti je možné pouze vynucené zvýšení úrovně, což znamená, že velikost ztráty dat je přibližně rovna aktuální prodlevě mezi replikou a primárním serverem. Proto je důležité sledovat prodlevu. Zvažte následující kroky:

Zvýšení úrovně na primární server

Tato možnost nebude vyžadovat aktualizaci připojovací řetězec ve vaší aplikaci za předpokladu, že jsou nakonfigurované virtuální koncové body. Po aktivaci se koncový bod zapisovače znovu nastaví na nový primární bod v jiné oblasti a sloupec stavu replikace na webu Azure Portal zobrazí možnost Překonfigurování. Po obnovení ovlivněné oblasti se bývalý primární server automaticky obnoví, ale teď v roli repliky.

Zvýšení úrovně na nezávislý server a odebrání replikace

V takovém případě je to jediná realizovatelná možnost. Po povýšení serveru budete muset aktualizovat připojovací řetězec aplikace. Po obnovení původní oblasti se původní primární oblast může znovu aktivovat. Nezapomeňte ho odebrat, abyste se vyhnuli zbytečným nákladům. Pokud chcete zachovat předchozí topologii, znovu vytvořte repliku pro čtení.

Související obsah