Delen via

Hyperscale secundaire replica's

Van toepassing op:Azure SQL Database

Zoals beschreven in Architectuur voor gedistribueerde functies, heeft Azure SQL Database Hyperscale twee verschillende typen rekenknooppunten, ook wel replica's genoemd:

Secundaire replica's zijn altijd alleen-lezen en kunnen van drie verschillende typen zijn:

  • Replica met hoge beschikbaarheid
  • Geo-replica
  • Benoemde replica

Elk type heeft een andere architectuur, functieset, doel en kosten. Op basis van de functies die je nodig hebt, kun je slechts één of zelfs alle drie samen gebruiken. U kunt secundaire replica's gebruiken met serverloze of ingerichte rekenlagen.

Zie voor zelfstudies over het configureren en beheren van replica's met een Hyperscale-naam:

Replica met hoge beschikbaarheid

Een replica met hoge beschikbaarheid (HA) maakt gebruik van dezelfde paginaservers als de primaire replica, dus er is geen gegevenskopie vereist om een HA-replica toe te voegen. HA-replica's worden gebruikt om de beschikbaarheid van databases te vergroten; Ze fungeren als hot stand-by replica's voor failover-doeleinden. Als de primaire replica niet meer beschikbaar is, wordt de failover naar een van de bestaande HA-replica's automatisch en snel uitgevoerd. De verbindingsreeks hoeft niet te veranderen; Tijdens failover-toepassingen kunnen minimale downtime ervaren als gevolg van het verbreken van actieve verbindingen. Zoals gebruikelijk voor dit scenario, wordt de juiste logica voor opnieuw proberen aanbevolen. Verschillende stuurprogramma's bieden al een zekere mate van logica voor automatisch opnieuw proberen. Als u .NET gebruikt, biedt de nieuwste Microsoft.Data.SqlClient-bibliotheek systeemeigen volledige ondersteuning voor configureerbare logica voor automatisch opnieuw proberen.

HA-replica's gebruiken dezelfde server- en databasenaam als de primaire replica. Hun Service Level Objective (SLO) is ook altijd hetzelfde als voor de primaire replica. HA-replica's zijn niet zichtbaar of beheerbaar als zelfstandige resources, vanuit de portal of vanuit een API. Ze worden gefactureerd tegen dezelfde rekensnelheid als de primaire replica, maar opslagkosten zijn niet van toepassing op secundaire replica's.

Er kunnen nul tot vier HA-replica's zijn. U kunt het aantal replica's opgeven tijdens het maken van een nieuwe database of het aantal replica's voor een bestaande database bijwerken. U kunt de algemene beheereindpunten en -hulpprogramma's (bijvoorbeeld: Azure PowerShell, Azure CLI, Azure Portal, REST API) gebruiken om het aantal HA-replica's op te geven. Het maken of verwijderen van HA-replica's heeft geen invloed op actieve verbindingen op de primaire replica.

Aansluiten op een HA-replica

In hyperscale-databases bepaalt het ApplicationIntent argument in de verbindingsreeks die door de client wordt gebruikt, of de verbinding wordt gerouteerd naar de primaire replica voor lezen en schrijven of naar een alleen-lezen HA-replica. Als ApplicationIntent is ingesteld op ReadOnly en de database geen secundaire replica heeft, wordt de verbinding gerouteerd naar de primaire replica en wordt standaard het ReadWrite gedrag ingesteld.

-- 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;

Alle HA-replica's zijn identiek in hun resourcecapaciteit. Als er meer dan één HA-replica aanwezig is, wordt de leesintentieworkload willekeurig verdeeld over alle beschikbare HA-replica's. Als er meerdere HA-replica's zijn, moet u er rekening mee houden dat elke replica een andere gegevenslatentie kan hebben met betrekking tot gegevenswijzigingen die op de primaire replica zijn aangebracht. Elke HA-replica gebruikt dezelfde gegevens als de primaire replica op dezelfde set paginaservers. Lokale gegevenscaches op elke HA-replica weerspiegelen echter de wijzigingen die zijn aangebracht op de primaire replica via de transactielogboekservice, die logboekrecords van de primaire replica doorstuurt naar HA-replica's. Als gevolg hiervan kan de toepassing van logboekrecords, afhankelijk van de workload die op de HA-replica wordt uitgevoerd, met verschillende snelheden plaatsvinden, en daarom kunnen verschillende replica's een verschillende gegevenslatentie hebben ten opzichte van de primaire replica.

