MongoDB Hoge beschikbaarheid in productie: replicasets, sharding en Kubernetes-operators

MongoDB neemt een unieke positie in het databaselandschap in. Het documentmodel is op natuurlijke wijze gekoppeld aan applicatieobjecten, het flexibele schema is geschikt voor evoluerende datastructuren zonder migraties, en de ingebouwde replicatie- en sharding-primitieven bieden een basis voor hoge beschikbaarheid en horizontale schaling waarvoor relationele databases externe tools nodig hebben. Maar een fundament is geen voltooid gebouw. Het draaien van MongoDB in productie met echte hoge beschikbaarheid (waarbij het uitvallen van een knooppunt, een netwerkpartitie of het offline gaan van een hele regio niet resulteert in downtime of gegevensverlies) vereist weloverwogen architectuur, zorgvuldige afstemming en rigoureuze operationele discipline.

Deze handleiding doorloopt elke laag van MongoDB HA: van het replicaset-consensusprotocol en oplog-replicatie die automatische failover mogelijk maken, via de sharded clusterarchitectuur die horizontaal schalen mogelijk maakt, tot de Kubernetes-operators die het levenscyclusbeheer automatiseren, en over de implementatieopties op AWS, Azure, GCP en bare metal k3s met Rancher. Elke sectie bevat concrete configuraties, YAML-manifesten en operationele procedures die u aan uw omgeving kunt aanpassen.

MongoDB Replicaset-architectuur

Een replicaset is de fundamentele eenheid van hoge beschikbaarheid van MongoDB. Het is een groepmongod-processen die dezelfde dataset onderhouden. Eén lid is deprimaire, die alle schrijfbewerkingen ontvangt. De overige leden zijnsecundaire, die gegevens van de primaire repliceren door het bewerkingslogboek (oplog) te volgen. Als de primaire niet meer beschikbaar is, bevat de replicaset een verkiezing om een ​​nieuwe primaire te kiezen uit de in aanmerking komende secundaire onderdelen – doorgaans binnen 10 tot 12 seconden.

Een productiereplicaset moet ten minste drie gegevensdragende leden hebben, idealiter verspreid over verschillende storingsdomeinen (beschikbaarheidszones, racks of datacenters). Dit zorgt ervoor dat de replicaset het verlies van een enkel lid kan overleven en toch een meerderheid kan behouden voor verkiezingsdoeleinden. Een optionele-arbiterneemt deel aan verkiezingen, maar houdt geen gegevens bij - deze bestaat uitsluitend om de banden te verbreken als u een even aantal gegevensdragende leden heeft, hoewel de beste praktijk van MongoDB is om in plaats daarvan een oneven aantal gegevensdragende leden te gebruiken.

Oplog en replicatiemechanica

De oplog is een afgetopte verzameling (local.oplog.rs) die elke gegevenswijzigingsbewerking op de primaire in idempotente vorm registreert. Secondaries volgen voortdurend de oplog van de primaire en passen bewerkingen lokaal toe. De grootte van de oplog bepaalt hoe ver achter een secundaire kan komen voordat deze volledig opnieuw moet worden gesynchroniseerd. Voor productieworkloads moet u de oplog zo groot maken dat deze minimaal 24 tot 72 uur aan schrijfactiviteit kan bevatten. MongoDB 4.4+ ondersteunt dynamische oplog-grootte 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()

Verkiezingen en het op vlot gebaseerde protocol

MongoDB 4.0+ maakt gebruik van een op Raft geïnspireerd consensusprotocol voor replicaset-verkiezingen. Wanneer een secundaire detecteert dat de primaire onbereikbaar is (standaardelectionTimeoutMillisvan 10.000 ms), kan deze een verkiezing uitschrijven. Om te winnen moet een kandidaat stemmen krijgen van een meerderheid van de stemgerechtigde leden. Het lid met de meest recente oploginzending en de hoogste prioriteit wint als meerdere kandidaten in aanmerking komen. U kunt de verkiezingsresultaten beïnvloeden door ledenprioriteiten te stellen; een lid metpriority: 0kan nooit primair worden, wat handig is voor analysereplica's of leden in afgelegen regio's.

# 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 })

Leesvoorkeur en schrijfprobleem

Leesvoorkeurbepaalt waar de bestuurder leesbewerkingen verzendt. De opties zijn:

