Übersicht über die Geschäftsfortführung in Azure Database for PostgreSQL – Flexible Server

Geschäftskontinuität in Azure Database for PostgreSQL bezieht sich auf die Mechanismen, Richtlinien und Verfahren, die es Ihrem Unternehmen ermöglichen, angesichts von Unterbrechungen, insbesondere in seiner Computerinfrastruktur, weiter zu arbeiten. In den meisten Fällen behandelt Azure Database for PostgreSQL störende Ereignisse, die in der Cloudumgebung auftreten können, und hält Ihre Anwendungen und Geschäftsprozesse aktiv. Einige Ereignisse können jedoch nicht automatisch behandelt werden, z. B.:

  • Ein Benutzer löscht versehentlich eine Zeile in einer Tabelle oder aktualisiert sie.
  • Ein Erdbeben verursacht einen Stromausfall und setzt vorübergehend eine Verfügbarkeitszone oder eine Region außer Betrieb.
  • Erforderliches Datenbankpatching, um einen Fehler oder ein Sicherheitsproblem zu beheben.

Azure Database for PostgreSQL bietet Features, die Daten schützen und Ausfallzeiten für Ihre unternehmenskritischen Datenbanken während geplanter und ungeplanter Ausfallzeiten mindern. Basierend auf der Azure-Infrastruktur, die robuste Resilienz und Verfügbarkeit bietet, verfügt Azure-Datenbank für PostgreSQL über Geschäftskontinuitätsfeatures, die einen weiteren Fehlerschutz bieten, die Anforderungen an die Wiederherstellungszeit erfüllen und die Gefährdung von Datenverlust reduzieren. Berücksichtigen Sie beim Entwerfen Ihrer Anwendungen die Ausfallzeittoleranz – das Wiederherstellungszeitziel (RTO) und die Gefährdung von Datenverlust – das Wiederherstellungspunktziel (RPO). Beispielsweise müssen für Ihre unternehmenskritische Datenbank strengere Uptimeanforderungen erfüllt werden als bei einer Testdatenbank.

In der folgenden Tabelle sind die Features dargestellt, die Azure Database for PostgreSQL bietet.

Funktion Beschreibung Betrachtungen
Automatische Sicherungen Eine flexible Serverinstanz von Azure Database für PostgreSQL führt automatisch tägliche Sicherungen Ihrer Datenbankdateien durch und sichert fortlaufend Transaktionsprotokolle. Sie können Sicherungen von 7 Tagen bis zu 35 Tage aufbewahren. Sie können Ihren Datenbankserver auf jeden beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums Ihrer Sicherung wiederherstellen. RTO hängt von der Größe der Daten ab, die wiederhergestellt werden sollen, sowie von der Zeit zum Durchführen der Protokollwiederherstellung. Es kann zwischen ein paar Minuten und 12 Stunden dauern. Weitere ausführliche Informationen finden Sie unter Konzepte: Sicherung und Wiederherstellung. Sicherungsdaten verbleiben innerhalb der Region.
Zonenredundante Hochverfügbarkeit Sie können eine Instanz von Azure Database for PostgreSQL – Flexible Server mit einer zonenredundanten Hochverfügbarkeitskonfiguration (HA) bereitstellen, bei der der primäre Server und der Standbyserver in zwei verschiedenen Verfügbarkeitszonen innerhalb einer Region bereitgestellt werden. Diese HA-Konfiguration schützt Ihre Datenbanken vor Fehlern auf Zonenebene und hilft auch, Die Ausfallzeiten der Anwendung während geplanter und ungeplanter Ausfallzeiten zu reduzieren. Die Daten vom primären Server werden im synchronen Modus auf das Standbyreplikat repliziert. Im Falle einer Unterbrechung des primären Servers erfolgt automatisch ein Failover für den Server auf das Standbyreplikat. RTO wird in den meisten Fällen voraussichtlich weniger als 120 Sekunden betragen. Es wird erwartet, dass RPO den Wert 0 (kein Datenverlust) hat. Weitere Informationen finden Sie unter "Konzepte – Hohe Verfügbarkeit". Unterstützt auf den Computeebenen „Allgemeiner Zweck“ und „Arbeitsspeicheroptimiert“. Nur verfügbar in Regionen, in denen mehrere Zonen verfügbar sind.
Hochverfügbarkeit in derselben Zone Sie können eine Azure Database for PostgreSQL flexible Serverinstanz mit derselben Ha-Konfiguration (Zone High Availability) bereitstellen, bei der primäre und Standbyserver in derselben Verfügbarkeitszone in einer Region bereitgestellt werden. Diese HA-Konfiguration schützt Ihre Datenbanken vor Fehlern auf Knotenebene und hilft auch, die Ausfallzeiten der Anwendung während geplanter und ungeplanter Ausfallzeiten zu reduzieren. Die Daten vom primären Server werden im synchronen Modus auf das Standbyreplikat repliziert. Im Falle einer Unterbrechung des primären Servers erfolgt automatisch ein Failover für den Server auf das Standbyreplikat. RTO wird in den meisten Fällen voraussichtlich weniger als 120 Sekunden betragen. Es wird erwartet, dass RPO den Wert 0 (kein Datenverlust) hat. Weitere Informationen finden Sie unter [Konzepte – Hohe Verfügbarkeit]/azure/reliability/reliability-postgresql-flexible-server. Unterstützt auf den Computeebenen „Allgemeiner Zweck“ und „Arbeitsspeicheroptimiert“.
Managed Disks Premium Datenbankdateien werden in einem sehr langlebigen und zuverlässigen verwalteten Premiumspeicher gespeichert. Dieser Speicher bietet Datenredundanz mit drei Kopien des Replikats, die in einer Verfügbarkeitszone mit automatischen Datenwiederherstellungsfunktionen gespeichert sind. Weitere Informationen finden Sie in der Dokumentation zu verwalteten Datenträgern. In einer Verfügbarkeitszone gespeicherte Daten.
Zonenredundante Sicherung Azure Database for PostgreSQL flexible Serverinstanzsicherungen werden automatisch und sicher in einem zonenredundanten Speicher innerhalb einer Region gespeichert, wenn die Region Verfügbarkeitszonen unterstützt. Während eines Ausfalls auf Zonenebene, in der Ihr Server bereitgestellt ist, und wenn Ihr Server nicht für Zonenredundanz konfiguriert ist, können Sie Ihre Datenbank dennoch mithilfe des neuesten Wiederherstellungspunkts in einer anderen Zone wiederherstellen. Weitere Informationen finden Sie unter Konzepte: Sicherung und Wiederherstellung. Nur gültig in Regionen, in denen mehrere Zonen verfügbar sind.
Georedundante Sicherung Sicherungen von Azure Database for PostgreSQL Flexible Server-Instanz werden in eine Remoteregion kopiert. Dieses Feature hilft bei der Notfallwiederherstellung, wenn die primäre Serverregion ausgefallen ist. Dieses Feature ist derzeit in ausgewählten Regionen aktiviert. Je nach Größe der wiederherzustellenden Daten und Umfang der durchzuführenden Wiederherstellung ist das RTO länger und das RPO höher.
Lesereplikat Sie können regionsübergreifende Lesereplikate bereitstellen, um Ihre Datenbanken vor Fehlern auf Regionsebene zu schützen. Lesereplikate werden asynchron unter Verwendung der physischen Replikationstechnologie von PostgreSQL aktualisiert und können gegenüber dem Primärserver verzögert sein. Weitere Informationen finden Sie unter Konzepte für Lesereplikate. Unterstützt auf den Computeebenen „Allgemeiner Zweck“ und „Arbeitsspeicheroptimiert“.

In der folgenden Tabelle werden RTO und RPO in einem Szenario mit einer typischen Workload verglichen:

Fähigkeit Burstfähig Produktions-SKU (Allgemeiner Zweck/Speicheroptimiert)
Point-in-Time-Wiederherstellung von Sicherung Beliebiger Wiederherstellungspunkt innerhalb der Aufbewahrungsdauer
RTO: variiert
RPO < 5 Minuten		 Beliebiger Wiederherstellungspunkt innerhalb der Aufbewahrungsdauer
RTO: variiert
RPO < 5 Minuten
Geowiederherstellung von georeplizierten Sicherungen RTO: variiert
RPO und 1 Std.		 RTO: variiert
RPO und 1 Std.
Lesereplikate Nicht zutreffend RTO – Minuten*
RPO - Typischerweise von 30 Sekunden bis 5 Minuten*
Hohe Verfügbarkeit Nicht zutreffend RTO < 120 Sek.
RPO = 0

Geplante Downtimeereignisse

