Apply a 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 updates the binaries in the Oracle Home; datapatch then applies dictionary/SQL changes on the open database and records them in dba_registry_sqlpatch. On RAC, rolling-installable patches can be applied node by node.

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

Minor patches within the same major version series (16.3 -> 16.4) do not change the data format: updating the package and restarting the service is enough; no pg_upgrade or dump/restore is needed.

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+ upgrades the data dictionary automatically at startup; no separate mysql_upgrade step is needed. In replication, patch the replicas first, then the 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.

CU (Cumulative Update) and GDR (General Distribution Release) updates are applied with the setup installer and require an instance restart. In an Always On group, patch the secondary replicas first and fail over to minimize downtime.

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()

Patch updates within the same major version (7.0.x) are done in a rolling fashion, secondaries first. The primary is patched after handing over with rs.stepDown(), minimizing write downtime.

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

Patch versions (7.2.x) are applied with a rolling restart: replicas are upgraded and resynced first, then a replica is promoted to master and the old master is patched. Sentinel/Cluster automates the 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 } }

Patch/minor upgrades are done with a rolling upgrade: shard allocation is restricted, nodes are updated and restarted one at a time, then allocation is re-enabled and you wait for the cluster to return to green.