Ermöglichen von Anwendungsresilienz mit Azure SQL-Datenbank
Georeplikation und Gruppen für automatisches Failover sind beides Mechanismen, die in Azure SQL-Datenbank verwendet werden, um die Verfügbarkeit und Notfallwiederherstellung zu verbessern, aber sie weisen einige wichtige Unterschiede auf.
Grundlegendes zur aktiven Georeplikation
Eine Methode zur Steigerung der Verfügbarkeit von Azure SQL-Datenbank ist die Verwendung der aktiven Georeplikation. Die aktive Georeplikation ist als Lösung für Geschäftskontinuität konzipiert, mit der Sie lesbare sekundäre Datenbanken für einzelne Datenbanken auf einem Server in derselben oder in einer anderen Region erstellen können. Sie unterstützt bis zu vier sekundäre Replikate und wird pro Datenbank konfiguriert.
Im Hintergrund verwendet Azure Verfügbarkeitsgruppen, um diese Funktionalität bereitzustellen. Mit aktiver Georeplikation können Kunden bei schweren Katastrophen programmgesteuert oder manuell ein Failover für primäre Datenbanken in sekundären Regionen durchführen.
Um Mehraufwand bei der Replikation aufgrund einer hohen Schreiblast zu vermeiden, die sich auf die Replikationsleistung auswirken kann, wird empfohlen, die sekundäre Region mit derselben Dienstebene und Computegröße wie die primäre zu konfigurieren.
Es ist möglich, die Georeplikation manuell für Azure SQL-Datenbank zu konfigurieren. Dazu wählen Sie auf der Seite für die Datenbank im Abschnitt Datenverwaltung die Option Replikate aus.
Nachdem das sekundäre Replikat erstellt wurde, können Sie manuell ein Failover initiieren. Dadurch werden die Rollen vertauscht, so dass die sekundäre die neue primäre und die alte primäre die neue sekundäre wird.
Georeplikation ist asynchron. Das bedeutet, dass zwischen den primären und sekundären Datenbanken möglicherweise eine Datenverzögerung auftritt. Außerdem muss die Anwendungsverbindungszeichenfolge nach einem Failover aktualisiert werden.
Konfigurieren Sie die abonnementübergreifende Georeplikation
In einigen Szenarien müssen Sie ein sekundäres Replikat in einem anderen Abonnement als die primäre Datenbank konfigurieren. Hier kommt die abonnementübergreifende Georeplikation ins Spiel. Mit diesem Feature können Sie ein sekundäres Replikat in einem anderen Abonnement einrichten. Dies bietet größere Flexibilität und erweiterte Notfallwiederherstellungsoptionen. Mithilfe der abonnementübergreifenden Georeplikation können Sie sicherstellen, dass Ihre Daten geschützt und zugänglich sind, auch wenn bei einem Abonnement Probleme auftreten. Dieses Setup Einrichtung ist nützlich für Organisationen mit mehreren Abonnements oder für Organisationen, die einen robusten Geschäftskontinuitätsplan implementieren möchten.
Weitere Informationen zu den erforderlichen Schritten für das Konfigurieren einer abonnementübergreifenden Georeplikation finden Sie unter Abonnementübergreifende Georeplikation.
Aktivieren von Gruppen für automatisches Failover
Eine Autofailover-Gruppe ist eine Verfügbarkeitsfunktion, die sowohl mit Azure SQL-Datenbank als auch mit Azure SQL Managed Instance verwendet werden kann. Mit sogenannten Auto-Failover-Gruppen können Sie verwalten, wie Datenbanken in eine andere Region repliziert werden, und wie der Failover-Prozess ablaufen könnte. Der Name, welcher der Autofailover-Gruppe zugewiesen wird, muss innerhalb der Domäne *.database.windows.net eindeutig sein.
Autofailover-Gruppen bieten über einen Listener eine ähnliche Funktionalität wie Verfügbarkeitsgruppen und ermöglichen sowohl Lese-/Schreib- als auch schreibgeschützte Aktivitäten. Diese Funktionalität unterscheidet sich geringfügig von der aktiven Georeplikation. Es gibt zwei Arten von Listenern: einen für Lese-/Schreibdatenverkehr und einen für schreibgeschützten Datenverkehr. Während eines Failovers ermöglichen DNS-Updates Clients das Herstellen einer Verbindung mit dem Listenernamen, ohne dass zusätzliche Informationen erforderlich sind. Der Datenbankserver, der die Lese-/Schreibkopien enthält, ist der primäre Server, und der Server, der Transaktionen vom primären Server empfängt, ist der sekundäre Server.
Autofailover-Gruppen verfügen über zwei verschiedene Richtlinien, die konfiguriert werden können.
- Vom Kunden verwaltet (empfohlen): Kunden können ein Failover manuell initiieren, wenn sie einen unerwarteten Ausfall erkennen, der sich auf mindestens eine Datenbank in der Failovergruppe auswirkt. Dieses manuelle Failover kann mithilfe von Befehlszeilentools wie PowerShell, der Azure CLI oder der REST-API ausgeführt werden.
- Von Microsoft verwaltet: Sie werden automatisch von Microsoft während eines weitreichenden Ausfalls initiiert, der sich auf eine primäre Region auswirkt. Dieses automatische Failover gilt für alle betroffenen Failovergruppen, deren Failoverrichtlinie auf Von Microsoft verwaltet festgelegt ist.
Ungeplante Fehlumschaltungen können zu Datenverlusten führen, wenn sie erzwungen erfolgen und das Sekundärsystem nicht vollständig mit dem Primärsystem synchronisiert ist. Durch das Konfigurieren von GracePeriodWithDataLossHours können Sie steuern, wie lange Azure wartet, bevor ein Failover durchgeführt wird. Der Standardwert ist eine Stunde. Wenn ein striktes RPO gilt, das nicht viele Datenverluste zulässt, legen Sie einen höheren Wert fest. Obwohl Azure länger wartet, bevor ein Failover ausgeführt wird, kann dieser Ansatz zu weniger Datenverlusten führen, da das sekundäre Replikat mehr Zeit für die vollständige Synchronisierung mit dem primären Replikat hat.
Darüber hinaus kann eine Autofailover-Gruppe eine oder mehrere Datenbanken mit der gleichen Größe und Edition auf den primären und sekundären Servern enthalten. Die Datenbank auf dem sekundären Server wird automatisch über einen Prozess erstellt, der als Seeding bezeichnet wird. Dies kann je nach Datenbankgröße einige Zeit dauern. Es ist wichtig, entsprechend zu planen und Faktoren wie die Netzwerkgeschwindigkeit zu berücksichtigen.
Wie man auswählt
Die Georeplikation eignet sich für Szenarien, in denen Sie mehrere lesbare Replikate benötigen und ein manuelles Failover akzeptabel ist. Autofailover-Gruppen eignen sich ideal für Szenarien, die automatisches Failover und synchrone Replikation für eine Gruppe von Datenbanken erfordern.
In der folgenden Tabelle werden die Features von Georeplikation und Autofailover-Gruppen zusammen mit anderen relevanten Details verglichen.
| Merkmal | Georeplikation | Autofailover-Gruppen |
|---|---|---|
| Anzahl von Replikaten | Unterstützt bis zu vier sekundäre Replikate. | Unterstützt nur ein sekundäres Replikat. |
| Konfigurationsebene | Pro Datenbank konfiguriert. | Konfiguriert für eine Gruppe von Datenbanken. |
| Replikationstyp | Asynchron. Das bedeutet, dass zwischen den primären und sekundären Datenbanken möglicherweise eine Datenverzögerung auftritt. | Synchron, um sicherzustellen, dass die sekundäre Datenbank immer mit der primären Datenbank synchronisiert ist. |
| Failover | Erfordert ein manuelles Failover. Die Anwendungsverbindungszeichenfolge muss nach einem Failover aktualisiert werden. | Unterstützt automatisches und manuelles Failover, ohne dass Verbindungszeichenfolgen nach einem Failover geändert werden müssen. |
| Lesbarkeit | Stellt lesbare sekundäre Datenbanken bereit. | Stellt lesbare sekundäre Datenbanken bereit und dient als Hot-Standby für Failover |
| Anwendungsfall | Geeignet für Szenarien, die mehrere lesbare Replikate und manuelles Failover benötigen | Ideal für Szenarien, die automatisches Failover und synchrone Replikation für eine Gruppe von Datenbanken erfordern |
