Ce document décrit les mises à niveau sur place des versions majeures de la base de données AlloyDB pour PostgreSQL. Elles 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 en utilisant 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 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 (principales et de pool de lecture) sont mises à niveau au cours 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 :
- Exécute des vérifications préalables à la mise à niveau pour identifier les incompatibilités qui peuvent avoir un impact sur la mise à niveau.
- Prépare la mise à niveau de la version majeure, qui inclut la création d'un clone interne du cluster.
- Rend l'instance principale indisponible. Le temps de pause commence. Les lectures peuvent toujours être effectuées via des pools de lecture.
- Lance une sauvegarde préalable à la mise à niveau.
- Mise à niveau de l'instance principale.
- Rend les instances de pool de lecture indisponibles.
- Rend l'instance principale disponible. Le temps de pause se termine.
- Lance une sauvegarde post-mise à niveau.
- Mise à niveau des instances de pool de lecture.
Une fois les vérifications avant mise à niveau effectuées, 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 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 minutes à une heure. Il dépend principalement du schéma de votre 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 la version majeure échoue à une étape quelconque 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 n'effectue pas de rollback du cluster si la mise à niveau d'une ou de plusieurs instances de pool de lecture échoue. 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 migration (sans temps d'arrêt) | Temps d'arrêt principal | Temps d'arrêt du pool de lecture | Durée totale |
|---|---|---|---|---|
| 100 Go | Environ 15 minutes | Environ 20 minutes | Environ 20 minutes | ~1 heure |
| 1 To | Environ 30 minutes | Environ 20 minutes | Environ 20 minutes | Environ 1 heure et 15 minutes |
| 4 To | ~1 heure | Environ 20 minutes | Environ 20 minutes | ~1 heure 45 minutes |
| 16 To | environ 3 heures | Environ 20 minutes | Environ 20 minutes | environ 3 heures 45 minutes |
| 32 To | environ 5 heures 30 minutes | Environ 20 minutes | Environ 20 minutes | Environ 6 heures 15 minutes |
| 64 To | ~11 heures | Environ 20 minutes | Environ 20 minutes | ~12 heures |
| 128 To | ~21 heures 30 minutes | Environ 20 minutes | Environ 20 minutes | Environ 22 heures et 15 minutes |
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 opération de mise à niveau de version majeure de base de données sur place pendant qu'elle est en cours.
Le processus de migration comprend les étapes suivantes :
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(uniquement en cas d'échec avant la mise à niveau du pool de lecture)CLEANUP
Voici les états possibles de ces étapes :
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Annulation de la mise à niveau
Vous pouvez annuler l'opération de mise à niveau jusqu'à un certain point lors de la mise à niveau de l'instance principale. Une fois ce point dépassé, 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
cancellablecorrespond àtrue, vous pouvez annuler la mise à niveau. - Si
cancellableest défini surfalseou 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 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 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 été modifiées 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 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 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.