Assistant de mise à niveau de version
Correctif ou majeure, sur place ou par migration ? Planifiez la mise à niveau étape par étape ; chaque branche couvre les vérifications préalables, la méthode et les travaux post-mise à niveau. Répétez-la ici avant de toucher à la production.
Quel type de montée de version effectuez-vous ?
Une version patch/mineure (au sein de la même version majeure, par ex. 16.2 -> 16.4, ou un CU SQL Server) présente un faible risque et se fait généralement sur place. Une version majeure (par ex. 15 -> 16) peut impliquer des changements de format des données et exige une planification plus soignée.
SELECT * FROM v$version;
SELECT patch_id, action, status FROM dba_registry_sqlpatch ORDER BY action_time DESC;- Version mineure / patch (même version majeure, CU)
- Version majeure (la version majeure change)
- Je ne connais pas la différence ; expliquez-moi
Correctif ou majeure ?
Correctif : la version majeure reste la même (16.2 -> 16.4) ; le format des datafiles ne change pas, généralement remplacement des binaires + redémarrage. Majeure : la version majeure change (15 -> 16) ; le catalogue/format peut changer, pg_upgrade / AutoUpgrade / dump-restore est nécessaire, et la compatibilité de l'application doit être testée.
- C'est un correctif (même version majeure)
- C'est une majeure (la version majeure change)
Votre sauvegarde et votre plan de retour arrière sont-ils prêts ?
Même si un correctif présente peu de risque, la règle d'or de toute mise à niveau est : d'abord une sauvegarde complète (et un snapshot si possible). Il vous faut un point de retour si quelque chose tourne mal.
- Oui, sauvegarde + retour arrière prêts
- Non, pas encore
D'abord la sauvegarde + le plan de retour arrière
Mettez en place le filet de sécurité avant de commencer la mise à niveau.
Appliquer le correctif
Un correctif au sein de la même version majeure. L'appliquer en rolling sur un cluster (en commençant par les réplicas) réduit l'interruption.
Méthode de mise à niveau majeure
Deux voies principales : (1) Sur place : conversion sur le serveur existant (pg_upgrade, Oracle AutoUpgrade/DBUA, MySQL in-place). Rapide mais retour arrière difficile. (2) Par migration : construire un nouveau serveur sur la nouvelle version, y déplacer les données (par dump/restore ou réplication), puis basculer. Plus sûr, avec une interruption minimale.
- Je veux d'abord lancer une vérification de préparation/compatibilité
- Sur place
- Par migration vers un nouveau serveur (interruption minimale)
Vérification de compatibilité / de préparation
Avant la mise à niveau, recueillez les avertissements de la version cible : fonctionnalités supprimées (dépréciées), objets invalides, niveau de compatibilité.
-- AutoUpgrade analyze mode: java -jar autoupgrade.jar -config cfg -mode analyze- Sortie propre, continuer
- Il y a des avertissements/incompatibilités
Corrigez d'abord les avertissements
Résolvez chaque avertissement du rapport AVANT la mise à niveau ; sinon la mise à niveau peut échouer en cours de route ou l'application peut casser.
Mise à niveau majeure sur place
Conversion sur le serveur existant. Rapide, mais le retour arrière implique généralement une restauration depuis la sauvegarde, un snapshot est donc indispensable.
Mise à niveau par migration (interruption minimale)
Construisez un nouveau serveur sur la nouvelle version, déplacez les données, puis basculez avec un cutover court. La méthode la plus sûre ; l'ancien système reste intact.