Benoemde replica

Een replica met een naam maakt, net als een HA-replica, gebruik van dezelfde paginaservers als de primaire replica. Net als bij HA-replica's is er geen gegevenskopie nodig om een benoemde replica toe te voegen.

Er zijn verschillen tussen HA-replica's en replica's op naam:

  • Benoemde replica's worden weergegeven als gewone (alleen-lezen) Azure SQL-databases in de portal en in API-aanroepen (Azure CLI, Azure PowerShell, T-SQL).
  • Benoemde replica's kunnen een andere databasenaam hebben dan de primaire replica en zich eventueel op een andere logische server bevinden (zolang deze zich in dezelfde regio bevindt als de primaire replica).
  • Benoemde replica's hebben hun eigen Service Level Objective die onafhankelijk van de primaire replica kan worden ingesteld en gewijzigd.
  • Benoemde replica's bieden ondersteuning voor maximaal 30 benoemde replica's (voor elke primaire replica).
  • Benoemde replica's ondersteunen verschillende verificatie voor elke benoemde replica door verschillende aanmeldingen te maken op logische servers die benoemde replica's hosten.

Als gevolg hiervan bieden benoemde replica's verschillende voordelen ten opzichte van HA-replica's, voor wat betreft alleen-lezen workloads:

  • Gebruikers die zijn verbonden met een benoemde replica, worden niet verbroken als de primaire replica omhoog of omlaag wordt geschaald.
  • Gebruikers die zijn verbonden met de primaire replica worden niet beïnvloed wanneer benoemde replica's worden vergroot of verkleind.

Het belangrijkste doel van benoemde replica's is het mogelijk maken van een breed scala aan uitschrijvingsscenario's voor lezen en het verbeteren van HTAP-workloads (Hybrid Transactional and Analytical Processing). Voorbeelden van hoe u dergelijke oplossingen kunt maken, zijn hier beschikbaar:

Bovendien bieden named replica's flexibiliteit en elasticiteit om ook aan vele andere gebruiksscenario's te voldoen:

  • Toegangsisolatie: u kunt toegang verlenen tot een specifieke benoemde replica, maar niet tot de primaire replica of andere benoemde replica's.
  • Workloadafhankelijke serviceniveaudoelstelling: aangezien een benoemde replica een eigen serviceniveaudoelstelling kan hebben, is het mogelijk om verschillende benoemde replica's te gebruiken voor verschillende workloads en gebruiksscenario's. De ene replica met een naam kan bijvoorbeeld worden gebruikt om Power BI-aanvragen af te dienen, terwijl een andere replica kan worden gebruikt om gegevens te leveren aan Apache Spark voor Data Science-taken. Elk kan een onafhankelijke doelstelling op het gebied van serviceniveau hebben en onafhankelijk schalen.
  • Werklastafhankelijke routering: met maximaal 30 benoemde replica's is het mogelijk om benoemde replica's in groepen te gebruiken, zodat een toepassing van een andere kan worden geïsoleerd. Een groep van vier benoemde replica's kan bijvoorbeeld worden gebruikt om aanvragen af te dienen die afkomstig zijn van mobiele toepassingen, terwijl een andere groep van twee benoemde replica's kan worden gebruikt om aanvragen af te dienen die afkomstig zijn van een webtoepassing. Deze aanpak zou een fijnmazige afstemming van de prestaties en kosten voor elke groep mogelijk maken.

Opmerking

Zie Veelgestelde vragen over replica's met een hyperscale die een naam hebben bereikt, zie Veelgestelde vragen over replica's met een naam in Azure SQL Database Hyperscale op naam.

Zoneredundantie voor replica's met hyperscale

