Hochverfügbarkeit und Disaster-Recovery für Databases for MongoDB
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 Kapazitäten des Hochverfügbarkeitsdesigns. versteht man die Wiederherstellung eines funktionierenden Zustands der Service-Instanz.
Databases for MongoDB ist ein regionaler Dienst, der die definierten Service Level Objectives(SLO ) mit den Plänen Standard und Enterprise erfüllt. Weitere Informationen finden Sie unter Service Level Agreement(SLA). Weitere Informationen über die verfügbaren IBM Cloud Regionen und Rechenzentren für Databases for MongoDB finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.
Architektur für hohe Verfügbarkeit
Databases for MongoDB 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 - ein primäres und zwei sekundäre Mitglieder. Der aus zwei Mitgliedern bestehende Replikationssatz 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 Primärserver nicht verfügbar ist, wählt der Replikationssatz einen Sekundärserver als Primärserver aus und setzt den normalen Betrieb fort. Der vorherige primäre Knoten wird, sobald erneut verfügbar, wieder eingebunden. Die primären und sekundären Mitglieder werden sich immer in verschiedenen Zonen eines MZR befinden. Wenn ein Zonenausfall dazu führt, dass ein Mitglied ausfällt, wird das neue Replikat in einer überlebenden Zone erstellt.
Funktionen für hohe Verfügbarkeit
Databases for MongoDB unterstützt die folgenden Hochverfügbarkeitsfunktionen.
| Feature | Beschreibung |
|---|---|
| Automatische Ausfallsicherung | Standard bei allen Clustern und widerstandsfähig gegen den Ausfall einer Zone oder eines einzelnen Mitglieds. |
| Mitgliedsanzahl | Mindestens 3 Mitglieder. Die Standardeinstellung ist ein Einsatz mit drei Mitgliedern. Ein Cluster mit drei Mitgliedern stellt sich nach dem Ausfall einer einzelnen Instanz oder Zone automatisch wieder her (mit Datenverlusten bis zur Verzögerungsgrenze). |
| Asynchrone Replikation | Sekundäre Systeme replizieren die Operationen des primären Systems und wenden die Operationen asynchron auf ihre Datensätze an. Dadurch, dass die Datensätze der Sekundärsysteme den Datensatz des Primärsystems widerspiegeln, kann das Replikat trotz des Ausfalls eines oder mehrerer Mitglieder weiter funktionieren. |
Architektur zur Wiederherstellung im Katastrophenfall
Die allgemeine Strategie für die Wiederherstellung im Katastrophenfall besteht darin, eine neue Datenbank zu erstellen, z. B. die folgende Datenbank MongoDB 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 für den Enterprise-Plan erstellt werden, wenn die Produktionsdatenbank verfügbar ist.
Funktionen zur Wiederherstellung im Katastrophenfall
Databases for MongoDB 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 für den Enterprise-Plan möglich und wenn die aktive Datenbank verfügbar ist und der 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. |
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. Die Mitglieder der Datenbank sind auf die Zonen verteilt. Die Konfiguration von drei Mitgliedern bietet zusätzliche Ausfallsicherheit bei mehreren Zonenausfällen. |
| 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. |
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.
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.
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.
Beim Wiederherstellen 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 möglicherweise die gleichen vom Kunden erstellten Abhängigkeiten wie die Notfalldatenbank:
- 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 Details zu den Wiederherstellungsprozeduren von Datenbanken finden Sie in der Dokumentation zu den FAQ-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, die jedem Merkmal zugeordnet ist, 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 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.
- 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 die gewünschte Sicherung im Fenster angezeigt wird.
Weitere Informationen über die Verantwortlichkeiten zwischen dem Kunden und IBM Cloud für die Nutzung von Databases for MongoDB finden Sie unter Gemeinsame Verantwortlichkeiten 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, lesen Sie bitte Monitoring-Benachrichtigungen und Status. Überprüfen Sie außerdem regelmäßig die Versionsrichtlinie, um die neuesten Aktualisierungen der End-of-Life-Versionen und -Termine zu erhalten.