• primary— Alle leesbewerkingen gaan naar de primaire. Sterkste consistentie maar geen leesschaling.
• primaryPreferred— Lezingen gaan naar de primaire, tenzij deze niet beschikbaar is, en vervolgens naar een secundaire.
• secondary— Alle leesbewerkingen gaan naar secundaire bestanden. Biedt leesschaling, maar retourneert mogelijk verouderde gegevens.
• secondaryPreferred— Lezingen gaan naar secundaire bestanden, tenzij er geen beschikbaar zijn.
• nearest— Leesbewerkingen gaan naar het lid met de laagste netwerklatentie, ongeacht de rol. Het beste voor geografisch gedistribueerde implementaties.

Schrijfprobleembepaalt hoeveel leden van de replicaset een schrijfactie moeten bevestigen voordat de bewerking terugkeert naar de client.

• w: 1— Alleen de primaire moet bevestigen. Het snelst, maar er bestaat een risico op gegevensverlies als de primaire mislukt vóór de replicatie.
• w: "majority"— Een meerderheid van de gegevensdragende leden moet dit erkennen. Dit is de aanbevolen productiestandaard. Het garandeert dat de schrijver een voorverkiezing overleeft.
• w: <number>— Een specifiek aantal leden moet dit bevestigen.
• j: true— Het schrijven moet vóór bevestiging worden vastgelegd in het journaal op schijf. Gecombineerd metw: "majority"biedt dit de sterkste duurzaamheidsgarantie.

# 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 Sharded Cluster-architectuur

Een replicaset biedt hoge beschikbaarheid, maar geen horizontale schrijfschaling: alle schrijfbewerkingen gaan naar één primaire schijf. Wanneer uw dataset de capaciteit van een enkele server overschrijdt of uw schrijfdoorvoer groter is dan wat één primaire server aankan, heeft u sharding nodig. Een shard-cluster distribueert gegevens over meerdere replicasets (shards) met behulp van een shard-sleutel, waardoor horizontale schaling van zowel opslag als schrijfdoorvoer mogelijk is.

Een sharded cluster heeft drie componenttypen.mongos-routers zijn staatloze queryrouters die clientbewerkingen naar de juiste shard(s) leiden. Implementeer er ten minste twee voor redundantie.Config-serversvormen een replicaset waarin de metagegevens van het cluster worden opgeslagen: welke chunks op welke shards leven, de shard-sleutelbereiken en de status van de balancer.​​Shard-serverszijn replicasets die elk een subset van de sharded-gegevens bevatten.

Shard-sleutelselectie

De Shard-sleutel is de beslissing met de meeste gevolgen in een Shard-cluster. Het bepaalt hoe gegevens over shards worden verdeeld en heeft rechtstreeks invloed op de prestaties van query's, schrijfdistributie en de mogelijkheid om te schalen. Een goede Shard-sleutel heeft een hoge kardinaliteit (veel verschillende waarden), verdeelt schrijfbewerkingen gelijkmatig over Shards en ondersteunt de meest voorkomende querypatronen met gerichte bewerkingen in plaats van verspreide verzameling.

# 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 } }
])

Veelgebruikte shard-sleutelstrategieën zijn onder meer:gehashte sleutelsvoor uniforme schrijfdistributie (het beste als u geen bereikquery's op de shard-sleutel nodig hebt),samengestelde sleutelsdie een grof groeperingsveld combineren met een veld met hoge kardinaliteit (bijvoorbeeld{ tenant_id: 1, _id: 1 }voor toepassingen met meerdere tenants) enop zones gebaseerde sleutelsdie de plaatsing van gegevens afstemt op geografische regio's.

Zone Sharding voor

Zone-sharding beperkt specifieke bereiken van de shard-sleutel tot specifieke shards, waardoor gegevenslocatie mogelijk wordt. U kunt er bijvoorbeeld voor zorgen dat Europese klantgegevens zich op shards in de EU-regio bevinden, terwijl Amerikaanse klantgegevens zich op shards in de Amerikaanse regio bevinden.

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

MongoDB-implementatie voor meerdere regio's

Het distribueren van MongoDB over meerdere regio's dient twee doelen: noodherstel (het verlies van een hele regio overleven) en latentie-optimalisatie (lezen vanaf de dichtstbijzijnde replica). MongoDB ondersteunt implementaties in meerdere regio's via replicasetleden die over regio's zijn verdeeld, zone-sharding voor gegevenslocatie en leesvoorkeursconfiguratie die leesbewerkingen naar het dichtstbijzijnde lid stuurt.

In een replicaset met vijf leden, verdeeld over drie regio's (2 in de primaire regio, 2 in de DR-regio, 1 in de leesregio), blijven er door het verlies van de primaire regio nog steeds drie leden beschikbaar – genoeg voor een meerderheid om een nieuwe primaire regio te kiezen. Het lid in de leesregio moetpriority: 0hebben om te voorkomen dat deze primair wordt (een hoge latentie tussen de regio's zou de schrijfprestaties verslechteren). Gebruikhidden: truevoor leden die toegewijd zijn aan analyse en die geen reguliere applicatielezingen mogen ontvangen.