In der folgenden Tabelle werden einige allgemeine geplante Wartungsszenarien beschrieben. Diese Ereignisse verursachen in der Regel einige Minuten Ausfallzeiten, aber sie verursachen keinen Datenverlust.

Szenario Prozess
Computeskalierung (von Benutzenden initiiert) Während des Berechnungsskalierungsvorgangs ermöglicht der Prozess den Abschluss aktiver Prüfpunkte, entwässert Clientverbindungen, bricht alle nicht ausgelassenen Transaktionen ab, trennt Speicher und beendet dann. Der Prozess stellt eine neue Azure Database for PostgreSQL Flexible Server-Instanz mit demselben Namen für den Datenbankserver, aber mit einer skalierten Rechenkonfiguration bereit. Der Prozess fügt den Speicher an den neuen Server an und startet die Datenbank, die bei Bedarf eine Wiederherstellung durchführt, bevor Clientverbindungen akzeptiert werden.
Hochskalieren des Speichers (von Benutzenden initiiert) Wenn Sie einen Vorgang zum Hochskalieren des Speichers initiieren, ermöglicht der Prozess, dass aktive Prüfpunkte abgeschlossen, Clientverbindungen ordnungsgemäß beendet und alle nicht festgeschriebenen Transaktionen abgebrochen werden. Danach fährt der Prozess den Server herunter. Der Prozess skaliert den Speicher auf die gewünschte Größe und fügt ihn dann an den neuen Server an. Der Prozess führt bei Bedarf eine Wiederherstellung durch, bevor Clientverbindungen akzeptiert werden. Beachten Sie, dass die Herunterskalierung der Speichergröße nicht unterstützt wird.
Bereitstellung neuer Software (von Azure initiiert) Der Dienst führt automatisch neue Features oder Bugfixes als Teil der geplanten Wartung aus. Sie können planen, wann diese Aktivitäten stattfinden. Weitere Informationen finden Sie in Ihrem Portal.
Upgrades auf Nebenversionen (von Azure initiiert) Azure Database for PostgreSQL patcht Datenbankserver automatisch auf die von Azure festgelegte Nebenversion. Dieser Patch erfolgt im Rahmen der geplanten Wartung des Diensts. Der Vorgang startet den Datenbankserver automatisch mit der neuen Nebenversion neu. Weitere Informationen finden Sie in der Dokumentation. Sie können auch in Ihrem Portal nachsehen.

Wenn Sie die Azure Database for PostgreSQL flexible Serverinstanz mit hoher Verfügbarkeit konfigurieren, führt der Dienst zuerst die Skalierung und die Wartungsvorgänge auf dem Standbyserver aus. Weitere Informationen finden Sie unter [Konzepte – Hohe Verfügbarkeit]/azure/reliability/reliability-postgresql-flexible-server.

Minimierung von ungeplanter Downtime

Ungeplante Downtimes können aufgrund von unvorhergesehenen Unterbrechungen auftreten, darunter Fehler in der zugrunde liegenden Hardware, Netzwerkprobleme und Softwarefehler. Wenn der datenbankserver, der mit hoher Verfügbarkeit konfiguriert ist, unerwartet abläuft, aktiviert der Dienst das Standbyreplikat, und die Clients können ihre Vorgänge fortsetzen. Wenn Sie den Server nicht mit hoher Verfügbarkeit (HIGH Availability, HA) konfigurieren, stellt der Dienst automatisch einen neuen Datenbankserver fest, wenn der Neustartversuch fehlschlägt. Während Sie ungeplante Ausfallzeiten nicht vermeiden können, hilft Azure Database for PostgreSQL, die Ausfallzeiten zu mindern, indem Sie Wiederherstellungsvorgänge automatisch ausführen, ohne dass ein menschliches Eingreifen erforderlich ist.

Obwohl das Entwicklungsteam ständig bemüht ist, hohe Verfügbarkeit zu bieten, gibt es Zeiten, in denen Azure Database for PostgreSQL einen Ausfall verursacht, der zu einer Unverfügbarkeit der Datenbanken führt und sich somit auf Ihre Anwendung auswirkt. Wenn die Dienstüberwachung Probleme erkennt, die zu weit verbreiteten Konnektivitätsfehlern, Fehlern oder Leistungsproblemen führen, deklariert der Dienst automatisch einen Ausfall, um Sie auf dem Laufenden zu halten.

Dienstunterbrechung

Wenn eine Instanz von Azure Database for PostgreSQL – Flexible Server ausfällt, finden Sie weitere Informationen über den Ausfall an den folgenden Stellen:

  • Azure Portalbanner: Wenn Ihr Abonnement betroffen ist, zeigt das Azure Portalbenachrichtigungen eine Ausfallwarnung für ein Dienstproblem an.

Screenshot: Benachrichtigungen im Azure-Portal.

  • Hilfe + Support oder Support + Problembehandlung: Wenn Sie ein Supportticket über Hilfe + Support oder Support + Problembehandlung erstellen, enthält das Portal Informationen zu Problemen, die sich auf Ihre Ressourcen auswirken. Wählen Sie Details zum Ausfall anzeigen aus, um weitere Informationen und eine Zusammenfassung der Auswirkungen zu erhalten. Die Seite " Neue Supportanfrage" enthält auch eine Benachrichtigung.

Screenshot: Benachrichtigungen unter „Hilfe + Support“ im Azure-Portal.

  • Dienststatus: Die Seite "Dienststatus" im Azure-Portal enthält Informationen zu Azure Rechenzentrumsstatus global. Suchen Sie in der Suchleiste im Azure-Portal nach "Dienststatus", und zeigen Sie dann Dienstprobleme in der Kategorie "Aktive Ereignisse" an. Sie können die Integrität einzelner Ressourcen auch auf der Seite Ressourcenintegrität einer beliebigen Ressource im Menü Hilfe anzeigen. Der folgende Screenshot der Seite "Dienststatus " zeigt Informationen zu einem aktiven Dienstproblem in Südostasien.

Screenshot: Dienstausfall im Service Health-Portal.

  • E-Mail-Benachrichtigung: Wenn Sie Benachrichtigungen einrichten, erhalten Sie eine E-Mail-Benachrichtigung, wenn sich ein Dienstausfall auf Ihr Abonnement und Ihre Ressource auswirkt. Die E-Mails stammen von "azure-noreply@microsoft.com". Der Text der E-Mail beginnt mit „Die Aktivitätsprotokollwarnung ... wurde durch ein Dienstproblem für das Azure-Abonnement ... ausgelöst“. Weitere Informationen zu Dienststatuswarnungen finden Sie unter Empfangen von Aktivitätsprotokollbenachrichtigungen in Azure Dienstbenachrichtigungen mithilfe Azure Portals.

Von Bedeutung

Wie der Name schon sagt, werden temporäre Tabellenbereiche in PostgreSQL für temporäre Objekte sowie andere interne Datenbankvorgänge wie Sortierung verwendet. Erstellen Sie daher keine Benutzerschemaobjekte im temporären Tabellenbereich, da die Haltbarkeit dieser Objekte nach dem Neustart des Servers, HA-Failovers und ähnlichen Ereignissen nicht garantiert ist.

Ungeplante Downtime: Fehlerszenarien und Dienstwiederherstellung

In der folgenden Tabelle werden allgemeine ungeplante Fehlerszenarien und der Wiederherstellungsvorgang beschrieben.

Szenario Wiederherstellungsprozess
[Ohne zonenredundante Hochverfügbarkeit konfigurierte Server]		 Wiederherstellungsprozess
[Mit zonenredundanter Hochverfügbarkeit konfigurierte Server]
Ausfall des Datenbankservers Wenn der Datenbankserver abläuft, versucht Azure, den Datenbankserver neu zu starten. Wenn dieser Versuch fehlschlägt, startet Azure den Datenbankserver auf einem anderen physischen Knoten neu.

Die Wiederherstellungszeit (RTO) hängt von verschiedenen Faktoren ab, einschließlich der Aktivität zum Zeitpunkt des Fehlers, z. B. einer großen Transaktion und dem Umfang der Wiederherstellung, die während des Datenbankserverstartvorgangs ausgeführt werden soll.

