Sdílet prostřednictvím

Sekundární repliky úrovně Hyperscale

  • Článek

Platí pro: Azure SQL Database

Jak je popsáno v architektuře distribuovaných funkcí, Azure SQL Database Hyperscale má dva různé typy výpočetních uzlů, označované také jako repliky:

Sekundární repliky jsou vždy jen pro čtení a můžou mít tři různé typy:

  • Replika s vysokou dostupností
  • Geografická replika
  • Pojmenovaná replika

Každý typ má jinou architekturu, sadu funkcí, účel a náklady. Na základě funkcí, které potřebujete, můžete použít jenom jeden nebo dokonce všechny tři společně. Sekundární repliky můžete používat s bezserverovou nebo zřízenou úrovní výpočetních prostředků.

Kurzy týkající se konfigurace a správy pojmenovaných replik Hyperscale najdete v následujících tématech:

Replika s vysokou dostupností

Replika vysoké dostupnosti (HA) používá stejné stránkové servery jako primární replika, takže k přidání repliky vysoké dostupnosti se nevyžaduje žádná kopie dat. Repliky vysoké dostupnosti se používají ke zvýšení dostupnosti databáze; fungují jako aktivní pohotovostní repliky pro účely převzetí služeb při selhání. Pokud se primární replika stane nedostupnou, převzetí služeb při selhání jedné z existujících replik vysoké dostupnosti je automatické a rychlé. Připojovací řetězec se nemusí měnit. Během aplikací s podporou převzetí služeb při selhání může dojít k minimálnímu výpadku kvůli vyřazení aktivních připojení. Pro tento scénář se doporučuje správná logika opakování. Několik ovladačů již poskytuje určitou míru logiky automatického opakování. Pokud používáte .NET, nejnovější knihovna Microsoft.Data.SqlClient poskytuje nativní úplnou podporu pro konfigurovatelnou logiku automatického opakování.

Repliky vysoké dostupnosti používají stejný název serveru a databáze jako primární replika. Cíl úrovně služeb (SLO) také vždy stejný jako pro primární repliku. Repliky vysoké dostupnosti nejsou viditelné ani spravovatelné jako samostatné prostředky, z portálu nebo z jakéhokoli rozhraní API. Účtují se za stejnou výpočetní sazbu jako primární replika, ale náklady na úložiště se nevztahují na sekundární repliky.

Může existovat nula až čtyři repliky vysoké dostupnosti. Můžete zadat počet replik během vytváření nové databáze nebo aktualizovat počet replik pro existující databázi. Pomocí běžných koncových bodů a nástrojů pro správu (například Azure PowerShell, Azure CLI, Azure Portal, REST API) můžete určit počet replik vysoké dostupnosti. Vytváření nebo odebírání replik vysoké dostupnosti nemá vliv na aktivní připojení na primární replice.

Připojení k replice vysoké dostupnosti

V databázích Hyperscale argument v připojovací řetězec používaném klientem určuje, ApplicationIntent jestli je připojení směrováno na primární repliku pro čtení i zápis nebo na repliku vysoké dostupnosti jen pro čtení. Pokud ApplicationIntent je nastavená ReadOnly hodnota a databáze nemá sekundární repliku, připojení se směruje na primární repliku ReadWrite a výchozí nastavení chování.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;

Všechny repliky vysoké dostupnosti jsou ve své kapacitě prostředků stejné. Pokud existuje více než jedna replika vysoké dostupnosti, úloha záměru čtení se distribuuje libovolně napříč všemi dostupnými replikami vysoké dostupnosti. Pokud existuje více replik vysoké dostupnosti, mějte na paměti, že každá replika může mít odlišnou latenci dat vzhledem ke změnám dat provedeným v primárním serveru. Každá replika vysoké dostupnosti používá stejná data jako primární na stejné sadě stránkových serverů. Místní mezipaměti dat na každé replice vysoké dostupnosti však odrážejí změny provedené v primární službě transakčních protokolů, které předávají záznamy protokolů z primární repliky na repliky vysoké dostupnosti. V důsledku toho může aplikace záznamů protokolu probíhat v závislosti na úloze spuštěné na replice vysoké dostupnosti v různých rychlostech, takže různé repliky můžou mít odlišnou latenci dat vzhledem k primární replice.

