Sdílet prostřednictvím

Zvýšení úrovně replik pro čtení na flexibilním serveru Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Zvýšení úrovně odkazuje na proces, kdy je replika příkazem ukončit režim repliky a přejít na úplné operace čtení a zápisu.

Důležité

Operace zvýšení úrovně není automatická. V případě selhání primárního serveru se systém nepřepne na repliku pro čtení nezávisle. Akce uživatele se vždy vyžaduje pro operaci povýšení.

Povýšení replik je možné provádět dvěma různými způsoby:

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

Tato akce zvýší úroveň repliky na roli primárního serveru. V procesu se aktuální primární server sníží na roli repliky a prohodí jejich role. Pro úspěšné povýšení je nutné mít virtuální koncový bod nakonfigurovaný pro aktuální primární koncový bod jako koncový bod zapisovače a repliku určenou pro povýšení jako koncový bod čtenáře. Povýšení proběhne úspěšně pouze v případě, že cílová replika je součástí konfigurace koncového bodu čtenáře.

Diagram znázorňuje konfiguraci serverů před povýšení a výsledným stavem po úspěšném dokončení operace povýšení.

Diagram znázorňující zvýšení úrovně na operaci primárního serveru

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

Když zvolíte tuto možnost, replika se zvýší na nezávislý server a odebere se z procesu replikace. V důsledku toho primární i propagovaný server fungují jako dva nezávislé servery pro čtení i zápis. Je třeba poznamenat, že i když je možné nakonfigurovat virtuální koncové body, nejsou pro tuto operaci nezbytné. Nově upřednostněný server už není součástí žádného existujícího virtuálního koncového bodu, i když na něj dříve odkazoval koncový bod čtenáře. Proto je důležité aktualizovat připojovací řetězec aplikace tak, aby se nasměrovala na nově upřednostněnou repliku, pokud se k ní má aplikace připojit.

Diagram znázorňuje, jak jsou servery nastavené před povýšením a jejich konfigurací po úspěšném získání nezávislých serverů.

Diagram znázorňující zvýšení úrovně na nezávislý server a odebrání z operace replikace

Důležité

Povýšení na nezávislý server a odebrání z akce replikace je zpětně kompatibilní s předchozími funkcemi povýšení.

Důležité

Symetrie serveru: Pro úspěšné povýšení pomocí povýšení na provoz primárního serveru musí mít primární i replikované servery stejné úrovně a velikosti úložiště. Pokud má například primární server 2vCore a replika má 4vCores, jedinou realizovatelnou možností je použít akci "Zvýšit úroveň na nezávislý server a odebrat z replikace". Kromě toho musí sdílet stejné hodnoty pro parametry serveru, které přidělují sdílenou paměť.

U obou metod povýšení je potřeba zvážit další možnosti:

  • Plánované: Tato možnost zajišťuje synchronizaci dat před povýšením. Před přijetím klientských připojení použije všechny čekající protokoly, aby se zajistila konzistence dat.

  • Vynuceno: Tato možnost je určená pro rychlé obnovení ve scénářích, jako jsou regionální výpadky. Místo čekání na synchronizaci všech dat z primárního serveru se server zprovozní, jakmile zpracuje soubory WAL potřebné k dosažení nejbližšího konzistentního stavu. Pokud zvýšíte úroveň repliky pomocí této možnosti, prodleva v okamžiku odpojení repliky od primárního serveru označuje, kolik dat se ztratí.

Důležité

Možnost vynuceného povýšení je speciálně navržená tak, aby řešila regionální výpadky a v takových případech přeskočí všechny kontroly , včetně požadavku na symetrii serveru, a pokračuje s povýšením. Je to proto, že upřednostňuje okamžitou dostupnost serveru, aby zvládla scénáře havárie. Použití možnosti Vynucené mimo scénáře mimo oblast mimo oblast není však povoleno, pokud nejsou splněny požadavky na repliky pro čtení zadané v dokumentaci, zejména požadavek na symetrii serveru, protože by to mohlo vést k problémům, jako je přerušení replikace.

Zjistěte, jak zvýšit úroveň repliky na primární server a zvýšit úroveň na nezávislý server a odebrat z replikace.

Správa konfigurace

Repliky pro čtení se považují za samostatné servery z hlediska konfigurací řídicí roviny. Tento přístup poskytuje flexibilitu pro scénáře škálování čtení. Při použití replik pro účely zotavení po havárii ale uživatelé musí zajistit, aby byla konfigurace požadovaná.

Operace povýšení nepřenáší konkrétní konfigurace a parametry. Tady jsou některé z lépe použitelných:

  • PgBouncer: Integrované nastavení a stav sdružování připojení PgBouncer se během procesu povýšení nereplikují. Pokud byl nástroj PgBouncer povolený na primárním serveru, ale ne na replice, zůstane na replice po povýšení zakázaný. Pokud chcete pgBouncer na nově propagovaný server povolit, musíte ho povolit před akcí povýšení nebo po ní.
  • Geograficky redundantní úložiště zálohování: Nastavení geografického zálohování se nepřenese. Vzhledem k tomu, že repliky nemohou mít povolenou geografickou zálohu, primární primární server (dříve replika) ho po povýšení nemá. Tuto funkci je možné aktivovat pouze při vytváření standardního serveru (nikoli v replice).
  • Parametry serveru: Pokud se jejich hodnoty liší v primární replice a replikě pro čtení, během povýšení se nezmění. Je důležité si uvědomit, že parametry ovlivňující velikost sdílené paměti musí mít stejné hodnoty na primárních i replikách. Tento požadavek je podrobně popsaný v části Parametry serveru.
  • Ověřování Microsoft Entra: Pokud primární měl nakonfigurované ověřování Microsoft Entra, ale replika byla nastavena s ověřováním PostgreSQL, pak po povýšení se replika automaticky nepřepne na ověřování Microsoft Entra. Uchovává ověřování PostgreSQL. Uživatelé musí ručně nakonfigurovat ověřování Microsoft Entra na upřednostněné replice před nebo po procesu povýšení.
  • Vysoká dostupnost (HA):Pokud po povýšení vyžadujete vysokou dostupnost , musí být nakonfigurovaná na nově propagované primárním serveru, a to po zrušení role.

Důležité informace

Stavy serveru během povýšení

Ve scénářích Plánované i Vynucené povýšení je nutné, aby servery (primární i repliky) byly ve stavu Dostupné. Pokud je stav serveru jiný než Dostupný (například Aktualizace nebo Restartování), povýšení obvykle nemůže pokračovat bez problémů. V případě regionálních výpadků se však provede výjimka.

Během takových oblastních výpadků lze metodu vynuceného povýšení implementovat bez ohledu na aktuální stav primárního serveru. Tento přístup umožňuje rychle reagovat na potenciální regionální havárie a obejít normální kontroly dostupnosti serveru.

Všimněte si, že pokud bývalý primární server selže nad rámec obnovení během povýšení repliky, jedinou možností je odstranit bývalý primární server a znovu vytvořit server repliky.

Viditelnost více replik během povýšení v neprůhledných oblastech

Při práci s více replikami a v případě, že primární oblast nemá spárovanou oblast, je potřeba vzít v úvahu zvláštní pozornost. V případě regionálního výpadku, který ovlivňuje primární server, nebudou automaticky rozpoznány všechny ostatní repliky nově upřednostněnou replikou. I když se aplikace stále dají směrovat na upřednostněnou repliku pro pokračování provozu, nerozpoznané repliky zůstanou během výpadku odpojené. Tyto další repliky se znovu přidružují a obnoví jejich role až po obnovení původní primární oblasti.

Nejčastější dotazy

  • Můžu zvýšit úroveň repliky, pokud má primární server povolenou vysokou dostupnost (HA)?

    Ano, jestli je primární server povolený nebo ne, můžete zvýšit úroveň repliky pro čtení. Schopnost propagovat repliku pro čtení na primární server je nezávislá na konfiguraci vysoké dostupnosti primárního serveru.

  • Pokud mám primární server s povolenou vysokou dostupností a repliku pro čtení a zvýším úroveň repliky, přepněte zpátky na původní primární server, bude server stále ve vysoké dostupnosti?

    Ne, vysokou dostupnost zakážeme během počátečního povýšení, protože nepodporujeme repliky pro čtení s podporou vysoké dostupnosti. Zvýšení úrovně repliky pro čtení na primární znamená, že původní primární server mění svou roli na repliku. Pokud přepnete zpátky, musíte povolit vysokou dostupnost na původním primárním serveru.

Související obsah