Appliquer un patch

Oracle

# 1) Shut down the database, apply the binary patch with OPatch:
$ $ORACLE_HOME/OPatch/opatch apply
# 2) Open the database and load the SQL layer changes:
$ $ORACLE_HOME/OPatch/datapatch -verbose

opatch apply met à jour les binaires de l'Oracle Home ; datapatch applique ensuite les modifications du dictionnaire/SQL sur la base ouverte et les enregistre dans dba_registry_sqlpatch. Sur RAC, les patchs installables en rolling peuvent être appliqués nœud par nœud.

PostgreSQL

# Minor version patch = replace binaries + restart (no dump needed):
$ sudo systemctl stop postgresql-16
$ sudo dnf update postgresql16-server   # or apt upgrade
$ sudo systemctl start postgresql-16

Les patchs mineurs d'une même série majeure (16.3 -> 16.4) ne modifient pas le format des données : mettre à jour le paquet et redémarrer le service suffit ; ni pg_upgrade ni dump/restore n'est nécessaire.

MySQL

# Minor/patch update: update the package and restart the service
$ sudo systemctl stop mysqld
$ sudo dnf update mysql-community-server   # or apt upgrade
$ sudo systemctl start mysqld

MySQL 8.0+ met à niveau le dictionnaire de données automatiquement au démarrage ; aucune étape mysql_upgrade séparée n'est nécessaire. En réplication, patchez d'abord les réplicas, puis la source.

SQL Server

-- Run the Cumulative Update (CU) or GDR security update installer:
-- SQLServer2022-KB<no>-x64.exe /quiet /IAcceptSQLServerLicenseTerms
--   /Action=Patch /InstanceName=MSSQLSERVER
-- The instance then restarts; verify the version with SERVERPROPERTY.

Les mises à jour CU (Cumulative Update) et GDR (General Distribution Release) s'appliquent avec le programme d'installation setup et nécessitent un redémarrage de l'instance. Dans un groupe Always On, patchez d'abord les réplicas secondaires et basculez pour minimiser l'interruption.

MongoDB

// 'Rolling' patch on a replica set: one node at a time
// 1) Stop mongod, replace the binary with the new patch version, restart
// 2) Secondaries first, the primary last
// Step down the primary manually before patching it:
rs.stepDown()

Les mises à jour de patch d'une même version majeure (7.0.x) se font en rolling, les secondaires d'abord. Le primaire est patché après passation avec rs.stepDown(), ce qui minimise l'interruption des écritures.

Redis

# Patch via rolling restart in a replicated deployment:
# 1) Stop one replica node, install the new version, start it, wait for sync
# 2) Repeat for the remaining replicas
# 3) Finally, fail over the master and patch it:
redis-cli -h <replica> REPLICAOF NO ONE   # promote the upgraded replica

Les versions de patch (7.2.x) s'appliquent par redémarrage rolling : les réplicas sont mis à niveau et resynchronisés d'abord, puis un réplica est promu master et l'ancien master est patché. Sentinel/Cluster automatise le failover.

Elasticsearch

# Rolling upgrade (patch within the same major version), per node:
PUT _cluster/settings
{ "persistent": { "cluster.routing.allocation.enable": "primaries" } }
# -> stop the node, update the package, start the node, then:
PUT _cluster/settings
{ "persistent": { "cluster.routing.allocation.enable": null } }

Les mises à niveau de patch/mineures se font en rolling upgrade : l'allocation des shards est restreinte, les nœuds sont mis à jour et redémarrés un par un, puis l'allocation est réactivée et l'on attend que le cluster repasse en green.