MongoDB Community Kubernetes-operator

De MongoDB Community Kubernetes Operator implementeert en beheert MongoDB-replicasets op Kubernetes. Het is de open-source operator van MongoDB Inc. die het StatefulSet-beheer, de geautomatiseerde replicasetconfiguratie, TLS-certificaatroulatie, gebruikersbeheer en doorlopende upgrades afhandelt.

# 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="*"

MongoDBCommunity CRD-specificatie

De aangepaste bronMongoDBCommunitydefinieert de gewenste status van een MongoDB-replicaset. Hieronder vindt u een productieklare specificatie.

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

Deze specificatie creëert een replicaset met drie leden waarop MongoDB 7.0 draait met SCRAM-authenticatie, TLS-codering, afzonderlijke gegevens- en logvolumes, pod-anti-affiniteit over beschikbaarheidszones en WiredTiger-afstemming geschikt voor een knooppunt met 16 GB RAM. De operator zorgt voor de initialisatie van de replicaset, de configuratie van leden en doorlopende upgrades wanneer u het veldversionwijzigt.

Percona-server voor MongoDB-operator

De Percona Operator voor MongoDB (PSMDB Operator) biedt een alternatief met meer functies voor de Community Operator. Het implementeert Percona Server voor MongoDB (een drop-in vervanging voor MongoDB met extra bedrijfsfuncties), beheert zowel sharded clusters als replicasets, integreert back-up via Percona Backup for MongoDB (PBM) en ondersteunt point-in-time herstel.

# 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

Het belangrijkste voordeel van de Percona Operator is het geïntegreerde back-upbeheer met Percona Backup for MongoDB (PBM). PBM ondersteunt logische en fysieke back-ups, incrementele back-ups en herstel op een bepaald tijdstip vanaf de oplog – allemaal declaratief geconfigureerd via de CRD.

AWS-implementatie: DocumentDB versus Atlas versus zelfbeheer op EKS

Amazon DocumentDBis een MongoDB-compatibele documentdatabaseservice. Het is niet MongoDB - het is een eigen engine die het MongoDB-draadprotocol implementeert (compatibel tot MongoDB 4.0 API). DocumentDB scheidt rekenkracht van opslag met behulp van een gedistribueerde opslaglaag vergelijkbaar met Aurora. Het biedt automatische failover binnen een regio, maximaal 15 leesreplica's en herstel op een bepaald tijdstip. Het mist echter veel MongoDB-functies: veranderingsstromen hebben beperkingen, transacties werken anders en veel fasen van de aggregatiepijplijn worden niet ondersteund. Gebruik DocumentDB alleen als uw applicatie een subset van de API van MongoDB gebruikt en u waarde hecht aan de operationele eenvoud van een volledig beheerde service.

MongoDB Atlas op AWSis de eigen beheerde service van MongoDB die draait op de AWS-infrastructuur. Het biedt echte MongoDB met alle functies, geautomatiseerde HA, continue back-ups, herstel op een bepaald tijdstip, automatisch schalen en clusters met meerdere regio's. Atlas is de gemakkelijkste weg naar productie van MongoDB, maar op schaal de duurste optie.

Zelfbeheerd op EKSgeeft u volledige controle over de MongoDB-versie, configuratie en kosten. Gebruik de MongoDB Community Operator of Percona Operator met EBS gp3-opslag en IAM Roles for Service Accounts (IRSA) voor veilige S3-back-uptoegang.

# 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-implementatie: Cosmos DB versus Atlas versus zelfbeheer op AKS

Azure Cosmos DB voor MongoDB (vCore)is het native Azure-aanbod dat het dichtst in de buurt komt van echte MongoDB. In tegenstelling tot de oudere op RU gebaseerde Cosmos DB API voor MongoDB, voert het vCore-model daadwerkelijke MongoDB-engine-instances uit op speciale rekenkracht, wat een hoge compatibiliteit biedt met MongoDB 6.0+ functies, waaronder volledige aggregatiepijplijn, wijzigingsstromen en transacties. Het biedt zone-redundante HA, herstel op een bepaald tijdstip en automatische back-ups.

MongoDB Atlas op Azurebiedt dezelfde volledig beheerde MongoDB-ervaring als op AWS, uitgevoerd op Azure-infrastructuur met VNET-peering, Azure Private Link en Azure AD-integratie.

Zelfbeheerd op AKSmaakt gebruik van Azure Managed Disks (Premium SSD v2 aanbevolen) met de MongoDB- of Percona-operator.

# 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-implementatie: Atlas op GCP versus zelfbeheer op GKE

MongoDB Atlas op GCPdraait op de Google Cloud-infrastructuur met GCP-native integraties: VPC-peering, Private Service Connect en GKE-clusterintegratie. Atlas op GCP ondersteunt clusters met meerdere regio's die GCP-regio's omspannen met automatische failover.

Zelfbeheerd op GKEmaakt gebruik van Persistent Disk SSD met de MongoDB- of Percona-operator. GKE Workload Identity biedt veilige, sleutelloze authenticatie voor back-up naar 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

Blank metaal k3s/Rancher met Longhorn

Voor datasoevereiniteit, compliance of kostenoptimalisatie draait MongoDB effectief op bare metal Kubernetes met behulp van k3s met Rancher-beheer en gedistribueerde Longhorn-opslag. Deze architectuur elimineert de afhankelijkheden van cloudproviders, terwijl hetzelfde operatorgebaseerde beheermodel behouden blijft.

Longhorn-opslag voor 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 wordt aanbevolen boven ext4 voor MongoDB op Linux. De WiredTiger-opslagengine van MongoDB profiteert van de toewijzingspatronen van XFS, met name voor de journaal- en gegevensbestanden. De driewegreplicatie van Longhorn biedt redundantie op volumeniveau bovenop de replica-redundantie op setniveau van MongoDB, waardoor u diepgaande bescherming krijgt tegen opslagfouten.

MetalLB en Headless Services

# 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

De MongoDB-operator creëert een headless Service die elke pod een stabiele DNS-naam geeft (mongo-0.mongo-svc.databases.svc.cluster.local). Dit is essentieel voor het ontdekken van replicasetleden. Als u externe toegang nodig hebt, wijst MetalLB een routeerbaar IP-adres toe aan een LoadBalancer-service vóór de mongos-routers (voor sharded clusters) of de primaire (voor replicasets).

Back-upstrategieën

MongoDB biedt meerdere back-upbenaderingen, elk geschikt voor verschillende scenario's.

mongodump / mongorestore

Logische back-ups die BSON-documenten exporteren. Draagbaar en door mensen te inspecteren, maar langzaam voor grote datasets en ondersteunen op zichzelf geen herstel op een bepaald tijdstip.

# 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 voor MongoDB (PBM)

PBM biedt fysieke back-ups, incrementele back-ups en herstel op een bepaald tijdstip. Het is de aanbevolen back-uptool voor zelfbeheerde MongoDB in productie.

# 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

Cloud-snapshots

Bij cloudproviders bieden EBS-snapshots (AWS), beheerde schijfsnapshots (Azure) en persistente schijfsnapshots (GCP) snelle back-ups op opslagniveau. Gecombineerd metdb.fsyncLock()voor point-in-time consistentie, bieden ze de snelste back-up- en hersteltijden voor grote datasets.

# 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

Oplog-gebaseerd point-in-time herstel

De oplog maakt point-in-time herstel (PITR) mogelijk in combinatie met een basisback-up. PBM archiveert voortdurend oploggegevens in de back-upopslag. Om te herstellen naar een specifiek tijdstip herstelt PBM de meest recente basisback-up en speelt vervolgens de oplog-items opnieuw af tot aan de doeltijdstempel. Dit wordt in de Percona Operator CRD geconfigureerd via depitr-sectie.

Verbindingsreeksconfiguratie voor HA

Een juiste configuratie van de verbindingsreeks is van cruciaal belang voor de veerkracht van applicaties tijdens failover-gebeurtenissen.

# 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

Belangrijke verbindingsreeksparameters voor HA:retryWrites=trueenretryReads=truemaken automatisch opnieuw proberen mogelijk van bewerkingen die mislukken tijdens een failover.w=majorityzorgt ervoor dat schrijfbewerkingen de voorverkiezingen overleven.serverSelectionTimeoutMSbepaalt hoe lang het stuurprogramma wacht om een ​​geschikte server te vinden – stel deze hoger in dan de verwachte verkiezingstijd (minimaal 15 seconden).maxPoolSizebeperkt de verbindingspool per lid van de mongos/replicaset om uitputting van de verbinding te voorkomen.

Indexoptimalisatie en queryprestaties

-indexen zijn de belangrijkste hefboom voor MongoDB-queryprestaties. Een ontbrekende index op een vaak opgevraagd veld dwingt een collectiescan af die lineair afneemt met de gegevensgrootte.

# 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: {} } ])

Controleer$indexStatsregelmatig om ongebruikte indexen te identificeren die opslag verspillen en trage schrijfbewerkingen veroorzaken. Gebruik deexplain()-methode om te verifiëren dat query's de verwachte index gebruiken en controleer op hogetotalDocsExaminedten opzichte vannReturned, wat duidt op een inefficiënt queryplan.

WiredTiger-opslagmotortuning

WiredTiger is de standaard en enige productieopslagengine van MongoDB sinds MongoDB 4.2. De prestatiekenmerken worden sterk beïnvloed door de cachegrootte, compressie en journaalconfiguratie.

# 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

De WiredTiger-cache moet zo groot zijn dat deze uw werkset kan bevatten: de gegevens en indexen waartoe uw zoekopdrachten actief toegang hebben. Als de cache te klein is, verwijdert WiredTiger pagina's regelmatig, wat een hoge I/O veroorzaakt. Als het te groot is, blijft er onvoldoende geheugen over voor de cache van het besturingssysteembestandssysteem en andere processen. Een uitgangspunt is 50% van het beschikbare RAM minus 1 GB (voor het besturingssysteem en andere processen), met een maximum van de werksetgrootte.

-authenticatie en TLS-codering

# 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

-bewaking met Prometheus en Grafana

MongoDB maakt statistieken zichtbaar via demongodb_exporter(van Percona) die kan worden geïntegreerd met Prometheus. Belangrijke meetgegevens die moeten worden gecontroleerd, zijn onder meer het aantal verbindingen, de werkingssnelheid, de replicatievertraging, het WiredTiger-cachegebruik en de efficiëntie van de zoekopdrachten.

# 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"

Wijzig streams voor realtime toepassingen

Wijzigingsstreams bieden een realtime meldingsmechanisme voor gegevenswijzigingen in MongoDB. Ze maken gebruik van de oplog om veranderingsgebeurtenissen naar applicaties te pushen, waardoor gebeurtenisgestuurde architecturen, realtime dashboards en datasynchronisatiepijplijnen zonder polling mogelijk worden.

// 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
});

Wijzigingsstreams vereisen een replicaset of een sharded cluster (ze werken niet op zelfstandige mongod-instanties). Ze overleven de voorverkiezingen – de chauffeur maakt automatisch opnieuw verbinding en gaat verder vanaf het laatst ontvangen CV-token. Voor productiegebruik moet u altijd het hervattingstoken behouden, zodat uw toepassing kan herstellen na opnieuw opstarten zonder gebeurtenissen te missen.

Rollend onderhoud en versie-upgrades

MongoDB ondersteunt doorlopende upgrades waarbij u één lid van de replicaset tegelijk upgradet, beginnend met secundaire onderdelen en eindigend met de primaire (die een stap omlaag en verkiezing activeert). Dit maakt upgrades zonder downtime mogelijk voor kleine en grote versiewijzigingen.

# 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" })

Met de MongoDB Community Operator of Percona Operator op Kubernetes zijn doorlopende upgrades geautomatiseerd: u werkt eenvoudigweg hetversion-veld in de CRD bij, waarna de operator de voortschrijdende update van elke pod afhandelt, waarbij hij wacht tot elk lid gezond is voordat hij verdergaat.

Noodherstel en failover-testen

Een implementatie met hoge beschikbaarheid die nog nooit is getest onder fouten, is niet getest. Regelmatige failover-tests valideren uw architectuur, uw monitoringwaarschuwingen en de incidentresponsprocedures van uw team.

Gecontroleerde failovertests

# 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

Wat te meten tijdens een failover

• RTO (Recovery Time Objective)— Tijd vanaf primaire fout tot nieuwe primaire acceptatie van schrijfbewerkingen. Doel: minder dan 30 seconden voor replicasets.
• RPO (Recovery Point Objective)— Gegevensverlies tijdens failover. Metw: majorityis de RPO nul voor bevestigde schrijfbewerkingen. Metw: 1is RPO gelijk aan de replicatievertraging op het moment van falen.
• Applicatiefoutenpercentage— Percentage verzoeken dat mislukt tijdens de failover-periode. MetretryWrites=trueworden de meeste schrijffouten automatisch opnieuw geprobeerd door het stuurprogramma.
• Verander de continuïteit van de stream— Controleer of consumenten van de wijzigingsstroom doorgaan vanaf hun opgeslagen token zonder gebeurtenissen te missen.

Noodherstel-runbook

1. Fout bij één lid— Automatisch herstel via herstart van de Kubernetes-pod en oplog-inhaalslag. Er is geen handmatige actie vereist, tenzij het lid een volledige hersynchronisatie nodig heeft.
2. Primaire fout— Automatische verkiezing bevordert een secundaire fout binnen 10-12 seconden. Controleer de applicatieconnectiviteit en replicatievertraging op de resterende secundaire bestanden.
3. Meerderheidsfout— Als een meerderheid van de leden afwezig is, wordt de replicaset alleen-lezen (geen verkiezingen mogelijk). Herstel leden of gebruikrs.reconfig({ force: true })als laatste redmiddel (dit kan gegevensverlies veroorzaken).
4. Volledig clusterverlies— Implementeer een nieuw cluster, herstel vanaf de nieuwste PBM-back-up en speel de oplog opnieuw af naar het doelpunt. Update verbindingsreeksen en DNS-records.
5. Regionale failover— Als de primaire regio verloren gaat, wordt een secundaire regio in een andere regio automatisch als primair gekozen (als deze voldoende prioriteit heeft en de overige leden de meerderheid vormen). Update DNS om verkeer naar de nieuwe primaire regio te routeren.

Aanbevelingen voor productietuning

Afstemming op besturingssysteemniveau

# 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

Richtlijnen voor het dimensioneren van bronnen

• WiredTiger-cache: 50% van het beschikbare RAM minus 1 GB, of de grootte van uw werkset, afhankelijk van welke kleiner is.
• Oplog-grootte: genoeg voor 24-72 uur schrijfbewerkingen. Begin met 50 GB en monitor metrs.printReplicationInfo().
• Opslag IOPS: MongoDB is I/O-intensief, vooral tijdens compactie en controlepunten. Gebruik NVMe SSD of cloudopslag met ingerichte IOPS (gp3 met 6000+ IOPS op AWS, Premium SSD v2 op Azure, pd-ssd op GCP).
• CPU: MongoDB profiteert van meerdere cores voor gelijktijdige lees-/schrijfbewerkingen, gelijktijdige transacties van WiredTiger en achtergrondtaken (controlepunten, compactie, replicatie).
• Netwerk: Replicatieverkeer kan aanzienlijk zijn voor schrijfintensieve werklasten. Zorg voor netwerken met lage latentie en hoge bandbreedte tussen leden van de replicaset.

Verbindingsbeheer

# 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"]
});

Controlechecklist

• Replicatievertraging— Waarschuw wanneer een secundaire vertraging meer dan 30 seconden bedraagt.
• Verbindingsverzadiging— Waarschuw wanneer de huidige verbindingen 80% vanmaxIncomingConnectionsoverschrijden.
• WiredTiger cache— Waarschuw wanneer de vuile vullingsratio van de cache groter is dan 20% (geeft aan dat de schrijfdruk de controlepuntdoorvoer overschrijdt).
• Oplog-venster— Waarschuw wanneer het oplog-venster onder de 12 uur komt (risico dat secundaire bestanden na onderhoud volledig opnieuw moeten worden gesynchroniseerd).
• Query gericht op: waarschuwing wanneer de verhouding tussen gescande documenten en geretourneerde documenten groter is dan 100 (ontbrekende index).
• Schijfgebruik— Waarschuwing bij drempelwaarden van 70% en 85%. MongoDB kan tijdens het comprimeren aanzienlijke tijdelijke schijfruimte gebruiken.
• Versheid van back-ups— Waarschuw wanneer de laatste succesvolle back-up ouder is dan uw RPO-venster.
• Ticketbeschikbaarheid— Monitor WiredTiger lees- en schrijftickets. Uitputting veroorzaakt wachtrijen voor bewerkingen en latentiepieken.

Operationele commando's Beknopte referentie

# 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

-beslissingsmatrix: uw MongoDB HA-architectuur kiezen

• Enkele cloud, beheerde voorkeur— Gebruik MongoDB Atlas. Het verzorgt HA, back-ups, monitoring en schaling met minimale operationele overhead.
• AWS met MongoDB-compatibel heeft alleennodig - Overweeg Amazon DocumentDB als uw applicatie een basissubset van de MongoDB API gebruikt en u een volledig beheerde ervaring wilt. Anders Atlas of zelfbeheerd op EKS.
• Azure met volledige MongoDB-functies— Gebruik Cosmos DB voor MongoDB vCore voor een beheerde ervaring, of Atlas op Azure voor de echte beheerde MongoDB-service.
• Multi-cloud of hybride— Zelfbeheerd met de MongoDB Community Operator of Percona Operator. De Kubernetes-abstractie maakt een consistente implementatie bij alle providers mogelijk.
• Blank metaal of rand— k3s + Rancher + Longhorn + MongoDB Community Operator of Percona Operator. Geen cloudafhankelijkheden vereist.
• Grootschalige horizontale schaling— Sharded cluster met zone-sharding voor datalokaliteit. Gebruik de Percona Operator die native shard-implementaties ondersteunt.
• Realtime, gebeurtenisgestuurde toepassingen— MongoDB-wijzigingsstromen bieden ingebouwde CDC. Zorg ervoor dat u een replicaset of een shard-cluster gebruikt (niet zelfstandig).

Conclusie

MongoDB geven het een architectonisch voordeel voor hoge beschikbaarheid: replicasets met automatische failover en sharded clusters met horizontale schaling zijn native mogelijkheden, geen vastgeschroefde bijzaken. Maar deze primitieven moeten correct worden geconfigureerd en met discipline worden beheerd om de beschikbaarheidsgaranties te bieden die productiesystemen vereisen.

Voor een productie-MongoDB-implementatie zijn drie gegevensdragende replicasetleden in foutdomeinen nodig,w: majority-schrijfzorg voor duurzaamheid, de juiste oplog-grootte voor replicatieveerkracht, WiredTiger-cache-afstemming voor uw werkset en een beproefde back-upstrategie met point-in-time herstelmogelijkheden. Kubernetes-operators – of het nu de MongoDB Community Operator voor replicasets is of de Percona Operator voor volledige implementaties, inclusief sharding en geïntegreerde back-ups – automatiseren het levenscyclusbeheer dat anders aanzienlijke operationele investeringen zou vergen.

De implementatiepatronen voor AWS, Azure, GCP en bare metal delen dezelfde kern MongoDB-configuratie. Wat verandert is de opslagklasse, de back-upbestemming en de netwerklaag. Deze consistentie is de waarde van een operatorgebaseerde aanpak: uw team leert één tool, één operationeel model en één set runbooks die overal werken.

Begin met een replicaset met drie leden,w: majorityschrijft, een dagelijkse PBM-back-up met continue oplog-archivering en de kern Prometheus-waarschuwingen voor replicatievertraging, verbindingsverzadiging en cachedruk. Test uw failover op de eerste dag, niet tijdens uw eerste incident. Breid uit naar sharding, zonegebaseerde gegevenslocatie en implementaties in meerdere regio's naarmate uw gegevensvolume en beschikbaarheidsvereisten toenemen. De infrastructuur verzorgt de mechanica; het is jouw verantwoordelijkheid om de architectuur diep genoeg te begrijpen om de juiste afwegingen te maken voor je werklast en om die aannames meedogenloos te testen.