Ce document décrit les mises à niveau de version majeure sur place d'une base de données AlloyDB pour PostgreSQL, qui vous permettent de mettre à niveau une base de données vers une version supérieure 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 qu'une nouvelle version majeure de PostgreSQL est publiée, AlloyDB ajoute la compatibilité avec la version correspondante. 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 les règles de versions de la base 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 options 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 (principale et pool de lecture) sont mises à niveau dans le cadre de la même opération.
En outre, les appartenances à des rôles avec des responsables inexistants (appartenances orphelines) ne sont pas conservées. Si un cluster contient des appartenances orphelines dans le catalogue pg_auth_members, ces appartenances à des rôles sont perdues après la mise à niveau. Pour en savoir plus, consultez
Préparer le cluster pour une mise à niveau de version majeure.
Workflow de mise à niveau de version majeure sur place
Lorsque vous démarrez une mise à niveau sur votre cluster, AlloyDB effectue les actions suivantes :
- Exécute des vérifications préalables à la mise à niveau pour détecter les incompatibilités susceptibles d'avoir un impact sur la mise à niveau.
- Prépare la mise à niveau de version majeure, ce qui inclut la création d'un clone interne du cluster.
- Rend l'instance principale indisponible. Le temps d'arrêt commence. Les lectures peuvent toujours être effectuées via des pools de lecture.
- Lance une sauvegarde préalable à la mise à niveau.
- Met à niveau l'instance principale.
- Rend les instances de pool de lecture indisponibles.
- Rend l'instance principale disponible. Le temps d'arrêt se termine.
- Lance une sauvegarde post-mise à niveau.
- Met à niveau les instances de pool de lecture.
Une fois les vérifications préalables à la mise à niveau réussies, votre cluster est cloné dans un cluster interne du même projet. La sauvegarde et la restauration nécessaires pour cloner le cluster prennent environ 10 minutes par téraoctet de données.
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 démarre. 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 minutes à une heure, et dépend principalement de votre schéma de base de données et du nombre d'objets.
Une fois l'instance principale mise à niveau, les instances de pool de lecture deviennent indisponibles. Les mises à niveau sont tentées simultanément sur toutes les instances de pool de lecture. Le temps d'arrêt devrait durer environ 20 minutes.
Si la mise à niveau de version majeure échoue à une étape quelconque avant la mise à niveau de l'instance principale, AlloyDB restaure automatiquement toutes les modifications.
Une fois l'instance principale mise à niveau, la version du cluster est mise à niveau vers la version cible et aucune restauration n'est déclenchée en cas d'échec après ce point. Par exemple, AlloyDB ne restaure 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.
Le tableau suivant fournit une estimation approximative du temps nécessaire à la mise à niveau pour les clusters de différentes tailles de base de données :
| Taille de la base de données | Avant la mise à niveau (sans temps d'arrêt) | Temps d'arrêt de l'instance principale | Temps d'arrêt du pool de lecture | Durée totale |
|---|---|---|---|---|
| 100 Go | ~15 minutes | ~20 minutes | ~20 minutes | ~1 heure |
| 1 To | ~30 minutes | ~20 minutes | ~20 minutes | ~1 heure 15 minutes |
| 4 To | ~1 heure | ~20 minutes | ~20 minutes | ~1 heure 45 minutes |
| 16 To | ~3 heures | ~20 minutes | ~20 minutes | ~3 heures 45 minutes |
| 32 To | ~5 heures 30 minutes | ~20 minutes | ~20 minutes | ~6 heures 15 minutes |
| 64 To | ~11 heures | ~20 minutes | ~20 minutes | ~12 heures |
| 128 To | ~21 heures 30 minutes | ~20 minutes | ~20 minutes | ~22 heures 15 minutes |
Pour en savoir plus, consultez Mettre à niveau une version majeure sur place d'une base de données.
État de mise à niveau
Vous pouvez surveiller l'état d'une opération de mise à niveau de version majeure sur place d'une base de données pendant son exécution.
Le processus de mise à niveau comprend les étapes suivantes :
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(uniquement en cas d'échec avant les mises à niveau du pool de lecture)CLEANUP
Les états possibles de ces étapes sont les suivants :
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Annulations de mise à niveau
Vous pouvez annuler l'opération de mise à niveau jusqu'à un certain point pendant la mise à niveau de l'instance principale. Une fois ce point dépassé, vous ne pouvez plus annuler la mise à niveau.
Dans la Google Cloud console, 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
cancellableesttrue, vous pouvez annuler la mise à niveau. - Si
cancellableestfalseou est absent de 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 correspond à 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 sur place et qu'elle crée un cluster. - La sauvegarde post-mise à niveau est créée une fois l'instance principale mise à niveau. 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 Présentation de la sauvegarde et de la récupération des 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
Afficher une liste de sauvegardes.
Pour effectuer une récupération à un moment précis, 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.