Alta disponibilidade MongoDB em produção: conjuntos de réplicas, fragmentação e operadores Kubernetes

MongoDB ocupa uma posição única no cenário de bancos de dados. Seu modelo de documento é mapeado naturalmente para objetos de aplicativos, seu esquema flexível acomoda estruturas de dados em evolução sem migrações e suas primitivas de replicação e fragmentação integradas fornecem uma base para alta disponibilidade e escalabilidade horizontal que os bancos de dados relacionais exigem ferramentas externas para alcançar. Mas uma fundação não é uma construção acabada. Executar a MongoDB em produção com alta disponibilidade genuína — onde uma falha de nó, uma partição de rede ou uma região inteira ficando off-line não resulta em tempo de inatividade ou perda de dados — exige arquitetura deliberada, ajuste cuidadoso e disciplina operacional rigorosa.

Este guia percorre todas as camadas do MongoDB HA: desde o protocolo de consenso do conjunto de réplicas e a replicação oplog que potencializam o failover automático, passando pela arquitetura de cluster fragmentado que permite o escalonamento horizontal, até os operadores Kubernetes que automatizam o gerenciamento do ciclo de vida e pelas opções de implantação em AWS, Azure, GCP e bare metal k3s com Rancher. Cada seção inclui configuração concreta, manifestos YAML e procedimentos operacionais que você pode adaptar ao seu ambiente.

MongoDB

Um conjunto de réplicas é a unidade fundamental de alta disponibilidade da MongoDB. É um grupo de processosmongodque mantêm o mesmo conjunto de dados. Um membro é oprimário, que recebe todas as operações de gravação. Os membros restantes são secundários, que replicam dados do primário seguindo seu log de operação (oplog). Se o primário ficar indisponível, o conjunto de réplicas realizará uma eleição para escolher um novo primário dentre os secundários elegíveis — normalmente dentro de 10 a 12 segundos.

Um conjunto de réplicas de produção deve ter pelo menos três membros portadores de dados, idealmente espalhados por diferentes domínios de falha (zonas de disponibilidade, racks ou data centers). Isso garante que o conjunto de réplicas possa sobreviver à perda de qualquer membro e ainda manter a maioria para fins eleitorais. Um árbitroopcional Oparticipa de eleições, mas não retém dados — ele existe apenas para romper laços quando você tem um número par de membros portadores de dados, embora a prática recomendada do MongoDB seja usar um número ímpar de membros portadores de dados.

O oplog é uma coleção limitada (local.oplog.rs) que registra todas as operações de modificação de dados no primário em formato idempotente. Os secundários seguem continuamente o oplog do primário e aplicam operações localmente. O tamanho do oplog determina até que ponto um secundário pode ficar antes de precisar de uma ressincronização completa — para cargas de trabalho de produção, dimensione o oplog para manter pelo menos 24 a 72 horas de atividade de gravação. MongoDB 4.4+ oferece suporte ao dimensionamento dinâmico de oplog viareplSetResizeOplog.

# Check current oplog size and window
rs.printReplicationInfo()

# Resize the oplog to 50 GB
db.adminCommand({ replSetResizeOplog: 1, size: 51200 })

# Check replication lag on secondaries
rs.printSecondaryReplicationInfo()

e o protocolo baseado em jangada

MongoDB 4.0+ usa um protocolo de consenso inspirado em Raft para eleições de conjuntos de réplicas. Quando um secundário detecta que o primário está inacessível (padrãoelectionTimeoutMillisde 10.000ms), ele pode convocar uma eleição. Para vencer, o candidato deve receber os votos da maioria dos membros votantes. O membro com a entrada de oplog mais recente e a prioridade mais alta vence se vários candidatos forem elegíveis. Você pode influenciar os resultados eleitorais definindo prioridades de membros — um membro compriority: 0nunca pode se tornar primário, o que é útil para réplicas analíticas ou membros em regiões remotas.

# Initiate a 3-member replica set
rs.initiate({
  _id: "rs-production",
  members: [
    { _id: 0, host: "mongo-0.mongo-svc:27017", priority: 10 },
    { _id: 1, host: "mongo-1.mongo-svc:27017", priority: 5 },
    { _id: 2, host: "mongo-2.mongo-svc:27017", priority: 5 }
  ],
  settings: {
    electionTimeoutMillis: 10000,
    heartbeatTimeoutSecs: 10,
    chainingAllowed: true
  }
})

# Check replica set status
rs.status()

# Step down the primary (for maintenance)
rs.stepDown(60)   // step down for 60 seconds

# Force reconfiguration (emergency)
rs.reconfig(newConfig, { force: true })

Preferência de leitura e preocupação de gravação

Preferência de leituracontrola para onde o driver envia operações de leitura. As opções são:

• primary— Todas as leituras vão para o primário. Consistência mais forte, mas sem escala de leitura.
• primaryPreferred— As leituras vão para o primário, a menos que esteja indisponível, e depois para um secundário.
• secondary— Todas as leituras vão para os secundários. Fornece escalonamento de leitura, mas pode retornar dados obsoletos.
• secondaryPreferred— As leituras vão para os secundários, a menos que nenhum esteja disponível.
• nearest— As leituras vão para o membro com a latência de rede mais baixa, independentemente da função. Melhor para implantações distribuídas geograficamente.

Preocupação com gravaçãocontrola quantos membros do conjunto de réplicas devem confirmar uma gravação antes que a operação retorne ao cliente.

• w: 1— Somente o primário deve confirmar. Mais rápido, mas há risco de perda de dados se o primário falhar antes da replicação.
• w: "majority"— A maioria dos membros portadores de dados deve reconhecer. Este é o padrão de produção recomendado. Isso garante que a escrita sobreviva às eleições primárias.
• w: <number>— Um número específico de membros deve confirmar.
• j: true— A gravação deve ser confirmada no diário no disco antes da confirmação. Combinado comw: "majority", isso oferece a maior garantia de durabilidade.

# Connection string with write concern and read preference
mongodb://mongo-0:27017,mongo-1:27017,mongo-2:27017/appdb?replicaSet=rs-production&w=majority&j=true&readPreference=secondaryPreferred&readPreferenceTags=region:us-east

# SRV connection string (DNS-based discovery)
mongodb+srv://appuser:password@cluster.example.com/appdb?w=majority&retryWrites=true&readPreference=nearest

MongoDB

Um conjunto de réplicas fornece alta disponibilidade, mas não escala de gravação horizontal – todas as gravações vão para um único primário. Quando seu conjunto de dados excede a capacidade de um único servidor ou sua taxa de transferência de gravação excede o que um primário pode suportar, você precisa de fragmentação. Um cluster fragmentado distribui dados entre vários conjuntos de réplicas (fragmentos) usando uma chave de fragmento, permitindo o dimensionamento horizontal do armazenamento e da taxa de transferência de gravação.

Um cluster fragmentado possui três tipos de componentes. Os roteadoresmongossão roteadores de consulta sem estado que direcionam as operações do cliente para o(s) fragmento(s) apropriado(s). Implante pelo menos dois para redundância. Os servidores de configuraçãoformam um conjunto de réplicas que armazena os metadados do cluster – quais pedaços residem em quais shards, os intervalos de chaves de shard e o estado do balanceador. Os servidores Shard​​são conjuntos de réplicas em que cada um contém um subconjunto dos dados fragmentados.

A chave de fragmento é a decisão mais importante em um cluster fragmentado. Ele determina como os dados são distribuídos entre fragmentos e impacta diretamente o desempenho da consulta, a distribuição de gravação e a capacidade de escalabilidade. Uma boa chave de fragmento tem alta cardinalidade (muitos valores distintos), distribui gravações uniformemente entre os fragmentos e oferece suporte aos padrões de consulta mais comuns com operações direcionadas em vez de coleta dispersa.

# Enable sharding on a database
sh.enableSharding("appdb")

# Shard a collection with a hashed shard key (even distribution)
sh.shardCollection("appdb.events", { "event_id": "hashed" })

# Shard with a ranged shard key (supports range queries)
sh.shardCollection("appdb.orders", { "customer_id": 1, "order_date": 1 })

# Check shard distribution
db.orders.getShardDistribution()

# View chunk distribution across shards
use config
db.chunks.aggregate([
  { $group: { _id: "$shard", count: { $sum: 1 } } },
  { $sort: { count: -1 } }
])

As estratégias comuns de chave de fragmento incluem: chaves de hashpara distribuição uniforme de gravação (melhor quando você não precisa de consultas de intervalo na chave de fragmento), chaves compostasque combinam um campo de agrupamento grosseiro com um campo de alta cardinalidade (por exemplo,{ tenant_id: 1, _id: 1 }para aplicativos multilocatários) ebaseado em zona chavesque alinham o posicionamento dos dados com as regiões geográficas.

para multirregião

restringe intervalos específicos da chave de fragmento a fragmentos específicos, permitindo a localidade dos dados. Por exemplo, você pode garantir que os dados dos clientes europeus residam em fragmentos na região da UE, enquanto os dados dos clientes dos EUA residem em fragmentos na região dos EUA.

# Add shards to zones
sh.addShardTag("shard-us-east", "US")
sh.addShardTag("shard-eu-west", "EU")
sh.addShardTag("shard-ap-south", "APAC")

# Define zone ranges
sh.addTagRange("appdb.customers",
  { "region": "US", "customer_id": MinKey },
  { "region": "US", "customer_id": MaxKey },
  "US"
)
sh.addTagRange("appdb.customers",
  { "region": "EU", "customer_id": MinKey },
  { "region": "EU", "customer_id": MaxKey },
  "EU"
)
sh.addTagRange("appdb.customers",
  { "region": "APAC", "customer_id": MinKey },
  { "region": "APAC", "customer_id": MaxKey },
  "APAC"
)

# Verify zone configuration
sh.status()

A distribuição do MongoDB em múltiplas regiões serve a dois propósitos: recuperação de desastres (sobreviver à perda de uma região inteira) e otimização de latência (servir leituras da réplica mais próxima). A MongoDB oferece suporte a implantações multirregionais por meio de membros de conjuntos de réplicas distribuídos entre regiões, fragmentação de zona para localidade de dados e configuração de preferência de leitura que roteia leituras para o membro mais próximo.

Em um conjunto de réplicas de cinco membros distribuídos em três regiões (2 na região primária, 2 na região DR, 1 na região de leitura), a perda da região primária ainda deixa três membros disponíveis – o suficiente para que a maioria eleja uma nova primária. O membro na região de leitura deve terpriority: 0para evitar que se torne primário (alta latência entre regiões degradaria o desempenho de gravação). Usehidden: truepara membros dedicados à análise que não devem receber leituras regulares de aplicativos.

MongoDB Comunidade Kubernetes Operador

O operador Kubernetes da comunidade MongoDB implanta e gerencia conjuntos de réplicas MongoDB na Kubernetes. É o operador de código aberto da MongoDB Inc. que lida com o gerenciamento StatefulSet, configuração automatizada do conjunto de réplicas, rotação de certificados TLS, gerenciamento de usuários e atualizações contínuas.

# Install the MongoDB Community Operator via Helm
helm repo add mongodb https://mongodb.github.io/helm-charts
helm repo update

helm install community-operator mongodb/community-operator \
  --namespace mongodb \
  --create-namespace \
  --set operator.watchNamespace="*"

MongoDBEspecificação comunitária CRD

