Close Menu
  • Home
  • Databases
    • Oracle
      • ASM
      • Data Guard
      • RAC
  • Performance
  • Tools
  • Troubleshooting
  • Python
  • Shell Script
Search

Upgrade Percona Server for MongoDB 8.0.23-10 para 8.0.26-11

2026-06-26 MongoDB By Henrique

Clonar Usuário MongoDB Preservando a Senha

2026-06-26 MongoDB By Henrique

ORA-06553: DBCA Falha no catalog.sql com PLS-213

2026-06-25 Oracle By Henrique
YouTube LinkedIn RSS
  • Sobre
  • Contato
  • Legal
    • Aviso Legal
    • Política de Cookies
    • Política de Privacidade
    • Termos de Uso
  • RSS
  • Português
    • Inglês
Execute StepExecute Step
YouTube LinkedIn RSS
  • Home
  • Databases
    • Oracle
      • ASM
      • Data Guard
      • RAC
  • Performance
  • Tools
  • Troubleshooting
  • Python
  • Shell Script
Execute StepExecute Step
Home » Upgrade Percona Server for MongoDB 8.0.23-10 para 8.0.26-11
MongoDB

Upgrade Percona Server for MongoDB 8.0.23-10 para 8.0.26-11

HenriqueBy Henrique2026-06-26Updated:2026-06-298 Mins Read
Share
Facebook Twitter LinkedIn Pinterest Email Telegram WhatsApp

This post is also available in: English (Inglês)

A Percona publicou em 25/06/2026 a versão 8.0.26-11 do Percona Server for MongoDB com recomendação explícita de atualização urgente devido a múltiplas vulnerabilidades de alta severidade.

Este post documenta o upgrade realizado em lab: Replica Set de 3 nós no Oracle Linux 8, sem downtime para a aplicação.

Por que atualizar agora?

A versão 8.0.26-11 corrige 10 CVEs de severidade High e 1 Medium, todas afetando todas as versões 8.0.x anteriores.

CVEs corrigidas

CVESeveridadeImpacto
CVE-2026-11933HighUse-after-free no engine JS server-side ($where, $function) — information disclosure ou crash
CVE-2026-9740HighBSON validator — DoS por input nao autenticado
CVE-2026-9743HighAggregation framework — DoS via cursor malicioso
CVE-2026-9753High$_internalApplyOplogUpdate — crash do servidor
CVE-2026-9752HighIndice 2dsphere — crash por documento crafted
CVE-2026-9750HighQuery execution — crash e resultados incorretos
CVE-2026-9749High$exchange stage — crash em key-range partitioning
CVE-2026-9748High$_internalConvertBucketIndexStats + $facet — crash
CVE-2026-9747HighfromRouter: true + runtimeConstants.userRoles — crash
CVE-2026-9746High$changeStream + $_requestReshardingResumeToken — crash
CVE-2026-9751MediumsetParameter logava credenciais em plaintext (ex: ldapQueryPassword)

⚠️ CVE-2026-9740 merece atencao especial: permite DoS por usuario nao autenticado via BSON validator. Qualquer porta mongod ou mongos exposta e um vetor de ataque imediato.

Alem das CVEs do servidor, os binarios mongodump/tools foram recompilados com golang.org/x/crypto v0.52.0 e golang.org/x/net v0.55.0, fechando 15 CVEs adicionais nas bibliotecas Go.

Ambiente do lab

HostIPRole
mongo-vm01192.168.15.180PRIMARY
mongo-vm02192.168.15.181SECONDARY
mongo-vm03192.168.15.182SECONDARY
  • OS: Oracle Linux 8
  • Replica Set: rs-source
  • Versao anterior: 8.0.23-10
  • Versao alvo: 8.0.26-11

Tem downtime?

Nao, desde que a connection string da aplicacao use retryWrites=true:

mongodb://host1,host2,host3/?replicaSet=rs-source&retryWrites=true

O rolling upgrade mantem o cluster operacional durante todo o processo. O unico impacto e ~5-15 segundos sem writes durante a eleicao do novo primario — drivers modernos absorvem isso automaticamente com retry.

Pre-checagem (obrigatoria)

1. Validar estado do cluster

mongosh --quiet --eval '
rs.status().members.forEach(m => print(m.name + " | " + m.stateStr + " | health=" + m.health));
print("---");
print("Version: " + db.version());
print("fCV: " + JSON.stringify(db.adminCommand({getParameter:1, featureCompatibilityVersion:1}).featureCompatibilityVersion));
'

Output obtido:

192.168.15.180:27017 | PRIMARY | health=1
192.168.15.181:27017 | SECONDARY | health=1
192.168.15.182:27017 | SECONDARY | health=1
---
Version: 8.0.23-10
fCV: {"version":"8.0"}

✅ 3 nos saudaveis, fCV 8.0 — pode prosseguir.

2. Validar repositorio e pacote disponivel

Execute em cada no:

sudo dnf clean all && sudo dnf makecache
sudo dnf --showduplicates list percona-server-mongodb 2>/dev/null | grep 8.0.26

Output esperado:

percona-server-mongodb.x86_64    8.0.26-11.el8    psmdb-80-release-x86_64

3. Validar pacotes instalados

rpm -qa | grep -i percona-server-mongodb | sort

Output obtido:

percona-server-mongodb-8.0.23-10.el8.x86_64
percona-server-mongodb-mongos-8.0.23-10.el8.x86_64
percona-server-mongodb-server-8.0.23-10.el8.x86_64
percona-server-mongodb-tools-8.0.23-10.el8.x86_64

Obtencao dos pacotes

Opcao A — Download via repositorio Percona (host com acesso a internet)

sudo dnf install -y dnf-plugins-core

mkdir -p /tmp/psmdb-8.0.26-11

sudo dnf download \
  --releasever=8 \
  --arch=x86_64 \
  --destdir=/tmp/psmdb-8.0.26-11 \
  percona-server-mongodb-8.0.26-11.el8 \
  percona-server-mongodb-server-8.0.26-11.el8 \
  percona-server-mongodb-mongos-8.0.26-11.el8 \
  percona-server-mongodb-tools-8.0.26-11.el8

Opcao B — Download no Windows e transferencia para Linux

Para ambientes sem acesso direto a internet nos servidores Linux.

Download via PowerShell:

$base = "https://downloads.percona.com/downloads/percona-server-mongodb-8.0/percona-server-mongodb-8.0.26-11/binary/redhat/8/x86_64"
$dest = "C:\tmp\psmdb-8.0.26-11"
New-Item -ItemType Directory -Force -Path $dest

@(
  "percona-server-mongodb-8.0.26-11.el8.x86_64.rpm",
  "percona-server-mongodb-server-8.0.26-11.el8.x86_64.rpm",
  "percona-server-mongodb-mongos-8.0.26-11.el8.x86_64.rpm",
  "percona-server-mongodb-tools-8.0.26-11.el8.x86_64.rpm"
) | ForEach-Object {
  Invoke-WebRequest -Uri "$base/$_" -OutFile "$dest\$_"
  Write-Host "Downloaded: $_"
}

Transferencia via SCP:

$dest = "C:\tmp\psmdb-8.0.26-11"
$hosts = @("192.168.15.180", "192.168.15.181", "192.168.15.182")

foreach ($h in $hosts) {
  ssh root@$h "mkdir -p /tmp/psmdb-8.0.26-11"
  scp "$dest\*.rpm" "root@${h}:/tmp/psmdb-8.0.26-11/"
  Write-Host "Transferido para $h"
}

Validacao dos pacotes (obrigatoria)

for f in /tmp/psmdb-8.0.26-11/*.rpm; do
  echo "=== $(basename $f) ==="
  rpm -K "$f"
done

Output obtido:

=== percona-server-mongodb-8.0.26-11.el8.x86_64.rpm ===
/tmp/psmdb-8.0.26-11/percona-server-mongodb-8.0.26-11.el8.x86_64.rpm: digests signatures OK
=== percona-server-mongodb-mongos-8.0.26-11.el8.x86_64.rpm ===
/tmp/psmdb-8.0.26-11/percona-server-mongodb-mongos-8.0.26-11.el8.x86_64.rpm: digests signatures OK
=== percona-server-mongodb-server-8.0.26-11.el8.x86_64.rpm ===
/tmp/psmdb-8.0.26-11/percona-server-mongodb-server-8.0.26-11.el8.x86_64.rpm: digests signatures OK
=== percona-server-mongodb-tools-8.0.26-11.el8.x86_64.rpm ===
/tmp/psmdb-8.0.26-11/percona-server-mongodb-tools-8.0.26-11.el8.x86_64.rpm: digests signatures OK

Se aparecer NOKEY, importe a chave GPG: “bash sudo rpm --import /etc/pki/rpm-gpg/PERCONA-PACKAGING-KEY “

Dry-run (simula sem instalar)

sudo dnf install --assumeno /tmp/psmdb-8.0.26-11/*.rpm

Output esperado:

Upgrading:
 percona-server-mongodb          x86_64  8.0.26-11.el8  @commandline   8.2 k
 percona-server-mongodb-mongos   x86_64  8.0.26-11.el8  @commandline    32 M
 percona-server-mongodb-server   x86_64  8.0.26-11.el8  @commandline    70 M
 percona-server-mongodb-tools    x86_64  8.0.26-11.el8  @commandline    33 M

Upgrade  4 Packages
Operation aborted.

✅ Apenas Upgrading — nenhum Installing de pacote novo, nenhum Removing. “Operation aborted” e o comportamento esperado do --assumeno.

Rolling Upgrade — um no por vez

Ordem de execucao:

1. mongo-vm03 (192.168.15.182) -- SECONDARY
2. mongo-vm02 (192.168.15.181) -- SECONDARY
3. mongo-vm01 (192.168.15.180) -- PRIMARY (stepDown antes)

No 1 — mongo-vm03 (SECONDARY)

mongosh --quiet --eval "rs.status().members.find(m => m.self).stateStr"

sudo systemctl stop mongod

sudo dnf install -y /tmp/psmdb-8.0.26-11/*.rpm

/usr/bin/mongod --version && \
sudo systemctl start mongod && \
sleep 5 && \
mongosh --quiet --eval "rs.status().members.find(m => m.self).stateStr"

Output obtido:

db version v8.0.26-11
...
SECONDARY

Validar lag de replicacao:

mongosh --quiet --eval "rs.printSecondaryReplicationInfo()"
source: 192.168.15.182:27017
  replLag: '-10 secs (0 hrs) behind the primary'

✅ Lag zero (valor negativo e normal — no ligeiramente a frente do snapshot do primario).

No 2 — mongo-vm02 (SECONDARY)

Mesma sequencia do no anterior:

mongosh --quiet --eval "rs.status().members.find(m => m.self).stateStr"

sudo systemctl stop mongod
sudo dnf install -y /tmp/psmdb-8.0.26-11/*.rpm
/usr/bin/mongod --version && sudo systemctl start mongod && sleep 5 && \
mongosh --quiet --eval "rs.status().members.find(m => m.self).stateStr"

Output obtido:

db version v8.0.26-11
...
SECONDARY
mongosh --quiet --eval "rs.printSecondaryReplicationInfo()"
source: 192.168.15.181:27017
  replLag: '0 secs (0 hrs) behind the primary'
source: 192.168.15.182:27017
  replLag: '0 secs (0 hrs) behind the primary'

✅ Ambos os secundarios em 8.0.26-11 com lag zero.

No 3 — mongo-vm01 (PRIMARY)

⚠️ Nao pare o primario diretamente. Faca o stepDown primeiro para garantir eleicao limpa.

StepDown:

mongosh --quiet --eval "db.adminCommand({ replSetStepDown: 60, secondaryCatchUpPeriodSecs: 30 })"

Output obtido:

{ ok: 1 }

Confirmar nova topologia:

mongosh --quiet --eval "rs.status().members.forEach(m => print(m.name + ' | ' + m.stateStr))"
192.168.15.180:27017 | SECONDARY
192.168.15.181:27017 | PRIMARY
192.168.15.182:27017 | SECONDARY

✅ mongo-vm01 virou SECONDARY. mongo-vm02 assumiu como PRIMARY.

Parar, instalar, subir:

sudo systemctl stop mongod
sudo dnf install -y /tmp/psmdb-8.0.26-11/*.rpm
/usr/bin/mongod --version && sudo systemctl start mongod && sleep 5 && \
mongosh --quiet --eval "rs.status().members.find(m => m.self).stateStr"

Output obtido:

db version v8.0.26-11
...
SECONDARY

Validacao final

mongosh --quiet --eval '
rs.status().members.forEach(m => print(m.name + " | " + m.stateStr));
print("---");
db.adminCommand({getParameter:1, featureCompatibilityVersion:1}).featureCompatibilityVersion;
rs.printSecondaryReplicationInfo();
'

Output obtido:

192.168.15.180:27017 | PRIMARY
192.168.15.181:27017 | SECONDARY
192.168.15.182:27017 | SECONDARY
---
{ version: '8.0' }
source: 192.168.15.181:27017
  replLag: '0 secs (0 hrs) behind the primary'
source: 192.168.15.182:27017
  replLag: '0 secs (0 hrs) behind the primary'

✅ Cluster 100% saudavel na versao 8.0.26-11.

Nota: mongo-vm01 voltou a ser PRIMARY via eleicao apos o startup — comportamento esperado, pois possui maior prioridade configurada no replica set.

Resumo

NoIPVersao anteriorVersao atual
mongo-vm03192.168.15.1828.0.23-108.0.26-11
mongo-vm02192.168.15.1818.0.23-108.0.26-11
mongo-vm01192.168.15.1808.0.23-108.0.26-11
  • Downtime efetivo: ~5-10s durante eleicao do primario
  • fCV: mantida em 8.0 — nenhuma acao necessaria
  • CVEs fechadas: 10 high + 1 medium no servidor; 15 CVEs Go nos tools

Referencias

  • Release Notes — Percona Server for MongoDB 8.0.26-11
  • Minor Upgrade — Percona Server for MongoDB
  • Security Advisory: CVE-2026-9740 e CVE-2026-11933
  • Install on RHEL and derivatives
CVE mongodb Oracle Linux percona replica set rolling upgrade
Share. Facebook Twitter Pinterest LinkedIn Tumblr Email WhatsApp
Previous ArticleClonar Usuário MongoDB Preservando a Senha
0 0 votes
Article Rating
Subscribe
Login
Notify of
guest

guest

0 Comments
Oldest
Newest Most Voted
Demo
Follow Me
  • Email
  • GitHub
  • LinkedIn
  • RSS
  • YouTube

INS-06006 – Passwordless SSH Connectivity Not Set Up

2026-02-2615 Views

Limpeza da biblioteca de software OEM: Purge seguro e controle de crescimento de swlib

2026-02-216 Views

ORA-29548 – Como corrigir o erro “Java System Class Reported” no Oracle Database

2026-03-054 Views
Demo
Blogroll
  • oravirt
Execute Step
YouTube LinkedIn RSS
  • Home
  • Sobre
  • Contato
  • RSS
  • Português
    • English (Inglês)
© 2026 ExecuteStep. Designed by ThemeSphere.

Type above and press Enter to search. Press Esc to cancel.

wpDiscuz
Ad Blocker Enabled!
Ad Blocker Enabled!
Our website is made possible by displaying online advertisements to our visitors. Please support us by disabling your Ad Blocker.