Hochverfügbarkeit und Disaster-Recovery für Databases for PostgreSQL
HochverfügbarkeitDie Fähigkeit eines Dienstes oder einer Arbeitslast, Ausfällen standzuhalten und die Verarbeitungsfähigkeit gemäß einem vordefinierten Servicelevel weiterhin bereitzustellen. (HA) ist die Fähigkeit eines Dienstes, auch bei unerwarteten Ausfällen betriebsbereit und zugänglich zu bleiben. Unter Disaster RecoveryDie Fähigkeit eines Dienstes oder einer Arbeitslast, sich von seltenen, schwerwiegenden Vorfällen und großflächigen Ausfällen, wie z. B. Dienstunterbrechungen, zu erholen. Dies umfasst eine Naturkatastrophe, die eine ganze Region betrifft, die Beschädigung einer Datenbank oder den Verlust eines Dienstes, der zu einer Arbeitsbelastung beiträgt. Die Auswirkungen übersteigen die Fähigkeit des Hochverfügbarkeitsdesigns, sie zu bewältigen. versteht man die Wiederherstellung eines funktionierenden Zustands der Service-Instanz.
Databases for PostgreSQL ist ein regionaler Dienst, der die mit dem Standardplan definierten Service Level Objectives(SLO ) erfüllt. Weitere Informationen finden Sie unter Service Level Agreement(SLA). Weitere Informationen über die verfügbaren IBM Cloud Regionen und Rechenzentren für site.data.keyword.databases-for-postgresql finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.
Architektur für hohe Verfügbarkeit
Databases for PostgreSQL bietet Replikations-, Failover- und Hochverfügbarkeitsfunktionen, um Ihre Datenbanken und Daten vor Infrastrukturwartung, Upgrades und einigen Ausfällen zu schützen. Bereitstellungen enthalten einen Cluster mit zwei Datenmitgliedern - Leader und Replica. Das Replikat wird durch asynchrone Replikation auf dem neuesten Stand gehalten. Ein verteilter Konsensmechanismus wird verwendet, um den Cluster-Status zu erhalten und Ausfälle zu bewältigen. Wenn der Leader unerreichbar wird, leitet der Cluster ein Failover ein, wobei die Replik zum Leader befördert wird und eine neue Replik dem Cluster als Replik beitritt. Der Anführer und die Nachbildung befinden sich immer in verschiedenen Zonen eines MZR. Wenn die Replik ausfällt, wird eine neue Replik erstellt. Wenn ein Zonenausfall dazu führt, dass ein Mitglied ausfällt, wird das neue Replikat in einer überlebenden Zone erstellt.
Sie können die Hochverfügbarkeit weiter ausbauen, indem Sie PostgreSQL Mitglieder zum Cluster hinzufügen, um die Redundanz innerhalb der Region zu erhöhen, oder indem Sie schreibgeschützte Replikate für ein regionenübergreifendes Failover oder Read Offloading bereitstellen.
Lesen Sie die PostgreSQL Dokumentation über Replikationstechniken, um die Einschränkungen und Kompromisse zu verstehen, die mit der standardmäßig eingesetzten asynchronen Replikationsstrategie verbunden sind.
In Szenarien, in denen eine Datenbank in einen kritischen Zustand gerät, z. B. bei einem Serverabsturz auf dem Leader, versucht Databases for PostgreSQL ein Failover. Diese Auto-Failover-Fähigkeit ist auf 16 MB Datenrückstand vom Leader zum Replikat begrenzt (ein paar Datenzeilen, die einmal mehr PostgreSQL Daten-Overhead ausmachen) und wird nicht ausgeführt, wenn der Rückstandsschwellenwert überschritten wird. Wenn die Gefahr eines Datenverlusts von 16 MB für die Anwendung untragbar ist, siehe synchrone Replikation.
Workloads, die programmatisch auf den Cluster zugreifen, müssen der Wiederholungslogik für die Client-Verfügbarkeit folgen, um die Verfügbarkeit zu gewährleisten.
Der Dienst führt im Normalbetrieb gelegentlich kontrollierte Failover durch. Diese Failover-Ereignisse sind keine Datenverluste, führen aber zum Zurücksetzen der aktiven Verbindungen. Es gibt einen Zeitraum von bis zu 15 Sekunden, in dem Neuverbindungen fehlschlagen können. Gelegentlich kann es aufgrund unvorhergesehener Ereignisse in der Betriebsumgebung zu einem ungeplanten Failover kommen. Diese können bis zu 45 Sekunden dauern, in der Regel aber weniger als 30. Die Wartung von Diensten beispielsweise löst einen kontrollierten Failover aus.
Funktionen für hohe Verfügbarkeit
Databases for PostgreSQL unterstützt die folgenden Hochverfügbarkeitsfunktionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Automatische Ausfallsicherung | Standard bei allen Clustern und widerstandsfähig gegen den Ausfall einer Zone oder eines einzelnen Mitglieds | |
| Mitgliedsanzahl | Minimum - 2 Mitglieder. Die Standardeinstellung ist ein Einsatz mit zwei Mitgliedern. Ein Cluster mit zwei Mitgliedern stellt sich nach dem Ausfall einer einzelnen Instanz oder Zone automatisch wieder her (mit Datenverlusten bis zur Verzögerungsgrenze). Während der Datensynchronisierung für eine neue Replik ist der Cluster einem zweiten Fehler ausgesetzt, der zu Datenverlusten führt. Ein dreigliedriges System (siehe PostgreSQL)ist gegen den Ausfall von zwei Gliedern während derselben Ausfallzeit resistent | Drei Mitglieder für synchrone Replikation erforderlich |
| Synchrone Replikation | Verbessert das RPO durch Hinzufügen von Remote Member Sync zum Datenschreibpfad. Siehe Synchrone Replikation unten. | Auswirkungen auf die Leistung und Kosten. |
| Schreibgeschütztes Replikat | Schreibgeschützte Replikate können lokalen Zugriff in entfernten Regionen bieten und so die Verfügbarkeit bei möglichen Netzwerklatenzen oder Verbindungsproblemen verbessern. | Alle Schreibanfragen müssen ausschließlich an den Lese-Schreib-Cluster gerichtet werden, der mit dem Lese-Replikat |
Synchrone Replikation Databases for PostgreSQL
Standardmäßig ist die Streaming-Replikation asynchron. Wenn der Leader abstürzt, werden einige Transaktionen, die übertragen wurden, möglicherweise nicht mit dem Replikat synchronisiert, was zu Datenverlusten führt. Cloud Databases stellt
sicher, dass Datenverluste auf ein Minimum beschränkt werden; die synchrone Replikation bietet jedoch die Möglichkeit zu bestätigen, dass alle von einer Transaktion vorgenommenen Änderungen mit einem Replikat synchronisiert wurden. Dies
gewährleistet die Konsistenz innerhalb eines Clusters. Diese Konsistenz ergibt sich aus der Bestätigung, dass Schreibvorgänge auf einen sekundären Rechner geschrieben werden, bevor sie mit success an den verbindenden Client
zurückgegeben werden. Für Variablen zur synchronen Replikation, siehe synchronous_commit auf der Seite Ändern
der Konfiguration.
Die synchrone Replikation bringt die Replikatverfügbarkeit in den primären Schreibpfad. Wenn es keine Replik gibt, die einen Schreibvorgang bestätigt, bleibt er hängen, bis eine Replik verfügbar ist. Dies erfordert eine zuverlässige Funktion von mindestens drei Membern, da die synchrone Replikation in Implementierungen mit zwei Membern nicht unterstützt wird. Sie müssen eine horizontale Skalierung auf mindestens drei Mitglieder vornehmen, bevor Sie die synchrone Replikation aktivieren. Siehe PostgreSQL Mitglieder hinzufügen.
Es ist zwar unwahrscheinlich, aber es ist möglich, dass mehr als eine Replik gleichzeitig nicht mehr verfügbar ist. In diesem Fall kann die Primärdatenbank keine Schreiboperationen ausführen, bis ein Replikat wieder online ist. Dies blockiert effektiv den gesamten Schreibdatenverkehr für Ihre Datenbank. Wenn Sie sich für die synchrone Replikation entscheiden, wägen Sie die relativen Kosten und Vorteile einer höheren Datenbeständigkeit gegen mögliche Verfügbarkeitsprobleme ab.
Die Konfiguration der synchronen Replikation kann die Schreiblatenz erheblich erhöhen und den Gesamtdurchsatz verringern. Um eine optimale Leistung zu erzielen, wird empfohlen, die synchrone Replikation nur für bestimmte Datenbanken oder Arbeitslasten zu verwenden, die ein Höchstmaß an Datenbeständigkeit erfordern.
Architektur zur Wiederherstellung im Katastrophenfall
Die allgemeine Strategie für die Wiederherstellung im Katastrophenfall besteht darin, eine neue Datenbank zu erstellen, wie die nachstehende Datenbank Restore. Der Inhalt der neuen Datenbank kann ein Backup der Quelldatenbank sein,
das vor der Katastrophe erstellt wurde. Eine neue Datenbank kann mit der Point-in-Time-Funktion erstellt werden, wenn die Produktionsdatenbank verfügbar ist.
Funktionen zur Wiederherstellung im Katastrophenfall
Databases for PostgreSQL unterstützt die folgenden Disaster-Recovery-Funktionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Sicherung wiederherstellen | Erstellen einer Datenbank aus einer zuvor erstellten Sicherung; siehe Verwaltung von Cloud Databases Sicherungen. | Neue Verbindungszeichenfolgen für die wiederhergestellte Datenbank müssen während des gesamten Workloads referenziert werden. |
| Zeitpunktgesteuerte Wiederherstellung | Erstellen einer Datenbank aus der Live-Produktion mit Point-in-Time-Recovery | Dies ist nur möglich, wenn die aktive Datenbank verfügbar ist und das RPO (Disaster) innerhalb des unterstützten Zeitfensters liegt. Sie ist nicht sinnvoll, wenn der Produktionscluster nicht verfügbar ist. Neue Verbindungszeichenfolgen für die wiederhergestellte Datenbank müssen während des gesamten Workloads referenziert werden. |
| Förderung der Replik lesen | Erstellen Sie eine schreibgeschützte Replik, wenn Sie für eine Katastrophe in der gleichen oder einer entfernten Region planen. Promoten Sie die schreibgeschützte Replik zur Wiederherstellung nach einer Katastrophe. | Zuvor erstellte Lesekopien müssen verfügbar sein. Neue Verbindungszeichenfolgen für die wiederhergestellte Datenbank müssen während des gesamten Workloads referenziert werden. |
Disaster-Recovery planen
Die Wiederherstellungsmaßnahmen müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.
| Fehler | Lösung |
|---|---|
| Hardware-Ausfall (einzelner Punkt) | IBM bietet eine Datenbank, die gegen einen einzelnen Hardwareausfall innerhalb einer Zone gefeit ist - eine Konfiguration ist nicht erforderlich. |
| Zonenfehler | Automatische Ausfallsicherung (#postgresql-high-availability). Die Mitglieder der Datenbank sind auf die Zonen verteilt. Die Konfiguration von drei Mitgliedern bietet zusätzliche Ausfallsicherheit bei mehreren Zonenausfällen.
Die synchrone Replikation verringert das RPO auf Kosten der Leistung. |
| Datenbeschädigung | Backup wiederherstellen. Verwenden Sie die wiederhergestellte Datenbank in der Produktion oder für Quelldaten, um die Beschädigung in der wiederhergestellten Datenbank zu korrigieren.
Point-in-Time-Wiederherstellung. Verwenden Sie die wiederhergestellte Datenbank in der Produktion oder für Quelldaten, um die Beschädigung in der wiederhergestellten Datenbank zu korrigieren. |
| Regionales Versagen | Backup wiederherstellen. Verwenden Sie die wiederhergestellte Datenbank in der Produktion.
Förderung der Replik lesen. Eine schreibgeschützte Replik in eine Datenbank mit Lese-/Schreibzugriff umwandeln. Verwenden Sie die wiederhergestellte Datenbank in der Produktion |
Hochverfügbarkeit auf Anwendungsebene
Anwendungen, die über Netze und Cloud-Services kommunizieren, sind temporären Verbindungsfehlern ausgesetzt. Sie möchten Ihre Anwendungen so gestalten, dass sie den Aufbau von Verbindungen neu versuchen, wenn Fehler durch einen temporären Verlust der Verbindung zu Ihrer Bereitstellung oder zu IBM Cloud verursacht werden.
Da Databases for PostgreSQL ein verwalteter Dienst ist, gehören regelmäßige Aktualisierungen und die Wartung der Datenbank zum normalen Betrieb. Dies kann gelegentlich zu kurzen Intervallen führen, in denen Ihre Datenbank nicht verfügbar ist. Es kann auch dazu führen, dass die Datenbank ein geordnetes Failover, eine Wiederholung und Neuherstellung der Verbindung auslöst. Es dauert eine kurze Zeit, bis die Datenbank ermittelt hat, welches Member ein Replikat und welches der Leader ist, sodass möglicherweise auch eine kurze Verbindungsunterbrechung auftritt. Failover dauern in der Regel weniger als 30 Sekunden.
Ihre Anwendungen müssen so konzipiert sein, dass sie temporäre Unterbrechungen bezüglich der Datenbank handhaben können, eine Fehlerbehandlung bei fehlgeschlagenen Datenbankbefehlen implementieren und eine Neuversuchslogik für die Wiederherstellung nach einer temporären Unterbrechung implementieren.
Mit einer Nichtverfügbarkeit von Datenbanken oder einer Unterbrechung von Verbindungen für mehrere Minuten muss nicht gerechnet werden. Eröffnen Sie einen Support-Fall mit Details, wenn Sie länger als eine Minute keine Verbindung haben, damit wir dies untersuchen können.
Verbindungslimits
Databases for PostgreSQL legt die maximale Anzahl von Verbindungen zu Ihrer PostgreSQL-Datenbank auf 115 fest. 15 Verbindungen sind für den Superuser reserviert, um den Status und die Integrität Ihrer Datenbank zu erhalten, und für Sie und Ihre Anwendungen stehen 100 Verbindungen zur Verfügung. Nach Erreichen des Verbindungslimits führen alle Versuche, eine neue Verbindung aufzubauen, zu einem Fehler. Um zu verhindern, dass Ihre Bereitstellung mit Verbindungen überlastet wird, verwenden Sie Verbindungspooling oder skalieren Sie Ihre Bereitstellung und erhöhen Sie das Verbindungslimit. Weitere Informationen finden Sie auf der Seite Verwaltung von Verbindungen PostgreSQL.
Ihre Verantwortlichkeiten für HA und DR
Die folgenden Informationen können Ihnen dabei helfen, Ihren Plan für HA und DR zu erstellen und kontinuierlich zu üben.
Bei der Wiederherstellung einer Datenbank aus Sicherungskopien oder bei der Point-in-Time-Wiederherstellung wird eine neue Datenbank mit neuen Verbindungszeichenfolgen erstellt. Bestehende Workloads und Prozesse müssen an die neuen Verbindungsstrings angepasst werden. Das Heraufstufen eines Lese-Replikats zu einem Cluster hat ähnliche Auswirkungen, obwohl bestehende schreibgeschützte Teile des Workloads davon nicht betroffen sind.
Eine wiederhergestellte Datenbank benötigt unter Umständen die gleichen vom Kunden erstellten Abhängigkeiten wie die Notfalldatenbank - stellen Sie sicher, dass diese und andere Dienste in der wiederhergestellten Region vorhanden sind:
- IBM® Key Protect for IBM Cloud®
Denken Sie daran, dass beim Löschen einer Datenbank auch die zugehörigen Sicherungen gelöscht werden. Gelöschte Datenbanken können jedoch innerhalb eines begrenzten Zeitrahmens wiederhergestellt werden. Spezifische Einzelheiten zu den Verfahren zur Wiederherstellung der Datenbank finden Sie in der Dokumentation.
Es ist nicht möglich, Sicherungen von IBM Cloud zu kopieren, daher sollten Sie die datenbankspezifischen Tools für zusätzliche Sicherungen verwenden. Sie kann erforderlich sein, um eine böswillig gelöschte Datenbank wiederherzustellen, gefolgt von einer Reklamationslöschung einer Datenbank. Eine sorgfältige Verwaltung des IAM-Zugriffs auf Datenbanken kann dazu beitragen, die Anfälligkeit für dieses Problem zu verringern.
Die folgende Checkliste für jedes Merkmal kann Ihnen bei der Erstellung und Umsetzung Ihres Plans helfen.
- Sicherung wiederherstellen
- Überprüfen Sie, ob Backups in der gewünschten Häufigkeit verfügbar sind, um die RPO-Anforderungen zu erfüllen. Die Verwaltung von Cloud Databases Backups dokumentiert die Häufigkeit der Backups. Erwägen Sie ein Skript unter Verwendung von IBM Cloud® Code Engine – Arbeiten mit dem Ereignisproduzenten des periodischen Timers(Cron), um zusätzliche On-Demand-Backups zu erstellen und so das RPO zu verbessern, wenn die Kritikalität und Größe der Datenbank dies zulassen. In Anbetracht der PITR-Fähigkeiten von PostgreSQL's sollte jedoch sorgfältig geprüft werden, ob zusätzliche Backups erforderlich sind.
- Es gibt einige Einschränkungen für die Wiederherstellungsregionen von Datenbanken - vergewissern Sie sich, dass Ihre Wiederherstellungsziele erreicht werden können, indem Sie Cloud Databases Backups verwalten lesen.
- Überprüfen Sie, ob die Aufbewahrungsfrist der Backups Ihren Anforderungen entspricht.
- Planen Sie regelmäßig Testwiederherstellungen, um zu überprüfen, ob die tatsächlichen Wiederherstellungszeiten den definierten RTO einhalten. Denken Sie daran, dass die Größe der Datenbank die Wiederherstellungszeit erheblich beeinflusst. Bitte ziehen Sie Strategien in Betracht, um die Wiederherstellungszeiten zu minimieren, z. B. die Aufteilung großer Datenbanken in kleinere, besser zu verwaltende Einheiten und die Bereinigung nicht verwendeter Daten.
- Überprüfen Sie den Dienst Key Protect.
- Zeitpunktgesteuerte Wiederherstellung
- Überprüfen Sie die zuvor beschriebenen Verfahren.
- Vergewissern Sie sich, dass die gewünschte Sicherung im Fenster angezeigt wird.
- Förderung der Replik lesen
- Überprüfen Sie, ob eine Lesekopie in der Wiederherstellungsregion vorhanden ist.
- Üben Sie den Heraufstufungsprozess - erstellen Sie eine temporäre Lesekopie in der gewünschten Region. Das temporäre Replikat kann auf Lese-/Schreibzugriff umgestellt und einige Tests mit geringen Auswirkungen auf die Produktion durchgeführt werden.
Um mehr über die Verantwortung zwischen dem Kunden und IBM Cloud für die Nutzung von Databases for PostgreSQL zu erfahren, siehe Gemeinsame Verantwortung für Cloud Databases.
Bleiben Sie informiert: IBM Benachrichtigungen
Aktualisierungen, die sich auf die Arbeitslasten der Kunden auswirken, werden über IBM Cloud mitgeteilt. Um über geplante Wartungsarbeiten, Ankündigungen und Versionshinweise in Bezug auf diesen Dienst informiert zu bleiben, besuchen Sie die Seite Benachrichtigungen und Status der Überwachung. Prüfen Sie außerdem regelmäßig die Seite Versionsrichtlinie, um sich über die neuesten Versionen und Termine für das End-of-Life zu informieren.