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. Vérifiez que votre application de test parvient à se connecter correctement à l'environnement de préproduction et qu'elle fonctionne comme prévu. Effectuer tous les tests de performance et d'exploitation nécessaires sur l'environnement de préproduction.

3. Mettez à jour la version principale de votre déploiement de test en cliquant sur le bouton « Mettre à jour la version principale » 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 à jour afin de pouvoir utiliser le paramètre d'expiration des mises à jour pour les faire coïncider avec 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 vous êtes assuré que votre application fonctionne correctement avec la nouvelle version de la base de données, vous pouvez 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 principale » et suivez les étapes indiquées.

   Une fois le processus de mise à niveau sur place lancé, il ne peut être ni interrompu ni annulé. Ainsi, dans l'éventualité peu probable 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 majeure sur place avec sauvegarde », la sauvegarde ainsi créée pourra être utilisée pour restaurer les données dans un nouveau déploiement.

L'option « expiration for starting upgrade » vous permet de définir un délai d'expiration au-delà duquel la tâche de mise à niveau doit avoir démarré, faute de quoi elle sera automatiquement annulée. De plus, testez au préalable la mise à niveau dans l'environnement de préproduction afin de vous assurer qu'elle s'effectue bien dans le délai souhaité. Si, par exemple, vous souhaitez effectuer la mise à niveau en moins d'une heure, et que vous l'avez testée et savez qu'elle dure 30 minutes, votre tâche de mise à niveau doit alors démarrer dans les 30 minutes qui suivent votre confirmation de la mise à niveau. Par conséquent, définissez la durée d'expiration à 30 minutes, afin que, si le processus ne démarre pas dans ce délai, il ne dépasse pas la fenêtre prévue.

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

L'option « expiration for starting upgrade » vous permet de définir un délai d'expiration au-delà duquel la tâche de mise à niveau doit avoir démarré, faute de quoi elle sera automatiquement annulée. De plus, testez au préalable la mise à niveau dans l'environnement de préproduction afin de vous assurer qu'elle s'effectue bien dans le délai souhaité. Si, par exemple, vous souhaitez effectuer la mise à niveau en moins d'une heure, et que vous l'avez testée et savez qu'elle dure 30 minutes, votre tâche de mise à niveau doit alors démarrer dans les 30 minutes qui suivent votre confirmation de la mise à niveau. Par conséquent, définissez la date d'expiration à un horodatage correspondant à 30 minutes à compter de maintenant, de sorte que si le processus ne démarre pas dans ce délai, il ne dépasse pas la fenêtre que vous avez définie. La durée de validité doit être comprise entre 5 minutes (par défaut) et 24 heures à compter de maintenant. Pour plus d'informations, consultez 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 exécuter la commande « upgrade » avec les paramètres requis :

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

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

ibmcloud cdb deployment-version-upgrade --help

L'option « expiration for starting upgrade » vous permet de définir un délai d'expiration au-delà duquel la tâche de mise à niveau doit avoir démarré, faute de quoi elle sera automatiquement annulée. De plus, testez au préalable la mise à niveau dans l'environnement de préproduction afin de vous assurer qu'elle s'effectue bien dans le délai souhaité. Si, par exemple, vous souhaitez effectuer la mise à niveau en moins d'une heure, et que vous l'avez testée et savez qu'elle dure 30 minutes, votre tâche de mise à niveau doit alors démarrer dans les 30 minutes qui suivent votre confirmation de la mise à niveau. Par conséquent, définissez la durée d'expiration à 30 minutes, afin que, si le processus ne démarre pas dans ce délai, il ne dépasse pas la fenêtre prévue. La durée de validité doit être comprise entre 5 minutes (par défaut) et 24 heures à compter de maintenant. Il existe deux façons de configurer la durée de validité via l'interface 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 la mise à niveau, il suffit d'ajouter ou de modifier la valeur « version » dans votre configuration. Il existe également un indicateur booléen facultatif, version_upgrade_skip_backup``, que vous pouvez activer pour ignorer la sauvegarde.

Il n'est pas recommandé de ne pas effectuer de sauvegarde. Ne pas effectuer de sauvegarde avant une mise à jour de version est dangereux et peut entraîner une perte de données si la mise à jour échoue à n'importe quelle étape : il n'y aura alors aucune sauvegarde récente à partir de laquelle effectuer une restauration.

La base de données sera mise en mode « lecture seule » pendant la mise à niveau. Il est vivement recommandé de procéder à des tests avant la mise à niveau.

La mise à niveau peut prendre plus de temps que le délai d'attente par défaut. Il est possible de définir un délai d'expiration plus long à l'aide de l'attribut « timeouts ».

Terraform utilise des délais d'expiration plutôt que des horodatages d'expiration. Par conséquent, augmentez votre délai d'expiration, car la valeur de mise à jour de ce délai sert de date d'expiration. Par exemple, si vous définissez un délai d'expiration de 20 minutes, celui-ci sera fixé à 20 minutes; si la mise à jour ne démarre pas dans ce délai, elle expirera et ne pourra pas être lancée. Notez que la durée maximale d'expiration est de 24 heures; ainsi, même si vous définissez un délai d'expiration de 36 heures, la mise à niveau expirera si elle n'a pas démarré dans les 24 premières heures.

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

Mise à niveau via l'interface utilisateur

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

Vous pouvez effectuer la mise à niveau vers une nouvelle version en restaurant une sauvegarde à partir de la page « Sauvegardes et restauration » 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 pourrez 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 suivre 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. Définissez votre backup_id. Pour plus d'informations, voir backup_id.
2. Définissez votre version dans l'attribut « 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, consultez le registre Terraform de l' Cloud Databases.