Planen von Azure-Wartungsereignissen in Azure SQL-Datenbank und Azure SQL Managed InstancePlan for Azure maintenance events in Azure SQL Database and Azure SQL Managed Instance

GILT FÜR: JaAzure SQL-Datenbank JaAzure SQL Managed Instance APPLIES TO: yesAzure SQL Database yesAzure SQL Managed Instance

Es wird beschrieben, wie Sie Ereignisse der geplanten Wartung in Ihrer Datenbank für Azure SQL-Datenbank und für verwaltete Azure SQL-Instanzen vorbereiten.Learn how to prepare for planned maintenance events on your database in Azure SQL Database and Azure SQL Managed Instance.

Was ist ein geplantes Wartungsereignis?What is a planned maintenance event?

Damit die Dienste Azure SQL-Datenbank und Azure SQL Managed Instance sicher, konform, stabil und leistungsfähig bleiben, werden nahezu fortlaufend Updates über die Dienstkomponenten ausgeführt.To keep Azure SQL Database and Azure SQL Managed Instance services secure, compliant, stable, and performant, updates are being performed through the service components almost continuously. Dank der modernen und robusten Dienstarchitektur und innovativer Technologien wie Hotpatching sind die meisten Updates in Bezug auf die Dienstverfügbarkeit vollständig transparent und stellen keine Beeinträchtigung dar.Thanks to the modern and robust service architecture and innovative technologies like hot patching, majority of updates are fully transparent and non-impactful in terms of service availability. Trotzdem verursachen einige Arten von Updates kurze Dienstunterbrechungen und erfordern eine besondere Behandlung.Still, few types of updates cause short service interrupts and require special treatment.

Für jede Datenbank halten Azure SQL-Datenbank und verwaltete Azure SQL-Instanzen ein bestimmtes Quorum an Datenbankreplikaten vor, von denen eines das primäre Replikat ist.For each database, Azure SQL Database and Azure SQL Managed Instance maintain a quorum of database replicas where one replica is the primary. Zu jeder Zeit muss ein primäres Replikat online in Betrieb sein, und mindestens ein sekundäres Replikat muss fehlerfrei sein.At all times, a primary replica must be online servicing, and at least one secondary replica must be healthy. Während der geplanten Wartung werden die Mitglieder des Datenbankquorums nacheinander mit der Absicht offline geschaltet, dass ein antwortendes primäres Replikat und mindestens ein sekundäres Replikat online vorhanden ist, um sicherzustellen, dass es keine Ausfallzeiten des Clients auftreten.During planned maintenance, members of the database quorum will go offline one at a time, with the intent that there is one responding primary replica and at least one secondary replica online to ensure no client downtime. Wenn das primäre Replikat offline geschaltet werden muss, erfolgt ein Neukonfigurations-/Failoverprozess, bei dem ein sekundäres Replikat zum neuen primären Replikat wird.When the primary replica needs to be brought offline, a reconfiguration/failover process will occur in which one secondary replica will become the new primary.

Was Sie bei einem geplanten Wartungsereignis erwarten könnenWhat to expect during a planned maintenance event

Das Wartungsereignis kann je nach der Konstellation der primären und sekundären Replikate zu Beginn des Wartungsereignisses einen einzelnen oder mehrere Failover erzeugen.Maintenance event can produce single or multiple failovers, depending on the constellation of the primary and secondary replicas at the beginning of the maintenance event. Im Durchschnitt treten pro geplantem Wartungsereignis 1,7 Failover auf.On average, 1.7 failovers occur per planned maintenance event. Neukonfigurationen/Failover werden in der Regel innerhalb von 30 Sekunden abgeschlossen.Reconfigurations/failovers generally finish within 30 seconds. Die durchschnittliche Dauer beträgt 8 Sekunden.The average is 8 seconds. Wenn sie bereits verbunden ist, muss Ihre Anwendung mit dem neuen primären Replikat Ihrer Datenbank erneut eine Verbindung herstellen.If already connected, your application must reconnect to the new primary replica of your database. Wenn eine neue Verbindung versucht wird, während für die Datenbank eine Neukonfiguration durchgeführt wird, bevor das neue primäre Replikat online ist, erhalten Sie Fehler 40613 (Datenbank nicht verfügbar): Die Datenbank "{Datenbankname}" auf Server "{Servername}" ist zurzeit nicht verfügbar. Wiederholen Sie den Verbindungsversuch später.“If a new connection is attempted while the database is undergoing a reconfiguration before the new primary replica is online, you get error 40613 (Database Unavailable): "Database '{databasename}' on server '{servername}' is not currently available. Please retry the connection later." Wenn Ihre Datenbank gerade eine zeitintensive Abfrage ausführt, wird diese bei einer Neukonfiguration unterbrochen und muss neu gestartet werden.If your database has a long-running query, this query will be interrupted during a reconfiguration and will need to be restarted.

Simulieren eines geplanten WartungsereignissesHow to simulate a planned maintenance event

Wenn Sie sicherstellen, dass Ihre Clientanwendung vor der Bereitstellung für die Produktionsumgebung hinsichtlich der Wartungsereignisse resilient ist, tragen Sie dazu bei, das Risiko von Anwendungsfehlern zu reduzieren und die Verfügbarkeit der Anwendung für Ihre Endbenutzer zu erhöhen.Ensuring that your client application is resilient to maintenance events prior to deploying to production will help mitigate the risk of application faults and will contribute to application availability for your end users. Sie können das Verhalten Ihrer Clientanwendung während geplanter Wartungsereignisse testen, indem Sie einen manuellen Failover über PowerShell, CLI oder REST-API initiieren.You can test behavior of your client application during planned maintenance events by initiating manual failover via PowerShell, CLI, or REST API. Es wird ein identisches Verhalten wie ein Wartungsereignis erzeugen, bei dem die primäre Replik offline geschaltet wird.It will produce identical behavior as maintenance event bringing primary replica offline.

WiederholungslogikRetry logic

Jede Clientproduktionsanwendung, die eine Verbindung mit einem Clouddatenbankdienst herstellt, sollte eine stabile Wiederholungslogik für Verbindungen implementieren.Any client production application that connects to a cloud database service should implement a robust connection retry logic. Dies wird dazu beitragen, Failover für die Endbenutzer transparent zu gestalten oder zumindest negative Auswirkungen zu minimieren.This will help make failovers transparent to the end users, or at least minimize negative effects.

RessourcenintegritätResource health

Wenn für Ihre Datenbank Anmeldefehler auftreten, sollten Sie im Fenster Resource Health im Azure-Portal den aktuellen Status überprüfen.If your database is experiencing log-on failures, check the Resource Health window in the Azure portal for the current status. Der Abschnitt „Integritätsverlauf“ enthält den Grund für die Ausfallzeit für jedes Ereignis (wenn verfügbar).The Health History section contains the downtime reason for each event (when available).

Nächste SchritteNext steps