Montée de version / retour arrière d'un patch

Symptôme

Problèmes après une montée de version/un patch : régression de performance, incompatibilité applicative ou base qui ne s'ouvre pas.

1. Arrêtez-vous d'abord : avez-vous un plan de repli ?

Si vous n'avez pas pris une sauvegarde complète + (si possible) un snapshot de stockage AVANT la montée de version en production, la voie la plus sûre est de corriger vers l'avant. Dans la plupart des bases, revenir en arrière signifie restaurer depuis une sauvegarde. Cette étape aurait dû être planifiée AVANT la montée de version.

2. Classez le problème

S'agit-il d'une régression de plan de l'optimiseur (requêtes ralenties), d'une incompatibilité application/driver, ou d'un échec d'ouverture/d'une corruption ? La solution varie fortement en conséquence.

3. Voie de retour arrière par base

Oracle : retour arrière du patch avec datapatch, ou Flashback Database (si vous avez créé un guaranteed restore point). PostgreSQL : retour arrière après pg_upgrade = anciens binaires + sauvegarde de l'ancien répertoire de données. MySQL : le DOWNGRADE en place n'est généralement PAS PRIS EN CHARGE ; restaurez depuis une sauvegarde. SQL Server : aucun downgrade possible ; restaurez la sauvegarde d'avant la montée de version. Dans tous les cas : le snapshot/la sauvegarde est votre assurance.

4. S'il s'agit d'une régression de plan : corrigez sans retour arrière

Il n'est généralement pas nécessaire de revenir sur toute la version ; seuls les plans ont changé.

Oracle

ALTER SYSTEM SET optimizer_features_enable='19.1.0';  -- pin to the old behavior
-- or lock in the good plan with a SQL Plan Baseline

PostgreSQL

ANALYZE;  -- fresh statistics first
-- if needed, temporarily: steer the plan with settings such as SET enable_nestloop=off;

5. Définitif : la prochaine fois

Testez d'abord la montée de version en préproduction avec une charge réelle, appliquez des montées de version canary/rolling, prenez un guaranteed restore point / snapshot et documentez la procédure de repli.