O recurso customizadoMongoDBCommunitydefine o estado desejado de um conjunto de réplicas MongoDB. Abaixo está uma especificação pronta para produção.

apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: production-mongodb
  namespace: databases
spec:
  members: 3
  type: ReplicaSet
  version: "7.0.12"

  security:
    authentication:
      modes: ["SCRAM"]
    tls:
      enabled: true
      certificateKeySecretRef:
        name: mongodb-tls-cert
      caCertificateSecretRef:
        name: mongodb-ca-cert

  users:
    - name: appuser
      db: admin
      passwordSecretRef:
        name: mongodb-appuser-password
      roles:
        - name: readWrite
          db: appdb
        - name: clusterMonitor
          db: admin
      scramCredentialsSecretName: appuser-scram
    - name: backup-user
      db: admin
      passwordSecretRef:
        name: mongodb-backup-password
      roles:
        - name: backup
          db: admin
        - name: restore
          db: admin
      scramCredentialsSecretName: backup-scram
    - name: monitoring
      db: admin
      passwordSecretRef:
        name: mongodb-monitoring-password
      roles:
        - name: clusterMonitor
          db: admin
      scramCredentialsSecretName: monitoring-scram

  additionalMongodConfig:
    storage.wiredTiger.engineConfig.cacheSizeGB: 4
    storage.wiredTiger.engineConfig.journalCompressor: snappy
    storage.wiredTiger.collectionConfig.blockCompressor: snappy
    net.maxIncomingConnections: 10000
    operationProfiling.mode: slowOp
    operationProfiling.slowOpThresholdMs: 100
    replication.oplogSizeMB: 51200
    setParameter.cursorTimeoutMillis: 600000

  statefulSet:
    spec:
      template:
        spec:
          containers:
            - name: mongod
              resources:
                requests:
                  cpu: "2"
                  memory: 8Gi
                limits:
                  cpu: "4"
                  memory: 16Gi
            - name: mongodb-agent
              resources:
                requests:
                  cpu: 250m
                  memory: 256Mi
                limits:
                  cpu: 500m
                  memory: 512Mi
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - topologyKey: topology.kubernetes.io/zone
                  labelSelector:
                    matchLabels:
                      app: production-mongodb-svc
          tolerations:
            - key: "workload"
              operator: "Equal"
              value: "database"
              effect: "NoSchedule"
      volumeClaimTemplates:
        - metadata:
            name: data-volume
          spec:
            storageClassName: gp3-csi
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 100Gi
        - metadata:
            name: logs-volume
          spec:
            storageClassName: gp3-csi
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 10Gi

Esta especificação cria um conjunto de réplicas de três membros executando MongoDB 7.0 com autenticação SCRAM, criptografia TLS, dados separados e volumes de log, antiafinidade de pod entre zonas de disponibilidade e ajuste WiredTiger apropriado para um nó com 16 GB de RAM. O operador trata da inicialização do conjunto de réplicas, da configuração do membro e das atualizações contínuas quando você altera o campoversion.

Percona para Operador MongoDB

O Operador Percona para MongoDB (Operador PSMDB) oferece uma alternativa mais rica em recursos ao Operador Comunitário. Ele implanta o Percona Server para MongoDB (um substituto imediato para o MongoDB com recursos empresariais adicionais), gerencia clusters fragmentados, bem como conjuntos de réplicas, integra backup via Percona Backup for MongoDB (PBM) e oferece suporte à recuperação pontual.

# Install Percona Operator
helm repo add percona https://percona.github.io/percona-helm-charts/
helm repo update

helm install psmdb-operator percona/psmdb-operator \
  --namespace psmdb \
  --create-namespace

# Percona Server for MongoDB Cluster CRD
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDB
metadata:
  name: production-psmdb
  namespace: databases
spec:
  crVersion: "1.16.0"
  image: percona/percona-server-mongodb:7.0.12-7
  imagePullPolicy: IfNotPresent

  replsets:
    - name: rs0
      size: 3
      resources:
        requests:
          cpu: "2"
          memory: 8Gi
        limits:
          cpu: "4"
          memory: 16Gi
      volumeSpec:
        persistentVolumeClaim:
          storageClassName: gp3-csi
          accessModes: [ReadWriteOnce]
          resources:
            requests:
              storage: 100Gi
      nonvoting:
        enabled: false
      arbiter:
        enabled: false
      configuration: |
        storage:
          wiredTiger:
            engineConfig:
              cacheSizeGB: 4
              journalCompressor: snappy
            collectionConfig:
              blockCompressor: snappy
        operationProfiling:
          mode: slowOp
          slowOpThresholdMs: 100
        replication:
          oplogSizeMB: 51200
      affinity:
        antiAffinityTopologyKey: topology.kubernetes.io/zone

  sharding:
    enabled: false

  mongos: {}
  configsrv: {}

  backup:
    enabled: true
    image: percona/percona-backup-mongodb:2.5.0
    storages:
      s3-backup:
        type: s3
        s3:
          bucket: company-mongodb-backups
          region: us-east-1
          credentialsSecret: aws-s3-credentials
          prefix: production
          insecureSkipTLSVerify: false
    pitr:
      enabled: true
      oplogOnly: false
      compressionType: gzip
    tasks:
      - name: daily-full
        enabled: true
        schedule: "0 3 * * *"
        keep: 7
        storageName: s3-backup
        compressionType: gzip

  secrets:
    users: mongodb-users-secret

  pmm:
    enabled: true
    image: percona/pmm-client:2
    serverHost: pmm-server.monitoring

A principal vantagem do Operador Percona é seu gerenciamento de backup integrado com Percona Backup for MongoDB (PBM). O PBM oferece suporte a backups lógicos e físicos, backups incrementais e recuperação pontual do oplog, tudo configurado de forma declarativa por meio do CRD.

