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 Infrastrukturwartungen, Upgrades und bestimmten Ausfällen zu schützen. Bereitstellungen umfassen einen Cluster mit zwei Datenknoten – 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 erhöhen, indem Sie dem Cluster Mitglieder von PostgreSQL hinzufügen, um die Redundanz innerhalb der Region zu verbessern, oder indem Sie schreibgeschützte Replikate für regionenübergreifendes Failover oder Leseentlastung 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 der Zustand einer Datenbank kritisch beeinträchtigt ist, beispielsweise bei einem Serverausfall des Leaders, versucht Databases for PostgreSQL ein Failover. Diese automatische Failover-Funktion ist auf einen Datenrückstand von maximal 16 MB zwischen Leader und Replik begrenzt (einige Datenzeilen, die früher einen größeren Daten-Over PostgreSQL-Aufwand verursachten) und wird nicht ausgeführt, wenn der Schwellenwert für den Rückstand ü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 Failovers führen zu keinem Datenverlust, haben jedoch eine Neuinitialisierung aktiver Verbindungen zur Folge. 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 ungeplanten Failovers 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 wird dadurch gewährleistet, dass sichergestellt wird, dass Schreibvorgänge zunächst auf einen Sekundärserver geschrieben werden, bevor mit dem verbindenden Client
zurückgemeldet wird success. 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.
Auch wenn dies unwahrscheinlich ist, ist es möglich, dass mehr als eine Replik gleichzeitig nicht verfügbar wird. 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 Datensicherheit 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 Knoten sorgt für zusätzliche Ausfallsicherheit bei Ausfällen in mehreren Zonen.
Die synchrone Replikation reduziert das RPO auf Kosten der Leistung. |
| Datenbeschädigung | Backup wiederherstellen. Verwenden Sie die wiederhergestellte Datenbank in der Produktion oder als Quelldaten, um die Beschädigung in der wiederhergestellten Datenbank zu beheben.
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.
Erhöhen Sie die Lesereplika. 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 es sich bei Databases for PostgreSQL um einen Managed Service handelt, erfolgen regelmäßige Updates und die Datenbankwartung im Rahmen des normalen Betriebs. 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 Supportfall mit detaillierten Angaben, wenn die Verbindung länger als eine Minute unterbrochen ist, damit wir den Vorfall 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 herzustellen, zu einer Fehlermeldung. Um zu verhindern, dass Ihre Bereitstellung durch zu viele Verbindungen überlastet wird, nutzen Sie Connection Pooling oder skalieren Sie Ihre Bereitstellung und erhöhen Sie deren 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.