Patch einspielen

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 aktualisiert die Binärdateien im Oracle Home; datapatch spielt anschließend die Dictionary-/SQL-Änderungen in der geöffneten Datenbank ein und vermerkt sie in dba_registry_sqlpatch. Bei RAC lassen sich rolling-fähige Patches Knoten für Knoten einspielen.

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 innerhalb derselben Major-Versionsreihe (16.3 -> 16.4) ändern das Datenformat nicht: Paket aktualisieren und Dienst neu starten genügt; pg_upgrade oder Dump/Restore ist nicht nötig.

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+ aktualisiert das Data Dictionary beim Start automatisch; ein separater Schritt mysql_upgrade ist nicht nötig. Bei Replikation zuerst die Replicas patchen, dann die 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) und GDR-Updates (General Distribution Release) werden mit dem Setup-Installer eingespielt und erfordern einen Neustart der Instanz. In einer Always On-Gruppe zuerst die sekundären Replicas patchen und per Failover umschalten, um die Ausfallzeit zu minimieren.

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 innerhalb derselben Major-Version (7.0.x) erfolgen rollierend, zuerst die Secondaries. Der Primary wird gepatcht, nachdem er mit rs.stepDown() abgegeben wurde; so bleibt die Schreibunterbrechung minimal.

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-Versionen (7.2.x) werden per Rolling Restart eingespielt: Zuerst werden die Replicas aktualisiert und neu synchronisiert, dann wird eine Replica zum Master befördert und der alte Master gepatcht. Sentinel/Cluster automatisiert den 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 erfolgen per Rolling Upgrade: Die Shard-Allokation wird eingeschränkt, die Knoten werden einzeln aktualisiert und neu gestartet, dann wird die Allokation wieder aktiviert und gewartet, bis der Cluster wieder green ist.