Hyperscale benoemde replica's die zijn geconfigureerd voor zoneredundantie, maken gebruik van Azure-beschikbaarheidszones om benoemde replica's rekenknooppunten te distribueren over verschillende fysieke locaties binnen een Azure-regio. Door zoneredundantie te kiezen voor benoemde replica's, kunt u de tolerantie van alle lagen van uw Hyperscale-databases verbeteren tegen een breder scala aan fouten, waaronder datacenterstoringen, zonder enige wijziging van de toepassingslogica. Zie Redundante beschikbaarheid van hyperscale-zones voor meer informatie.

Zie Een replica met hyperschaalnaam maken voor een zelfstudie voor het maken van een replica met hyperscale-benoemde naam voor een zone-redundante hyperscale-benoemde replica.

Zie Tolerantie van toepassingsfouten testen voor het oplossen van problemen en het testen van de tolerantie van toepassingsfouten.

Geografische replica

Met actieve geo-replicatie kunt u een leesbare secundaire replica maken van de primaire Hyperscale-database in dezelfde of in een andere Azure-regio. Geo-replica's moeten op een andere logische server worden gemaakt. De databasenaam van een geo-replica komt altijd overeen met de databasenaam van de primaire.

Wanneer u een georeplica maakt, worden alle gegevens gekopieerd van de primaire naar een andere set paginaservers. Een geo-replica deelt geen paginaservers met de primaire server, zelfs niet als ze zich in dezelfde regio bevinden. Deze architectuur biedt de nodige redundantie voor geo-failovers.

Geo-replica's worden gebruikt om een transactioneel consistente kopie van de database te onderhouden via asynchrone replicatie. Als een georeplica zich in een andere Azure-regio bevindt, kan deze worden gebruikt voor herstel na noodgevallen als er een noodgeval of storing is in de primaire regio. Geo-replica's kunnen ook worden gebruikt voor geografische uitleesscenario's. Vanaf oktober 2022 wordt databasekopie van een secundaire Hyperscale geo-replica ondersteund.

Geo-replicatie voor Hyperscale database heeft de volgende huidige beperkingen:

  • Er kan slechts één geo-replica worden gemaakt (in dezelfde of een andere regio).
  • Herstel op een bepaald tijdstip van de geo-replica wordt niet ondersteund.
  • Het maken van een georeplica van een georeplica (ook wel 'georeplica-ketening' genoemd) wordt niet ondersteund.

Problemen oplossen

Problemen met zone-redundante Hyperscale-replica's met een naam oplossen

  • Zie Tolerantie van toepassingsfouten testen voor het oplossen van problemen en het testen van de tolerantie van toepassingsfouten.

  • Zorg ervoor dat ten minste één replica met hoge beschikbaarheid is opgegeven bij het maken van een zone-redundante replica met een naam in PowerShell en CLI. Zie Een replica met een hyperscale met de naam maken.

    • In Azure CLI moet u zowel de parameters ha-replicas als redundant.
    • In PowerShell moet u de parameter HighAvailabilityReplicaCount en ZoneRedundantopgeven.
    • Als dit wordt weggelaten, ontvangt u de foutmelding: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • In de Hyperscale-database moet zoneredundantie al zijn ingeschakeld als vereiste om deze functie in te schakelen voor benoemde replica's.

    • Het is optioneel om zoneredundantie in te schakelen voor benoemde replica's, zelfs als zoneredundantie is ingeschakeld in de primaire database.
    • Als dit niet is ingeschakeld, ontvangt u het foutbericht: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Bekende problemen

Gedeeltelijk onjuiste gegevens geretourneerd uit sys.databases

Rijwaarden die worden geretourneerd uit sys.databases, voor benoemde replica's, in andere kolommen dan name en database_id, kunnen inconsistent en onjuist zijn. De compatibility_level kolom voor een benoemde replica kan bijvoorbeeld worden gerapporteerd als 140, zelfs als de primaire database die overeenkomt met de benoemde replica is ingesteld op compatibiliteitsniveau 150. Een tijdelijke oplossing, indien mogelijk, is om dezelfde gegevens op te halen met behulp van de DATABASEPROPERTYEX() functie, die de juiste gegevens retourneert.

Verwante inhoud

Zie voor zelfstudies over het configureren en beheren van replica's met een Hyperscale-naam:

Voor meer informatie, zie: