Dela via

Checklista för hög tillgänglighet och haveriberedskap i Azure SQL Database

  • Artikel

Gäller för:Azure SQL Database

Azure SQL Database-tjänsten säkerställer automatiskt att alla databaser är online, felfria och ständigt strävar efter att uppnå det publicerade serviceavtalet.

Den här guiden innehåller en detaljerad genomgång av proaktiva åtgärder som du kan vidta för att maximera tillgängligheten, säkerställa återställning och förbereda för Azure-avbrott. Den här vägledningen gäller för alla inköpsmodeller och tjänstnivåer i Azure SQL Database.

Checklista för tillgänglighet

Följande är rekommenderade konfigurationer för att maximera tillgängligheten:

Checklista för hög tillgänglighet

Följande är den rekommenderade konfigurationen för att uppnå hög tillgänglighet:

  • Aktivera zonredundans där det är tillgängligt för databasen eller den elastiska poolen för att säkerställa återhämtning vid zonfel.

Checklista för haveriberedskap

Även om Azure SQL Database automatiskt bibehåller tillgängligheten finns det instanser när även hög tillgänglighet (zonredundans) kanske inte garanterar återhämtning eftersom det påverkade driftstoppet sträcker sig över en hel region. Ett regionalt Azure SQL Database-avbrott kan kräva att du initierar haveriberedskap.

Följ dessa rekommendationer för att förbereda för haveriberedskap på bästa sätt:

  • Aktivera redundansgrupper för en grupp databaser.
    • Använd slutpunkterna skrivskyddad och skrivskyddad lyssnare i programmet anslutningssträng så att program automatiskt ansluter till den server och databas som är primär.
    • Ange redundanspolicyn till kundhanterad.
  • Alternativt kan du aktivera aktiv geo-replikering för att ha en läsbar sekundär databas i en annan Azure-region.
  • Se till att den geo-sekundära databasen skapas med samma tjänstnivå, beräkningsnivå (etablerad eller serverlös) och beräkningsstorlek (DTU:er eller virtuella kärnor) som den primära databasen.
  • När du skalar upp skalar du först upp den geo-sekundära och skalar sedan upp den primära.
  • När du skalar ned gör du det i omvänd ordning: skala ned den primära först och sedan den sekundära.
  • Haveriberedskap är till sin natur utformad för att använda asynkron replikering av data mellan den primära och sekundära regionen. Om du vill prioritera datatillgänglighet framför högre fördröjning vid incheckning kan du anropa den sp_wait_for_database_copy_sync lagrade proceduren omedelbart efter att transaktionen har genomförts. Anrop sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senast checkade transaktionen har överförts och härdats i transaktionsloggen för den sekundära databasen.
  • Övervaka fördröjning med avseende på mål för återställningspunkt (RPO) med hjälp replication_lag_sec av kolumnen i sys.dm_geo_replication_link_status dynamisk hanteringsvy (DMV) på den primära databasen. DMV visar fördröjning i sekunder mellan transaktionerna som checkas in på den primära och härdade till transaktionsloggen på den sekundära. Anta till exempel att fördröjningen är en sekund vid en tidpunkt, om det primära påverkas av ett avbrott och en geo-redundans initieras vid den tidpunkten, kommer transaktioner som checkas in under den sista sekunden att gå förlorade.
  • Om det inte går att aktivera redundansgrupper eller aktiv geo-replikering kan du överväga att ställa in redundansalternativet för säkerhetskopiering till Geo-redundant lagring av säkerhetskopiering för att använda geo-återställningsfunktionen.
  • Planera och kör ofta haveriberedskapstest så att du är bättre förberedd i händelse av ett verkligt avbrott.

Förbereda sekundärt för ett avbrott

För lyckad återställning till en annan dataregion med aktiv geo-replikering, redundansgrupper eller geo-återställning måste du förbereda en sekundär logisk Azure SQL Database-server i en annan region. Den här sekundära servern kan bli den nya primära servern om det behövs. Du bör också ha väldefinierade steg dokumenterade och testade för att säkerställa en smidig återställning. De här förberedelsestegen omfattar:

  • För geo-återställning identifierar du servern i en annan region för att bli den nya primära servern. Detta är vanligtvis en server i den kopplade regionen för den region där din primära databas finns. Att använda en server i samma region eliminerar den extra trafikkostnaden under geo-återställningsåtgärder.
  • Bestäm hur du ska omdirigera användare till den nya primära servern. Omdirigering av användare kan utföras genom att manuellt ändra program anslutningssträng eller DNS-poster. Om du har konfigurerat redundansgrupper och använder den skrivskyddade och skrivskyddade lyssnaren i program anslutningssträng behövs ingen ytterligare åtgärd – anslutningar dirigeras automatiskt till ny primär efter redundansväxling.
  • Identifiera och definiera de brandväggsregler som krävs för att användarna ska få åtkomst till den nya primära databasen.
  • Identifiera, och eventuellt skapa, de inloggningar som måste finnas i master databasen på den nya primära servern och se till att dessa inloggningar har lämpliga behörigheter i master databasen, om sådana finns. Mer information finns i Azure SQL Database-säkerhet efter haveriberedskap.
  • Identifiera aviseringsregler som måste uppdateras för att mappa till den nya primära.
  • Dokumentera granskningskonfigurationen för den aktuella primära.

Relaterat innehåll