Freigeben über

Prüfliste der Hochverfügbarkeit und Notfallwiederherstellung - Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL Managed Instance

Der Azure SQL Managed Instance-Dienst stellt automatisch sicher, dass alle Datenbanken online und fehlerfrei sind, und ist ständig bestrebt, die veröffentlichte SLA einzuhalten.

Dieser Leitfaden enthält eine detaillierte Übersicht über proaktive Schritte, die Sie ausführen können, um die Verfügbarkeit zu maximieren, die Wiederherstellung sicherzustellen und sich auf Azure-Ausfälle vorzubereiten. Dieser Leitfaden gilt für alle Dienstebenen von Azure SQL Managed Instance.

Checkliste für die Verfügbarkeit

Die folgenden Konfigurationen werden empfohlen, um die Verfügbarkeit zu maximieren:

  • Integrieren Sie Wiederholungslogik in die Anwendung, um vorübergehende Fehler zu behandeln.
  • Nutzen Sie Wartungsfenster, um Wartungsereignisse mit großen Auswirkungen vorhersagbar zu machen, sodass sie geringere Störungen verursachen.
  • Testen Sie die Ausfallsicherheit von Anwendungen, indem Sie manuell einen Failover auslösen, um die Ausfallsicherheit in Aktion zu sehen.

Checkliste für Hochverfügbarkeit

Es folgt die empfohlene Konfiguration, um hohe Verfügbarkeit zu erzielen:

  • Aktivieren Sie die Zonenredundanz, sofern verfügbar, für die SQL Managed Instance, um die Ausfallsicherheit bei zonalen Ausfällen zu gewährleisten.

Prüfliste zur Notfallwiederherstellung

Obwohl Azure SQL Managed Instance automatisch die Verfügbarkeit aufrechterhält, gibt es Fälle, in denen selbst eine hohe Verfügbarkeit (Zonenredundanz) keine Ausfallsicherheit garantiert, da sich der Ausfall auf eine ganze Region erstreckt. Ein regionaler Ausfall der Azure SQL Managed Instance kann dazu führen, dass Sie eine Notfallwiederherstellung einleiten müssen.

Befolgen Sie die folgenden Empfehlungen, um für die Notfallwiederherstellung am besten vorbereitet zu sein:

  • Aktivieren Sie Failovergruppen für eine Instanz.
    • Verwenden Sie die Schreib- und Schreibschutz-Listenerendpunkte in Ihrer Anwendung Verbindungszeichenfolge, sodass Anwendungen automatisch eine Verbindung zu der Instanz herstellen, die primär ist.
    • Legen Sie die Failoverrichtlinie auf vom Kunden verwaltet fest.
  • Stellen Sie sicher, dass die geo-sekundäre Instanz mit derselben Dienstebene, Hardwaregenerierung und Computegröße wie die primäre Instanz erstellt wird.
  • Beim Skalieren vergrößern Sie zuerst die geo-sekundäre und dann die primäre Datenbank.
  • Bei der Verkleinerung kehren Sie die Reihenfolge um: Verkleinern Sie zuerst die Primärseite und dann die Sekundärseite.
  • Die Notfallwiederherstellung ist von Natur aus so konzipiert, dass die asynchrone Replikation von Daten zwischen der primären und der sekundären Region verwendet wird. Um die Datenverfügbarkeit vor einer höheren Commitlatenz zu priorisieren, rufen Sie die gespeicherte Prozedur sp_wait_for_database_copy_sync unmittelbar nach dem Committen einer Transaktion auf. Der Aufruf von sp_wait_for_database_copy_sync blockiert den aufrufenden Thread, bis die letzte committete Transaktion übertragen und im Transaktionsprotokoll der sekundären Datenbank gehärtet wurde.
  • Überwachen Sie die Verzögerung in Bezug auf Recovery Point Objective (RPO), indem Sie die replication_lag_sec-Spalte der dynamischen Verwaltungssicht (Dynamic Management View, DMV) sys.dm_geo_replication_link_status für die primäre Datenbank verwenden. Die DMV zeigt die Verzögerung in Sekunden zwischen den Transaktionen, die auf dem primären System durchgeführt wurden, und den gehärteten Transaktionen im Transaktionsprotokoll des sekundären Systems. Wenn die primäre Datenbank von einem Ausfall betroffen ist und zu diesem Zeitpunkt ein Geo-Failover eingeleitet wird, gehen die in der letzten Sekunde committeten Transaktionen verloren.
  • Wenn die Aktivierung von Failover-Gruppen nicht möglich ist, sollten Sie die Redundanzoption für den Sicherungsspeicher auf Georedundanter Sicherungsspeicher setzen, um die Möglichkeit der Geowiederherstellung zu nutzen.
  • Planen Sie Notfallwiederherstellungsübungen, und führen Sie sie häufig durch, damit Sie für einen echten Ausfall besser vorbereitet sind.

Vorbereiten eines sekundären Ausfalls

Für eine erfolgreiche Wiederherstellung in einer anderen Datenregion mit Failovergruppen oder Geowiederherstellung müssen Sie eine sekundäre Azure SQL Managed Instance in einer anderen Region vorbereiten. Diese sekundäre Instanz kann bei Bedarf die neue primäre Instanz werden. Sie sollten auch gut definierte Schritte dokumentiert und getestet haben, um eine reibungslose Wiederherstellung sicherzustellen. Folgende Vorbereitungsschritte sind erforderlich:

  • Identifizieren Sie zur Geowiederherstellung die Instanz in einer anderen Region, die die neue primäre Instanz werden soll. Dies ist im Allgemeinen eine Instanz in der gekoppelten Region für die Region, in der sich Ihre Instanz befindet. Durch die Verwendung einer Instanz in einer Region, die mit der primären Region gepaart ist, entfallen die zusätzlichen Datenverkehrskosten während der Geo-Wiederherstellungsvorgänge.
  • Legen Sie fest, wie Sie die Benutzer zum neuen primären Server umleiten möchten. Die Umleitung von Benutzern kann durch manuelles Ändern von Anwendungsverbindungszeichenfolgen oder DNS-Einträgen erreicht werden. Wenn Sie Failovergruppen aktiviert haben und den Lese-/Schreibzugriffslistener und schreibgeschützten Listener in Anwendungsverbindungs-Zeichenfolgen verwenden, ist keine weitere Aktion erforderlich, da Verbindungen automatisch an einen neuen primären Server weitergeleitet werden.
  • Identifizieren und, optional, definieren Sie die NSG- und Routingtabellen-Konfiguration, die Benutzer für den Zugriff auf die neue primäre Datenbank für die neue primäre Datenbank benötigen.
  • Identifizieren Sie die Anmeldeinformationen, die in der master-Datenbank auf dem neuen primären Server vorhanden sein müssen, und stellen Sie sicher, dass die entsprechenden Benutzer*innen über die geeigneten Berechtigungen in der master-Datenbank verfügen. Optional können Sie diese Informationen auch neu erstellen.
  • Dokumentieren Sie die Überwachungskonfiguration für die aktuelle primäre Instanz, und machen Sie sie in der sekundären Instanz identisch.

Zugehöriger Inhalt

Weitere Informationen finden Sie unter: