Hochverfügbarkeit und Disaster-Recovery für Databases for MySQL
HochverfügbarkeitDie Fähigkeit eines Dienstes oder einer Arbeitslast, Ausfällen standzuhalten und die Verarbeitungsfähigkeit gemäß einem vordefinierten Servicelevel weiterhin bereitzustellen. Für Dienstleistungen ist die Verfügbarkeit im Service Level Agreement definiert. Die Verfügbarkeit umfasst sowohl geplante als auch ungeplante Ereignisse wie Wartungsarbeiten, Ausfälle und Katastrophen. (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 MySQL ist ein regionaler Dienst, der die mit dem Standardplan definierten Service Level Objectives(SLO ) erfüllt. Weitere Informationen finden Sie im Service Level Agreement(SLA). Weitere Informationen über die verfügbaren IBM Cloud Regionen und Rechenzentren für Databases for MySQL finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.
Architektur für hohe Verfügbarkeit
Databases for MySQL 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 drei Datenmitgliedern - einem Leader und zwei Replikaten. Alle Member enthalten eine Kopie Ihrer Daten, wobei Orchestrator für die Handhabung des Failover genutzt wird. Wenn der Leader unerreichbar wird, initiiert der Cluster ein Failover, ein Replikat wird zum Leader befördert, ein neues Replikat tritt dem Cluster als Replikat bei, und Ihr Cluster arbeitet normal weiter. Der Anführer und die Replikanten 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 schreibgeschützte Replikate für regionenübergreifendes Failover oder Read Offloading bereitstellen.
Lesen Sie die MySQL Dokumentation über Replikationstechniken, um die Einschränkungen und Kompromisse zu verstehen, die mit der semisynchronen Replikationsstrategie verbunden sind.
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.
Databases for MySQL führt manchmal kontrollierte Umschaltungen im Normalbetrieb durch. Bei diesen Umschaltungen handelt es sich um Ereignisse ohne Datenverluste, die zum Zurücksetzen aktiver Verbindungen führen. 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 Sekunden. Die Wartung von Diensten beispielsweise löst einen kontrollierten Failover aus.
Funktionen für hohe Verfügbarkeit
Databases for MySQL 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 | Ein dreiköpfiger Einsatz. Ein Cluster mit drei Mitgliedern stellt sich bei einem einzelnen Ausfall einer Instanz oder Zone automatisch wieder her, wobei es während des Wiederherstellungsprozesses zu einer Datenverzögerung kommen kann. Im Falle eines Ausfalls wird ein Replikat zum Leader befördert, und der Cluster arbeitet normal weiter. | |
| Nur-Lese-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 mit der Lese-Replik verbundenen Lese-Schreib-Cluster gerichtet werden. |
Architektur zur Wiederherstellung im Katastrophenfall
Die allgemeine Strategie für die Wiederherstellung im Katastrophenfall besteht darin, eine neue Datenbank zu erstellen, z. B. die Datenbank Restore. Der Inhalt der neuen Datenbank kann eine Sicherung der Quelldatenbank sein, die
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 MySQL unterstützt die folgenden Disaster-Recovery-Funktionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Sicherung wiederherstellen | Erstellen Sie eine Datenbank aus einem zuvor erstellten Backup. Weitere Informationen finden Sie unter Verwalten von Cloud Databases Backups. | Neue Verbindungszeichenfolgen für die wiederhergestellte Datenbank müssen während des gesamten Workloads referenziert werden. |
| Zeitpunktgesteuerte Wiederherstellung | Erstellen Sie eine 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 ein schreibgeschütztes Replikat, 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 (#mysql-high-availability). Die Mitglieder der Datenbank sind auf die Zonen verteilt. |
| 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 MySQL ein verwalteter Dienst ist, gehören regelmäßige Aktualisierungen und die Wartung der Datenbank zum normalen Betrieb. Wenn beide Replikate verloren gehen, bleiben die Schreibvorgänge auf dem Leader hängen, da der semisynchrone Replikationsprozess keinen Follower hat. Weitere Informationen finden Sie unter semisynchrone Replikation. Dieses Szenario führt gelegentlich zu kurzen Intervallen, in denen Ihre Datenbank nicht verfügbar ist. Es kann auch dazu führen, dass die Datenbank einen ordnungsgemäßen Failover, eine Wiederholung und eine erneute 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. Um Unterbrechungen zu minimieren, werden Aktualisierungen zuerst auf Replikate und zuletzt auf den Leiter angewendet.
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 MySQL setzt die maximale Anzahl von Verbindungen zu Ihrer MySQL-Datenbank auf 200. Lassen Sie einige Connections verfügbar, da einige von ihnen intern reserviert sind, um den Status und die Integrität Ihrer Datenbank zu erhalten. Nachdem das Verbindungslimit erreicht ist, führen alle Versuche, eine neue Verbindung aufzubauen, zu einem Fehler. Um zu verhindern, dass Ihre Bereitstellung von Verbindungen überflutet wird, verwenden Sie Verbindungspooling oder skalieren Sie Ihre Bereitstellung und erhöhen Sie ihre Verbindungsbegrenzung. Weitere Informationen finden Sie unter Verwalten von MySQL Verbindungen.
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. Vorhandene 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 möglicherweise dieselben 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®
- Hyper Protect Crypto Services
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. Nähere Informationen zur Wiederherstellung von Datenbanken finden Sie in den FAQ zu Backups.
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. Weitere Informationen finden Sie unter Verwalten von Cloud Databases Backups. Erwägen Sie ein Skript mit IBM Cloud® Code Engine- Arbeiten Sie mit dem Event Producer Periodic Timer(cron), um zusätzliche On-Demand-Backups zu erstellen, um das RPO zu verbessern, wenn die Kritikalität und Größe der Datenbank dies zulassen. In Anbetracht der PITR-Fähigkeiten von MySQL's sollte jedoch sorgfältig geprüft werden, ob zusätzliche Backups erforderlich sind.
- Es gibt einige Einschränkungen für Datenbank-Wiederherstellungsregionen - vergewissern Sie sich, dass Ihre Wiederherstellungsziele erreicht werden können, indem Sie Cloud Databases Backups verwalten lesen.
- Vergewissern Sie sich, dass 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. Ziehen Sie Strategien zur Minimierung der Wiederherstellungszeiten in Erwägung, 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 sich die gewünschte Sicherung im Fenster befindet.
- 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 MySQL 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.