Actieve geo-replicatie

VAN TOEPASSING OP: Azure SQL Database

Actieve geo-replicatie is een functie waarmee u een continu gesynchroniseerde, leesbare secundaire database voor een primaire database kunt maken. De leesbare secundaire database kan zich in dezelfde Azure-regio als de primaire of, vaker, in een andere regio. Dit soort leesbare secundaire databases worden ook wel geo-secundaire databases of geo-replica's genoemd.

Actieve geo-replicatie is ontworpen als een oplossing voor bedrijfscontinuïteit waarmee u snel herstel na noodgeval van afzonderlijke databases kunt uitvoeren in het geval van een regionaal noodgeval of een grootschalige storing. Zodra geo-replicatie is ingesteld, kunt u een geo-failover naar een geo-secundaire regio in een andere Azure-regio initiëren. De geo-failover wordt programmatisch geïnitieerd door de toepassing of handmatig door de gebruiker.

Als uw toepassing naast geo-replicatie een stabiel verbindings-eindpunt en automatische ondersteuning voor geo-failover vereist, gebruikt u Groepen voor automatische failover.

Het volgende diagram illustreert een typische configuratie van een geografisch redundante cloudtoepassing met behulp van actieve geo-replicatie.

Als uw primaire database om een of andere reden mislukt, kunt u een geo-failover naar een van uw secundaire databases initiëren. Wanneer een secundaire wordt gepromoveerd naar de primaire rol, worden alle andere secundaire bestanden automatisch gekoppeld aan de nieuwe primaire.

U kunt geo-replicatie beheren en een geo-failover starten met behulp van het volgende:

• De Azure Portal
• PowerShell: individuele database
• PowerShell: Elastische pool
• Transact-SQL: individuele database of elastische pool
• REST API: Individuele database

Actieve geo-replicatie maakt gebruik van de AlwaysOn-technologie voor beschikbaarheidsgroep om transactielogboek dat is gegenereerd op de primaire replica asynchroon te repliceren naar alle geo-replica's. Hoewel een secundaire database op een bepaald moment iets achter de primaire database kan liggen, zijn de gegevens op een secundaire database gegarandeerd transactioneel consistent. Met andere woorden, wijzigingen die worden aangebracht door niet-doorgevoerde transacties zijn niet zichtbaar.

Met regionale redundantie die wordt geboden door geo-replicatie kunnen toepassingen snel herstellen van een permanent verlies van een volledige Azure-regio of delen van een regio, veroorzaakt door natuurrampen, onherstelbare menselijke fouten of schadelijke acties. Geo-replicatie RPO vindt u in Overzicht van bedrijfscontinuïteit.

In de volgende afbeelding ziet u een voorbeeld van actieve geo-replicatie die is geconfigureerd met een primaire replicatie in de regio VS - noord-centraal en een geo-secundaire replicatie in de regio VS - zuid-centraal.

Naast herstel na nood gevallen kan actieve geo-replicatie worden gebruikt in de volgende scenario's:

• Databasemigratie: u kunt actieve geo-replicatie gebruiken om een database met minimale downtime van de ene server naar de andere te migreren.
• Toepassingsupgrades: u kunt een extra secundaire kopie maken als failback-kopie tijdens toepassingsupgrades.

Voor volledige bedrijfscontinuïteit maakt het toevoegen van regionale redundantie van databases slechts deel uit van de oplossing. Als u een toepassing (service) end-to-end herstelt na een onherstelbare fout, moet u alle onderdelen herstellen waar de service deel van uit maakt en alle afhankelijke services. Voorbeelden van deze onderdelen zijn de clientsoftware (bijvoorbeeld een browser met een aangepaste JavaScript), webfront-ends, opslag en DNS. Het is essentieel dat alle onderdelen bestand zijn tegen dezelfde fouten en beschikbaar komen binnen de RTO (Recovery Time Objective) van uw toepassing. Daarom moet u alle afhankelijke services identificeren en inzicht krijgen in de garanties en mogelijkheden die ze bieden. Vervolgens moet u voldoende stappen ondernemen om ervoor te zorgen dat uw service functioneert tijdens de failover van de services waarvan deze afhankelijk is. Zie Cloudoplossingen ontwerpen voor herstel na noodherstel met behulp van actieve geo-replicatie voor meer informatie over het ontwerpen van oplossingen voor herstel na noodherstel.

Terminologie en mogelijkheden voor actieve geo-replicatie

• Automatische asynchrone replicatie

  U kunt alleen een geo-secundaire database maken voor een bestaande database. De geo-secundaire server kan worden gemaakt op elke logische server, met andere dan de server met de primaire database. Na het maken wordt de geo-secundaire replica gevuld met de gegevens van de primaire database. Dit proces wordt seeding genoemd. Nadat een geo-secundaire database is gemaakt en geseed, worden updates voor de primaire database automatisch en asynchroon gerepliceerd naar de geo-secundaire replica. Asynchrone replicatie betekent dat transacties worden vastgelegd op de primaire database voordat ze worden gerepliceerd.

• Leesbare geo-secundaire replica's

  Een toepassing heeft toegang tot een geo-secundaire replica om alleen-lezenquery's uit te voeren met behulp van dezelfde of verschillende beveiligings-principals die worden gebruikt voor toegang tot de primaire database. Zie Use read-only replicas to offload read-only query workloads (Alleen-lezenreplica's gebruiken om alleen-lezenqueryworkloads te offloaden) voor meer informatie.

  Belangrijk

  U kunt geo-replicatie gebruiken om secundaire replica's te maken in dezelfde regio als de primaire replica's. U kunt deze secondaries gebruiken om te voldoen aan uitschaalscenario's voor lezen in dezelfde regio. Een secundaire replica in dezelfde regio biedt echter geen extra tolerantie tegen onherstelbare storingen of grootschalige storingen en is daarom geen geschikt failoverdoel voor noodhersteldoeleinden. Het biedt ook geen garantie voor isolatie van beschikbaarheidszone. Gebruik Bedrijfskritiek of Premium zone-redundante configuratie voor servicelagen of Algemeen zone-redundante configuratie voor servicelagen om isolatie van beschikbaarheidszone te bereiken.

• Geplande geo-failover

  Geplande geo-failover schakelt over naar de rollen van primaire en geo-secundaire databases na het voltooien van de volledige gegevenssynchronisatie. Een geplande failover leidt niet tot gegevensverlies. De duur van de geplande geo-failover is afhankelijk van de grootte van het transactielogboek op de primaire die moet worden gesynchroniseerd met de geo-secundaire. Geplande geo-failover is ontworpen voor de volgende scenario's:

  • Dr-oefeningen uitvoeren in productie wanneer het gegevensverlies niet acceptabel is;
  • Verplaats de database naar een andere regio;
  • Keer de database terug naar de primaire regio nadat de storing is vereengeld (ook wel failback genoemd).

• Niet-geplande geo-failover

  Met niet-geplande of geforceerd geo-failover wordt de geo-secundaire functie onmiddellijk overgezet naar de primaire rol zonder synchronisatie met de primaire rol. Alle transacties die zijn vastgelegd op de primaire maar nog niet gerepliceerd naar de secundaire, gaan verloren. Deze bewerking is ontworpen als een herstelmethode tijdens uitval wanneer de primaire niet toegankelijk is, maar de beschikbaarheid van de database snel moet worden hersteld. Wanneer de oorspronkelijke primaire versie weer online is, wordt deze automatisch opnieuw verbonden, opnieuw gekoppeld met behulp van de huidige primaire gegevens en wordt deze een nieuwe geo-secundaire.

  Belangrijk

  Na een geplande of niet-geplande geo-failover wordt het verbindings-eindpunt voor de nieuwe primaire gewijzigd omdat de nieuwe primaire server zich nu op een andere logische server bevindt.

• Meerdere leesbare geo-secondaries

  Er kunnen maximaal vier geo-secundaire bestanden worden gemaakt voor een primaire. Als er slechts één secundaire is en deze mislukt, loopt de toepassing een hoger risico totdat er een nieuwe secundaire wordt gemaakt. Als er meerdere secondaries bestaan, blijft de toepassing beveiligd, zelfs als een van de secondaries uitvalt. Aanvullende secondaries kunnen ook worden gebruikt om alleen-lezen workloads uit te schalen.

  Tip

  Als u actieve geo-replicatie gebruikt om een wereldwijd gedistribueerde toepassing te bouwen en alleen-lezentoegang tot gegevens in meer dan vier regio's wilt bieden, kunt u een secundaire van een secundaire toepassing (een proces dat ketening wordt genoemd) maken om extra geo-replica's te maken. Replicatievertraging op gekoppelde geo-replica's kan hoger zijn dan op geo-replica's die rechtstreeks zijn verbonden met de primaire replica's. Het instellen van geketende geo-replicatie-topologies wordt alleen programmatisch ondersteund en niet vanuit Azure Portal.

• Geo-replicatie van databases in een elastische pool

  Elke geo-secundaire database kan één database of een database in een elastische pool zijn. De elastische poolkeuze voor elke geo-secundaire database is gescheiden en is niet afhankelijk van de configuratie van een andere replica in de topologie (primair of secundair). Elke elastische pool is opgenomen in één logische server. Omdat databasenamen op een logische server uniek moeten zijn, kunnen meerdere geo-secundaire databases van dezelfde primaire server nooit een elastische pool delen.

• Door gebruiker beheerde geo-failover en failback

  Een geo-secundaire functie die de initiële seeding heeft voltooid, kan expliciet op elk moment door de toepassing of de gebruiker worden overgeschakeld naar de primaire rol (failed over). Tijdens een storing waarbij de primaire niet toegankelijk is, kan alleen een niet-geplande geo-failover worden gebruikt. Dat promovert onmiddellijk een geo-secundaire naar de nieuwe primaire. Wanneer de storing wordt vereenzaakt, maakt het systeem automatisch van de herstelde primaire een geo-secundaire, en wordt deze bijgewerkt met de nieuwe primaire. Vanwege de asynchrone aard van geo-replicatie kunnen recente transacties verloren gaan tijdens niet-geplande geo-failovers als de primaire failover mislukt voordat deze transacties naar een geo-secundaire transactie worden gerepliceerd. Wanneer een primaire functie met meerdere geo-secundaire replica's een fout maakt, worden de replicatierelaties automatisch opnieuw geconfigureerd en worden de resterende geo-secundaire replica's zonder tussenkomst van de gebruiker aan de zojuist gepromoveerde primaire replica's koppelt. Nadat de storing die de geo-failover heeft veroorzaakt, is beperkt, kan het wenselijk zijn om de primaire te retourneren naar de oorspronkelijke regio. U doet dit door een geplande geo-failover aan te roepen.

Voorbereiden op geo-failover

Om ervoor te zorgen dat uw toepassing onmiddellijk toegang heeft tot de nieuwe primaire server na geo-failover, controleert u of de verificatie en netwerktoegang voor uw secundaire server correct zijn geconfigureerd. Zie Beveiliging na SQL Database na noodherstel voor meer informatie. Controleer ook of het bewaarbeleid voor back-ups voor de secundaire database overeenkomt met dat van de primaire database. Deze instelling maakt geen deel uit van de database en wordt niet gerepliceerd vanuit de primaire database. De geo-secundaire regio is standaard geconfigureerd met een standaardretentieperiode van zeven dagen voor een pitr. Zie automatische back SQL Database back-ups voor meer informatie.

Geo-secundaire regio's configureren

Zowel primaire als geo-secundaire moeten dezelfde servicelaag hebben. Het wordt ook sterk aanbevolen dat de geo-secundaire is geconfigureerd met dezelfde redundantie voor back-upopslag en rekenkracht (DTUs of vCores) als de primaire. Als de primaire computer een zware schrijfbelasting ondervindt, is een geo-secundaire computer met een lagere rekenkracht mogelijk niet in staat om dit bij te houden. Dit veroorzaakt replicatievertraging op de geo-secundaire replica en kan uiteindelijk leiden tot onbeschikbaarheid van de geo-secundaire replica. Om deze risico's te beperken, vermindert (beperkt) actieve geo-replicatie zo nodig de snelheid van het transactielogboek van de primaire regio om de secundaire replica's in te halen.

Een ander gevolg van een onevenwichtige geo-secundaire configuratie is dat de prestaties van de toepassing na een failover kunnen worden verstoord door onvoldoende rekencapaciteit van de nieuwe primaire server. In dat geval is het nodig om de database omhoog te schalen om voldoende resources te hebben. Dit kan veel tijd kosten en vereist een failover met hoge beschikbaarheid aan het einde van het opschaalproces, waardoor werkbelastingen van toepassingen kunnen worden onderbroken.

Als u besluit om de geo-secundaire te maken met een lagere rekenkracht, moet u de I/O-snelheid van logboeken op de primaire in de tijd bewaken. Hiermee kunt u een schatting maken van de minimale rekenkracht van de geo-secundaire die nodig is om de replicatiebelasting te ondersteunen. Als uw primaire database bijvoorbeeld P6 (1000 DTU) is en de logboek-I/O 50% bedraagt, moet de geo-secundaire database ten minste P4 (500 DTU) zijn. Als u historische logboek-I/O-gegevens wilt ophalen, gebruikt u sys.resource_stats weergave. Als u recente logboek-I/O-gegevens met een hogere granulariteit wilt ophalen die beter in staat zijn pieken op de korte termijn weer te geven, gebruikt u sys.dm_db_resource_stats weergave.