AWS: DocumentDB vs Atlas vs autogerenciado no EKS

Amazon DocumentDBé um serviço de banco de dados de documentos compatível com MongoDB. Não é MongoDB — é um mecanismo proprietário que implementa o protocolo de fio MongoDB (compatível até MongoDB 4.0 API). O DocumentDB separa a computação do armazenamento usando uma camada de armazenamento distribuído semelhante ao Aurora. Ele fornece failover automático dentro de uma região, até 15 réplicas de leitura e recuperação pontual. No entanto, faltam muitos recursos do MongoDB: os fluxos de mudança têm limitações, as transações funcionam de maneira diferente e muitos estágios do pipeline de agregação não são suportados. Use o DocumentDB somente se seu aplicativo usar um subconjunto do API do MongoDB e você valorizar a simplicidade operacional de um serviço totalmente gerenciado.

MongoDB Atlas na AWSé o serviço gerenciado próprio da MongoDB executado na infraestrutura AWS. Ele fornece MongoDB genuíno com todos os recursos, alta disponibilidade automatizada, backups contínuos, recuperação pontual, escalonamento automático e clusters multirregionais. Atlas é o caminho mais fácil para a produção do MongoDB, mas é a opção mais cara em escala.

autogerenciado no EKSoferece controle total sobre a versão, configuração e custo da MongoDB. Use o MongoDB Community Operator ou Percona Operator com armazenamento EBS gp3 e funções IAM para contas de serviço (IRSA) para acesso seguro ao backup S3.

# EBS StorageClass optimised for MongoDB
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-csi
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "6000"
  throughput: "250"
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

# IRSA for backup S3 access
eksctl create iamserviceaccount \
  --name mongodb-backup-sa \
  --namespace databases \
  --cluster my-eks-cluster \
  --attach-policy-arn arn:aws:iam::111122223333:policy/MongoDBBackupS3Policy \
  --approve

Azure: Cosmos DB vs Atlas vs Autogerenciado em AKS

Azure Cosmos DB para MongoDB (vCore)é a oferta nativa Azure mais próxima do MongoDB real. Ao contrário do antigo Cosmos DB API baseado em RU para MongoDB, o modelo vCore executa instâncias reais do mecanismo MongoDB em computação dedicada, fornecendo alta compatibilidade com recursos do MongoDB 6.0+, incluindo pipeline de agregação completo, fluxos de mudança e transações. Ele oferece alta disponibilidade com redundância de zona, recuperação pontual e backups automáticos.

MongoDB Atlas no Azure Ooferece a mesma experiência MongoDB totalmente gerenciada que no AWS, executando na infraestrutura Azure com peering VNET, Azure Private Link e integração Azure AD.

autogerenciado no AKSusa discos gerenciados Azure (recomenda-se SSD Premium v2) com o operador MongoDB ou Percona.

# Azure Premium SSD StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-premium-mongodb
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
  cachingMode: None
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

GCP: Atlas no GCP versus autogerenciado no GKE

MongoDB Atlas no GCPé executado na infraestrutura do Google Cloud com integrações nativas do GCP: peering de VPC, Private Service Connect e integração de cluster do GKE. O Atlas no GCP oferece suporte a clusters multirregionais que abrangem regiões do GCP com failover automático.

autogerenciado no GKEusa SSD de disco permanente com o operador MongoDB ou Percona. O GKE Workload Identity fornece autenticação segura e sem chave para backup no GCS.

# GKE SSD StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-ssd-mongodb
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

Bare Metal k3s/Rancher com Longhorn

Para soberania de dados, conformidade ou otimização de custos, o MongoDB funciona de forma eficaz em Kubernetes bare metal usando k3s com gerenciamento Rancher e armazenamento distribuído Longhorn. Essa arquitetura elimina dependências de provedores de nuvem, mantendo o mesmo modelo de gerenciamento baseado em operadora.

para MongoDB

# Install Longhorn
helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.storageMinimalAvailablePercentage=15

# StorageClass for MongoDB on Longhorn
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-mongo
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  dataLocality: best-effort
  fsType: xfs
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

XFS é recomendado em vez de ext4 para MongoDB no Linux. O mecanismo de armazenamento WiredTiger do MongoDB se beneficia dos padrões de alocação do XFS, especialmente para diários e arquivos de dados. A replicação de três vias do Longhorn fornece redundância em nível de volume além da redundância em nível de conjunto de réplicas do MongoDB, proporcionando defesa profunda contra falhas de armazenamento.

MetalLB e serviços sem cabeça

# MetalLB IP Pool for MongoDB
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: mongo-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.220-192.168.1.225
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: mongo-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - mongo-pool

O operador MongoDB cria um serviço headless que fornece a cada pod um nome DNS estável (mongo-0.mongo-svc.databases.svc.cluster.local). Isto é essencial para a descoberta de membros do conjunto de réplicas. Se você precisar de acesso externo, o MetalLB atribui um IP roteável a um serviço LoadBalancer na frente dos roteadores mongos (para clusters fragmentados) ou primário (para conjuntos de réplicas).

MongoDB oferece múltiplas abordagens de backup, cada uma adequada para diferentes cenários.

mongodump/mongorestore

Backups lógicos que exportam documentos BSON. Portátil e inspecionável por humanos, mas lento para grandes conjuntos de dados e não suporta recuperação pontual por si só.

# Full logical backup with oplog for consistency
mongodump --uri="mongodb://backup-user:password@mongo-0:27017,mongo-1:27017,mongo-2:27017/appdb?replicaSet=rs-production&authSource=admin" \
  --oplog \
  --gzip \
  --out=/backups/$(date +%Y%m%d-%H%M%S)

# Restore
mongorestore --uri="mongodb://admin:password@mongo-0:27017/?replicaSet=rs-production&authSource=admin" \
  --oplogReplay \
  --gzip \
  /backups/20260412-030000/

Percona Backup para MongoDB (PBM)

PBM fornece backups físicos, backups incrementais e recuperação pontual. É a ferramenta de backup recomendada para MongoDB autogerenciada em produção.

# Configure PBM storage
pbm config --set storage.type=s3 \
  --set storage.s3.bucket=company-mongodb-backups \
  --set storage.s3.region=us-east-1 \
  --set storage.s3.credentials.access-key-id=$AWS_ACCESS_KEY \
  --set storage.s3.credentials.secret-access-key=$AWS_SECRET_KEY

# Full backup
pbm backup --type=logical --compression=gzip

# Physical backup (faster, requires WiredTiger)
pbm backup --type=physical --compression=gzip

# Incremental backup
pbm backup --type=incremental --base-snapshot=2026-04-12T03:00:00Z

# Point-in-time recovery
pbm restore --time="2026-04-12T09:30:00Z"

# List backups
pbm list

# Check backup status
pbm status

Em provedores de nuvem, os snapshots do EBS (AWS), os snapshots de disco gerenciado (Azure) e os snapshots de disco persistente (GCP) fornecem backups rápidos em nível de armazenamento. Combinados com odb.fsyncLock()para consistência pontual, eles oferecem tempos de backup e restauração mais rápidos para grandes conjuntos de dados.

# Kubernetes VolumeSnapshot for MongoDB
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mongodb-snapshot-$(date +%Y%m%d)
  namespace: databases
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: data-volume-production-mongodb-0

Recuperação Point-in-Time Baseada em Oplog

O oplog permite recuperação pontual (PITR) quando combinado com um backup base. O PBM arquiva continuamente entradas de oplog no armazenamento de backup. Para restaurar para um momento específico, o PBM restaura o backup base mais recente e, em seguida, reproduz as entradas do oplog até o carimbo de data/hora de destino. Isso é configurado no Percona Operator CRD por meio da seçãopitr.

para HA

A configuração adequada da cadeia de conexão é crítica para a resiliência do aplicativo durante eventos de failover.

# Standard connection string with all replica set members
mongodb://appuser:password@mongo-0.mongo-svc:27017,mongo-1.mongo-svc:27017,mongo-2.mongo-svc:27017/appdb?replicaSet=rs-production&w=majority&j=true&readPreference=secondaryPreferred&retryWrites=true&retryReads=true&connectTimeoutMS=10000&socketTimeoutMS=30000&serverSelectionTimeoutMS=15000&maxPoolSize=100&minPoolSize=10

# SRV-based connection string (DNS discovery)
mongodb+srv://appuser:password@mongo-cluster.databases.svc.cluster.local/appdb?w=majority&retryWrites=true&readPreference=nearest

# For sharded clusters (connect through mongos)
mongodb://appuser:password@mongos-0:27017,mongos-1:27017/appdb?w=majority&retryWrites=true&readPreference=nearest

Principais parâmetros de cadeia de conexão para HA:retryWrites=trueeretryReads=truepermitem novas tentativas automáticas de operações que falham durante o failover.w=majoritygarante que as gravações sobrevivam às eleições primárias. OserverSelectionTimeoutMScontrola quanto tempo o driver espera para encontrar um servidor adequado – configure-o para um tempo de eleição superior ao esperado (pelo menos 15 segundos).maxPoolSizelimita o pool de conexões por membro do conjunto mongos/réplica para evitar o esgotamento da conexão.

e desempenho de consulta

são a principal alavanca para o desempenho de consultas MongoDB. Um índice ausente em um campo consultado com frequência força uma varredura de coleção que se degrada linearmente com o tamanho dos dados.

# Create compound index for common query pattern
db.orders.createIndex(
  { customer_id: 1, order_date: -1, status: 1 },
  { name: "idx_customer_orders", background: true }
)

# Partial index (only index documents matching a filter)
db.events.createIndex(
  { timestamp: 1 },
  { name: "idx_active_events", partialFilterExpression: { status: "active" } }
)

# TTL index for automatic document expiration
db.sessions.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 86400, name: "idx_session_ttl" }
)

# Text index for search
db.products.createIndex(
  { name: "text", description: "text" },
  { weights: { name: 10, description: 5 }, name: "idx_product_search" }
)

# Analyze query performance
db.orders.find({ customer_id: "c123" }).sort({ order_date: -1 }).explain("executionStats")

# Find unused indexes
db.orders.aggregate([ { $indexStats: {} } ])

Revise o$indexStatsregularmente para identificar índices não utilizados que desperdiçam armazenamento e tornam as gravações lentas. Use o métodoexplain()para verificar se as consultas usam o índice esperado e verifique se hátotalDocsExaminedalto em relação anReturned, o que indica um plano de consulta ineficiente.

WiredTiger é o mecanismo de armazenamento padrão e único de produção do MongoDB desde o MongoDB 4.2. Suas características de desempenho são fortemente influenciadas pelo dimensionamento do cache, pela compactação e pela configuração do diário.

# WiredTiger configuration in mongod.conf
storage:
  dbPath: /data/db
  journal:
    enabled: true
    commitIntervalMs: 100
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4            # ~50% of (RAM - 1GB), max 80%
      journalCompressor: snappy
      directoryForIndexes: true  # separate dir for index files
    collectionConfig:
      blockCompressor: snappy   # or zstd for better ratio
    indexConfig:
      prefixCompression: true

operationProfiling:
  mode: slowOp
  slowOpThresholdMs: 100

replication:
  oplogSizeMB: 51200            # 50 GB oplog
  replSetName: rs-production

net:
  maxIncomingConnections: 10000
  compression:
    compressors: snappy,zstd,zlib

setParameter:
  wiredTigerConcurrentReadTransactions: 128
  wiredTigerConcurrentWriteTransactions: 128

O cache do WiredTiger deve ser dimensionado para conter seu conjunto de trabalho – os dados e índices acessados ativamente por suas consultas. Se o cache for muito pequeno, o WiredTiger despeja páginas com frequência, causando alta E/S. Se for muito grande, deixará memória insuficiente para o cache do sistema de arquivos do sistema operacional e outros processos. Um ponto de partida é 50% da RAM disponível menos 1 GB (para o sistema operacional e outros processos), limitado ao tamanho do conjunto de trabalho.

e criptografia TLS

# Generate TLS certificates for MongoDB
# CA certificate
openssl req -x509 -newkey rsa:4096 -days 3650 -nodes \
  -keyout ca.key -out ca.crt \
  -subj "/CN=MongoDB-CA"

# Server certificate (include all member hostnames in SAN)
openssl req -newkey rsa:4096 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=mongo-0.mongo-svc.databases.svc.cluster.local" \
  -addext "subjectAltName=DNS:mongo-0.mongo-svc.databases.svc.cluster.local,DNS:mongo-1.mongo-svc.databases.svc.cluster.local,DNS:mongo-2.mongo-svc.databases.svc.cluster.local,DNS:localhost,IP:127.0.0.1"

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365

# Combine cert and key into PEM
cat server.crt server.key > server.pem

# Create Kubernetes secrets
kubectl create secret tls mongodb-tls-cert \
  --cert=server.crt --key=server.key -n databases

kubectl create secret generic mongodb-ca-cert \
  --from-file=ca.crt=ca.crt -n databases

# MongoDB TLS configuration (mongod.conf)
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/tls/server.pem
    CAFile: /etc/mongodb/tls/ca.crt
    allowConnectionsWithoutCertificates: false

security:
  authorization: enabled
  clusterAuthMode: x509

com Prometheus e Grafana

MongoDB expõe métricas através domongodb_exporter(da Percona) que se integra ao Prometheus. As principais métricas a serem monitoradas incluem contagens de conexões, taxas de operação, atraso de replicação, uso de cache do WiredTiger e eficiência de direcionamento de consulta.

# Deploy mongodb_exporter as a sidecar or standalone
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb-exporter
  namespace: databases
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb-exporter
  template:
    metadata:
      labels:
        app: mongodb-exporter
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9216"
    spec:
      containers:
        - name: exporter
          image: percona/mongodb_exporter:0.40.0
          args:
            - --mongodb.uri=mongodb://monitoring:password@production-mongodb-0.production-mongodb-svc:27017,production-mongodb-1.production-mongodb-svc:27017,production-mongodb-2.production-mongodb-svc:27017/?replicaSet=rs-production&authSource=admin
            - --collect-all
            - --compatible-mode
          ports:
            - containerPort: 9216
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

# ServiceMonitor for Prometheus Operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: mongodb-metrics
  namespace: databases
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: mongodb-exporter
  endpoints:
    - port: metrics
      interval: 15s
      scrapeTimeout: 10s

# Critical Prometheus alert rules for MongoDB
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: mongodb-alerts
  namespace: databases
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: mongodb-health
      rules:
        - alert: MongoDBReplicationLagHigh
          expr: mongodb_mongod_replset_member_replication_lag > 30
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "MongoDB replica {{ $labels.name }} lag exceeds 30s"

        - alert: MongoDBConnectionsHigh
          expr: mongodb_connections{state="current"} / mongodb_connections{state="available"} > 0.8
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "MongoDB connections above 80% capacity"

        - alert: MongoDBWiredTigerCacheEvictions
          expr: rate(mongodb_wiredtiger_cache_evicted_pages_total[5m]) > 100
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "High WiredTiger cache eviction rate"

        - alert: MongoDBReplicaSetNoPrimary
          expr: mongodb_mongod_replset_number_of_members{state="PRIMARY"} == 0
          for: 1m
          labels:
            severity: critical
          annotations:
            summary: "MongoDB replica set has no primary"

        - alert: MongoDBQueryTargetingInefficient
          expr: rate(mongodb_mongod_metrics_query_executor_total{state="scanned_objects"}[5m]) / rate(mongodb_mongod_metrics_query_executor_total{state="returned"}[5m]) > 100
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "MongoDB scanning 100x more documents than returned"

Alterar fluxos para aplicações em tempo real

fornecem um mecanismo de notificação em tempo real para alterações de dados no MongoDB. Eles aproveitam o oplog para enviar eventos de mudança aos aplicativos, permitindo arquiteturas orientadas a eventos, painéis em tempo real e pipelines de sincronização de dados sem pesquisa.

// Watch changes on a collection
const pipeline = [
  { $match: { operationType: { $in: ["insert", "update", "replace"] } } },
  { $match: { "fullDocument.status": "active" } }
];

const changeStream = db.collection("orders").watch(pipeline, {
  fullDocument: "updateLookup",  // include full document on updates
  resumeAfter: resumeToken       // resume from last processed event
});

changeStream.on("change", (change) => {
  console.log("Change detected:", change.operationType);
  console.log("Document:", change.fullDocument);
  // Store resume token for crash recovery
  saveResumeToken(change._id);
});

changeStream.on("error", (error) => {
  console.error("Change stream error:", error);
  // Reconnect using saved resume token
});

requerem um conjunto de réplicas ou cluster fragmentado (eles não funcionam em instâncias mongod independentes). Eles sobrevivem às eleições primárias – o driver se reconecta automaticamente e retoma a partir do último token de currículo recebido. Para uso em produção, sempre persista o token de retomada para que seu aplicativo possa se recuperar das reinicializações sem perder eventos.

