Présentation de la mise à niveau de version majeure de la base de données sur place

Ce document décrit les mises à niveau de version majeure sur place de la base de données AlloyDB pour PostgreSQL, qui vous permettent de mettre à niveau une base de données vers une version plus récente sans migrer les données ni remplacer l'instance existante.

La communauté PostgreSQL publie régulièrement de nouvelles versions majeures contenant de nouvelles fonctionnalités, des améliorations de performances et des améliorations de sécurité. Une fois que PostgreSQL a publié une nouvelle version majeure, AlloyDB ajoute la prise en charge de la version compatible. Pour maintenir votre base de données à jour, vous pouvez mettre à niveau votre cluster AlloyDB vers une version majeure supérieure. Vous pouvez mettre à niveau votre cluster à l'aide de cette fonctionnalité de mise à niveau sur place ou en migrant vos données vers un nouveau cluster AlloyDB.

Pour en savoir plus, consultez la page Règles concernant les versions de bases de données.

Les mises à niveau de version majeure sur place constituent un moyen efficace de mettre à niveau la version majeure de votre cluster pour les raisons suivantes:

  • AlloyDB conserve les détails du cluster et de l'instance, ainsi que les paramètres de la base de données, tels que le nom de l'instance, l'adresse IP et les indicateurs de base de données, après la mise à niveau.
  • Vous n'avez pas besoin de modifier les chaînes de connexion de l'application.
  • Toutes les instances de cluster (pool principal et de lecture) sont mises à niveau dans le cadre de la même opération.

Workflow de mise à niveau de version majeure sur place

Lorsque vous lancez une mise à niveau sur votre cluster, AlloyDB effectue les actions suivantes:

  1. Exécute des vérifications préalables à la mise à niveau pour détecter les incompatibilités pouvant affecter la mise à niveau.
  2. Prépare la mise à niveau de version majeure, ce qui inclut la création d'un clone interne du cluster.
  3. Rend l'instance principale indisponible. Le temps de pause commence. Les lectures peuvent toujours être effectuées via des pools de lecture.
  4. Lance une sauvegarde préalable à la mise à niveau.
  5. Met à niveau l'instance principale.
  6. Rend les instances de pool de lecture indisponibles.
  7. Rend l'instance principale disponible. Le temps de pause se termine.
  8. Lance une sauvegarde après la mise à niveau.
  9. Met à niveau les instances de pool de lecture.

Une fois les vérifications préalables à la mise à niveau terminées, votre cluster est cloné dans un cluster interne du même projet. La sauvegarde et la restauration nécessaires pour cloner le cluster peuvent prendre un certain temps, en fonction de la taille de la base de données. Voici des exemples de tailles de base de données et de durées de sauvegarde et de restauration correspondantes:

  • Le clonage de votre cluster prend environ 30 minutes pour 1 To.
  • Le clonage de votre cluster prend environ deux heures pour 10 To.

Pendant l'opération de clonage, vous pouvez continuer à utiliser votre cluster d'origine. Une fois l'opération de clonage terminée, le processus de mise à niveau commence. L'instance principale est indisponible pour les lectures et les écritures jusqu'à ce qu'elle soit mise à niveau. Le temps d'arrêt prévu est généralement de 20 à 60 minutes, et dépend principalement du schéma de votre base de données et du nombre d'objets.

Si la mise à niveau de la version majeure échoue à n'importe quelle étape avant la mise à niveau de l'instance principale, AlloyDB annule automatiquement toutes les modifications.

Une fois l'instance principale mise à niveau, la version du cluster est mise à niveau vers la version cible, et aucun rollback n'est déclenché en cas d'échec après ce point. Par exemple, AlloyDB ne rétablit pas le cluster si une ou plusieurs mises à niveau d'instances de pool de lecture échouent. Dans ce cas, contactez l'assistance Google Cloud CLI.

Pour en savoir plus, consultez Mettre à niveau la version majeure d'une base de données sur place.

État de mise à niveau

Vous pouvez surveiller l'état d'une mise à niveau de version majeure de la base de données sur place pendant son exécution.

Le processus de mise à niveau comprend les étapes suivantes:

  • ALLOYDB_PRECHECK
  • PG_UPGRADE_CHECK
  • PREPARE_FOR_UPGRADE
  • PRIMARY_INSTANCE_UPGRADE
  • READ_POOL_INSTANCES_UPGRADE
  • ROLLBACK(uniquement en cas d'échec avant la mise à niveau du pool de lecture)
  • CLEANUP

Les états possibles de ces étapes sont les suivants:

  • NOT_STARTED
  • IN_PROGRESS
  • SUCCESS
  • FAILED
  • CANCEL_IN_PROGRESS
  • CANCELLED

Annulation de la mise à niveau

Vous pouvez annuler l'opération de mise à niveau jusqu'à un certain point pendant la mise à niveau de l'instance principale. Passé ce point, vous ne pouvez plus annuler la mise à niveau.

Dans la console Google Cloud, l'opération ne peut pas être annulée si le bouton Annuler la mise à niveau est grisé. À l'aide de Google Cloud CLI ou de l'API REST, vous pouvez déterminer si vous pouvez annuler la mise à niveau en vérifiant upgradeClusterStatus dans l'état de la mise à niveau:

  • Si cancellable correspond à true, vous pouvez annuler la mise à niveau.
  • Si cancellable est false ou est manquant dans l'état, vous ne pouvez pas annuler la mise à niveau.

Sauvegardes automatiques avant et après la mise à niveau

Lorsque vous effectuez une mise à niveau de version majeure, AlloyDB crée automatiquement les sauvegardes continues suivantes, où XX est la version majeure source et YY la version majeure cible.

  • La sauvegarde préalable à la mise à niveau est créée immédiatement avant le début de la mise à niveau. Cette sauvegarde est nommée au format pre-upgrade-bkp-pgXX-pgYY-<uuid>. Vous pouvez utiliser cette sauvegarde pour restaurer l'état antérieur à la mise à niveau. Notez que la restauration n'est pas une opération in situ et qu'elle crée un nouveau cluster.
  • La sauvegarde post-mise à niveau est créée après la mise à niveau de l'instance principale. Cette sauvegarde est nommée au format post-upgrade-bkp-pgXX-pgYY-<uuid>.

Une sauvegarde continue est incrémentielle, ce qui signifie qu'elle ne stocke que les données qui ont changé par rapport à la sauvegarde continue précédente. Cette approche réduit la taille et le coût (en ressources) de la sauvegarde, et accélère le processus de création de la sauvegarde. Pour en savoir plus, consultez la section Présentation de la sauvegarde et de la récupération de données.

Lorsque vous affichez la liste de vos sauvegardes, les sauvegardes de mise à niveau sont répertoriées avec le type CONTINUOUS. Pour en savoir plus, consultez la section Afficher la liste des sauvegardes.

Pour effectuer une récupération à un moment précis (PITR), une sauvegarde d'une version doit être disponible. La récupération n'est pas disponible sur le cluster mis à niveau tant que la sauvegarde post-mise à niveau ou une autre sauvegarde lancée après la mise à niveau de l'instance principale n'est pas terminée.

Étape suivante