Upgrade auf eine neue übergeordnete Version durchführen
Databases for MongoDB bietet zwei verschiedene Upgrade-Pfade:
- In-Place-Upgrade auf eine neue Hauptversion (derzeit unterstützt für MongoDB Standard-Plan, MongoDB Enterprise-Plan).
- Wiederherstellung aus Backup (unterstützt für MongoDB Standard-Plan und MongoDB Enterprise-Plan).
Vor Ort durchgeführte Hauptversions-Upgrades
Durch das direkte Hauptversionsupgrade können Sie Ihre Bereitstellung auf die nächste neue Hauptversion aktualisieren, sodass Sie keine Sicherung in einer neuen Bereitstellung wiederherstellen müssen. Bei diesem Ansatz werden die gleichen Verbindungszeichenfolgen beibehalten, ohne dass die Bereitstellung neu konfiguriert werden muss. Wenn die neue Hauptversion jedoch Anpassungen der Anwendung erfordert, müssen diese berücksichtigt werden.
Während des Zeitfensters für das In-Place-Hauptversions-Upgrade (einschließlich eines Backups) wird die Bereitstellung auf den Modus setUserWriteBlockMode gesetzt, der nur Lese-, aber keine Schreiboperationen in der Bereitstellung zulässt, um ein sicheres Upgrade zu gewährleisten. Sobald das Major-Versions-Upgrade der Bereitstellung abgeschlossen ist, wird writeBlockMode die entfernt.
Es gibt zwei Möglichkeiten, ein Upgrade einer Hauptversion vor Ort durchzuführen:
-
In-Place-Upgrade der Hauptversion mit Backup: Bei diesem Pfad wird vor dem eigentlichen Upgrade ein Backup erstellt, was zusätzliche Sicherheit bietet (die einzige Option für den MongoDB Enterprise-Plan).
-
Upgrade der Hauptversion vor Ort ohne Backup: Bei dieser Option wird das Upgrade durchgeführt, ohne vorher ein Backup zu erstellen. Falls das In-Place-Upgrade nicht erfolgreich ist, müssen Sie Ihre Bereitstellung aus der letzten Sicherung in eine neue Bereitstellung wiederherstellen.
Ein direktes Upgrade ohne Backup wird nicht empfohlen. Wenn die Aktualisierung zu irgendeinem Zeitpunkt fehlschlägt, kann es zu Datenverlusten kommen, da keine unmittelbare Sicherungskopie zum Wiederherstellen vorhanden ist.
[Die Point-in-Time-Wiederherstellung](/docs/databases-for-mongodb?topic=databases-for-mongodb-pitr) und [die Offline-Wiederherstellung mittels Point-in-Time-Wiederherstellung(PITR)](/docs/databases-for-mongodb?topic=databases-for-mongodb-pitr#pitr-offline-restore) sind für eine Version vorübergehend nicht verfügbar, bis ein Snapshot für diese Version erstellt und erfolgreich gesichert wurde. Dieser Snapshot erscheint nicht in Ihrer Sicherungsliste.
Vorbereitende Schritte
Beachten Sie die folgenden Aspekte, bevor Sie mit dem Upgrade beginnen.
- Vor dem Upgrade muss sich Ihre Einrichtung in einem einwandfreien Zustand befinden.
- Ihre Bereitstellung muss über mindestens 2 GB freien Speicherplatz verfügen.
- Ihr Einsatz darf keinen Benutzer mit der Berechtigung haben bypassWriteBlockingMode.
- Sie können nur auf die nächste Hauptversion aktualisieren, anstatt die Version Ihrer Wahl anzugeben.
- Jede Hauptversion enthält einige Funktionen, die möglicherweise nicht abwärtskompatibel mit früheren Versionen sind. Informieren Sie sich in den Versionshinweisen des Datenbankanbieters über alle Änderungen, die Ihre Anwendungen betreffen könnten.
- Ein Downgrade einer Bereitstellung auf eine frühere Version wird nicht unterstützt.
- Ein einmal begonnenes Upgrade der Hauptversion kann nicht mehr abgebrochen werden.
- Für MongoDB Enterprise Edition muss vor dem Upgrade mindestens ein Backup verfügbar sein.
- Für MongoDB Enterprise Edition muss die Wiederherstellung und Aktualisierung mittels PITR mit einem Zeitpunkt der früheren Version nach einem In-Place-Upgrade auf eine neue Hauptversion in zwei getrennten Schritten durchgeführt werden.
Upgrade über die Benutzerschnittstelle
-
Erstellen Sie eine neue „ Databases for MongoDB “, um den Upgrade-Prozess zu testen.
Erstellen Sie die Bereitstellung, indem Sie die vorhandene Bereitstellung mit derselben Version über „ Wiederherstellung eines Backups “ kopieren. -
Richten Sie Ihre Staging-Anwendung auf die Testbereitstellung aus.
Aktualisieren Sie Ihre Staging-Anwendung so, dass sie auf die Testumgebung verweist. Bestätigen Sie, dass Ihre Testanwendung erfolgreich eine Verbindung zur Staging-Bereitstellung herstellen kann und dass die Anwendung wie erwartet funktioniert. Durchführung aller erforderlichen Leistungs- und Betriebstests der Staging-Umgebung. -
Aktualisieren Sie die Hauptversion Ihrer Testbereitstellung, indem Sie auf der Seite „Übersicht“ auf die Schaltfläche „Hauptversion aktualisieren“ klicken.
Dadurch wird Ihre Datenbank für die Dauer des Upgrade-Vorgangs in den schreibgeschützten Modus versetzt. Notieren Sie sich, wie lange das Upgrade dauert, damit Sie die Einstellung für den Ablauf des Upgrades verwenden können, um Upgrades innerhalb Ihres Wartungsfensters einzuschränken. -
Vergewissern Sie sich, dass Ihre Staging-Anwendung mit der neuen Datenbankversion funktioniert.
Wenn Ihre Anwendung funktioniert, bestätigt dieser Schritt, dass ein Upgrade Ihrer Produktionsdatenbank unbedenklich sein sollte. -
Aktualisieren Sie Ihre Produktionsdatenbank auf die neue Version.
Sobald Sie sich vergewissert haben, dass Ihre Anwendung mit der neuen Datenbankversion einwandfrei funktioniert, können Sie zur Verwaltungskonsole zurückkehren und mit der Aktualisierung Ihrer Produktionsumgebung beginnen. Klicken Sie im Abschnitt Einsatzdetails der Seite Übersicht auf die Schaltfläche Hauptversion aktualisieren und folgen Sie den Anweisungen.Sobald der In-Place-Upgrade-Prozess beginnt, kann er nicht mehr gestoppt oder rückgängig gemacht werden. Im unwahrscheinlichen Fall eines Fehlers könnte Ihre Datenbankeinrichtung also nicht mehr wiederherstellbar sein. Erstellen Sie daher eine Sicherungskopie, die Sie dann für die Wiederherstellung einer neuen Bereitstellung verwenden können. Wenn Sie die Option "Vor-Ort-Hauptversions-Upgrade mit Backup" wählen, kann das erstellte Backup zur Wiederherstellung bei einer neuen Bereitstellung verwendet werden.
Unter expiration for starting upgrade können Sie eine "Timeout"-Periode konfigurieren, innerhalb derer der Upgrade-Auftrag beginnen muss, bevor er automatisch abgebrochen wird. Testen Sie außerdem das Upgrade im Staging-Modus,
um sicherzustellen, dass das Upgrade innerhalb des gewünschten Zeitfensters abgeschlossen wird. Wenn Sie z. B. das Upgrade innerhalb von 1 Stunde abschließen wollen und wissen, dass es 30 Minuten dauert, dann muss Ihr Upgrade-Auftrag innerhalb
von 30 Minuten nach Bestätigung des Upgrades beginnen. Stellen Sie daher die Ablaufzeit auf 30 Minuten ein, damit das Fenster nicht überläuft, wenn es nicht innerhalb dieser Zeit gestartet wird.
Upgrade über die Anwendungsprogrammierschnittstelle
Verwenden Sie den folgenden Befehl, um ein direktes Upgrade durchzuführen:
curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/version -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{"version": "7.0"}'
Unter expiration for starting upgrade können Sie eine "Timeout"-Periode konfigurieren, innerhalb derer der Upgrade-Auftrag beginnen muss, bevor er automatisch abgebrochen wird. Testen Sie außerdem das Upgrade im Staging-Modus,
um sicherzustellen, dass das Upgrade innerhalb des gewünschten Zeitfensters abgeschlossen wird. Wenn Sie z. B. das Upgrade innerhalb von 1 Stunde abschließen wollen und wissen, dass es 30 Minuten dauert, dann muss Ihr Upgrade-Auftrag innerhalb
von 30 Minuten nach Bestätigung des Upgrades beginnen. Legen Sie daher den Ablauf auf einen Zeitstempel von 30 Minuten ab jetzt fest, so dass das Zeitfenster nicht überschritten wird, wenn der Vorgang nicht innerhalb dieser Zeit beginnt.
Der Ablauf muss zwischen 5 Minuten (Standard) und 24 Stunden ab jetzt liegen. Weitere Informationen finden Sie in der Cloud Databases API.
Upgrade über die Befehlszeilenschnittstelle
Verfügbar in der CDB-Plugin-Version >= 0.20.0
So zeigen Sie die Liste der zulässigen Aktualisierungs- und Wiederherstellungsübergänge für die Bereitstellung an:
ibmcloud cdb deployment-capability-show <NAME|CRN> versions
Um den Befehl mit den erforderlichen Parametern zu aktualisieren:
ibmcloud cdb deployment-version-upgrade <NAME|CRN> <TARGET_VERSION>
Um alle Details der Befehlsparameter anzuzeigen:
ibmcloud cdb deployment-version-upgrade --help
Unter expiration for starting upgrade können Sie eine "Timeout"-Periode konfigurieren, innerhalb derer der Upgrade-Auftrag beginnen muss, bevor er automatisch abgebrochen wird. Testen Sie außerdem das Upgrade im Staging-Modus,
um sicherzustellen, dass das Upgrade innerhalb des gewünschten Zeitfensters abgeschlossen wird. Wenn Sie z. B. das Upgrade innerhalb von 1 Stunde abschließen wollen und wissen, dass es 30 Minuten dauert, dann muss Ihr Upgrade-Auftrag innerhalb
von 30 Minuten nach Bestätigung des Upgrades beginnen. Stellen Sie daher die Ablaufzeit auf 30 Minuten ein, damit das Fenster nicht überläuft, wenn es nicht innerhalb dieser Zeit gestartet wird. Der Ablauf muss zwischen 5 Minuten (Standard)
und 24 Stunden ab jetzt liegen. Es gibt zwei Möglichkeiten, den Ablauf mit CLI --expire-in oder --expire-at einzustellen. Weitere Informationen finden Sie in der Hilfe zum Befehl.
Upgrades durch Terraform
Verfügbar in der Terraform-Provider-Version >= 1.79.2
Um ein Upgrade durchzuführen, fügen Sie einfach den Wert version in Ihrer Konfiguration hinzu oder ändern ihn. Es gibt auch ein optionales bool-Flag, version_upgrade_skip_backup, das Sie setzen können, um die Sicherung
zu überspringen.
Es wird nicht empfohlen, ein Backup auszulassen. Das Überspringen einer Sicherung vor einem Versions-Upgrade ist gefährlich und kann zu einem Datenverlust führen, wenn das Upgrade zu irgendeinem Zeitpunkt fehlschlägt - es gibt dann keine unmittelbare Sicherung, von der aus wiederhergestellt werden kann.
Die Datenbank wird während des Upgrades in den READ-ONLY-Modus versetzt. Es wird dringend empfohlen, vor der Aufrüstung einen Test durchzuführen.
Die Aktualisierung kann mehr Zeit in Anspruch nehmen als der Standard-Timeout. Mit dem Attribut timeouts kann ein längerer Timeout-Wert festgelegt werden.
Terraform hat Timeouts anstelle von Verfallszeitstempeln. Erhöhen Sie daher die Zeitüberschreitung, da der Aktualisierungswert der Zeitüberschreitung als Ablaufdatum verwendet wird. Wenn Sie z. B. eine Zeitüberschreitung von 20 Minuten festlegen, wird der Ablauf auf 20 Minuten festgelegt, und wenn das Upgrade nicht innerhalb dieses Zeitrahmens beginnt, läuft es ab und wird nicht gestartet. Beachten Sie, dass die maximale Ablaufzeit 24 Stunden beträgt. Selbst wenn Sie also eine Zeitüberschreitung von 36 Stunden einstellen, läuft das Upgrade ab, wenn es nicht innerhalb der ersten 24 Stunden gestartet wurde.
Wenn ein Upgrade im Gange ist, beachten Sie, dass einige Aufgaben in der Warteschlange stehen und erst nach Abschluss des Versions-Upgrades fortgesetzt werden können.
Fehlerbehebung
Benutzer mit bypassWriteBlockingMode
Um ein sicheres Upgrade zu gewährleisten, darf kein Benutzer während des Backups oder Upgrades eine Schreibaktion durchführen können. Bevor die Datenbank in den writeBlockMode geht, wird geprüft, ob ein Benutzer das Recht hat bypassWriteBlockingMode. Wenn ein solcher Benutzer identifiziert wird, geht die Aufgabe in einen fehlgeschlagenen Zustand über. Jeder Wiederholungsversuch schlägt fehl, und nur das Entfernen eines Benutzers mit einem solchen Privileg ermöglicht die Durchführung des Hauptversions-Upgrades an Ort und Stelle.
Gesundheitschecks
Wenn die Ressourcen einer Dienstinstanz knapp werden, schlägt die Aufgabe fehl, da ein sicheres Upgrade unter diesen Umständen nicht garantiert werden kann. Der Ressourcenverbrauch kann mit Hilfe der Monitoring-Integration bewertet werden. Wenn nicht alle Datenbankkomponenten für ein Upgrade verfügbar sind, schlägt die Upgrade-Aufgabe fehl.
Für erfordert die Unterstützung MongoDBEnterprise Edition von PITR, dass aktuelle Snapshots ohne Lücken vorhanden sind, und während des Upgrades werden keine Snapshots erstellt. Wenn PITR nicht garantiert werden kann, schlägt das In-Place-Upgrade fehl.
Dies kann aufgrund von Wartungsarbeiten oder der Nutzung der Datenbank geschehen. Aufgaben, die aufgrund von fehlgeschlagenen Gesundheitsprüfungen fehlgeschlagen sind, können später erneut versucht werden. Wenn die Aufgabe weiterhin fehlschlägt, öffnen Sie ein Support-Ticket bei IBM Cloud support.
Von der Sicherung wiederherstellen
Bevor eine Hauptversion einer Datenbank das Ende ihrer Lebensdauer (EOL) erreicht, führen Sie ein Upgrade auf die nächste verfügbare Hauptversion durch, indem Sie eine Sicherung in eine neue Datenbankinstanz wiederherstellen.
Bereiten Sie die Ausführung unter vor und migrieren Sie anschließend auf die neueste Version vor dem EOL-Datum. Weitere Informationen finden Sie unter Versionssteuerungsrichtlinie.
Das Rollback von Versionen wird nicht unterstützt.
Führen Sie ein Upgrade auf die neueste Version von „ MongoDB “ durch, die unter Databases for MongoDB verfügbar ist. Suchen Sie die neueste Version auf der Katalogseite, über den Cloud Databases-CLI-Plug-in-Befehl ibmcloud cdb deployables-show oder über den API-Endpunkt Cloud Databases /deployables.
Das Upgrade erfolgt durch das Wiederherstellen einer Sicherungskopie Ihrer Daten in einer neuen Bereitstellung. Die Wiederherstellung aus einer Sicherung hat verschiedene Vorteile:
- Die ursprüngliche Datenbank bleibt aktiv und die Produktionsarbeiten können ohne Unterbrechung fortgesetzt werden.
- Sie können die neue Datenbank aus der Produktion heraus testen und auf eine etwaige Inkompatibilität von Anwendungen reagieren.
- Der gesamte Prozess kann an jedem beliebigen Punkt erneut ausgeführt werden.
- Durch eine aktuelle Wiederherstellung wird die Wahrscheinlichkeit verringert, dass nicht benötigte Artefakte der älteren Datenbankversion in die neue Datenbank übernommen werden.
Upgradepfade
| Aktuelle Version | Upgradepfad der Hauptversion |
|---|---|
| MongoDB 7 | MongoDB 8 |
Upgrade über die Benutzerschnittstelle
Für die neuen Hosting-Modelle (isolierter Rechner und gemeinsam genutzter Rechner) ist ein Upgrade auf eine neue Hauptversion über die CLI und API möglich.
Sie können auf eine neue Version aktualisieren, indem Sie ein Backup von der Seite Backups und Wiederherstellung Ihrer Bereitstellung auf der Konsole IBM Cloud wiederherstellen. Klicken Sie auf Sicherung wiederherstellen bei einer Sicherung, um eine Seite in einer neuen Registerkarte zu öffnen, auf der Sie einige Optionen für die neue Bereitstellung ändern können. Eine dieser Optionen ist die Datenbankversion, die automatisch mit den verfügbaren Versionen gefüllt wird, auf die Sie ein Upgrade durchführen können. Wählen Sie eine Version aus und klicken Sie auf „Sicherung wiederherstellen“, um den Bereitstellungs- und Wiederherstellungsprozess zu starten.
Upgrade über die Befehlszeilenschnittstelle
Wenn Sie das Upgrade und die Wiederherstellung der Sicherung über die IBM Cloud-Befehlszeilenschnittstelle durchführen, verwenden Sie den Einrichtungsbefehl aus dem Ressourcencontroller.
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE_ID> <SERVICE_PLAN_ID> <REGION>
Die Parameter „ instance_name “, „ service_id “, „ service_plan_id “ und „ region “ sind alle erforderlich. Geben Sie auch -p mit den Parametern für Version und Sicherungs-ID
in einem JSON-Objekt an. Die neue Bereitstellung hat automatisch eine Platte und einen Speicher derselben Größe wie die Quellenbereitstellung zum Zeitpunkt der Sicherung.
ibmcloud resource service-instance-create example-upgrade databases-for-mongodb standard us-south \
-p \ '{
"backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
"version":"7.0"
}'
Upgrade über die Anwendungsprogrammierschnittstelle
Ähnlich wie bei der Bereitstellung über die API müssen Sie die erforderlichen Schritte zur Nutzung der Ressourcen-Controller-API durchführen, bevor Sie diese für ein Upgrade aus einer Sicherung verwenden können. Anschließend senden Sie der API eine POST-Anforderung. Die Parameter name, target, resource_group und resource_plan_id sind erforderlich. Geben Sie außerdem die Versionsnummer und die Backup-ID an. Die neue Bereitstellung verfügt über die gleiche Speicher- und Plattenzuordnung wie die Quellenbereitstellung zum Zeitpunkt der Sicherung.
curl -X POST https://resource-controller.cloud.ibm.com/v2/resource_instances -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{
"name": "my-instance",
"target": "us-south",
"resource_group": "5g9f447903254bb58972a2f3f5a4c711",
"resource_plan_id": "databases-for-mongodb-standard",
"backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
"version":"7.0"
}'
Upgrades durch Terraform
Verwenden Sie Terraform, um ein Backup von einer älteren Version auf eine neue Version wiederherzustellen.
- Stellen Sie Ihre
backup_idein. Weitere Informationen finden Sie unterbackup_id. - Setzen Sie Ihre
versionin das Attribut Version. Weitere Informationen finden Sie unterversion.
Der Code sieht wie folgt aus:
resource "ibm_database" "<your-instance>" {
name = "<your_database_name>"
service = "<service>"
plan = "<plan>"
location = "<region>"
version = "<version>"
backup_id = "<backup_id>"
}
Weitere Informationen finden Sie in der Cloud Databases Terraform Registry. Alternativ können Sie auch Terraform IBM Module(TIM) verwenden, um eine neue Datenbankinstanz aus einer Sicherungsinstanz zu erstellen. Weitere Informationen finden Sie unter Beispiel für die Wiederherstellung aus einem Backup.