MongoDB oferece suporte a atualizações contínuas nas quais você atualiza um membro do conjunto de réplicas por vez, começando com os secundários e terminando com o primário (o que aciona uma redução e uma eleição). Isso permite atualizações sem tempo de inatividade para alterações de versão principais e secundárias.

# Rolling upgrade procedure for self-managed replica set
# 1. Upgrade each secondary one at a time
# On secondary (mongo-2):
sudo systemctl stop mongod
sudo yum install -y mongodb-org-7.0.14  # or apt-get
sudo systemctl start mongod
# Wait for the member to reach SECONDARY state
rs.status()

# 2. Step down the primary
rs.stepDown()

# 3. Upgrade the old primary (now a secondary)
sudo systemctl stop mongod
sudo yum install -y mongodb-org-7.0.14
sudo systemctl start mongod

# 4. Verify cluster health
rs.status()
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

# 5. Set feature compatibility version (irreversible)
db.adminCommand({ setFeatureCompatibilityVersion: "7.0" })

Com o MongoDB Community Operator ou Percona Operator no Kubernetes, as atualizações contínuas são automatizadas — basta atualizar o campoversionno CRD e o operador lida com a atualização contínua de cada pod, aguardando que cada membro se torne íntegro antes de continuar.

Recuperação de desastres e teste de failover

Uma implantação de alta disponibilidade que nunca foi testada sob falha não foi testada. Testes regulares de failover validam sua arquitetura, seus alertas de monitoramento e os procedimentos de resposta a incidentes de sua equipe.

# Test 1: Step down the primary
rs.stepDown(120)  // 120-second election hold
// Monitor: election should complete in ~10-12s
// Verify: application reconnects and resumes operations

# Test 2: Kill a secondary pod in Kubernetes
kubectl delete pod production-mongodb-1 -n databases --grace-period=0 --force
// The StatefulSet recreates the pod
// The operator rejoins it to the replica set

# Test 3: Simulate network partition
kubectl exec production-mongodb-0 -n databases -- \
  iptables -A INPUT -p tcp --dport 27017 -j DROP
// The isolated primary should step down (cannot reach majority)
// Remaining members elect a new primary
// Cleanup: remove iptables rule and let member rejoin

# Test 4: Simulate storage failure
kubectl exec production-mongodb-2 -n databases -- \
  chmod 000 /data/db
// mongod should crash; Kubernetes restarts the pod
// The member resyncs from the primary's oplog

O que medir durante o failover

• RTO (objetivo de tempo de recuperação)— Tempo desde a falha primária até a aceitação de novas gravações primárias. Meta: menos de 30 segundos para conjuntos de réplicas.
• RPO (objetivo de ponto de recuperação)— Perda de dados durante failover. Comw: majority, o RPO é zero para gravações confirmadas. Comw: 1, o RPO é igual ao atraso de replicação no momento da falha.
• Taxa de erros do aplicativo— Porcentagem de solicitações que falham durante a janela de failover. ComretryWrites=true, a maioria das falhas de gravação são repetidas automaticamente pelo driver.
• Continuidade do fluxo de mudança— Verifique se os consumidores do fluxo de mudança retomam a partir de seu token salvo sem perder eventos.

1. Falha de membro único— Recuperação automática por meio de reinicialização do pod Kubernetes e atualização do oplog. Nenhuma ação manual é necessária, a menos que o membro precise de uma ressincronização completa.
2. Falha primária— A eleição automática promove um secundário dentro de 10 a 12 segundos. Verifique a conectividade do aplicativo e o atraso de replicação nos secundários restantes.
3. Falha majoritária— Se a maioria dos membros estiver inativa, o conjunto de réplicas se tornará somente leitura (não é possível fazer eleições). Restaure membros ou users.reconfig({ force: true })como último recurso (isso pode causar perda de dados).
4. Perda completa de cluster— Implante um novo cluster, restaure a partir do backup PBM mais recente e reproduza o oplog para o ponto no tempo de destino. Atualize strings de conexão e registros DNS.
5. Failover regional— Se a região primária for perdida, um secundário em outra região será automaticamente eleito primário (se tiver prioridade suficiente e os membros restantes formarem a maioria). Atualize o DNS para rotear o tráfego para a nova região primária.

# Disable Transparent Huge Pages (critical for MongoDB)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Set readahead to 8-32 sectors for SSD
blockdev --setra 32 /dev/sda

# Increase file descriptor limits
ulimit -n 64000
ulimit -u 64000

# Swappiness
vm.swappiness = 1

# Dirty page ratio
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# Network tuning
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_keepalive_time = 120

• WiredTiger cache: 50% da RAM disponível menos 1 GB ou o tamanho do seu conjunto de trabalho, o que for menor.
• Tamanho do Oplog: Suficiente para armazenar 24 a 72 horas de operações de gravação. Comece com 50 GB e monitore comrs.printReplicationInfo().
• IOPS de armazenamento: MongoDB exige muita E/S, especialmente durante compactação e checkpoint. Use SSD NVMe ou armazenamento em nuvem com IOPS provisionados (gp3 com mais de 6.000 IOPS no AWS, Premium SSD v2 no Azure, pd-ssd no GCP).
• CPU: MongoDB se beneficia de múltiplos núcleos para operações simultâneas de leitura/gravação, transações simultâneas do WiredTiger e tarefas em segundo plano (ponto de verificação, compactação, replicação).
Rede
• : O tráfego de replicação pode ser significativo para cargas de trabalho com uso intenso de gravação. Garanta redes de baixa latência e alta largura de banda entre membros do conjunto de réplicas.

# Application-side connection pool configuration
const client = new MongoClient(uri, {
  maxPoolSize: 100,
  minPoolSize: 10,
  maxIdleTimeMS: 60000,
  waitQueueTimeoutMS: 5000,
  connectTimeoutMS: 10000,
  socketTimeoutMS: 30000,
  serverSelectionTimeoutMS: 15000,
  retryWrites: true,
  retryReads: true,
  w: "majority",
  readPreference: "secondaryPreferred",
  compressors: ["snappy", "zstd"]
});

• Atraso de replicação— Alerta quando qualquer secundário excede 30 segundos de atraso.
• Saturação da conexão— Alerta quando as conexões atuais excedem 80% domaxIncomingConnections.
• WiredTiger cache— Alerta quando a taxa de preenchimento sujo do cache excede 20% (indica que a pressão de gravação excede a taxa de transferência do ponto de verificação).
• Janela de oplog— Alerta quando a janela de oplog cai abaixo de 12 horas (risco de os secundários precisarem de ressincronização completa após a manutenção).
• Consulta direcionada ao— Alerta quando a proporção de documentos digitalizados para documentos devolvidos excede 100 (índice ausente).
• Uso do disco— Alerta nos limites de 70% e 85%. A MongoDB pode usar um espaço temporário significativo em disco durante a compactação.
• Atualização do backup— Alerta quando o último backup bem-sucedido é mais antigo que a janela do RPO.
• Disponibilidade de tickets— Monitore a leitura e gravação de tickets do WiredTiger. A exaustão causa filas de operações e picos de latência.

# Replica set status
rs.status()
rs.conf()
rs.printReplicationInfo()
rs.printSecondaryReplicationInfo()

# Cluster health (sharded)
sh.status()
db.adminCommand({ balancerStatus: 1 })
db.adminCommand({ listShards: 1 })

# Server diagnostics
db.serverStatus()
db.currentOp({ "$all": true })
db.adminCommand({ hostInfo: 1 })

# Kill long-running operations
db.killOp(opId)

# Compaction (reclaim disk space)
db.runCommand({ compact: "orders" })

# Profiler (identify slow queries)
db.setProfilingLevel(1, { slowms: 100 })
db.system.profile.find().sort({ ts: -1 }).limit(10)

# Index management
db.orders.getIndexes()
db.orders.createIndex({ field: 1 }, { background: true })
db.orders.dropIndex("index_name")

# Kubernetes-specific
kubectl get mongodbcommunity -n databases
kubectl describe mongodbcommunity production-mongodb -n databases
kubectl logs production-mongodb-0 -n databases -c mongod
kubectl exec -it production-mongodb-0 -n databases -c mongod -- mongosh

: Escolhendo sua arquitetura MongoDB HA

• Nuvem única, preferência gerenciada— Use MongoDB Atlas. Ele lida com HA, backups, monitoramento e escalonamento com sobrecarga operacional mínima.
• AWS compatível com MongoDB precisa apenas de— considere o Amazon DocumentDB se seu aplicativo usa um subconjunto básico do MongoDB API e você deseja uma experiência totalmente gerenciada. Caso contrário, Atlas ou autogerenciado no EKS.
• Azure com recursos completos do MongoDB— Use o Cosmos DB para MongoDB vCore para uma experiência gerenciada ou o Atlas no Azure para o serviço gerenciado MongoDB genuíno.
• Multinuvem ou híbrida— Autogerenciado com o Operador Comunitário MongoDB ou Operador Percona. A abstração Kubernetes permite implantação consistente entre provedores.
• Bare metal ou edge— k3s + Rancher + Longhorn + MongoDB Community Operator ou Percona Operator. Não são necessárias dependências de nuvem.
• Escalabilidade horizontal em grande escala— Cluster fragmentado com fragmentação de zona para localidade de dados. Use o Operador Percona que oferece suporte nativo a implantações fragmentadas.
• Aplicativos orientados a eventos em tempo real— Os fluxos de mudança MongoDB fornecem CDC integrado. Certifique-se de usar um conjunto de réplicas ou cluster fragmentado (não autônomo).

MongoDB oferecem uma vantagem arquitetônica para alta disponibilidade – conjuntos de réplicas com failover automático e clusters fragmentados com escalabilidade horizontal são recursos nativos, e não considerações posteriores. Mas estas primitivas devem ser configuradas corretamente e operadas com disciplina para fornecer as garantias de disponibilidade que os sistemas de produção exigem.

Uma implantação de produção MongoDB requer três membros do conjunto de réplicas com suporte de dados em domínios de falha, preocupação de gravação dow: majoritycom durabilidade, dimensionamento de oplog adequado para resiliência de replicação, ajuste de cache WiredTiger para seu conjunto de trabalho e uma estratégia de backup testada com capacidade de recuperação pontual. Os operadores Kubernetes — seja o MongoDB Community Operator para conjuntos de réplicas ou o Percona Operator para implantações completas, incluindo fragmentação e backups integrados — automatizam o gerenciamento do ciclo de vida que, de outra forma, exigiria um investimento operacional significativo.

Os padrões de implantação em AWS, Azure, GCP e bare metal compartilham a mesma configuração principal do MongoDB. O que muda é a classe de armazenamento, o destino do backup e a camada de rede. Essa consistência é o valor de uma abordagem baseada em operadores: sua equipe aprende uma ferramenta, um modelo operacional e um conjunto de runbooks que funcionam em qualquer lugar.

Comece com um conjunto de réplicas de três membros, gravaçõesw: majority, um backup PBM diário com arquivamento oplog contínuo e os principais alertas Prometheus para atraso de replicação, saturação de conexão e pressão de cache. Teste seu failover no primeiro dia, não durante o primeiro incidente. Expanda para fragmentação, localidade de dados baseada em zona e implantações multirregionais à medida que seu volume de dados e requisitos de disponibilidade aumentam. A infraestrutura cuida da mecânica; sua responsabilidade é compreender a arquitetura profundamente o suficiente para fazer as compensações corretas para sua carga de trabalho e testar essas suposições incansavelmente.