Standaard is redundantie van back-upopslag van de geo-secundaire database hetzelfde als voor de primaire database. U kunt ervoor kiezen om een geo-secundaire opslag te configureren met een andere redundantie voor back-upopslag. Back-ups worden altijd gemaakt op de primaire database. Als de secundaire is geconfigureerd met een andere redundantie voor back-upopslag, worden nieuwe back-ups opgeslagen en gefactureerd op basis van het type opslag (RA-GRS, ZRS, LRS) dat is geselecteerd op de nieuwe primaire (vorige secundaire) wanneer de geo-secundaire opslag wordt gepromoveerd naar de primaire server.

Geo-replicatie tussen abonnementen

Volg de stappen in deze sectie om een geo-secundair abonnement te maken in een ander abonnement dan het abonnement van de primaire tenant (al dan niet onder dezelfde Azure Active Directory tenant).

1. Voeg het IP-adres van de clientmachine die de onderstaande T-SQL-opdrachten uit te voeren toe aan de serverfirewalls van de primaire en secundaire servers. U kunt dat IP-adres bevestigen door de volgende query uit te voeren terwijl u vanaf dezelfde clientmachine verbinding hebt met de primaire server.

   select client_net_address from sys.dm_exec_connections where session_id = @@SPID;
   

   Zie Firewall configureren voor meer informatie.

2. Maak in de hoofddatabase op de primaire server een SQL voor verificatie die is toegewezen aan het instellen van actieve geo-replicatie. Pas de aanmeldingsnaam en het wachtwoord naar behoefte aan.

   create login geodrsetup with password = 'ComplexPassword01';
   

3. Maak in dezelfde database een gebruiker voor de aanmelding en voeg deze toe aan de dbmanager rol:

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

4. Noteer de SID-waarde van de nieuwe aanmelding. Verkrijg de SID-waarde met behulp van de volgende query.

   select sid from sys.sql_logins where name = 'geodrsetup';
   

5. Verbinding maken naar de primaire database (niet de hoofddatabase) en maak een gebruiker voor dezelfde aanmelding.

   create user geodrsetup for login geodrsetup;
   

6. Voeg in dezelfde database de gebruiker toe aan de db_owner rol.

   alter role db_owner add member geodrsetup;
   

7. Maak in de hoofddatabase op de secundaire server dezelfde aanmelding als op de primaire server met dezelfde naam, hetzelfde wachtwoord en dezelfde SID. Vervang de hexadecimale SID-waarde in de onderstaande voorbeeldopdracht door de waarde die is verkregen in stap 4.

   create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
   

8. Maak in dezelfde database een gebruiker voor de aanmelding en voeg deze toe aan de dbmanager rol.

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

9. Verbinding maken de hoofddatabase op de primaire server met behulp van de nieuwe aanmelding en start het maken van geodrsetup geo-secundaire databases op de secundaire server. Pas de databasenaam en de secundaire servernaam naar behoefte aan. Zodra de opdracht is uitgevoerd, kunt u het maken van geo-secundaire databases controleren door een query uit te voeren op de sys.dm_geo_replication_link_status-weergave in de primaire database en de sys.dm_operation_status-weergave in de hoofddatabase op de primaire server. De tijd die nodig is om een geo-secundaire database te maken, is afhankelijk van de grootte van de primaire database.

   alter database [dbrep] add secondary on server [servername];
   

10. Nadat de geo-secundaire is gemaakt, kunnen de gebruikers, aanmeldingen en firewallregels die door deze procedure zijn gemaakt, worden verwijderd.

Referenties en firewallregels gesynchroniseerd houden

Wanneer u openbare netwerktoegang gebruikt om verbinding te maken met de database, raden we u aan IP-firewallregels op databaseniveau te gebruiken voor geo-gerepliceerde databases. Deze regels worden gerepliceerd met de database, zodat alle geo-secundaire databases dezelfde IP-firewallregels hebben als de primaire database. Deze aanpak elimineert de noodzaak voor klanten om handmatig firewallregels te configureren en te onderhouden op servers die als host voor de primaire en secundaire databases worden gebruikt. Op dezelfde manier zorgt het gebruik van ingesloten databasegebruikers voor gegevenstoegang ervoor dat zowel primaire als secundaire databases altijd dezelfde verificatiereferenties hebben. Op deze manier zijn er na een geo-failover geen onderbrekingen vanwege niet-overeenkomende verificatiereferenties. Als u aanmeldingen en gebruikers gebruikt (in plaats van ingesloten gebruikers), moet u extra stappen ondernemen om ervoor te zorgen dat dezelfde aanmeldingen bestaan voor uw secundaire database. Zie Aanmeldingen en gebruikers configureren voor configuratiedetails.