Pojmenovaná replika

Pojmenovaná replika, stejně jako replika vysoké dostupnosti, používá stejné stránkové servery jako primární replika. Podobně jako repliky vysoké dostupnosti není k přidání pojmenované repliky potřeba žádná kopie dat.

Mezi replikami vysoké dostupnosti a pojmenovanými replikami existují rozdíly:

  • Pojmenované repliky se na portálu a v rozhraní API (Azure CLI, Azure PowerShell, T-SQL) zobrazují jako běžné (jen pro čtení) databáze Azure SQL.
  • Pojmenované repliky můžou mít jiný název databáze než primární replika a volitelně se nachází na jiném logickém serveru (pokud je ve stejné oblasti jako primární replika).
  • Pojmenované repliky mají vlastní cíl úrovně služeb, který lze nastavit a změnit nezávisle na primární replice.
  • Pojmenované repliky podporují až 30 pojmenovaných replik (pro každou primární repliku).
  • Pojmenované repliky podporují různé ověřování pro každou pojmenovanou repliku vytvořením různých přihlášení na logických serverech hostujících pojmenované repliky.

V důsledku toho pojmenované repliky nabízejí několik výhod oproti replikám vysoké dostupnosti, které se týkají úloh jen pro čtení:

  • Uživatelé připojení k pojmenované replice se neodpojí, pokud se primární replika vertikálně navyšuje nebo zmenšuje.
  • Uživatelé připojení k primární replice nebudou ovlivněni při vertikálním navýšení nebo snížení kapacity všech pojmenovaných replik.
  • Úlohy spuštěné na jakékoli replice ( primární nebo pojmenované) nemají vliv na dlouhotrvající dotazy spuštěné na jiných replikách.

Hlavním cílem pojmenovaných replik je umožnit širokou škálu scénářů škálování na více systémů čtení a zlepšit úlohy HTAP (Hybrid Transactional And Analytical Processing). Příklady vytvoření takových řešení jsou k dispozici tady:

Pojmenované repliky navíc nabízejí flexibilitu a elasticitu, aby vyhovovaly mnoha dalším případům použití:

  • Izolace přístupu: Můžete udělit přístup ke konkrétní pojmenované replice, ale ne primární nebo jiné pojmenované repliky.
  • Cíl na úrovni služby závislý na úlohách: jako pojmenovaná replika může mít vlastní cíl na úrovni služby, je možné použít různé pojmenované repliky pro různé úlohy a případy použití. Například jednu pojmenovanou repliku lze použít k obsluhování požadavků Power BI, zatímco jiná se dá použít k obsluhování dat do Apache Sparku pro Datová Věda úloh. Každý z nich může mít nezávislý cíl na úrovni služby a nezávisle škálovat.
  • Směrování závislé na úlohách: s až 30 pojmenovanými replikami je možné použít pojmenované repliky ve skupinách, aby bylo možné aplikaci izolovat od jiné. Například skupinu čtyř pojmenovaných replik lze použít k obsluhování požadavků přicházejících z mobilních aplikací, zatímco k obsluhování požadavků přicházejících z webové aplikace je možné použít jinou skupinu dvou pojmenovaných replik. Tento přístup by umožnil jemně odstupňované ladění výkonu a nákladů pro každou skupinu.

Poznámka:

Nejčastější dotazy týkající se hyperškálování pojmenovaných replik najdete v nejčastějších dotazech k hyperškálování pojmenovaných replik služby Azure SQL Database.

Zónová redundance pro pojmenované repliky Hyperscale

Hyperškálování pojmenovaných replik nakonfigurovaných pro zónovou redundanci využívá Azure Zóny dostupnosti k distribuci výpočetních uzlů pojmenovaných replik napříč různými fyzickými umístěními v rámci oblasti Azure. Výběrem redundance zóny pro pojmenované repliky můžete zvýšit odolnost všech vrstev databází Hyperscale na širší škálu selhání, včetně výpadků datacentra, bez jakýchkoli úprav logiky aplikace. Další informace najdete v tématu Zónově redundantní dostupnost hyperškálování.

Kurz vytvoření zónově redundantní hyperškálování pojmenované repliky naleznete v tématu Vytvoření hyperškálování pojmenované repliky.

Informace o řešení potíží a testování odolnosti proti chybám aplikací najdete v tématu Testování odolnosti proti chybám aplikace.

Geografická replika

Při aktivní geografické replikaci můžete vytvořit čitelné sekundární repliky primární databáze Hyperscale ve stejné oblasti nebo v jiné oblasti Azure. Geografické repliky musí být vytvořeny na jiném logickém serveru. Název databáze geografické repliky se vždy shoduje s názvem databáze primární repliky.

Při vytváření geografické repliky se všechna data zkopírují z primární do jiné sady stránkových serverů. Geografická replika nesdílí stránkové servery s primárním serverem, i když jsou ve stejné oblasti. Tato architektura poskytuje potřebnou redundanci pro geografické převzetí služeb při selhání.

Geografické repliky se používají k udržování transakční konzistentní kopie databáze prostřednictvím asynchronní replikace. Pokud je geografická replika v jiné oblasti Azure, dá se použít k zotavení po havárii, pokud dojde k havárii nebo výpadku v primární oblasti. Geografické repliky je možné použít také pro scénáře horizontálního navýšení kapacity geografického čtení. Od října 2022 se podporuje kopírování databáze z geograficky sekundární repliky Hyperscale.

Geografická replikace databáze Hyperscale má následující aktuální omezení:

  • Lze vytvořit pouze jednu geografickou repliku (ve stejné nebo jiné oblasti).
  • Obnovení geografické repliky k určitému bodu v čase se nepodporuje.
  • Vytvoření geografické repliky geografické repliky (označované také jako řetězení geografických replik) se nepodporuje.

Odstraňování potíží

Řešení potíží se zónově redundantními replikami s názvem Hyperscale

  • Informace o řešení potíží a testování odolnosti proti chybám aplikací najdete v tématu Testování odolnosti proti chybám aplikace.

  • Při vytváření zónově redundantní pojmenované repliky v PowerShellu a rozhraní příkazového řádku se ujistěte, že je zadána alespoň jedna replika s vysokou dostupností. Příklad najdete v tématu Vytvoření hyperškálování pojmenované repliky.

    • V Azure CLI musíte zadat parametry ha-replicas i redundant.
    • V PowerShellu musíte zadat parametr HighAvailabilityReplicaCount a ZoneRedundant.
    • Pokud tuto chybu vynecháte, zobrazí se chybová zpráva: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • Databáze Hyperscale by už měla mít povolenou redundanci zón jako předpoklad pro povolení této funkce pro pojmenované repliky.

    • Je volitelné povolit redundanci zón pro pojmenované repliky, i když má primární databáze povolenou redundanci zóny.
    • Pokud není povoleno, zobrazí se chybová zpráva: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Známé problémy

Částečně nesprávná data vrácená z sys.databases

Hodnoty řádků vrácené z sys.databases, pro pojmenované repliky, v jiných sloupcích než name a database_id, mohou být nekonzistentní a nesprávné. Například compatibility_level sloupec pojmenované repliky může být hlášen jako 140, i když je primární databáze odpovídající pojmenované replice nastavená na úroveň kompatibility 150. Alternativním řešením, pokud je to možné, je získat stejná data pomocí DATABASEPROPERTYEX() funkce, která vrací správná data.

Související obsah

Kurzy týkající se konfigurace a správy pojmenovaných replik Hyperscale najdete v následujících tématech:

Další informace naleznete v tématu: