Freigeben über

Prüfliste für Hochverfügbarkeit und Notfallwiederherstellung - Azure SQL-Datenbank

  • Artikel

Gilt für:: Azure SQL-Datenbank

Der Azure SQL-Datenbank-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 Kaufmodelle und Dienstebenen von Azure SQL-Datenbank.

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 Datenbank oder den elastischen Pool, um die Ausfallsicherheit bei zonalen Ausfällen zu gewährleisten.

Prüfliste zur Notfallwiederherstellung

Obwohl Azure SQL Database 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-Datenbank 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 Gruppe von Datenbanken.
    • Verwenden Sie die Schreib- und Schreibschutz-Listenerendpunkte in Ihrer Anwendung Verbindungszeichenfolge, sodass Anwendungen automatisch eine Verbindung zu dem Server und der Datenbank herstellen, der aktuell primär ist.
    • Legen Sie die Failoverrichtlinie auf vom Kunden verwaltet fest.
  • Aktivieren Sie die aktive Georeplikation, um über eine lesbare sekundäre Datenbank in einer anderen Azure-Region zu verfügen.
  • Stellen Sie sicher, dass die geo-sekundäre Datenbank mit derselben Dienstebene, Computeebene (bereitgestellt oder serverlos) und Computegröße (DTUs oder virtuelle Kerne) als primäre Datenbank 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 oder aktiver Georeplikation 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 aktiver Georeplikation, Failovergruppen oder Geowiederherstellung müssen Sie einen sekundären logischen Azure SQL-Datenbank-Server in einer anderen Region vorbereiten. Dieser sekundäre Server kann bei Bedarf der neue primäre Server werden. Sie sollten auch gut definierte Schritte dokumentiert und getestet haben, um eine reibungslose Wiederherstellung sicherzustellen. Folgende Vorbereitungsschritte sind erforderlich:

  • Identifizieren Sie zur Geowiederherstellung einen Server in einer anderen Region, der der neue primäre Server werden soll. Dies ist im Allgemeinen ein Server in der gekoppelten Region für die Region, in der sich Ihre Datenbank befindet. Durch die Verwendung eines Servers in einer Region, die mit dem primären gekoppelt 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 Sie die Firewallregeln, die Benutzer benötigen, um auf die neue primäre Datenbank zugreifen zu können. Optional können Sie diese Regeln auch neu definieren.
  • 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. Weitere Informationen finden Sie unter Konfigurieren und Verwalten der Sicherheit von Azure SQL-Datenbank für die Geowiederherstellung oder das Failover.
  • Identifizieren Sie die Warnungsregeln, die aktualisiert werden müssen, um dem neuen primären Server zugeordnet werden zu können.
  • Dokumentieren Sie die Überwachungskonfiguration auf dem aktuellen primären Server, und machen Sie sie auf dem sekundären Server identisch.

Zugehöriger Inhalt