DBAtlas · Atlas de operaciones de bases de datos

Aplicar un parche

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 actualiza los binarios del Oracle Home; después datapatch aplica los cambios de diccionario/SQL en la base de datos abierta y los registra en dba_registry_sqlpatch. En RAC, los parches rolling-installable se pueden aplicar nodo por nodo.

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

Los parches menores dentro de la misma serie de versión mayor (16.3 -> 16.4) no cambian el formato de datos: basta con actualizar el paquete y reiniciar el servicio; no se necesita pg_upgrade ni dump/restore.

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+ actualiza el diccionario de datos automáticamente al arrancar; no se necesita un paso mysql_upgrade aparte. En replicación, aplique el parche primero a las réplicas y luego al origen.

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.

Las actualizaciones CU (Cumulative Update) y GDR (General Distribution Release) se aplican con el instalador setup y requieren reiniciar la instancia. En un grupo Always On, aplique el parche primero a las réplicas secundarias y haga failover para minimizar el tiempo de inactividad.

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

Las actualizaciones de parche dentro de la misma versión mayor (7.0.x) se hacen de forma rolling, primero los secondaries. El primary se actualiza tras cederle el rol con rs.stepDown(), lo que minimiza la indisponibilidad de escritura.

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

Las versiones de parche (7.2.x) se aplican con un rolling restart: primero se actualizan y resincronizan las réplicas, luego se promueve una réplica a master y se actualiza el antiguo master. Sentinel/Cluster automatiza el 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 } }

Las actualizaciones de parche/menores se hacen con un rolling upgrade: se restringe la asignación de shards, los nodos se actualizan y reinician de uno en uno, luego se vuelve a habilitar la asignación y se espera a que el clúster vuelva a green.

Abrir en DBAtlas →