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

Oracle RAC 12.2 no VMware Workstation – Post 5: Validação Final e Referência Rápida

2026-05-11 Oracle By Henrique

Oracle RAC 12.2 no VMware Workstation — Post 4: Instalação do Oracle Database e DBCA

2026-05-11 Oracle By Henrique

Oracle RAC 12.2 no VMware Workstation — Post 2: Configuração do Oracle Linux e iSCSI

2026-05-11 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 » MongoDB 8.0 + MongoShake no Oracle Linux 8 — Do Zero ao Cutover
MongoDB

MongoDB 8.0 + MongoShake no Oracle Linux 8 — Do Zero ao Cutover

HenriqueBy Henrique2026-05-05Updated:2026-05-1920 Mins Read
Share
Facebook Twitter LinkedIn Pinterest Email Telegram WhatsApp

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

Este post documenta a instalação completa do MongoDB 8.0 no Oracle Linux 8 com todas as boas práticas recomendadas pela documentação oficial, seguida da configuração do MongoShake para replicação em tempo real entre dois Replica Sets. Todo o processo foi executado e validado em ambiente real — nada aqui é teórico.

O ambiente consiste em 7 VMs VMware, todas Oracle Linux 8, com dois Replica Sets de 3 nós cada e uma VM dedicada ao MongoShake. Usamos o dataset MovieLens com mais de 24 milhões de documentos para validar a sincronização em condições próximas de produção.


Arquitetura do ambiente

192.168.15.180  mongo-vm01  PRIMARY   rs-source
192.168.15.181  mongo-vm02  SECONDARY rs-source
192.168.15.182  mongo-vm03  SECONDARY rs-source

192.168.15.183  mongo-vm04  PRIMARY   rs-target
192.168.15.184  mongo-vm05  SECONDARY rs-target
192.168.15.185  mongo-vm06  SECONDARY rs-target

192.168.15.186  mongo-vm07  MongoShake

Sizing de cada VM MongoDB: 2 vCPUs, 2GB RAM, 20GB disco. VM do MongoShake: 1 vCPU, 1GB RAM, 10GB disco.


Parte 1 — Instalação do MongoDB 8.0 no Oracle Linux 8

Esta parte foi executada em todas as VMs 1 a 6. A estratégia foi configurar uma VM base e clonar as demais, ajustando apenas o IP, hostname e replSetName em cada clone via sed.

Passo 0 — Configurar /etc/hosts

Execute em todos os nós para garantir resolução de nomes sem dependência de DNS:

sudo bash -c 'cat >> /etc/hosts << EOF

192.168.15.180  mongo-vm01
192.168.15.181  mongo-vm02
192.168.15.182  mongo-vm03

192.168.15.183  mongo-vm04
192.168.15.184  mongo-vm05
192.168.15.185  mongo-vm06

192.168.15.186  mongo-vm07
EOF'

Passo 1 — Verificar o kernel (obrigatório no Oracle Linux)

O MongoDB suporta apenas o Red Hat Compatible Kernel (RHCK) no Oracle Linux. O Unbreakable Enterprise Kernel (UEK), que é o padrão do OL8, não é suportado.

Documentação oficial: “MongoDB only supports Oracle Linux running the Red Hat Compatible Kernel (RHCK). MongoDB does not support the Unbreakable Enterprise Kernel (UEK).” Fonte: MongoDB Production Notes

uname -r

Se o sistema estiver com UEK:

rpm -q kernel | grep -v uek

RHCK=$(rpm -q kernel | grep -v uek | tail -1 | sed 's/kernel-//')
sudo grubby --set-default /boot/vmlinuz-${RHCK}

sudo grubby --default-kernel

sudo reboot

Passo 2 — Instalar dependências

sudo dnf install -y curl wget net-tools chrony numactl

Passo 3 — Adicionar repositório e instalar MongoDB 8.0

