Politique de version
Lorsque vous provisionnez une instance Cloud Databases, vous pouvez choisir parmi les versions actuellement disponibles sur IBM Cloud®. Trouvez les dernières versions à partir des pages du catalogue, du plug-in CLI Cloud Databases Ou de l'Cloud Databases API.
Versions majeures définies
| Service | Cloud Databases schéma de gestion des versions | Prochaine version de fin de vie connue et date | Version majeure préférée | Procédure de fin de vie (EOF) [1] |
|---|---|---|---|---|
| Databases for MongoDB | Cloud Databases les versions majeures sont les deux premiers chiffres du numéro de version de major.x.patch. Dans les cas où x est pair, il s'agit d'une édition stable adaptée à la production. Les versions x paires sont les seules disponibles sur Cloud Databases. |
v7 25 août 2027 | v8.0 | Mise à niveau automatique en place vers la version majeure suivante, la mise à niveau en place à l'initiative du client vers la version majeure suivante est prise en charge pour les plans Standard et Enterprise |
| Databases for Elasticsearch | Cloud Databases les versions majeures sont les deux premiers chiffres d'un numéro de version de maintenance release.version. |
v8.7, v8.10, v8.12, v8.15, 30 juin 2026 | v8.19 | Mise à niveau automatique en place vers la version majeure suivante, la mise à niveau en place à l'initiative du client vers la version 8.19 est prise en charge |
| Databases for Redis | Cloud Databases les versions majeures sont le premier chiffre du numéro de version major.minor.patch. |
v7.2 19 août 2026 | v8.2 | Mise à niveau automatique vers la dernière version majeure disponible |
| Databases for PostgreSQL | Cloud Databases la version majeure est définie par le premier chiffre du numéro de version. | v14, 21 octobre 2026 | v18 | Mise à niveau automatique sur place vers la version majeure suivante, mise à niveau sur place initiée par le client depuis v14 vers v15 prise en charge |
| Databases for MySQL | Cloud Databases les versions majeures sont les deux premiers chiffres du numéro de version de major.x.patch. |
v8.0 29 juillet 2026 | v8.4 | Sauvegarde effectuée et accès supprimé |
| Messages for RabbitMQ | Cloud Databases Les versions majeures sont les deux premiers chiffres du numéro de version de major.x.patch. |
v3.13, 20 mai 2026, v4.1, 12 août 2026 |
v4.2 | Sauvegarde effectuée et accès supprimé jusqu'à v3.13, Mise à niveau automatique en place vers la version majeure suivante à partir de v4.x |
Procédure de fin de vie (EOF)
La gestion de la fin de vie dépend du service et du modèle de version. Les approches suivantes s'appliquent :
-
Suppression de l'accès après la date de fin de vie
Pour MySQL v8.0 et RabbitMQ v3.13, après la date de fin de vie, l'accès aux déploiements est supprimé. Les sauvegardes seront conservées conformément à la politique, mais les instances ne sont plus accessibles.
-
Mise à niveau forcée vers la prochaine version prise en charge :
Pour toutes les autres versions de bases de données, après la date de fin de vie, tous les déploiements actifs fonctionnant avec une version obsolète sont mis à niveau de force vers la prochaine version prise en charge. Par exemple, la version 14 de PostgreSQL est automatiquement mise à jour vers la version 15.
Cette approche n'est pas recommandée pour les raisons suivantes :
- Nous ne fournissons aucun accord de niveau de service (SLA) pour ce type de mise à niveau forcée.
- Une perte de données pourrait se produire.
- Les applications peuvent connaître des temps d'arrêt.
- Les applications peuvent cesser de fonctionner si elles présentent des incompatibilités avec la nouvelle version de la base de données.
- Vous ne pouvez pas contrôler le moment où la mise à niveau forcée de vos instances aura lieu.
- Il n'existe aucun processus de restauration pour les mises à niveau forcées.
- Nous recommandons vivement de mettre à niveau Cloud Databases les instances vers la dernière version disponible dès que possible après sa mise à disposition.
Informations supplémentaires sur les méthodes de mise à niveau pour chaque type de base de données :
- Mise à niveau des Databases for MongoDB versions majeures
- Mise à niveau des Databases for Elasticsearch versions majeures
- Mise à niveau des Databases for Redis versions majeures
- Mise à niveau des Databases for PostgreSQL versions majeures
- Mise à niveau des Databases for MySQL versions majeures
- Mise à jour des versions majeures de Messages for RabbitMQ
S'abonner aux mises à jour des versions
La disponibilité d'une nouvelle version majeure de la base de données dans IBM Cloud est communiquée via les notes de mise à jour et la page IBM Cloud d'état. Configurez les notifications IBM Cloud d'état, comme décrit dans la documentation, afin de recevoir une notification lorsque de nouvelles notes de mise à jour sont publiées.
Procédures de fin de vie des versions majeures
Les dates de fin de vie des principales versions de la base de Cloud Databases données sont déterminées après avoir pris en compte deux facteurs principaux.
- Date à laquelle la communauté open source ou le fournisseur qui fournit la base de données cesse de maintenir cette version.
- Meilleures pratiques de l'industrie en matière de sécurité qui interdisent généralement l'utilisation de logiciels qui ne sont plus maintenus, car les bogues et les failles de sécurité sont peu susceptibles d'être corrigés dans une telle version.
Étant donné que la fréquence des versions majeures et les politiques de cycle de vie de maintenance associées à chaque base de données proposée dans le IBM Cloud portefeuille sont différentes, le délai entre la mise à disposition générale d'une version majeure dans IBM Cloud et la fin de vie de cette version dans IBM Cloud varie selon les bases de données et au fil du temps.
Lorsque la date IBM Cloud de fin de vie d'une version majeure est définie, une notification est fournie via la page des IBM Cloud annonces de statut. Entre la notification et la date de fin de vie d'une version majeure, il est fortement recommandé de procéder à la mise à niveau vers la version majeure la plus récente.
À la date de fin de vie, toutes les instances de base de données qui restent sur la version majeure obsolète sont traitées comme décrit dans la colonne « Procédure de fin de vie » du tableau 1. Si la procédure de fin de vie inclut la sauvegarde de l'instance, la sauvegarde peut être restaurée dans une nouvelle version prise en charge pendant 30 jours, après quoi elle est supprimée.
Les demandes visant à réactiver les formations désactivées des versions en fin de vie ne sont pas acceptées.
Les procédures de fin de vie et les actions connexes s'étendent sur plusieurs jours après la date de fin de vie. Nous nous efforçons, sans toutefois pouvoir le garantir, d'effectuer ces opérations en dehors des heures ouvrables dans la région. Si vous souhaitez avoir plus de contrôle sur le processus de mise à niveau de votre instance, nous vous recommandons d'effectuer la mise à niveau avant la date de fin de vie de votre version.
Versions mineures
IBM Cloud s'engage à fournir des versions sécurisées et actualisées de ses services. Au fur et à mesure que les mises à jour sont publiées par les responsables du projet, elles sont testées, évaluées et diffusées sur les instances Cloud Databases. Les mises à jour des versions mineures et des correctifs de votre instance sont gérées automatiquement et ne sont pas configurables par l'utilisateur.
Notification de fin de vie d'une version majeure
La possibilité d'informer à l'avance les utilisateurs de la base de données IBM Cloud de la date de fin de vie des principales versions de la base de données est limitée par l'information fournie à l'avance par la communauté open-source ou le fournisseur associé concernant la date de fin de maintenance d'une version.
Pour les bases de données dont la communauté open source ou le fournisseur annonce à l'avance la date de fin de maintenance des versions principales, plusieurs notifications seront envoyées afin d'informer les utilisateurs des dates de fin de vie à venir. Vous pouvez généralement vous attendre à
- Une annonce sur la page d'état du nuage, par exemple : Avis de fin d'assistance.
- Une annonce dans les notes de mise à jour de votre service, par exemple : IBM Cloud® Databases for PostgreSQL version 12 fin de vie le 22 janvier 2025
- Une notification par e-mail si les notifications du compte ont été correctement configurées pour inclure les adresses e-mail. Cet e-mail contient un lien vers la page de gestion des notifications. Assurez-vous que ces annonces ne sont pas bloquées par le filtre anti-spam de votre service de messagerie. Pour plus d'informations, consultez Configuration des listes de distribution pour IBM Cloud les notifications et{:external} Configuration des préférences de messagerie pour les notifications.
Assurez-vous que votre compte est activé pour recevoir des notifications et des annonces. Vous devez activer la réception des mises à jour de la plateforme et des ressources.
- Activez l'option « Majeur et mineur » sous l 'onglet Plateforme > Annonces > Majeur et mineur.
- Activez les mises à jour de service sous l 'onglet Ressources > Activité des ressources > Mises à jour de service.
Les clients sont également encouragés à vérifier de manière proactive l'état de la version de la base de données de toutes les instances IBM Cloud de base de données par programmation, via l'interface CLI ou l'API. Pour plus d'informations, voir Méthodes programmatiques de vérification de l'état des versions.
Informations spécifiques à la base de données
IBM Cloud Databases for Elasticsearch
Elastic publie ici la politique de maintenance pour les versions Elasticsearch. Conformément à cette politique, trois versions sont maintenues par Elastic à tout moment : la version la plus récente ( X.Y ), la version précédente ( X.Y-1 ) et la dernière version de la version majeure précédente ( X-1.last, 8.19 par exemple). Lorsqu'une nouvelle version est publiée ( X.Y+1 ), la maintenance de la version X.Y-1 prend fin immédiatement. Les clients peuvent choisir entre deux approches pour mettre à jour les versions de Elasticsearch qu'ils utilisent. La première approche consiste à toujours passer à la dernière version de Elasticsearch peu après sa sortie, en faisant en sorte que la fréquence des mises à niveau soit égale à la fréquence des versions d'Elastic. La deuxième approche consiste à rester sur la dernière version de la version majeure précédente tant qu'elle continue d'être maintenue par Elastic afin de réduire la fréquence des mises à niveau de version requises pendant cette période. Une notification IBM Cloud sera envoyée peu après chaque version majeure de Elasticsearch, indiquant que la maintenance d'Elastic a pris fin pour une version majeure supplémentaire et que cette version majeure atteindra sa fin de vie dans IBM Cloud Databases dans 5 semaines.
Méthodes programmatiques pour vérifier l'état des versions
Sur le CLI the following Cloud Databases deployables-show command shows deployable service types, specifically the available
versions and their preferred or stable status.
ibmcloud cdb deployables-show [--stable] [--preferred] [--json]
Vérifiez l'état d'une version majeure en examinant la sortie de la commande deployable, en particulier Status et Preferred. L'exemple suivant montre que la version 7 est la version Preferred et que
la version 6 Status est deprecated.
Service Type: mongodb
Version Status Preferred
7 stable true
6 deprecated false
Sur l'Cloud Databases Le point de terminaison deployables renvoie tous les services pouvant être
déployés. Utilisez le paramètre version pour obtenir le numéro de version.
GET /v5/ibm/deployables
Versions majeures et Terraform
Notez que vous ne pouvez pas actuellement passer à une nouvelle version majeure à l'aide de Terraform. La modification du numéro de version d'un script Terraform peut entraîner la destruction de vos données. La méthode recommandée pour la mise à niveau de la version consiste à restaurer une sauvegarde dans un nouveau déploiement avec la dernière version. Pour plus d'informations, voir Restauration d'une sauvegarde.
-
Cette colonne décrit les actions qui seront entreprises par l'équipe IBM Cloud® sur les instances de base de données qui n'ont pas été mises à niveau vers une nouvelle version avant la date de la version EoL. Cette approche n'est pas recommandée. Pour plus d'informations, voir Procédure de fin de vie. ↩︎