Implementieren von Hochverfügbarkeit und Notfallwiederherstellung
Ein Großteil der Konfiguration von Notfallwiederherstellungs- und Hochverfügbarkeitslösungen in SQL Server bleibt in SQL Servern, die auf Azure Virtual Machine ausgeführt werden, unverändert. Die Hochverfügbarkeitslösung soll sicherstellen, dass Daten, für die ein Commit ausgeführt werden, nie aufgrund von Fehlern verloren gehen, dass sich Wartungsvorgänge nicht auf Ihre Workload auswirken und dass die Datenbank keinen Single Point of Failure in der Softwarearchitektur darstellt.
Die meisten Azure SQL Dienstebenen bieten eine Reihe von Hochverfügbarkeitsoptionen, von lokalen Redundanzmodellen bis hin zu Zonenredundanzmodellen.
Als Nächstes untersuchen wir die spezifischen Lösungen für Notfallwiederherstellung und Hochverfügbarkeit für die PaaS-Angebote von Azure.
Fortlaufende Sicherung
Azure SQL Datenbank sorgt für regelmäßige und fortlaufende Sicherungen von Datenbanken, die dann in einen georedundanten Lesezugriffsspeicher (RA-GRS) repliziert werden.
Teil der automatisierten Sicherungsstrategie sind wöchentliche vollständige Sicherungen, differenzielle Sicherungen alle 12 bis 24 Stunden und Transaktionsprotokollsicherungen alle 5 bis 10 Minuten. Für eine erweiterte Sicherungsverfügbarkeit (bis zu 10 Jahre) kann die langfristige Aufbewahrung (LTR) sowohl für Einzel- als auch für Pooldatenbanken konfiguriert werden.
Langzeitaufbewahrung (Long-Term Retention, LTR)
Azure bietet eine Aufbewahrungsrichtlinie, die Sie über die üblichen Grenzwerte hinaus festlegen können, was für Szenarien nützlich ist, die eine langfristige Aufbewahrung erfordern. Sie können eine Aufbewahrungsrichtlinie für bis zu 10 Jahre festlegen, und diese Option ist standardmäßig deaktiviert.
Die Abbildung zeigt, wie Sie langfristige Aufbewahrungsrichtlinien im Azure-Portal einrichten. Nach der Auswahl der Datenbank erscheint ein Bereich auf der rechten Seite Ihres Bildschirms, in dem Sie die Standardeinstellungen festlegen ändern können.
Weitere Informationen zur langfristigen Aufbewahrung finden Sie unter Langzeitaufbewahrung – Azure SQL Datenbank und Azure SQL Managed Instance.
Geowiederherstellung
Sicherungskopien für SQL-Datenbank und SQL Managed Instance sind standardmäßig georedundant. Dadurch können Sie Datenbanken problemlos in einer anderen geografischen Region wiederherstellen,was für weniger strenge Notfallwiederherstellungsszenarien nützlich ist.
Sicherungsspeicher wird getrennt vom regulären Datenbankdateispeicher abgerechnet. Bei der Bereitstellung einer SQL-Datenbank-Instanz wird der Sicherungsspeicher jedoch ohne zusätzliche Kosten mit der maximalen Größe der für Ihre Datenbank ausgewählten Datenebene erstellt.
Die Dauer eines Geowiederherstellungsvorgangs kann von mehreren zugrunde liegenden Komponenten beeinflusst werden, einschließlich der Größe der Datenbank, der Anzahl von Transaktionsprotokollen, die an einem Wiederherstellungsvorgang beteiligt sind, und der Menge gleichzeitiger Wiederherstellungsanforderungen, die in der Zielregion verarbeitet werden.
Point-in-Time-Wiederherstellung
Sie können Ihre Datenbanken zu einem bestimmten Zeitpunkt gemäß der definierten Aufbewahrungsdauer wiederherstellen. PITR wird jedoch nur unterstützt, wenn Sie eine Datenbank auf demselben Server wiederherstellen, von dem die Sicherung stammt. Sie können das Azure-Portal, Azure PowerShell, die Azure CLI oder die REST-API verwenden, um eine SQL-Datenbank wiederherzustellen.
Aktive Georeplikation
Eine Methode zur Steigerung der Verfügbarkeit von Azure SQL-Datenbank ist die Verwendung der aktiven Georeplikation. Bei der aktiven Georeplikation wird ein Replikat der Datenbank in einer anderen Region erstellt, das asynchron auf dem neuesten Stand gehalten wird.
Dieses Replikat ist, ähnlich wie eine AlwaysOn-Verfügbarkeitsgruppe in SQL Server, lesbar. Im Hintergrund verwendet Azure Verfügbarkeitsgruppen, um diese Funktionalität zu erhalten. Deshalb sind einige Begriffe ähnlich.
Die aktive Georeplikation bietet Geschäftskontinuität, indem Kund*innen bei schweren Katastrophen programmgesteuert oder manuell ein Failover für primäre Datenbanken in sekundäre Regionen durchführen können.
Hinweis
Azure SQL Managed Instance unterstützt keine aktive Georeplikation. Stattdessen müssen Sie Autofailover-Gruppen verwenden, ein Thema, das wir später in dieser Lerneinheit untersuchen werden.
Alle Datenbanken, die an einer Georeplikation beteiligt sind, müssen die gleiche Dienstebene aufweisen. Darüber hinaus wird empfohlen, das sekundäre Replikat mit der gleichen Computegröße wie das primäre Replikat zu konfigurieren, um Probleme mit der Replikationsleistung aufgrund eines hohen Schreibworkloads zu vermeiden.
Es ist möglich, die Georeplikation manuell für Azure SQL-Datenbank zu konfigurieren. Dazu wählen Sie auf dem Blatt für die Datenbank im Abschnitt Datenverwaltung zunächst Replikate und dann + Replikat erstellen aus.
Nachdem das sekundäre Replikat eingerichtet wurde, haben Sie die Möglichkeit, ein Failover manuell zu initiieren. In diesem Prozess werden die Rollen umgekehrt: Das sekundäre Replikat übernimmt die Rolle des primären Replikats, während das ursprüngliche primäre Replikat zum sekundären wird.
Subscriptionübergreifende Georeplikation
In einigen Szenarien müssen Sie ein sekundäres Replikat in einem anderen Abonnement als die primäre Datenbank konfigurieren. Hier kommt das Feature der abonnementübergreifenden Georeplikation ins Spiel.
Hinweis
Die abonnementübergreifende Georeplikation ist nur programmgesteuert verfügbar.
Weitere Informationen zu den erforderlichen Schritten für das Konfigurieren einer abonnementübergreifenden Georeplikation finden Sie unter Abonnementübergreifende Georeplikation.
Autofailover-Gruppen
Eine Autofailover-Gruppe ist eine Verfügbarkeitsfunktion, die sowohl mit Azure SQL-Datenbank als auch mit Azure SQL Managed Instance verwendet werden kann. Mit Autofailover-Gruppen können sie die Replikation Ihrer Datenbank in eine andere Region, und wie der Failover ablaufen kann, verwalten. Der Name, welcher der Autofailover-Gruppe zugewiesen wird, muss innerhalb der Domäne *.database.windows.net eindeutig sein.
Eine Gruppe mit automatischem Failover kann mehrere Datenbanken enthalten. Sowohl die primäre als auch die sekundäre Datenbank haben die gleiche Größe.
Autofailover-Gruppen bieten eine ähnliche Funktionalität wie Verfügbarkeitsgruppen, die als Listener bezeichnet wird und sowohl Lese-/Schreibzugriff als auch schreibgeschützten Zugriff zulässt. Es gibt zwei verschiedene Arten von Listenern, nämlich einen für Lese-/Schreib-Zugriff und einen für reinen Lesezugriff. Hinter den Kulissen wird bei einem Failover das DNS aktualisiert, damit Clients auf den abstrahierten Listener-Namen verweisen können und nichts anderes wissen müssen. Der Datenbankserver, der die Lese-/Schreibkopien enthält, ist der primäre Server, und der Server, der die Transaktionen vom primären Server empfängt, ist ein sekundärer Server.
Es gibt zwei verschiedene Richtlinien für Autofailover-Gruppen.
| Richtlinientyp | Beschreibung |
|---|---|
| Automatisch | Wenn ein Fehler erkannt wird, löst das System standardmäßig automatisch ein Failover aus. Bei Bedarf können Sie das automatische Failover jedoch deaktivieren. |
| Schreibgeschützt | Während eines Failovers deaktiviert das Modul standardmäßig den schreibgeschützten Listener, um die Leistung des neuen primären Computers aufrechtzuerhalten, wenn das sekundäre Element ausgefallen ist. Sie können dieses Verhalten jedoch ändern, um beide Arten von Datenverkehr nach einem Failover zuzulassen. |
Failover ist ein Prozess, der manuell initiiert werden kann, auch wenn das automatische Failover aktiviert ist. Der Typ des Failovers kann jedoch beeinflussen, ob Datenverluste auftreten. Es kann zum Beispiel ein ungeplantes Failover zu einem Datenverlust führen, wenn es erzwungen wird und die sekundäre Datenbank nicht vollständig mit der primären Datenbank synchronisiert wurde.
GracePeriodWithDataLossHours bestimmt die Dauer, die Azure vor dem Initiieren eines Failovers wartet, wobei der Standardwert auf eine Stunde festgelegt ist. Wenn Ihr Recovery Point Objective (RPO) streng und Datenverlust keine Option ist, können Sie diesen Wert höher festlegen. Dies bedeutet zwar, dass Azure länger wartet, bevor ein Failover gestartet wird, kann jedoch den Datenverlust verringern, da es der sekundären Datenbank mehr Zeit für die vollständige Synchronisierung mit der primären Datenbank bietet.
Hinweis
Die sekundäre Datenbank wird automatisch über einen Prozess erstellt, der als Seeding bezeichnet wird. Dies kann je nach Datenbankgröße einige Zeit dauern. Daher ist es wichtig, unter Berücksichtigung von Faktoren wie der Netzwerkgeschwindigkeit, vorausschauend zu planen.
Weitere Informationen zu Hochverfügbarkeit und Notfallwiederherstellung für Azure SQL-Datenbank finden Sie unter Prüfliste Azure SQL Datenbank für Hochverfügbarkeit und Notfallwiederherstellung.