sudo bash -c 'cat > /etc/yum.repos.d/mongodb-org-8.0.repo << EOF
[mongodb-org-8.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/8/mongodb-org/8.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://pgp.mongodb.com/server-8.0.asc
EOF'

sudo dnf install -y mongodb-org

Versão instalada e validada: mongodb-org-8.0.21

Fonte: Install MongoDB 8.0 on Red Hat / Oracle Linux

Passo 4 — Configurar o tuned profile para MongoDB

No Oracle Linux 8 o tuned está ativo por padrão e aplica suas configurações de kernel depois do systemd-sysctl, podendo sobrescrever parâmetros definidos no sysctl.conf. Para evitar conflitos, defina os parâmetros de kernel diretamente na seção [sysctl] do profile do tuned.

sudo dnf install -y tuned

sudo mkdir -p /etc/tuned/mongodb-ol8

sudo bash -c 'cat > /etc/tuned/mongodb-ol8/tuned.conf << EOF
[main]
summary=Tuned profile for MongoDB on Oracle Linux 8

[base]
include=throughput-performance

[vm]
transparent_hugepages=always

[sysctl]
vm.swappiness=1
vm.dirty_ratio=15
vm.dirty_background_ratio=5
vm.zone_reclaim_mode=0
net.core.somaxconn=4096
net.ipv4.tcp_fin_timeout=30
EOF'

sudo tuned-adm profile mongodb-ol8

sudo tuned-adm active
sysctl -n vm.swappiness

Fonte: TCMalloc Performance Optimization — MongoDB Docs

Passo 5 — Habilitar Transparent Huge Pages

⚠️ Mudança crítica no MongoDB 8.0: nas versões 4.0 a 7.0, o THP deveria ser desabilitado. A partir do MongoDB 8.0, o THP deve ser habilitado.

A partir do MongoDB 8.0 foi adotado o novo TCMalloc com per-CPU caches, que requer THP habilitado. Manter THP desabilitado no MongoDB 8.0 desperdiça a principal melhoria de performance de memória desta versão.

sudo bash -c 'cat > /etc/systemd/system/enable-transparent-huge-pages.service << EOF
[Unit]
Description=Enable Transparent Huge Pages for MongoDB
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=mongod.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo always | tee /sys/kernel/mm/transparent_hugepage/enabled > /dev/null"

[Install]
WantedBy=basic.target
EOF'

sudo systemctl daemon-reload
sudo systemctl enable --now enable-transparent-huge-pages.service

cat /sys/kernel/mm/transparent_hugepage/enabled

Fonte: TCMalloc Performance Optimization — MongoDB Docs

Passo 6 — Configurar ulimits

No OL8 o systemd tem seu próprio controle de limites que pode sobrescrever o /etc/security/limits.d/. É necessário configurar os dois.

sudo bash -c 'cat > /etc/security/limits.d/mongodb.conf << EOF
mongod  soft  nproc   64000
mongod  hard  nproc   64000
mongod  soft  nofile  64000
mongod  hard  nofile  64000
EOF'

sudo mkdir -p /etc/systemd/system/mongod.service.d/

sudo bash -c 'cat > /etc/systemd/system/mongod.service.d/limits.conf << EOF
[Service]
LimitFNOFILE=64000
LimitNPROC=64000
EOF'

sudo systemctl daemon-reload

Fonte: UNIX ulimit Settings — MongoDB Docs

Passo 7 — Configurar I/O Scheduler

Para VMs com disco virtual (SSD virtualizado), o scheduler recomendado é none.

DISK=$(lsblk -d -o NAME,TYPE | awk '$2=="disk"{print $1}' | head -1)
echo "Disco identificado: $DISK"

echo none | sudo tee /sys/block/${DISK}/queue/scheduler

sudo bash -c "cat > /etc/udev/rules.d/60-mongodb-disk.rules << EOF
ACTION==\"add|change\", KERNEL==\"${DISK}\", ATTR{queue/scheduler}=\"none\"
EOF"

sudo udevadm control --reload-rules
sudo udevadm trigger

cat /sys/block/${DISK}/queue/scheduler

Fonte: MongoDB Production Notes

Passo 8 — NTP

O MongoDB exige que a diferença de tempo entre os nós do Replica Set seja inferior a 2 segundos.

sudo systemctl enable --now chronyd

chronyc tracking | grep "System time"

Passo 9 — SELinux

Não desabilite o SELinux. O pacote .rpm do MongoDB cria automaticamente o diretório /var/lib/mongo com o contexto SELinux mongod_var_lib_t correto. Use sempre os caminhos padrão do pacote para evitar configuração manual adicional de SELinux.

sudo dnf install -y policycoreutils-python-utils

sudo semanage port -a -t mongod_port_t -p tcp 27017

ls -laZ /var/lib/mongo

sudo semanage port -l | grep mongod

Fonte: Install MongoDB on Red Hat — Configure SELinux

Passo 10 — Firewall

sudo firewall-cmd --permanent --add-port=27017/tcp
sudo firewall-cmd --reload

sudo firewall-cmd --list-ports | grep 27017

Passo 11 — Persistir o diretório de PID

O diretório /run/mongodb/ é criado em tmpfs e é perdido após o reboot. É necessário persistir via tmpfiles.d.

sudo bash -c 'cat > /etc/tmpfiles.d/mongodb.conf << EOF
d /run/mongodb 0755 mongod mongod -
EOF'

sudo systemd-tmpfiles --create /etc/tmpfiles.d/mongodb.conf

ls -la /run/mongodb/

Passo 12 — Configurar mongod.conf

Pontos importantes:

  • Usar /var/lib/mongo (padrão do rpm) — não /var/lib/mongodb
  • Usar /run/mongodb/mongod.pid — não /var/run/mongodb/mongod.pid
  • cacheSizeGB: fórmula (RAM - 1GB) * 0.5 → para 2GB = 0.5GB
  • bindIp: sempre loopback + IP real da VM, nunca 0.0.0.0
sudo bash -c 'cat > /etc/mongod.conf << EOF

storage:
  dbPath: /var/lib/mongo
  wiredTiger:
    engineConfig:
      cacheSizeGB: 0.5

systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true
  logRotate: rename

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.15.180

replication:
  replSetName: "rs-source"
  oplogSizeMB: 1024

processManagement:
  timeZoneInfo: /usr/share/zoneinfo
  pidFilePath: /run/mongodb/mongod.pid

operationProfiling:
  slowOpThresholdMs: 100
EOF'

Após clonar as VMs, ajustar bindIp e replSetName com sed:

sed -i 's/192.168.15.180/192.168.15.183/' /etc/mongod.conf
sed -i 's/rs-source/rs-target/' /etc/mongod.conf

Passo 13 — Habilitar autenticação com keyFile

Em Replica Sets, a autenticação exige obrigatoriamente um keyFile para autenticação interna entre os membros.

⚠️ Ordem importa: crie os usuários antes de habilitar a autenticação. Depois que a autenticação está ativa, sem os usuários criados você perde o acesso ao banco.

openssl rand -base64 756 > /tmp/mongodb-keyfile
sudo cp /tmp/mongodb-keyfile /etc/mongodb-keyfile
sudo chown mongod:mongod /etc/mongodb-keyfile
sudo chmod 400 /etc/mongodb-keyfile

for ip in 192.168.15.181 192.168.15.182 192.168.15.183 192.168.15.184 192.168.15.185; do
  scp /tmp/mongodb-keyfile root@$ip:/tmp/
  ssh root@$ip "sudo cp /tmp/mongodb-keyfile /etc/mongodb-keyfile && \
                sudo chown mongod:mongod /etc/mongodb-keyfile && \
                sudo chmod 400 /etc/mongodb-keyfile"
done

Adicionar ao mongod.conf em todas as VMs:

sudo bash -c 'cat >> /etc/mongod.conf << EOF

security:
  authorization: enabled
  keyFile: /etc/mongodb-keyfile
EOF'

Script de validação pós-reboot

Execute após cada reboot para confirmar que todas as configurações persistiram:

echo "=== Kernel ===" && uname -r
echo "=== THP ===" && cat /sys/kernel/mm/transparent_hugepage/enabled
echo "=== Tuned ===" && tuned-adm active
echo "=== Swappiness ===" && sysctl -n vm.swappiness
echo "=== Scheduler ===" && cat /sys/block/sda/queue/scheduler
echo "=== NTP ===" && chronyc tracking | grep "System time"
echo "=== SELinux ===" && sestatus | grep "Current mode"
echo "=== Firewall ===" && firewall-cmd --list-ports | grep 27017
echo "=== MongoDB ===" && mongod --version

Saída esperada após reboot (validado em ambiente real):

=== Kernel ===
4.18.0-553.120.1.el8_10.x86_64
=== THP ===
[always] madvise never
=== Tuned ===
Current active profile: mongodb-ol8
=== Swappiness ===
1
=== Scheduler ===
[none] mq-deadline kyber bfq
=== NTP ===
System time     : 0.000000005 seconds fast of NTP time
=== SELinux ===
Current mode:                   enforcing
=== Firewall ===
27017/tcp
=== MongoDB ===
db version v8.0.21

Parte 2 — Configuração dos Replica Sets

Inicializar o rs-source (executar apenas na VM01)

mongosh --host 192.168.15.180 --port 27017 <<'EOF'
rs.initiate({
  _id: "rs-source",
  members: [
    { _id: 0, host: "192.168.15.180:27017", priority: 2 },
    { _id: 1, host: "192.168.15.181:27017", priority: 1 },
    { _id: 2, host: "192.168.15.182:27017", priority: 1 }
  ]
})
EOF

Inicializar o rs-target (executar apenas na VM04)

mongosh --host 192.168.15.183 --port 27017 <<'EOF'
rs.initiate({
  _id: "rs-target",
  members: [
    { _id: 0, host: "192.168.15.183:27017", priority: 2 },
    { _id: 1, host: "192.168.15.184:27017", priority: 1 },
    { _id: 2, host: "192.168.15.185:27017", priority: 1 }
  ]
})
EOF

Criar usuários — sequência correta

A melhor prática é criar os usuários antes de habilitar a autenticação.

Sequência obrigatória:

  1. rs.initiate()
  2. Criar usuários
  3. Habilitar autenticação + keyFile
  4. Popular com dados

Na VM01 (SOURCE):

mongosh --host 192.168.15.180 --port 27017 <<'EOF'
use admin

db.createUser({
  user: "admin",
  pwd: "Admin2024!",
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" },
    { role: "clusterAdmin",         db: "admin" }
  ]
})

db.createUser({
  user: "shakeuser",
  pwd: "Shake2024!",
  roles: [
    { role: "readAnyDatabase", db: "admin" },
    { role: "read",            db: "local"      },
    { role: "read",            db: "config"     },
    { role: "readWrite",       db: "mongoshake" }
  ]
})
EOF

Na VM04 (TARGET):

mongosh --host 192.168.15.183 --port 27017 <<'EOF'
use admin

db.createUser({
  user: "admin",
  pwd: "Admin2024!",
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" },
    { role: "clusterAdmin",         db: "admin" }
  ]
})

db.createUser({
  user: "shakeuser",
  pwd: "Shake2024!",
  roles: [
    { role: "readWriteAnyDatabase", db: "admin" },
    { role: "dbAdminAnyDatabase",   db: "admin" }
  ]
})
EOF

💡 Atenção — permissões do shakeuser na SOURCE: o role readAnyDatabase não cobre databases internos do MongoDB. É necessário adicionar explicitamente read nos databases local e config. Sem essa permissão, o MongoShake falha com erro Unauthorized durante o full sync ao tentar listar as coleções — não para replicá-las. Databases internos como admin, local, config e mongoshake são filtrados pelo MongoShake por padrão e não são replicados para o target.


Parte 3 — Instalação e configuração do MongoShake

Download (VM07)

mkdir -p ~/mongoshake/{conf,logs}
cd ~/mongoshake

wget "https://github.com/alibaba/MongoShake/releases/download/release-v2.8.4-20230425/mongo-shake-v2.8.4.tgz" \
  -O mongo-shake-v2.8.4.tgz

tar -xzf mongo-shake-v2.8.4.tgz

ln -s ~/mongoshake/mongo-shake-v2.8.4/collector.linux ~/mongoshake/collector

~/mongoshake/collector --version

Configurar o collector.conf

Use o collector.conf original do pacote como base — ele já tem o conf.version correto e todos os parâmetros válidos para a versão 2.8.4:

cp ~/mongoshake/mongo-shake-v2.8.4/collector.conf ~/mongoshake/conf/

Editar apenas os parâmetros necessários:

cd ~/mongoshake/conf

sed -i 's|^mongo_urls.*|mongo_urls = mongodb://shakeuser:Shake2024!@192.168.15.180:27017,192.168.15.181:27017,192.168.15.182:27017|' collector.conf
sed -i 's|^mongo_connect_mode.*|mongo_connect_mode = secondaryPreferred|' collector.conf
sed -i 's|^sync_mode.*|sync_mode = all|' collector.conf
sed -i 's|^tunnel =.*|tunnel = direct|' collector.conf
sed -i 's|^tunnel.address.*|tunnel.address = mongodb://shakeuser:Shake2024!@192.168.15.183:27017,192.168.15.184:27017,192.168.15.185:27017|' collector.conf
sed -i 's|^log.dir.*|log.dir = /root/mongoshake/logs|' collector.conf
sed -i 's|^checkpoint.start_position.*|checkpoint.start_position = 1970-01-01T00:00:00Z|' collector.conf
sed -i 's|^filter.namespace.black.*|filter.namespace.black = config|' collector.conf
sed -i 's|full_sync.collection_exist_drop = true|full_sync.collection_exist_drop = false|' collector.conf

Parâmetros principais

ParâmetroValorDescrição
mongo_urlstodos os membros do RSInformar todos os nós para o MongoShake eleger de onde ler
mongo_connect_modesecondaryPreferredLê do secondary para não impactar o primary
sync_modeallFull sync + incremental — use incr após o primeiro full sync
tunneldirectEscreve diretamente no MongoDB destino
checkpoint.start_position1970-01-01Na primeira execução, parte do oplog mais antigo disponível
filter.namespace.blackconfigIgnora o database interno config — evita erros de permissão
full_sync.collection_exist_dropfalseNão apaga dados no target ao reiniciar — crítico em produção
incr_sync.target_delay0Sem delay — aplica oplogs imediatamente

Iniciar o MongoShake

cd ~/mongoshake

nohup ./collector -conf=conf/collector.conf -verbose 1 \
  > logs/stdout.log 2>&1 &

echo $! > mongoshake.pid

tail -f logs/stdout.log | grep -E "stage=full|stage=incr|progress|finish full"

Sequência normal nos logs:

[INFO] [name=default-0, stage=full, get=500000, write_success=499800, tps=72258]
[INFO] collExecutor-5 sync ns {movielens ratings} successful. db syncer-0 progress 100%

[INFO] finish full sync, start incr sync with timestamp: fullBeginTs[...], fullFinishTs[...]

[INFO] [name=default-0, stage=incr, get=14, filter=14, write_success=0, tps=0, ...]

⚠️ Armadilha crítica — sync_mode + collection_exist_drop

A combinação sync_mode = all com full_sync.collection_exist_drop = true faz o MongoShake refazer o full sync completo toda vez que o processo reinicia, ignorando o checkpoint gravado na source. Em produção isso significa horas de reprocessamento desnecessário.

Configuração correta:

sync_mode = all
full_sync.collection_exist_drop = false

sync_mode = incr
full_sync.collection_exist_drop = false

Com sync_mode = incr o MongoShake retoma sempre do checkpoint gravado na source sem refazer o full sync.

