Mise à niveau vers une nouvelle version majeure

Databases for MongoDB offre deux voies de mise à niveau différentes :

  • Mise à niveau sur place vers une nouvelle version majeure (actuellement prise en charge pour le plan MongoDB Standard et le plan MongoDB Entreprise).
  • Restauration à partir d'une sauvegarde (pris en charge pour les MongoDB formules Standard et MongoDB Entreprise).

Mises à jour de versions majeures en cours d'exécution

La mise à niveau de la version majeure en place vous permet de mettre à niveau votre déploiement vers la nouvelle version majeure suivante, éliminant ainsi la nécessité de restaurer une sauvegarde dans un nouveau déploiement. Cette approche permet de conserver les mêmes chaînes de connexion, sans qu'il soit nécessaire de reconfigurer le déploiement. Toutefois, si la nouvelle version majeure nécessite des ajustements de l'application, ceux-ci doivent être pris en compte.

Pendant la fenêtre de mise à niveau de la version majeure sur place (y compris une sauvegarde), la répartition est réglée sur setUserWriteBlockMode, qui n'autorise que les opérations de lecture, mais aucune opération d'écriture sur la répartition, afin de garantir une mise à niveau en toute sécurité. Dès que la mise à niveau majeure de la version du déploiement est terminée, le writeBlockMode est supprimé.

Il existe deux options pour effectuer une mise à jour de version majeure sur place :

  • Mise à niveau majeure sur place avec sauvegarde : cette option crée une sauvegarde avant d'effectuer la mise à niveau proprement dite, offrant ainsi une sécurité supplémentaire (seule option disponible pour le forfait MongoDB Entreprise).

  • Mise à niveau de la version majeure sur place sans sauvegarde : Cette option permet de procéder à la mise à niveau sans créer de sauvegarde au préalable. Si la mise à niveau sur place échoue, vous devrez restaurer votre déploiement à partir de la dernière sauvegarde dans un nouveau déploiement.

    Il n'est pas recommandé de procéder à une mise à niveau sur place sans sauvegarde. Il peut en résulter une perte de données si la mise à niveau échoue à un moment ou à un autre, car il n'y aura pas de sauvegarde immédiate à partir de laquelle restaurer les données.

    [La restauration à un instant donné](/docs/databases-for-mongodb?topic=databases-for-mongodb-pitr) et [la restauration hors ligne PITR(Point-in-Time Recovery)](/docs/databases-for-mongodb?topic=databases-for-mongodb-pitr#pitr-offline-restore) ne sont temporairement pas disponibles pour une version tant qu'un instantané de cette version n'a pas été créé et sauvegardé avec succès. Cet instantané n'apparaît pas dans votre liste de sauvegardes.

Avant de commencer

Avant d'entamer la procédure de mise à niveau, il convient de tenir compte des aspects suivants.

  • Votre déploiement doit être en bon état avant la mise à niveau.
  • Votre déploiement doit disposer d'au moins 2 Go d'espace disque libre.
  • Votre déploiement ne doit pas avoir d'utilisateur ayant le privilège de bypassWriteBlockingMode.
  • Vous ne pouvez passer qu'à la version majeure suivante, au lieu de spécifier la version de votre choix.
  • Chaque version majeure contient des fonctionnalités qui peuvent ne pas être rétrocompatibles avec les versions précédentes. Consultez les notes de mise à jour du fournisseur de la base de données pour connaître les modifications susceptibles d'affecter vos applications.
  • La rétrogradation d'un déploiement vers une version antérieure n'est pas prise en charge.
  • La mise à jour de la version majeure en place ne peut pas être annulée une fois qu'elle a commencé.
  • Pour MongoDB Enterprise Edition, il doit y avoir au moins une sauvegarde disponible avant la mise à niveau.
  • Pour MongoDB Enterprise Edition, la restauration et la mise à niveau via PITR à partir d'un point dans le temps de la version antérieure, après une mise à niveau majeure sur place, doivent être effectuées en deux étapes distinctes.

Mise à niveau via l'interface utilisateur

  1. Créez une nouvelle instance « Databases for MongoDB » pour tester le processus de mise à niveau.
    Créez le déploiement en restaurant une sauvegarde de votre déploiement existant portant la même version.

  2. Configurez votre application de préproduction pour qu'elle pointe vers le déploiement de test.
    Mettez à jour votre application de préproduction pour qu'elle pointe vers le déploiement de test. Confirmez que votre application de test peut se connecter avec succès au déploiement par étapes et que l'application fonctionne comme prévu. Effectuer tous les tests de performance et de fonctionnement requis pour l'environnement de transition.

  3. Mettez à jour la version majeure de votre déploiement de test en cliquant sur le bouton « Mettre à jour la version majeure » sur la page « Aperçu ».
    Cela mettra votre base de données en mode LECTURE SEULE jusqu'à la fin du processus de mise à jour. Notez la durée de la mise à niveau afin de pouvoir utiliser le paramètre d'expiration de la mise à niveau pour contenir les mises à niveau dans votre fenêtre de maintenance.

  4. Vérifiez que votre application de préproduction fonctionne avec la nouvelle version de la base de données.
    Si votre application fonctionne, cette étape confirme que vous pouvez procéder en toute sécurité à la mise à niveau de votre base de données de production.

  5. Mettez à niveau le déploiement de votre base de données de production vers la nouvelle version.
    Une fois que vous aurez vérifié que votre application fonctionne correctement avec la nouvelle version de la base de données, vous pourrez revenir à la console d'administration et lancer le processus de mise à niveau de votre déploiement en production. Dans la section Détails du déploiement de la page Aperçu, cliquez sur le bouton Mettre à niveau la version majeure et suivez les étapes.

    Une fois que le processus de mise à niveau sur place a commencé, il ne peut pas être arrêté ou annulé. Ainsi, dans le cas improbable d'une erreur, le déploiement de votre base de données pourrait devenir irrécupérable. Par conséquent, créez une sauvegarde que vous pourrez ensuite utiliser pour restaurer un nouveau déploiement. Si vous sélectionnez "Mise à niveau de version majeure sur place avec sauvegarde", la sauvegarde créée peut être utilisée pour la restauration lors d'un nouveau déploiement.

Le site expiration for starting upgrade vous permet de configurer un délai d'attente dans lequel la tâche de mise à niveau doit être lancée avant d'être automatiquement annulée. En outre, testez la mise à niveau en amont pour vous assurer qu'elle s'effectue dans les délais souhaités. Si, par exemple, vous souhaitez terminer la mise à niveau dans un délai d'une heure et que vous avez testé la mise à niveau et savez qu'elle prend 30 minutes, votre tâche de mise à niveau doit démarrer dans les 30 minutes qui suivent votre confirmation de la mise à niveau. Par conséquent, fixez l'expiration à 30 minutes, de sorte que si elle ne démarre pas dans ce délai, elle ne débordera pas de votre fenêtre.

Mise à niveau via l'API

Utilisez la commande suivante pour effectuer une mise à niveau sur place :

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"}'

Le site expiration for starting upgrade vous permet de configurer un délai d'attente dans lequel la tâche de mise à niveau doit être lancée avant d'être automatiquement annulée. En outre, testez la mise à niveau en amont pour vous assurer qu'elle s'effectue dans les délais souhaités. Si, par exemple, vous souhaitez terminer la mise à niveau dans un délai d'une heure et que vous avez testé la mise à niveau et savez qu'elle prend 30 minutes, votre tâche de mise à niveau doit démarrer dans les 30 minutes qui suivent votre confirmation de la mise à niveau. Par conséquent, fixez l'expiration à 30 minutes à partir de maintenant, de sorte que si elle ne démarre pas dans ce délai, elle ne dépassera pas votre fenêtre. L'expiration doit être comprise entre 5 minutes (par défaut) et 24 heures. Pour plus d'informations, voir l'API Cloud Databases.

Mise à niveau via l'interface de ligne de commande

Disponible dans la version du plugin CDB >= 0.20.0

Pour afficher la liste des transitions de mise à niveau et de restauration autorisées pour le déploiement :

ibmcloud cdb deployment-capability-show <NAME|CRN> versions

Pour mettre à jour la commande avec les paramètres requis :

ibmcloud cdb deployment-version-upgrade <NAME|CRN> <TARGET_VERSION>

Pour afficher tous les détails des paramètres de la commande :

ibmcloud cdb deployment-version-upgrade --help

Le site expiration for starting upgrade vous permet de configurer un délai d'attente dans lequel la tâche de mise à niveau doit être lancée avant d'être automatiquement annulée. En outre, testez la mise à niveau en amont pour vous assurer qu'elle s'effectue dans les délais souhaités. Si, par exemple, vous souhaitez terminer la mise à niveau dans un délai d'une heure et que vous avez testé la mise à niveau et savez qu'elle prend 30 minutes, votre tâche de mise à niveau doit démarrer dans les 30 minutes qui suivent votre confirmation de la mise à niveau. Par conséquent, fixez l'expiration à 30 minutes, de sorte que si elle ne démarre pas dans ce délai, elle ne débordera pas de votre fenêtre. L'expiration doit être comprise entre 5 minutes (par défaut) et 24 heures. Il y a deux façons de définir l'expiration en utilisant le CLI --expire-in ou --expire-at. Pour plus d'informations, consultez l'aide de la commande.

Mise à jour via Terraform

Disponible dans la version du fournisseur Terraform >= 1.79.2

Pour effectuer une mise à niveau, il suffit d'ajouter ou de modifier la valeur version dans votre configuration. Il existe également une option bool, version_upgrade_skip_backup, qui permet d'ignorer la sauvegarde.

Il n'est pas recommandé d'omettre une sauvegarde. Il est dangereux d'omettre une sauvegarde avant une mise à niveau de version et cela peut entraîner une perte de données si la mise à niveau échoue à n'importe quel stade - il n'y aura pas de sauvegarde immédiate à partir de laquelle il sera possible de restaurer.

La base de données sera mise en mode LECTURE SEULE pendant la mise à jour. Il est fortement recommandé de faire un essai avant de procéder à la mise à niveau.

La mise à jour peut prendre plus de temps que le délai par défaut. Un délai plus long peut être défini à l'aide de l'attribut timeouts.

Terraform utilise des délais d'attente au lieu de timestamps d'expiration. Par conséquent, augmentez votre délai d'attente, car votre valeur de mise à jour du délai d'attente est utilisée comme expiration. Par exemple, si vous définissez un délai de 20 minutes, l'expiration sera fixée à 20 minutes et si la mise à niveau ne démarre pas dans ce délai, elle expirera et la mise à niveau ne démarrera pas. Notez que l'expiration maximale est de 24 heures - donc même si vous définissez un délai de 36 heures, la mise à niveau expirera si elle n'a pas commencé dans les 24 premières heures.

Si une mise à niveau est en cours, certaines tâches peuvent être mises en attente et ne seront pas exécutées tant que la mise à niveau de la version n'est pas terminée.

Traitement des incidents

Utilisateur avec bypassWriteBlockingMode

Pour garantir une mise à niveau sûre, aucun utilisateur ne doit être en mesure d'effectuer une action d'écriture pendant la sauvegarde ou la mise à niveau. Avant que la base de données ne passe en mode bloc d'écriture, un contrôle est effectué pour vérifier si un utilisateur a le privilège de bypassWriteBlockingMode. Si un tel utilisateur est identifié, la tâche entre dans un état d'échec. Toute nouvelle tentative échouera et seule la suppression d'un utilisateur disposant d'un tel privilège permet d'exécuter la mise à niveau de la version majeure sur place.

Bilans de santé

Si une instance de service manque de ressources, la tâche échoue car une mise à niveau sûre ne peut être garantie dans ces circonstances. La consommation de ressources peut être évaluée à l'aide de l'intégration de la surveillance. Si tous les composants de la base de données ne sont pas disponibles pour être mis à niveau, la tâche de mise à niveau échoue.

Pour MongoDB Enterprise Edition, la prise en charge de PITR nécessite l'existence d'instantanés actuels sans lacunes, et aucun instantané ne sera effectué pendant la mise à niveau. Si PITR ne peut être garanti, la mise à niveau sur place échouera.

Cela peut se produire en raison de la maintenance ou de l'utilisation de la base de données. Les tâches qui ont échoué en raison de l'échec des contrôles de santé peuvent être relancées ultérieurement. Si la tâche échoue continuellement, ouvrez un ticket d'assistance auprès IBM Cloud du service d'assistance.

Restauration depuis une sauvegarde

Avant qu'une version majeure d'une base de données n'atteigne sa fin de vie, mettez-la à niveau vers la version majeure suivante en restaurant une nouvelle instance de base de données à partir d'une sauvegarde.

Préparez l'exécution, puis migrez vers la version la plus récente avant la date de fin de vie. Pour plus d'informations, voir Politique de gestion des versions.

L'annulation des versions n'est pas prise en charge.

Passez à la dernière version d' MongoDB, disponible à l'adresse Databases for MongoDB. Recherchez la version la plus récente dans la page de catalogue, dans la Cloud Databases ibmcloud cdb deployables-show ou dans le noeud final Cloud Databases API /deployables.

La mise à niveau s'effectue en restaurant une sauvegarde de vos données dans un nouveau déploiement. La restauration à partir d'une sauvegarde présente plusieurs avantages:

  • La base de données d'origine reste opérationnelle et le travail de production n'est pas interrompu.
  • Vous pouvez tester la nouvelle base de données hors production et prendre des mesures concernant les incompatibilités liées aux applications.
  • L'ensemble du processus peut être réexécuté à tout moment.
  • Une nouvelle restauration réduit la probabilité que les artefacts non nécessaires de l'ancienne version de la base de données soient reportés sur la nouvelle base de données.

Chemins de mise à niveau

Chemins de mise à niveau des versions majeures
Version en cours Chemin de mise à niveau de version principale
MongoDB 7 MongoDB 8

Mise à niveau via l'interface utilisateur

Pour les nouveaux modèles d'hébergement (calcul isolé et calcul partagé), la mise à niveau vers une nouvelle version majeure est disponible via le CLI et l'API.

Vous pouvez passer à une nouvelle version en restaurant une sauvegarde à partir de la page des sauvegardes et des restaurations de votre déploiement sur la console IBM Cloud. Cliquez sur Restaurer la sauvegarde sur une sauvegarde pour ouvrir une page dans un nouvel onglet où vous pouvez modifier certaines options pour le nouveau déploiement. L'une d'entre elles est la version de base de données, indiquée automatiquement à partir des versions cible disponibles pour la mise à niveau. Sélectionnez une version, puis cliquez sur « Restaurer la sauvegarde » pour lancer le processus de provisionnement et de restauration.

Mise à niveau via l'interface de ligne de commande

Lorsque vous effectuez une mise à niveau et une restauration de la sauvegarde via l'interface de ligne de commande IBM Cloud, utilisez la commande de mise à disposition à partir du contrôleur de ressources.

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE_ID> <SERVICE_PLAN_ID> <REGION>

Les paramètres instance_name, service_id, service_plan_id et region sont tous obligatoires. Vous fournissez également l'option -p avec les paramètres de version et d'ID de sauvegarde dans un objet JSON. Le nouveau déploiement est automatiquement dimensionné avec la même taille de disque et de mémoire que le déploiement source au moment de la sauvegarde.

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"
}'

