Planera för Azure-underhållshändelser i Azure SQL Database och Azure SQL Managed Instance
GÄLLER FÖR:
Azure SQL Database Azure SQL Managed Instance
Lär dig hur du förbereder för planerade underhållshändelser i din databas i Azure SQL Database och Azure SQL Managed Instance.
Vad är en planerad underhållshändelse?
För att Azure SQL Database och Azure SQL Managed Instance-tjänster säkra, kompatibla, stabila och presterande utförs uppdateringar nästan kontinuerligt via tjänstkomponenterna. Tack vare den moderna och robusta tjänstarkitekturen och innovativa tekniker som snabbkorrigering ärde flesta uppdateringar helt transparenta och icke-effektfulla vad gäller tjänsttillgänglighet. Fortfarande orsakar få typer av uppdateringar korta tjänstavbrott och kräver särskild behandling.
Under planerat underhåll går medlemmar i databaskvorum offline en i taget, med avsikten att det finns en primär replik som svarar. För Affärskritisk och Premium databaser är minst en sekundär replik också online för att säkerställa att inga klientavbrott. När den primära repliken måste tas offline sker en omkonfigurationsprocess. För Affärskritisk och Premium databaser blir en av de sekundära replikerna den nya primära repliken. För Generell användning-, Standard- och Basic-databaser flyttas den primära repliken till en annan tillståndslös beräkningsnod med tillräckligt med ledigt utrymme.
Vad som händer under en planerad underhållshändelse
Underhållshändelsen kan skapa en eller flera omkonfigurationer, beroende på de primära och sekundära replikerna i början av underhållshändelsen. I genomsnitt sker 1,7 omkonfigurationer per planerat underhåll. Omkonfigurationer slutförs vanligtvis inom 30 sekunder. Genomsnittet är åtta sekunder. Om programmet redan är anslutet måste det återansluta till den nya primära repliken av databasen. Om en ny anslutning görs medan databasen genomgår en omkonfiguration innan den nya primära repliken är online får du felet 40613 (databasen är inte tillgänglig): "Databasen '{databasename}' på servern '{servername}' är inte tillgänglig för närvarande. Försök att ansluta igen senare." Om databasen har en långvarig fråga avbryts den här frågan under en omkonfiguration och måste startas om.
Så här simulerar du en planerad underhållshändelse
Att se till att klientprogrammet är motståndskraftigt mot underhållshändelser innan det distribueras till produktion minskar risken för programfel och bidrar till programmets tillgänglighet för slutanvändarna. Du kan testa klientprogrammets beteende under planerade underhållshändelser genom att testa programmets återhämtningsförmåga via PowerShell, CLI eller REST API. Mer information finns i Initiera manuell redundans för Managed Instance. Det ger identiskt beteende eftersom underhållshändelsen förs bort från den primära repliken.
Logik för omprövning
Alla klientproduktionsprogram som ansluter till en molndatabastjänst bör implementera en robust logik för anslutningsförsök. Detta hjälper till att göra omkonfigurationer transparenta för slutanvändarna, eller åtminstone minimera negativa effekter.
Service Health avisering
Om du vill få aviseringar om tjänstproblem eller planerade underhållsaktiviteter kan du använda Service Health aviseringar i Azure Portal med lämplig händelsetyp och åtgärdsgrupper. Mer information finns i Ta emot aviseringar om Azure-tjänstmeddelanden.
Resurshälsa
Om det uppstår inloggningsfel i databasen kontrollerar du Resource Health i fönstret Azure Portal den aktuella statusen. Avsnittet Hälsohistorik innehåller stilleståndsorsaken för varje händelse (när det är tillgängligt).
Underhållsfönstrets funktion
Med underhållsfönstret kan du konfigurera förutsägbara underhållsscheman för berättigade Azure SQL-databaser SQL hanterade instanser. Mer information finns i Underhållsfönstret.
Nästa steg
- Läs mer om Resource Health för Azure SQL Database och Azure SQL Managed Instance.
- Mer information om omprövningslogik finns i Omprövningslogik för tillfälliga fel.
- Konfigurera underhållsfönstrets scheman med funktionen Underhållsfönstret.