Monitoramento

curl -s http://192.168.15.186:9101 | python3 -m json.tool

curl -s http://192.168.15.186:9100 | python3 -m json.tool

mongosh --host 192.168.15.180 --port 27017 \
  -u admin -p 'Admin2024!' --authenticationDatabase admin \
  --eval "db.getSiblingDB('mongoshake').ckpt_default.find().pretty()"

Parte 4 — Validação com dataset real

Usamos o dataset MovieLens 32M para validar a sincronização em volume real.

Dataset importado na SOURCE

DatabaseCollectionDocumentos
movielensmovies87.585
movielenslinks87.585
movielenstags2.000.072
movielensratings24.610.000
my-films-dbfilms10.000
Total~26,8 milhões

Resultado do full sync

Tempo de full sync para ~26.8 milhões de documentos: aproximadamente 7 minutos. TPS máximo observado: 102.528 documentos/segundo.

Teste de incremental sync

mongosh --host 192.168.15.180 --port 27017 \
  -u admin -p 'Admin2024!' --authenticationDatabase admin \
  --eval "
    db.getSiblingDB('movielens').ratings.insertMany([
      { userId: 999991, movieId: 1, rating: 5.0, timestamp: new Date(), tag: 'cutover-test' },
      { userId: 999992, movieId: 2, rating: 4.5, timestamp: new Date(), tag: 'cutover-test' },
      { userId: 999993, movieId: 3, rating: 4.0, timestamp: new Date(), tag: 'cutover-test' }
    ]);
    print('Total source: ' + db.getSiblingDB('movielens').ratings.countDocuments());
  "

sleep 3
mongosh --host 192.168.15.183 --port 27017 \
  -u admin -p 'Admin2024!' --authenticationDatabase admin \
  --eval "
    print('Total target: ' + db.getSiblingDB('movielens').ratings.countDocuments());
    db.getSiblingDB('movielens').ratings.find({tag: 'cutover-test'}).toArray();
  "

✅ Resultado: 3 documentos replicados em menos de 3 segundos.


Parte 5 — Procedimento de Cutover

O cutover é a transferência da aplicação do cluster de origem para o cluster de destino com mínima indisponibilidade. Esta abordagem é válida tanto para migração entre datacenters quanto para upgrade de versão do MongoDB.

Pré-requisitos

tail -5 ~/mongoshake/logs/stdout.log

SOURCE=$(mongosh --host 192.168.15.180 --port 27017 \
  -u admin -p 'Admin2024!' --authenticationDatabase admin --quiet \
  --eval "db.getSiblingDB('movielens').ratings.countDocuments()")

TARGET=$(mongosh --host 192.168.15.183 --port 27017 \
  -u admin -p 'Admin2024!' --authenticationDatabase admin --quiet \
  --eval "db.getSiblingDB('movielens').ratings.countDocuments()")

echo "SOURCE: $SOURCE"
echo "TARGET: $TARGET"

if [ "$SOURCE" = "$TARGET" ]; then
  echo "Seguro para cutover"
else
  echo "NÃO fazer cutover — contagens diferentes"
fi

Passo 1 — Bloquear escritas na source

⚠️ Ação irreversível enquanto o lock estiver ativo. Tenha o rollback preparado antes de executar.

mongosh --host 192.168.15.180 --port 27017 \
  -u admin -p 'Admin2024!' --authenticationDatabase admin \
  --eval "db.adminCommand({ fsync: 1, lock: true })"

Passo 2 — Aguardar o MongoShake zerar o lag

watch -n 2 "tail -3 ~/mongoshake/logs/stdout.log | grep stage=incr"

Passo 3 — Parar o MongoShake

kill $(cat ~/mongoshake/mongoshake.pid)

Passo 4 — Redirecionar a aplicação

De:

mongodb://user:pass@192.168.15.180:27017,192.168.15.181:27017,192.168.15.182:27017/?replicaSet=rs-source

Para:

mongodb://user:pass@192.168.15.183:27017,192.168.15.184:27017,192.168.15.185:27017/?replicaSet=rs-target

Passo 5 — Validar no novo cluster

mongosh "mongodb://admin:Admin2024!@192.168.15.183:27017,192.168.15.184:27017,192.168.15.185:27017/?replicaSet=rs-target&authSource=admin" \
  --eval "
    print('RS: ' + rs.status().set);
    print('Primary: ' + rs.status().members.find(m => m.stateStr === 'PRIMARY').name);
    print('Ratings: ' + db.getSiblingDB('movielens').ratings.countDocuments());
  "

Rollback — se algo der errado

mongosh --host 192.168.15.180 --port 27017 \
  -u admin -p 'Admin2024!' --authenticationDatabase admin \
  --eval "db.adminCommand({ fsyncUnlock: 1 })"


cd ~/mongoshake
nohup ./collector -conf=conf/collector.conf -verbose 1 \
  > logs/stdout.log 2>&1 &
echo $! > mongoshake.pid

Aplicabilidade para upgrade de versão

Esta abordagem funciona como estratégia de upgrade de versão do MongoDB com mínima indisponibilidade. As vantagens sobre o upgrade in-place ou rolling upgrade são:

  • O cluster de destino já está na versão final validado com dados reais antes do cutover
  • Rollback imediato — se algo der errado basta apontar a aplicação de volta para o cluster original
  • Permite pular múltiplas versões maiores sem o processo incremental obrigatório do upgrade in-place
  • Zero downtime no cutover se feito corretamente

💡 Limitação: o MongoShake 2.8.x suporta MongoDB 5.0 em diante como source. Para versões mais antigas (4.0 ou 4.2) verifique a compatibilidade antes de usar em produção.


Pontos de atenção consolidados

  1. THP invertido no MongoDB 8.0 — ao contrário das versões anteriores, o MongoDB 8.0 requer THP habilitado
  2. tuned pode sobrescrever sysctl.conf no OL8 — como o tuned aplica suas configurações após o systemd-sysctl, defina os parâmetros de kernel na seção [sysctl] do profile do tuned para evitar conflitos
  3. systemd sobrescreve ulimits — configurar tanto o limits.d quanto o override do systemd
  4. RHCK obrigatório — o UEK não é suportado pelo MongoDB
  5. Usar /var/lib/mongo (padrão do rpm) — não /var/lib/mongodb. O padrão já vem com o contexto SELinux correto
  6. /run/mongodb/ precisa de tmpfiles.d — o diretório é perdido no reboot sem essa configuração
  7. shakeuser precisa de read no config — readAnyDatabase não cobre databases internos
  8. filter.namespace.black = config — o MongoShake não deve tentar replicar config.system.sessions
  9. sync_mode = all + collection_exist_drop = true é perigoso — refaz o full sync a cada restart
  10. Após o primeiro full sync, mudar para sync_mode = incr — retoma do checkpoint sem refazer tudo

Referências

  • MongoDB Production Notes
  • TCMalloc Performance Optimization
  • Install MongoDB 8.0 on Red Hat / Oracle Linux
  • UNIX ulimit Settings — MongoDB Docs
  • MongoDB Operations Checklist
  • MongoShake — GitHub (Alibaba)
  • MongoShake FAQ
  • MovieLens 32M Dataset

cutover lab mongodb mongoshake oracle-linux
Share. Facebook Twitter Pinterest LinkedIn Tumblr Email WhatsApp
Previous ArticleOracle Database 19c com Vagrant: Lab em 15 Minutos
Next Article Oracle RAC 12.2 no VMware Workstation – Apresentação da Série
Add A Comment
Leave A Reply Cancel Reply

Demo
Follow Me
  • Email
  • GitHub
  • LinkedIn
  • RSS
  • YouTube

INS-06006 – Passwordless SSH Connectivity Not Set Up

2026-02-2614 Views

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

2026-02-215 Views

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

2026-03-053 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.

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.