Repliky pro čtení v jednoúčelovém 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?

Funkce repliky pro čtení umožňuje replikovat data ze serveru Azure Database for PostgreSQL na server jen pro čtení. Repliky se aktualizují asynchronně pomocí nativní technologie fyzické replikace modulu PostgreSQL. Z primárního serveru můžete replikovat až do pěti replik.

Repliky jsou nové servery, které spravujete podobně jako běžné servery Azure Database for PostgreSQL. Pro každou repliku pro čtení se vám účtuje zřízený výpočetní výkon ve virtuálních jádrech a úložišti v GB/měsíc.

Naučte se vytvářet a spravovat repliky.

Kdy použít repliku pro čtení

Funkce repliky pro čtení pomáhá zvýšit výkon a zlepšit škálování úloh náročných na čtení. Úlohy čtení je možné izolovat do replik a úlohy zápisu je možné směrovat na primární server. Repliky pro čtení lze také nasadit v jiné oblasti a v případě zotavení po havárii je možné zvýšit úroveň na server pro čtení a zápis.

Častým scénářem je, že úlohy BI a analytické úlohy používají repliku pro čtení jako zdroj dat pro účely generování sestav.

Vzhledem k tomu, že jsou repliky jen pro čtení, nesnižují přímo kapacitu zápisu na primárním serveru.

Důležité informace

Tato funkce je určená pro scénáře, kdy je prodleva přijatelná a určená pro přesměrování dotazů. Nejedná se o scénáře synchronní replikace, u kterých se očekává, že data repliky budou aktuální. Mezi primárním serverem a replikou bude měřitelné zpoždění. To může být v minutách nebo dokonce hodinách v závislosti na úloze a latenci mezi primárním serverem a replikou. Data na replice nakonec budou konzistentní s daty na primárním serveru. Tuto funkci použijte pro úlohy, kterým toto zpoždění nevadí.

Poznámka:

Pro většinu úloh repliky pro čtení nabízejí replikaci aktualizací z primárního serveru téměř v reálném čase. U trvalých úloh primárního serveru náročných na zápis se však prodleva replikace může dál zvětšovat a replika tak nemusí být nikdy synchronizovaná s primárním serverem. Může se tím také zvýšit využití úložiště na primárním serveru, protože soubory WAL se neodstraní, dokud je neobdrží replika. Pokud tato situace přetrvává, můžete po dokončení úloh náročných na zápis repliku pro čtení odstranit a vytvořit znovu, aby se obnovil dobrý stav prodlevy repliky. Repliky pro asynchronní čtení nejsou pro takové úlohy náročné na zápis vhodné. Při vyhodnocování replik pro čtení pro vaši aplikaci monitorujte prodlevu na replice pro úplný cyklus zatížení aplikace, a to přes špičku a dobu mimo špičku, abyste měli přístup k možné prodlevě a očekávanému RTO/RPO v různých bodech cyklu úlohy.

Poznámka:

Automatické zálohování se provádí pro servery replik, které jsou nakonfigurované s až 4 TB konfigurací úložiště.

Replikace mezi oblastmi

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

Poznámka:

Servery úrovně Basic podporují pouze replikaci stejné oblasti.

Primární server se může nacházet v jakékoli oblasti služby Azure Database for PostgreSQL. Primární server může mít repliku ve své spárované oblasti nebo oblastech univerzální repliky. Následující obrázek ukazuje, které oblasti repliky jsou dostupné v závislosti na vaší primární oblasti.

Oblasti repliky pro čtení

Oblasti univerzální repliky

Repliku pro čtení můžete kdykoli vytvořit v libovolné z následujících oblastí bez ohledu na to, kde se nachází váš primární server. Toto jsou oblasti univerzální repliky:

Austrálie – východ, Austrálie – jih, Brazílie – jih, Kanada – střed, Kanada – východ, USA – střed, USA – východ, USA – východ 2, Japonsko – východ, Japonsko – západ, Korea – střed, Korea – jih, USA – středosever, Severní Evropa, USA – středojižní, Jihovýchodní Asie, Velká Británie – jih, Velká Británie – západ, Západní Evropa, USA – západ, USA – západ 2, USA – středozápad.

Spárované oblasti

Kromě oblastí univerzální repliky můžete vytvořit repliku pro čtení ve spárované oblasti Azure primárního serveru. Pokud pár oblastí neznáte, můžete se dozvědět víc v článku o spárovaných oblastech Azure.

Pokud pro plánování zotavení po havárii používáte repliky mezi oblastmi, doporučujeme místo jedné z ostatních oblastí vytvořit repliku ve spárované oblasti. Spárované oblasti se vyhýbají souběžným aktualizacím a upřednostňují fyzickou izolaci a rezidenci dat.

Existují omezení, která je potřeba vzít v úvahu:

  • Jednosměrné páry: Některé oblasti Azure jsou spárované pouze jedním směrem. Mezi tyto oblasti patří Západní Indie, Brazílie – jih. To znamená, že primární server v Západní Indii může vytvořit repliku v Jižní Indii. Primární server v Indii – jih však nemůže vytvořit repliku v západní Indii. Je to proto, že sekundární oblast Západní Indie je Indie – jih, ale sekundární oblast Jižní Indie není Západní Indie.

Vytvoření repliky

Při zahájení pracovního postupu vytvoření repliky se vytvoří prázdný server Azure Database for PostgreSQL. Nový server se naplní daty z primárního serveru. Doba potřebná k vytvoření závisí na množství dat v primárním clusteru a době uplynulé od posledního týdenního úplného zálohování. Tato doba se může pohybovat od několika minut až po několik hodin.

Pro automatické zvětšování úložiště je povolená každá replika. Funkce automatického zvětšování umožňuje replikě udržovat krok s daty replikovanými do ní a zabránit přerušení replikace způsobené chybami úložiště.

Funkce repliky pro čtení využívá fyzickou replikaci PostgreSQL, a ne logickou replikaci. Výchozím provozním režimem je replikace streamování s využitím slotů replikace. V případě potřeby se k dohnání používá přesouvání protokolu.

Přečtěte si, jak vytvořit repliku pro čtení na webu Azure Portal.

Pokud je zdrojový server PostgreSQL šifrovaný pomocí klíčů spravovaných zákazníkem, projděte si další informace v dokumentaci.

Připojení k replice

Když vytvoříte repliku, nezdědí pravidla brány firewall ani koncový bod služby virtuální sítě primárního serveru. Tato pravidla je potřeba pro repliku nastavit samostatně.

Replika dědí účet správce z primárního serveru. Všechny uživatelské účty na primárním serveru se replikují do replik pro čtení. K replice pro čtení se můžete připojit pouze s použitím uživatelských účtů, které jsou k dispozici na primárním serveru.

K replice se můžete připojit pomocí názvu hostitele a platného uživatelského účtu, stejně jako na běžném serveru Azure Database for PostgreSQL. Pro server s názvem moje replika s uživatelským jménem správce myadmin se můžete připojit k replice pomocí psql:

psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres

Na příkazovém řádku zadejte heslo k uživatelskému účtu.

Monitorování replikace

Azure Database for PostgreSQL poskytuje dvě metriky pro monitorování replikace. Dvě metriky jsou Max Lag Across Replicas (Maximální prodleva mezi replikami ) a Replica Lag (Prodleva replik). Informace o tom, jak tyto metriky zobrazit, najdete v části Monitorování repliky článku s postupy repliky pro čtení.

Metrika Max Lag Across Replicas zobrazuje prodlevu v bajtech mezi primární a nejvíce zpožděnou replikou. Tato metrika je použitelná a dostupná pouze na primárním serveru a bude dostupná pouze v případě, že je k primární replice připojena a primární je v režimu replikace streamování. Informace o prodlevě nezobrazují podrobnosti, když je replika v procesu zachycení primárního serveru pomocí archivovaných protokolů primární replikace v režimu replikace pro odesílání souborů.

Metrika Replica Lag zobrazuje čas od poslední přehrání transakce. Pokud na primárním serveru nedochází k žádným transakcím, metrika tentokrát odráží prodlevu. Tato metrika je použitelná a dostupná jenom pro servery replik. Prodleva repliky se vypočítá ze pg_stat_wal_receiver zobrazení:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

Nastavte upozornění, které vás informuje, když prodleva repliky dosáhne hodnoty, která není pro vaši úlohu přijatelná.

Další přehled získáte tak, že se na primární server přímo dotazuje, abyste získali prodlevu replikace v bajtech na všech replikách.

Poznámka:

Pokud se primární server nebo replika pro čtení restartuje, čas potřebný k restartování a zachycení se projeví v metrice Replica Lag.

Zastavení replikace / zvýšení úrovně repliky

Replikaci mezi primárním serverem a replikou můžete kdykoli zastavit. Akce zastavení způsobí restartování repliky a propaguje repliku jako nezávislý samostatný server pro čtení i zápis. Data na samostatném serveru představují data, která byla k dispozici na serveru repliky v okamžiku zastavení replikace. Všechny následné aktualizace v primárním serveru se do repliky nešírují. Server repliky ale možná nashromáždil protokoly, které se ještě nepoužívají. V rámci procesu restartování replika před přijetím klientských připojení použije všechny čekající protokoly.

Poznámka:

Resetování hesla správce na serveru repliky se v současné době nepodporuje. Kromě toho se nepodporuje aktualizace hesla správce spolu s operací povýšení repliky ve stejném požadavku. Pokud to chcete udělat, musíte nejprve zvýšit úroveň serveru repliky a pak aktualizovat heslo na nově propagovaný server samostatně.

Důležité informace

  • Před zastavením replikace repliky pro čtení zkontrolujte prodlevu replikace a ujistěte se, že replika obsahuje všechna data, která potřebujete.
  • Vzhledem k tomu, že replika pro čtení musí použít všechny čekající protokoly, než je možné vytvořit samostatný server, může být rtO vyšší pro úlohy náročné na zápis, když dojde k zastavení replikace, protože na replice může dojít ke značnému zpoždění. Při plánování propagace repliky věnujte pozornost tomu.
  • Server povýšené repliky nelze znovu vytvořit do repliky.
  • Pokud zvýšíte úroveň repliky na primární server, nemůžete navázat replikaci zpět na starý primární server. Pokud se chcete vrátit ke staré primární oblasti, můžete vytvořit nový server repliky s novým názvem, nebo odstranit starý primární server a vytvořit repliku s použitím názvu starého primárního serveru.
  • Pokud máte více replik pro čtení a zvýšíte úroveň jedné z nich tak, aby se z ní stal primární server, ostatní servery replik zůstanou připojené ke starému primárnímu serveru. Možná bude potřeba znovu vytvořit repliky z nového serveru se zvýšenou úrovní.

Když zastavíte replikaci, replika ztratí všechna propojení s předchozími primárními a dalšími replikami.

Zjistěte, jak zastavit replikaci do repliky.

Převzetí služeb při selhání do repliky

V případě selhání primárního serveru se replika pro čtení automaticky nepředá .

Vzhledem k tomu, že replikace je asynchronní, může mezi primárním serverem a replikou dojít ke značné prodlevě. Prodleva je ovlivněna řadou faktorů, jako je typ úlohy spuštěné na primárním serveru a latence mezi primárním serverem a serverem repliky. V typických případech s nominální úlohou zápisu se prodleva repliky očekává mezi několika sekundami a několika minutami. V případech, kdy ale primární spouští velmi náročné úlohy náročné na zápis a replika není dostatečně rychlá, může být prodleva mnohem vyšší. Prodlevu replikace pro každou repliku můžete sledovat pomocí prodlevy repliky metriky. Tato metrika ukazuje čas od poslední přehrání transakce v replice. Doporučujeme určit průměrnou prodlevu sledováním prodlevy repliky v určitém časovém období. Můžete nastavit upozornění na prodlevu repliky, takže pokud překročí očekávaný rozsah, budete upozorněni na provedení akce.

Tip

Pokud provedete převzetí služeb při selhání repliky, prodleva v okamžiku odpojení repliky od primárního serveru bude indikovat, kolik dat se ztratí.

Jakmile se rozhodnete, že chcete provést převzetí služeb při selhání repliky,

  1. Zastavení replikace do repliky
    Tento krok je nezbytný k tomu, aby se server repliky stal samostatným serverem a mohl přijímat zápisy. V rámci tohoto procesu se server repliky restartuje a bude odpojen od primárního serveru. Jakmile zahájíte zastavení replikace, proces back-endu obvykle trvá několik minut, než použije všechny protokoly reziduí, které ještě nebyly použity, a k otevření databáze jako serveru pro čtení i zápis. Informace o dopadech této akce najdete v části Zastavení replikace tohoto článku.

  2. Nasměrování aplikace na (bývalou) repliku
    Každý server má jedinečný připojovací řetězec. Aktualizujte aplikaci připojovací řetězec tak, aby odkazovat na (bývalou) repliku místo primární repliky.

Jakmile vaše aplikace úspěšně zpracuje čtení a zápisy, dokončíte převzetí služeb při selhání. Doba výpadku, na které vaše aplikace dojde, závisí na tom, kdy zjistíte problém a dokončíte kroky 1 a 2 výše.

Zotavení po havárii

Pokud dojde k závažné události havárie, jako je selhání na úrovni zóny dostupnosti nebo oblastní selhání, můžete provést operaci zotavení po havárii zvýšením úrovně repliky pro čtení. Na portálu uživatelského rozhraní můžete přejít na server repliky pro čtení. Pak vyberte kartu replikace a repliku můžete zastavit a zvýšit jeho úroveň na nezávislý server. Případně můžete pomocí Azure CLI zastavit a zvýšit úroveň serveru repliky.

Důležité informace

Tato část shrnuje důležité informace o funkci repliky pro čtení.

Požadavky

Repliky pro čtení i logické dekódování závisejí na hlavičkovém protokolu Postgres (WAL) pro informace. Tyto dvě funkce vyžadují různé úrovně protokolování z Postgres. Logické dekódování vyžaduje vyšší úroveň protokolování než repliky pro čtení.

Ke konfiguraci správné úrovně protokolování použijte parametr podpory replikace Azure. Podpora replikace Azure má tři možnosti nastavení:

  • Vypnuto - Umístí nejmenší informace do WAL. Toto nastavení není k dispozici na většině serverů Azure Database for PostgreSQL.
  • Replika – více podrobných než Vypnuto. Toto je minimální úroveň protokolování potřebná k tomu, aby repliky pro čtení fungovaly . Toto nastavení je výchozí na většině serverů.
  • Logické – více podrobné než replika. Toto je minimální úroveň protokolování, aby logické dekódování fungovalo. V tomto nastavení fungují také repliky pro čtení.

Nové repliky

Replika pro čtení se vytvoří jako nový server Azure Database for PostgreSQL. Existující server nejde vytvořit do repliky. Repliku jiné repliky pro čtení nemůžete vytvořit.

Konfigurace repliky

Replika se vytvoří pomocí stejného nastavení výpočetních prostředků a úložiště jako primární. Po vytvoření repliky je možné změnit několik nastavení, včetně doby uchovávání úložiště a zálohy.

Pravidla brány firewall, pravidla virtuální sítě a nastavení parametrů se při vytvoření nebo následném vytvoření repliky z primárního serveru do repliky nezdědí.

Škálování

Škálování virtuálních jader nebo mezi úrovněmi Pro obecné účely a Optimalizováno pro paměť:

  • PostgreSQL vyžaduje, max_connections aby nastavení na sekundárním serveru bylo větší nebo rovno nastavení na primárním serveru, jinak se sekundární nespustí.
  • Ve službě Azure Database for PostgreSQL je maximální povolená připojení pro každý server pevná pro výpočetní skladovou položku, protože připojení zabírají paměť. Další informace o mapování mezi max_connections a výpočetními skladovými položkami.
  • Vertikální navýšení kapacity: Nejprve vertikálně navyšte kapacitu výpočetních prostředků repliky a pak vertikálně navyšte kapacitu primární kapacity. Toto pořadí zabrání chybám v porušení max_connections požadavku.
  • Vertikální snížení kapacity: Nejprve vertikálně snížit kapacitu výpočetních prostředků primárního serveru a pak vertikálně snížit kapacitu repliky. Pokud se pokusíte škálovat repliku nižší než primární, dojde k chybě, protože to porušuje max_connections požadavek.

Škálování úložiště:

  • Všechny repliky mají povolené automatické zvětšování úložiště, aby se zabránilo problémům s replikací z celé repliky úložiště. Toto nastavení nelze zakázat.
  • Úložiště můžete také ručně vertikálně navýšit, jak byste to udělali na jakémkoli jiném serveru.

Základní úroveň

Servery úrovně Basic podporují pouze replikaci stejné oblasti.

max_prepared_transactions

PostgreSQL vyžaduje , aby hodnota parametru max_prepared_transactions repliky pro čtení byla větší nebo rovna primární hodnotě. Jinak se replika nespustí. Pokud chcete změnit max_prepared_transactions primární server, nejprve ho změňte na replikách.

Zastavené repliky

Pokud zastavíte replikaci mezi primárním serverem a replikou pro čtení, replika se restartuje, aby změnu použila. Zastavená replika se stane samostatným serverem, který přijímá čtení i zápisy. Samostatný server nelze znovu vytvořit do repliky.

Odstranění primárních a samostatných serverů

Po odstranění primárního serveru se všechny jeho repliky pro čtení stanou samostatnými servery. Repliky se restartují, aby odrážely tuto změnu.

Další kroky