Primaire database schalen

U kunt de primaire database omhoog of omlaag schalen naar een andere rekenkracht (binnen dezelfde servicelaag) zonder de verbinding met geo-secundaire databases te verbreken. Wanneer u omhoog schaalt, raden we u aan om eerst de geo-secundaire te schalen en vervolgens de primaire op te schalen. Wanneer u omlaag schaalt, draait u de volgorde om: schaal eerst omlaag naar de primaire en vervolgens omlaag naar de secundaire.

Verlies van kritieke gegevens voorkomen

Vanwege de hoge latentie van Wide Area Networks maakt geo-replicatie gebruik van een asynchrone replicatiemechanisme. Asynchrone replicatie maakt het mogelijk dat gegevensverlies onvermijdelijk is als de primaire uitvalt. Ter bescherming van kritieke transacties tegen gegevensverlies kan een toepassingsontwikkelaar de sp_wait_for_database_copy_sync opgeslagen procedure onmiddellijk na het uitvoeren van de transactie aanroepen. Het aanroepen van blokkeert de aanroepthread totdat de laatste vastgelegde transactie is verzonden en gehard in het sp_wait_for_database_copy_sync transactielogboek van de secundaire database. Er wordt echter niet gewacht tot de verzonden transacties opnieuw zijn afgespeeld (opnieuw) op de secundaire. sp_wait_for_database_copy_sync is gericht op een specifieke geo-replicatiekoppeling. Elke gebruiker met de verbindingsrechten voor de primaire database kan deze procedure aanroepen.

Vertraging bij geo-replicatie bewaken

Als u vertraging met betrekking tot RPO wilt bewaken, gebruikt replication_lag_sec kolom met sys.dm_geo_replication_link_status in de primaire database. Het toont vertraging in seconden tussen de transacties die zijn vastgelegd op de primaire en zijn gehard voor het transactielogboek op de secundaire. Als de vertraging bijvoorbeeld één seconde is, betekent dit dat als de primaire wordt beïnvloed door een storing op dit moment en er een geo-failover wordt gestart, de transacties die in de laatste seconde zijn vastgelegd, verloren gaan.

Als u vertraging wilt meten met betrekking tot wijzigingen in de primaire database die zijn gehard op de geo-secundaire database, vergelijkt u last_commit tijd op de geo-secundaire database met dezelfde waarde op de primaire database.

Actieve geo-replicatie programmatisch beheren

Zoals eerder besproken, kan actieve geo-replicatie ook programmatisch worden beheerd met T-SQL, Azure PowerShell en REST API. In de volgende tabellen wordt de set beschikbare opdrachten beschreven. Actieve geo-replicatie bevat een set Azure Resource Manager API's voor beheer, waaronder de cmdlets Azure SQL Database REST API en Azure PowerShell. Deze API's ondersteunen op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Zie Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)voor meer informatie over het implementeren van toegangsrollen.

T-SQL: geo-failover van individuele en pooldatabases beheren

PowerShell: geo-failover van individuele en pooldatabases beheren

REST API: geo-failover van individuele en pooldatabases beheren

Volgende stappen

• Zie voor voorbeeldscripts:
  • Configureer en failover van een individuele database met behulp van actieve geo-replicatie.
  • Configureer en failover van een pooldatabase met behulp van actieve geo-replicatie.
• SQL Database ondersteunt ook groepen voor automatische failover. Zie Groepen voor automatische failover gebruiken voor meer informatie.
• Raadpleeg Overzicht van bedrijfscontinuïteit voor een bedrijfscontinuïteitsoverzicht en bedrijfscontinuïteitsscenario's.
• Zie automatische Azure SQL Database voor meer informatie over SQL Database back-ups.
• Zie Restore a database from the service-initiated backups (Een databaseherstellen vanuit de door de service geïnitieerde back-ups) voor meer informatie over het gebruik van automatische back-ups voor herstel.
• Zie Beveiliging na herstel na noodherstel voor meer informatie over de verificatievereisten voor een nieuwe primaire server SQL Database database.