Mise à niveau via l'API

Tout comme pour le provisionnement via l'API, vous devez effectuer les étapes nécessaires à la mise en place de l'API du contrôleur de ressources avant de pouvoir l'utiliser pour effectuer une mise à niveau à partir d'une sauvegarde. Ensuite, envoyez à l'API une demande POST. Les paramètres name, target, resource_group et resource_plan_id sont tous obligatoires. Veuillez également indiquer la version et l'identifiant de la sauvegarde. Le nouveau déploiement possède la même allocation de mémoire et de disque que le déploiement source au moment de la sauvegarde.

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"
  }'

Mise à jour via Terraform

Utilisez Terraform pour restaurer une sauvegarde d'une ancienne version vers une nouvelle version.

  1. Réglez votre backup_id. Pour plus d'informations, voir backup_id.
  2. Définissez votre version dans l'attribut de version. Pour plus d'informations, voir version.

Le code se présente comme suit :

resource "ibm_database" "<your-instance>" {
  name                                 = "<your_database_name>"
  service                              = "<service>"
  plan                                 = "<plan>"
  location                             = "<region>"
  version                              = "<version>"
  backup_id                            = "<backup_id>"
}

Pour plus d'informations, voir Cloud Databases Terraform Registry. Vous pouvez également utiliser Terraform IBM Modules(TIM) pour créer une nouvelle instance de base de données à partir d'une instance de sauvegarde. Pour plus d'informations, voir l'exemple de restauration à partir d'une sauvegarde.