Aplicar um 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 atualiza os binários no Oracle Home; em seguida, o datapatch aplica as alterações de dicionário/SQL no banco aberto e as registra em dba_registry_sqlpatch. No RAC, patches rolling-installable podem ser aplicados nó por nó.

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

Patches minor dentro da mesma série major (16.3 -> 16.4) não alteram o formato dos dados: basta atualizar o pacote e reiniciar o serviço; não é necessário pg_upgrade nem 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

O MySQL 8.0+ faz o upgrade do data dictionary automaticamente na inicialização; não é necessária uma etapa separada de mysql_upgrade. Na replicação, aplique o patch primeiro nas réplicas e depois na origem.

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.

As atualizações CU (Cumulative Update) e GDR (General Distribution Release) são aplicadas com o instalador setup e exigem restart da instância. Em um grupo Always On, aplique o patch primeiro nas réplicas secundárias e faça failover para minimizar o 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()

Atualizações de patch dentro da mesma versão major (7.0.x) são feitas de forma rolling, primeiro nos secondaries. O primary recebe o patch depois de transferir o papel com rs.stepDown(), minimizando o downtime de escrita.

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

Versões de patch (7.2.x) são aplicadas com rolling restart: primeiro as réplicas são atualizadas e ressincronizadas, depois uma réplica é promovida a master e o antigo master recebe o patch. O Sentinel/Cluster automatiza o 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 } }

Upgrades de patch/minor são feitos com rolling upgrade: a alocação de shards é restringida, os nós são atualizados e reiniciados um de cada vez, depois a alocação é reabilitada e aguarda-se o cluster voltar a green.