Anwendungen, die die PostgreSQL-Datenbanken verwenden, müssen verworfene Verbindungen und fehlgeschlagene Transaktionen erkennen und wiederholen.		 Wenn der Ausfall des Datenbankservers erkannt wird, schaltet der Server auf den Standbyserver um, wodurch die Ausfallzeit reduziert wird. Weitere Informationen finden Sie unter [Konzepte – Hochverfügbarkeit]/azure/reliability/reliability-postgresql-flexible-server. RTO wird voraussichtlich 60-120 Sekunden betragen, ohne Datenverlust.
Speicherfehler Anwendungen sehen keine Auswirkungen auf speicherbezogene Probleme, z. B. einen Datenträgerfehler oder eine Beschädigung eines physischen Blocks. Da die Daten in drei Kopien gespeichert werden, dient der überlebende Speicher der Kopie der Daten. Der beschädigte Datenblock wird automatisch repariert, und eine neue Kopie der Daten wird automatisch erstellt. Bei seltenen und nicht behebbaren Fehlern, z. B. wenn auf den gesamten Speicher nicht mehr zugegriffen werden kann, führt die Azure Database for PostgreSQL Flexible Server-Instanz ein Failover auf das Standby-Replikat durch, um die Ausfallzeit zu reduzieren. Weitere Informationen finden Sie unter [Konzepte – Hochverfügbarkeit]/azure/reliability/reliability-postgresql-flexible-server.
Logische oder Benutzerfehler Führen Sie eine Point-in-Time-Wiederherstellung (PITR) aus, um Benutzerfehler wie versehentlich abgelegte Tabellen oder falsch aktualisierte Daten wiederherzustellen. Geben Sie beim Ausführen des Wiederherstellungsvorgangs den benutzerdefinierten Wiederherstellungspunkt an. Dies ist der Zeitpunkt, zu dem der Fehler aufgetreten ist.

Wenn Sie nur eine Teilmenge von Datenbanken oder bestimmten Tabellen anstelle aller Datenbanken auf dem Datenbankserver wiederherstellen möchten, können Sie den Datenbankserver in einer neuen Instanz wiederherstellen, die Tabellen über pg_dump exportieren und dann pg_restore verwenden, um diese Tabellen in Ihrer Datenbank wiederherzustellen.		 Diese Benutzerfehler sind nicht durch hohe Verfügbarkeit geschützt, da alle Änderungen synchron in das Standbyreplikat repliziert werden. Sie müssen eine Point-in-Time-Wiederherstellung durchführen, um sich von solchen Fehlern zu erholen.
Verfügbarkeitszonenfehler Zum Wiederherstellen eines Fehlers auf Zonenebene führen Sie die Point-in-Time-Wiederherstellung mithilfe der Sicherung aus, und wählen Sie einen benutzerdefinierten Wiederherstellungspunkt mit der neuesten Uhrzeit aus, um die neuesten Daten wiederherzustellen. Stellen Sie eine neue Azure Database for PostgreSQL flexible Serverinstanz in einer anderen nicht betroffenen Zone bereit. Die für die Wiederherstellung benötigte Zeit hängt von der vorherigen Sicherung und dem Volume der wiederherzustellenden Transaktionsprotokolle ab. Eine Azure Database for PostgreSQL flexible Serverinstanz schlägt automatisch innerhalb von 60 bis 120 Sekunden ohne Datenverlust auf den Standbyserver über. Weitere Informationen finden Sie unter [Konzepte – Hochverfügbarkeit]/azure/reliability/reliability-postgresql-flexible-server.
Regionsausfall Wenn Ihr Server mit georedundanter Sicherung konfiguriert ist, können Sie die Geowiederherstellung in der gekoppelten Region durchführen. Azure stellt einen neuen Server bereit und stellt ihn mit den zuletzt verfügbaren Daten wieder her, die in diese Region kopiert wurden.

Sie können auch regionsübergreifende Lesereplikate verwenden. Im Falle eines Ausfalls einer Region können Sie eine Notfallwiederherstellung durchführen, indem Sie Ihre Lesereplik zu einem eigenständigen Server mit Lese- und Schreibzugriff heraufstufen. Das RPO wird voraussichtlich bis zu fünf Minuten betragen (Datenverlust möglich), außer im Falle eines schwerwiegenden regionalen Ausfalls, wobei das RPO nahe der Replikationsverzögerung zum Zeitpunkt des Ausfalls liegen kann.		 Der gleiche Prozess.

Konfigurieren Ihrer Datenbank nach der Wiederherstellung nach einem regionalen Ausfall

Von Bedeutung

Sie können gelöschte Server wiederherstellen. Wenn Sie den Server löschen, befolgen Sie die Anweisungen unter "Wiederherstellen eines gelöschten Servers zum Wiederherstellen". Verwenden Sie die Azure-Ressourcensperre, um einer versehentlichen Löschung Ihres Servers vorzubeugen.

Verwandte Inhalte

  • Last updated on