Dela via

Checklista för hög tillgänglighet och haveriberedskap – Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Azure SQL Managed Instance-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 tjänstnivåer i Azure SQL Managed Instance.

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 backup för att se det 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 det är tillgängligt för SQL-hanterad instans som säkerställer motståndskraft vid zonfel.

Checklista för katastrofåterställning

Även om Azure SQL Managed Instance automatiskt bibehåller tillgängligheten finns det instanser när även hög tillgänglighet (zonredundans) kanske inte garanterar återhämtning eftersom det påverkar avbrott som sträcker sig över en hel region. Ett regionalt avbrott i Azure SQL Managed Instance kan kräva att du initierar katastrofåterställning.

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

  • Aktivera redundansgrupper för en instans.
    • Använd lyssnarslutpunkterna för både läs/skriv och endast läs i anslutningssträngen för applikationen så att program automatiskt ansluter till den instans som är primär.
    • Ställ in failover-policy till kundhanterad.
  • Se till att den geo-sekundära instansen skapas med samma tjänstnivå, maskinvarugenerering och beräkningsstorlek som den primära instansen.
  • 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 datareplikering mellan den primära och sekundära regionen. Om du vill prioritera datatillgänglighet framför högre fördröjning vid commit kan du anropa den sp_wait_for_database_copy_sync lagrade proceduren omedelbart efter att en transaktion har genomförts. Ett anrop till sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senaste committerade transaktionen har överförts och härdats i den sekundära databasens transaktionslogg.
  • Övervaka fördröjningen i förhållande till Recovery Point Objective (RPO) genom att använda kolumnen replication_lag_sec i sys.dm_geo_replication_link_status dynamiska hanteringsvy (DMV) på den primära databasen. DMV visar fördröjning i sekunder mellan transaktionerna som bekräftats på den primära servern och skrivits till transaktionsloggen på den sekundära servern. Anta till exempel att fördröjningen är en sekund vid en tidpunkt, om det primära systemet påverkas av ett avbrott och en geo-överlåtelse initieras just då, kommer transaktioner som genomförts under den sista sekunden att gå förlorade.
  • Om det inte går att aktivera redundansgrupper kan du överväga att ställa in alternativet redundans för säkerhetskopieringslagring till geo-redundant säkerhetskopieringslagring för att använda funktionen geoåterställning.
  • Planera och genomför regelbundet katastrofåterställningsövningar så att du är bättre förberedd vid ett verkligt avbrottstillfälle.

Förbered ett sekundärt system för ett avbrott

Om du vill återställa till en annan dataregion med hjälp av redundansgrupper eller geo-återställning måste du förbereda en sekundär Azure SQL Managed Instance i en annan region. Den här sekundära instansen kan bli den nya primära instansen 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 instans i en annan region så att den blir den nya primära instansen. Om din primära region har en associerad regionär det vanligt att använda den associerade regionen som sekundärregion. 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 redundansgrupper och använder både läs- och skrivlyssnaren samt skrivskyddad lyssnare i anslutningssträngarna till programmet, behövs ingen ytterligare åtgärd – anslutningar dirigeras automatiskt till den nya primären efter redundansväxling.
  • Identifiera och definiera om nödvändigt NSG och routetabellkonfiguration som användarna behöver för att komma åt 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.
  • Dokumentera granskningskonfigurationen på den nuvarande primära instansen och anpassa så den blir likadan på den sekundära instansen.

Relaterat innehåll

Mer information finns i: