Dela via

Checklista för hög tillgänglighet och haveriberedskap – 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:

  • Införliva omförsökslogik i programmet för att hantera tillfälliga fel.
  • Använd underhållsfönster för att göra påverkanskänsliga underhållshändelser förutsägbara och mindre störande.
  • Testa programfelresiliens genom att manuellt utlösa en övergång till reservsystem för att se resiliens i praktiken.

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 den är tillgänglig för databasen eller den elastiska poolen för att säkerställa återhämtning för zonfel.

Checklista för katastrofåterställning

Ä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ör att bäst förbereda för katastrofåterställning, följ dessa rekommendationer:

  • Aktivera redundansgrupper för en grupp databaser.
    • Använd läs- och skrivlyssnare och skrivskyddade lyssnare i din anslutningssträng så att dina program automatiskt ansluter till den server och databas som är den aktuella primära servern.
    • Ange redundansprincipen till kundhanterad.
  • Istället för felövergrupper kan du aktivera aktiv geo-replikering och få en läsbar sekundär databas i en annan Azure-region.
  • Kontrollera 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 ändrar du ordningen: skala ned den primära först och skala sedan ned 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 bekräftelse kan du anropa den sp_wait_for_database_copy_sync lagrade proceduren omedelbart efter att en transaktion har genomförts. Att anropa sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senaste bekräftade transaktionen har skickats och härdats i transaktionsloggen för den sekundära databasen.
  • Övervaka fördröjningen i förhållande till återställningspunktsmål (RPO) med hjälp av kolumnen replication_lag_sec i sys.dm_geo_replication_link_status dynamisk hanteringsvy, DMV, på den primära databasen. DMV visar försening i sekunder mellan transaktioner som genomförts på den primära och loggats i transaktionsloggen på den sekundära. Anta till exempel att fördröjningen är en sekund, om huvudenheten påverkas av ett avbrott och en geo-failover initieras vid den tidpunkten, kommer transaktionerna som bekräftades under den senaste sekunden att gå förlorade.
  • Om det inte går att aktivera redundansgrupper eller aktiv geo-replikering kan du överväga att ange alternativet redundans för säkerhetskopieringslagring till geo-redundant lagring för att använda geo-återställning för Azure SQL Database.
  • Planera och genomför ofta katastrofåterställningsövningar så att ni är bättre förberedda ifall ett verkligt avbrott skulle inträffa.

Förbered sekundärsystemet för ett avbrott

Om du vill återställa 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 en server i en annan region så att den blir den nya primära servern. Om din primära region har en parkopplad region ,, är det vanligt att använda den parkopplade regionen som din sekundära region. Genom att göra detta minskar du vanligtvis svarstiden för replikerings- och 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 programanslutningssträngar eller DNS-poster. Om du har konfigurerat failover-grupper och använder den läs-skriv- och skrivskyddade lyssnaren i programanslutningssträngar behövs ingen ytterligare åtgärd – anslutningar dirigeras automatiskt till ny primär efter failover.
  • Identifiera och, vid behov, definiera brandväggsregler som användarna behöver för å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 rätt behörigheter i master-databasen, om sådana finns. Mer information finns i Azure SQL Database-säkerhet efter katastrofåterställning.
  • Identifiera aviseringsregler som måste uppdateras för att anpassas till den nya huvudpunkten.
  • Dokumentera granskningskonfigurationen på den aktuella primära servern och gör den identisk på den sekundära servern.

Relaterat innehåll