Haute disponibilité MongoDB en production : ensembles de réplicas, partitionnement et opérateurs Kubernetes

MongoDB occupe une position unique dans le paysage des bases de données. Son modèle de document correspond naturellement aux objets d'application, son schéma flexible s'adapte aux structures de données évolutives sans migration, et ses primitives de réplication et de partitionnement intégrées constituent une base pour la haute disponibilité et la mise à l'échelle horizontale que les bases de données relationnelles nécessitent des outils externes pour réaliser. Mais une fondation n’est pas un bâtiment fini. L’exécution de MongoDB en production avec une véritable haute disponibilité – où une panne de nœud, une partition réseau ou la mise hors ligne d’une région entière n’entraîne pas de temps d’arrêt ou de perte de données – exige une architecture délibérée, un réglage minutieux et une discipline opérationnelle rigoureuse.

Ce guide présente chaque couche de MongoDB HA : du protocole de consensus du jeu de réplicas et de la réplication oplog qui alimentent le basculement automatique, en passant par l'architecture de cluster fragmenté qui permet une mise à l'échelle horizontale, jusqu'aux opérateurs Kubernetes qui automatisent la gestion du cycle de vie, et à travers les options de déploiement sur AWS, Azure, GCP et k3s sans système d'exploitation avec Rancher. Chaque section comprend une configuration concrète, des manifestes YAML et des procédures opérationnelles que vous pouvez adapter à votre environnement.

MongoDB

Un jeu de répliques constitue l'unité fondamentale de haute disponibilité du MongoDB. Il s'agit d'un groupe de processusmongodqui conservent le même ensemble de données. Un membre est leprincipal, qui reçoit toutes les opérations d'écriture. Les membres restants sont des secondaires, qui répliquent les données du principal en suivant son journal d'opérations (oplog). Si le réplica principal devient indisponible, le jeu de réplicas choisit un nouveau réplica principal parmi les secondaires éligibles, généralement dans un délai de 10 à 12 secondes.

Un jeu de répliques de production doit comporter au moins trois membres porteurs de données, idéalement répartis sur différents domaines de défaillance (zones de disponibilité, racks ou centres de données). Cela garantit que l'ensemble de répliques peut survivre à la perte d'un seul membre tout en conservant une majorité à des fins électorales. Un arbitrefacultatif,, participe aux élections mais ne détient aucune donnée. Il existe uniquement pour rompre les égalités lorsque vous avez un nombre pair de membres porteurs de données, bien que la meilleure pratique de MongoDB consiste à utiliser un nombre impair de membres porteurs de données à la place.

Oplog et mécanismes de réplication

L'oplog est une collection plafonnée (local.oplog.rs) qui enregistre chaque opération de modification de données sur le primaire sous forme idempotente. Les secondaires suivent continuellement l'oplog du primaire et appliquent les opérations localement. La taille de l'oplog détermine le retard qu'un secondaire peut prendre avant de nécessiter une resynchronisation complète. Pour les charges de travail de production, dimensionnez l'oplog pour qu'il contienne au moins 24 à 72 heures d'activité d'écriture. MongoDB 4.4+ prend en charge le dimensionnement dynamique des oplogs 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()

et protocole basé sur un radeau

MongoDB 4.0+ utilise un protocole de consensus inspiré de Raft pour les élections des jeux de répliques. Lorsqu'un secondaire détecte que le primaire est inaccessible (electionTimeoutMillispar défaut de 10 000 ms), il peut déclencher une élection. Pour gagner, un candidat doit recevoir les votes de la majorité des membres votants. Le membre avec l'entrée oplog la plus récente et la priorité la plus élevée gagne si plusieurs candidats sont éligibles. Vous pouvez influencer les résultats des élections en définissant les priorités des membres : un membre doté depriority: 0ne peut jamais devenir principal, ce qui est utile pour les réplicas d'analyse ou les membres des régions éloignées.

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

Préférence de lecture et préoccupation en écriture

Préférence de lecturecontrôle où le pilote envoie les opérations de lecture. Les options sont :

• primary— Toutes les lectures vont au primaire. Cohérence la plus forte mais pas de mise à l'échelle de lecture.
• primaryPreferred— Les lectures sont transmises au primaire sauf s'il n'est pas disponible, puis au secondaire.
• secondary— Toutes les lectures vont aux secondaires. Fournit une mise à l'échelle en lecture mais peut renvoyer des données obsolètes.
• secondaryPreferred— Les lectures sont transmises aux secondaires sauf si aucun n'est disponible.
• nearest— Les lectures sont effectuées vers le membre présentant la latence réseau la plus faible, quel que soit son rôle. Idéal pour les déploiements géo-distribués.

Problème d'écriturecontrôle le nombre de membres du jeu de réplicas qui doivent accuser réception d'une écriture avant que l'opération ne soit renvoyée au client.

• w: 1— Seul le serveur principal doit accuser réception. Le plus rapide mais risque de perdre des données si le principal échoue avant la réplication.
• w: "majority"— Une majorité des membres porteurs de données doivent reconnaître. Il s’agit de la valeur par défaut recommandée en production. Cela garantit que l’écriture survivra à une élection primaire.
• w: <number>— Un nombre spécifique de membres doivent reconnaître.
• j: true— L'écriture doit être validée dans le journal sur disque avant l'accusé de réception. Combiné avec lew: "majority", cela offre la plus forte garantie de durabilité.

# 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

Architecture de cluster partagé MongoDB

Un jeu de réplicas offre une haute disponibilité mais pas une mise à l'échelle horizontale des écritures : toutes les écritures sont effectuées sur un seul serveur principal. Lorsque votre ensemble de données dépasse la capacité d'un seul serveur ou que votre débit d'écriture dépasse ce qu'un serveur principal peut gérer, vous avez besoin d'un partitionnement. Un cluster partitionné distribue les données sur plusieurs jeux de réplicas (fragments) à l'aide d'une clé de partition, permettant une mise à l'échelle horizontale du débit de stockage et d'écriture.

Un cluster partitionné comporte trois types de composants.mongos Les routeurssont des routeurs de requêtes sans état qui dirigent les opérations client vers la ou les partitions appropriées. Déployez-en au moins deux pour la redondance. Les serveurs de configurationforment un jeu de réplicas qui stocke les métadonnées du cluster : quels fragments vivent sur quelles partitions, les plages de clés de partition et l'état de l'équilibreur. Les serveurs de fragments​​sont des jeux de réplicas qui contiennent chacun un sous-ensemble des données fragmentées.

La clé de partitionnement est la décision la plus importante dans un cluster partitionné. Il détermine la manière dont les données sont distribuées entre les partitions et a un impact direct sur les performances des requêtes, la distribution des écritures et la capacité d'évolutivité. Une bonne clé de partition a une cardinalité élevée (de nombreuses valeurs distinctes), répartit les écritures de manière égale entre les partitions et prend en charge les modèles de requête les plus courants avec des opérations ciblées plutôt que par dispersion.

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

incluent : les clés hachéespour une distribution d'écriture uniforme (idéale lorsque vous n'avez pas besoin de requêtes de plage sur la clé de partition), les clés composéesqui combinent un champ de regroupement grossier avec un champ à cardinalité élevée (par exemple,{ tenant_id: 1, _id: 1 }pour les applications multi-locataires) et les clés basées sur la zonequi aligner le placement des données avec les régions géographiques.

pour

limite des plages spécifiques de la clé de partition à des partitions spécifiques, permettant ainsi la localisation des données. Par exemple, vous pouvez vous assurer que les données des clients européens résident sur des partitions dans la région UE tandis que les données des clients américains résident sur des partitions dans la région États-Unis.

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

Déploiement MongoDB multirégional

La distribution de MongoDB dans plusieurs régions répond à deux objectifs : la reprise après sinistre (survivre à la perte d'une région entière) et l'optimisation de la latence (assurer les lectures à partir de la réplique la plus proche). MongoDB prend en charge les déploiements multirégionaux via des membres de jeux de réplicas répartis dans les régions, le partitionnement de zone pour la localité des données et la configuration des préférences de lecture qui achemine les lectures vers le membre le plus proche.

Dans un jeu de répliques de cinq membres répartis dans trois régions (2 dans la région principale, 2 dans la région DR, 1 dans la région de lecture), la perte de la région principale laisse toujours trois membres disponibles, soit suffisamment pour qu'une majorité élise une nouvelle région principale. Le membre dans la région de lecture doit disposer depriority: 0pour l'empêcher de devenir principal (une latence inter-régions élevée dégraderait les performances d'écriture). Utilisezhidden: truepour les membres dédiés à l'analyse qui ne doivent pas recevoir de lectures régulières d'applications.

Communauté MongoDB Opérateur Kubernetes

L'opérateur Kubernetes de la communauté MongoDB déploie et gère les jeux de réplicas MongoDB sur Kubernetes. Il s'agit de l'opérateur open source de MongoDB Inc. qui gère la gestion StatefulSet, la configuration automatisée des jeux de réplicas, la rotation des certificats TLS, la gestion des utilisateurs et les mises à niveau progressives.

# 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 Spécification

La ressource personnaliséeMongoDBCommunitydéfinit l'état souhaité d'un jeu de réplicas MongoDB. Vous trouverez ci-dessous une spécification prête pour la production.

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

Cette spécification crée un jeu de réplicas de trois membres exécutant MongoDB 7.0 avec l'authentification SCRAM, le cryptage TLS, des volumes de données et de journaux séparés, une anti-affinité de pod entre les zones de disponibilité et un réglage WiredTiger approprié pour un nœud avec 16 Go de RAM. L'opérateur gère l'initialisation du jeu de réplicas, la configuration des membres et les mises à niveau propagées lorsque vous modifiez le champversion.

pour opérateur MongoDB

L'opérateur Percona pour MongoDB (opérateur PSMDB) offre une alternative plus riche en fonctionnalités à l'opérateur communautaire. Il déploie Percona Server pour MongoDB (un remplacement immédiat de MongoDB avec des fonctionnalités d'entreprise supplémentaires), gère les clusters fragmentés ainsi que les jeux de réplicas, intègre la sauvegarde via Percona Backup for MongoDB (PBM) et prend en charge la récupération à un moment donné.

# 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

Le principal avantage de Percona Operator est sa gestion intégrée des sauvegardes avec Percona Backup for MongoDB (PBM). PBM prend en charge les sauvegardes logiques et physiques, les sauvegardes incrémentielles et la récupération ponctuelle à partir de l'oplog, toutes configurées de manière déclarative via le CRD.

AWS : DocumentDB vs Atlas vs autogéré sur EKS

Amazon DocumentDBest un service de base de données documentaire compatible MongoDB. Ce n'est pas MongoDB — c'est un moteur propriétaire qui implémente le protocole filaire MongoDB (compatible jusqu'à MongoDB 4.0 API). DocumentDB sépare le calcul du stockage à l'aide d'une couche de stockage distribuée similaire à Aurora. Il fournit un basculement automatique au sein d'une région, jusqu'à 15 réplicas en lecture et une récupération à un moment précis. Cependant, il lui manque de nombreuses fonctionnalités MongoDB : les flux de modifications ont des limites, les transactions fonctionnent différemment et de nombreuses étapes du pipeline d'agrégation ne sont pas prises en charge. Utilisez DocumentDB uniquement si votre application utilise un sous-ensemble de API de MongoDB et que vous appréciez la simplicité opérationnelle d'un service entièrement géré.

MongoDB Atlas sur AWSest le propre service géré de MongoDB fonctionnant sur l'infrastructure AWS. Il fournit un véritable MongoDB avec toutes les fonctionnalités, une haute disponibilité automatisée, des sauvegardes continues, une récupération ponctuelle, une mise à l'échelle automatique et des clusters multirégions. Atlas constitue le chemin le plus simple vers la production du MongoDB, mais l'option la plus coûteuse à grande échelle.

autogéré sur EKSvous donne un contrôle total sur la version, la configuration et le coût de MongoDB. Utilisez l'opérateur communautaire MongoDB ou l'opérateur Percona avec le stockage EBS gp3 et les rôles IAM pour les comptes de service (IRSA) pour un accès sécurisé à la sauvegarde 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 autogéré sur AKS

Azure Cosmos DB pour MongoDB (vCore)est l'offre native Azure la plus proche du vrai MongoDB. Contrairement à l'ancien Cosmos DB API pour MongoDB basé sur RU, le modèle vCore exécute de véritables instances du moteur MongoDB sur un calcul dédié, offrant une compatibilité élevée avec les fonctionnalités de MongoDB 6.0+, notamment un pipeline d'agrégation complet, des flux de modifications et des transactions. Il offre une haute disponibilité redondante par zone, une récupération ponctuelle et des sauvegardes automatiques.

MongoDB Atlas sur Azureoffre la même expérience MongoDB entièrement gérée que sur AWS, fonctionnant sur une infrastructure Azure avec peering VNET, Azure Private Link et intégration Azure AD.

autogéré sur AKSutilise des disques gérés Azure (Premium SSD v2 recommandé) avec l'opérateur 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

: Atlas sur GCP vs autogéré sur GKE

MongoDB Atlas sur GCPs'exécute sur l'infrastructure Google Cloud avec des intégrations natives GCP : peering VPC, Private Service Connect et intégration de cluster GKE. Atlas sur GCP prend en charge les clusters multirégionaux couvrant les régions GCP avec basculement automatique.

autogéré sur GKEutilise un disque SSD persistant avec l'opérateur MongoDB ou Percona. GKE Workload Identity fournit une authentification sécurisée et sans clé pour la sauvegarde sur 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

k3s/Rancher en métal nu avec Longhorn

Pour la souveraineté des données, la conformité ou l'optimisation des coûts, MongoDB fonctionne efficacement sur Kubernetes sans système d'exploitation en utilisant k3s avec gestion Rancher et stockage distribué Longhorn. Cette architecture élimine les dépendances des fournisseurs de cloud tout en conservant le même modèle de gestion basé sur l'opérateur.

Rangement Longhorn pour 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 est recommandé plutôt que ext4 pour MongoDB sous Linux. Le moteur de stockage WiredTiger de MongoDB bénéficie des modèles d'allocation de XFS, notamment pour les fichiers journaux et de données. La réplication à trois voies de Longhorn offre une redondance au niveau du volume en plus de la redondance au niveau du jeu de réplicas du MongoDB, vous offrant ainsi une défense en profondeur contre les pannes de stockage.

MetalLB et services sans tête

# 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

L'opérateur MongoDB crée un service sans tête qui donne à chaque pod un nom DNS stable (mongo-0.mongo-svc.databases.svc.cluster.local). Ceci est essentiel pour la découverte des membres du jeu de réplicas. Si vous avez besoin d'un accès externe, MetalLB attribue une IP routable à un service LoadBalancer devant les routeurs mongos (pour les clusters partitionnés) ou le principal (pour les jeux de réplicas).

Stratégies de sauvegarde

MongoDB propose plusieurs approches de sauvegarde, chacune adaptée à différents scénarios.

mongodump / mongorestore

Sauvegardes logiques qui exportent les documents BSON. Portable et inspectable par l'homme, mais lent pour les grands ensembles de données et ne prend pas en charge la récupération à un moment donné.

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

Sauvegarde Percona pour MongoDB (PBM)

PBM fournit des sauvegardes physiques, des sauvegardes incrémentielles et une restauration ponctuelle. Il s'agit de l'outil de sauvegarde recommandé pour le MongoDB autogéré en production.

# 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

Instantanés du cloud

Sur les fournisseurs de cloud, les instantanés EBS (AWS), les instantanés de disque géré (Azure) et les instantanés de disque persistant (GCP) fournissent des sauvegardes rapides au niveau du stockage. Associés audb.fsyncLock()pour une cohérence ponctuelle, ils offrent les temps de sauvegarde et de restauration les plus rapides pour les grands ensembles de données.

# 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

Récupération ponctuelle basée sur Oplog

L'oplog permet une récupération ponctuelle (PITR) lorsqu'il est combiné avec une sauvegarde de base. PBM archive en permanence les entrées du journal oplog dans le stockage de sauvegarde. Pour restaurer à un moment précis, PBM restaure la sauvegarde de base la plus récente, puis relit les entrées du journal oplog jusqu'à l'horodatage cible. Ceci est configuré dans le Percona Operator CRD via la sectionpitr.

pour HA

Une configuration correcte de la chaîne de connexion est essentielle pour la résilience des applications lors des événements de basculement.

# 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

pour HA :retryWrites=trueetretryReads=truepermettent une nouvelle tentative automatique des opérations qui échouent lors du basculement.w=majoritygarantit que les écritures survivent aux élections primaires.serverSelectionTimeoutMScontrôle le temps d'attente du pilote pour trouver un serveur approprié : définissez-le sur une durée supérieure à l'heure d'élection prévue (au moins 15 secondes).maxPoolSizelimite le pool de connexions par membre de l'ensemble mongos/réplique pour éviter l'épuisement des connexions.

Optimisation de l'index et performances des requêtes

constituent le principal levier des performances des requêtes MongoDB. Un index manquant sur un champ fréquemment interrogé force une analyse de collection qui se dégrade linéairement avec la taille des données.

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

Examinez régulièrement le$indexStatspour identifier les index inutilisés qui gaspillent le stockage et ralentissent les écritures. Utilisez la méthodeexplain()pour vérifier que les requêtes utilisent l'index attendu et recherchez untotalDocsExaminedélevé par rapport ànReturned, ce qui indique un plan de requête inefficace.

Réglage du moteur de stockage WiredTiger

WiredTiger est le moteur de stockage de production par défaut et unique de MongoDB depuis MongoDB 4.2. Ses caractéristiques de performances sont fortement influencées par la taille du cache, la compression et la configuration du journal.

# 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

Le cache WiredTiger doit être dimensionné pour contenir votre ensemble de travail – les données et les index activement consultés par vos requêtes. Si le cache est trop petit, WiredTiger supprime fréquemment des pages, ce qui entraîne des E/S élevées. S'il est trop volumineux, la mémoire sera insuffisante pour le cache du système de fichiers du système d'exploitation et d'autres processus. Un point de départ est 50 % de la RAM disponible moins 1 Go (pour le système d'exploitation et les autres processus), plafonné à la taille de l'ensemble de travail.

et cryptage 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

avec Prometheus et Grafana

MongoDB expose les métriques via lemongodb_exporter(de Percona) qui s'intègre à Prometheus. Les mesures clés à surveiller incluent le nombre de connexions, les taux de fonctionnement, le décalage de réplication, l'utilisation du cache WiredTiger et l'efficacité du ciblage des requêtes.

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

Flux de modifications pour les applications en temps réel

fournissent un mécanisme de notification en temps réel pour les modifications de données dans MongoDB. Ils exploitent l'oplog pour transmettre les événements de modification aux applications, permettant ainsi des architectures basées sur les événements, des tableaux de bord en temps réel et des pipelines de synchronisation de données sans interrogation.

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

nécessitent un jeu de réplicas ou un cluster partitionné (ils ne fonctionnent pas sur les instances mongod autonomes). Ils survivent aux élections primaires : le conducteur se reconnecte automatiquement et reprend à partir du dernier jeton de reprise reçu. Pour une utilisation en production, conservez toujours le jeton de reprise afin que votre application puisse récupérer après un redémarrage sans manquer d'événements.

Maintenance continue et mises à niveau de version

MongoDB prend en charge les mises à niveau progressives dans lesquelles vous mettez à niveau un membre du jeu de réplicas à la fois, en commençant par les secondaires et en terminant par le principal (ce qui déclenche une réduction et une élection). Cela permet des mises à niveau sans temps d'arrêt pour les modifications de version mineures et majeures.

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

Avec l'opérateur communautaire MongoDB ou l'opérateur Percona sur Kubernetes, les mises à niveau progressives sont automatisées : il vous suffit de mettre à jour le champversiondans le CRD et l'opérateur gère la mise à jour continue de chaque pod, en attendant que chaque membre redevienne sain avant de continuer.

Un déploiement haute disponibilité qui n'a jamais été testé en cas d'échec n'est pas testé. Des tests de basculement réguliers valident votre architecture, vos alertes de surveillance et les procédures de réponse aux incidents de votre équipe.

Tests de basculement contrôlé

# 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

Que mesurer pendant le basculement

• RTO (objectif de temps de récupération)— Temps écoulé entre l'échec principal et la nouvelle écriture principale acceptée. Cible : moins de 30 secondes pour les jeux de réplicas.
• RPO (objectif de point de récupération)— Perte de données lors du basculement. Avecw: majority, le RPO est nul pour les écritures confirmées. Avecw: 1, le RPO est égal au délai de réplication au moment de l'échec.
• Taux d'erreur d'application— Pourcentage de demandes qui échouent pendant la fenêtre de basculement. AvecretryWrites=true, la plupart des échecs d'écriture sont automatiquement réessayés par le pilote.
• Continuité du flux de modifications— Vérifiez que les consommateurs du flux de modifications reprennent leur jeton enregistré sans manquer d'événements.

Runbook de récupération après sinistre

1. Défaillance d'un seul membre— Récupération automatique via le redémarrage du pod Kubernetes et le rattrapage de l'oplog. Aucune action manuelle n'est requise, sauf si le membre a besoin d'une resynchronisation complète.
2. Échec du primaire— L'élection automatique favorise un secondaire dans les 10 à 12 secondes. Vérifiez la connectivité des applications et le décalage de réplication sur les secondaires restants.
3. Échec majoritaire— Si une majorité de membres sont en panne, le jeu de réplicas passe en lecture seule (aucune élection possible). Restaurez les membres ou utilisezrs.reconfig({ force: true })en dernier recours (cela peut entraîner une perte de données).
4. Perte complète du cluster— Déployez un nouveau cluster, restaurez à partir de la dernière sauvegarde PBM et relisez le journal d'opérations au point cible dans le temps. Mettez à jour les chaînes de connexion et les enregistrements DNS.
5. Basculement régional— Si la région principale est perdue, une région secondaire d'une autre région est automatiquement élue principale (si elle a une priorité suffisante et que les membres restants forment une majorité). Mettez à jour DNS pour acheminer le trafic vers la nouvelle région principale.

Réglage au niveau du système d'exploitation

# 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

• Cache WiredTiger: 50 % de la RAM disponible moins 1 Go, ou la taille de votre ensemble de travail, selon la valeur la plus petite.
• Taille Oplog: Assez pour contenir 24 à 72 heures d'opérations d'écriture. Commencez avec 50 Go et surveillez avecrs.printReplicationInfo().
• Stockage IOPS: MongoDB est gourmand en E/S, en particulier lors du compactage et des points de contrôle. Utilisez le SSD NVMe ou le stockage cloud avec des IOPS provisionnées (gp3 avec plus de 6 000 IOPS sur AWS, Premium SSD v2 sur Azure, pd-ssd sur GCP).
• CPU: MongoDB bénéficie de plusieurs cœurs pour les opérations de lecture/écriture simultanées, les transactions simultanées de WiredTiger et les tâches en arrière-plan (points de contrôle, compactage, réplication).
• Réseau: le trafic de réplication peut être important pour les charges de travail gourmandes en écriture. Garantissez une mise en réseau à faible latence et à bande passante élevée entre les membres du jeu de réplicas.

Gestion des connexions

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

• Retard de réplication— Alerte lorsqu'un secondaire dépasse 30 secondes de décalage.
• Saturation des connexions— Alerte lorsque les connexions actuelles dépassent 80 % demaxIncomingConnections.
• Cache WiredTiger— Alerte lorsque le taux de remplissage du cache sale dépasse 20 % (indique que la pression d'écriture dépasse le débit du point de contrôle).
• Fenêtre Oplog— Alerte lorsque la fenêtre oplog descend en dessous de 12 heures (risque que les secondaires nécessitent une resynchronisation complète après maintenance).
• Requête ciblant— Alerte lorsque le rapport entre les documents numérisés et les documents renvoyés dépasse 100 (index manquant).
• Utilisation du disque— Alerte aux seuils de 70 % et 85 %. MongoDB peut utiliser un espace disque temporaire important pendant le compactage.
• Fraîcheur de la sauvegarde— Alerte lorsque la dernière sauvegarde réussie est plus ancienne que votre fenêtre RPO.
• Disponibilité des billets— Surveillez les tickets de lecture et d'écriture WiredTiger. L’épuisement provoque une mise en file d’attente des opérations et des pics de latence.

# 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

: Choisir votre architecture MongoDB HA

• Cloud unique, préférence gérée— Utilisez MongoDB Atlas. Il gère la haute disponibilité, les sauvegardes, la surveillance et la mise à l'échelle avec une surcharge opérationnelle minimale.
• AWS compatible avec MongoDB nécessite uniquement— Pensez à Amazon DocumentDB si votre application utilise un sous-ensemble de base du MongoDB API et que vous souhaitez une expérience entièrement gérée. Sinon, Atlas ou autogéré sur EKS.
• Azure avec toutes les fonctionnalités MongoDB— Utilisez Cosmos DB pour MongoDB vCore pour une expérience gérée, ou Atlas sur Azure pour le véritable service géré MongoDB.
• Multi-cloud ou hybride— Autogéré avec l'opérateur communautaire MongoDB ou l'opérateur Percona. L'abstraction Kubernetes permet un déploiement cohérent entre les fournisseurs.
• Bare metal ou edge— k3s + Rancher + Longhorn + MongoDB Community Operator ou Percona Operator. Aucune dépendance cloud requise.
• Mise à l'échelle horizontale à grande échelle— Cluster fragmenté avec partitionnement de zone pour la localisation des données. Utilisez l'opérateur Percona qui prend en charge les déploiements partitionnés de manière native.
• Applications basées sur des événements en temps réel— Les flux de modifications MongoDB fournissent un CDC intégré. Assurez-vous d'utiliser un jeu de réplicas ou un cluster partitionné (non autonome).

Conclusion

MongoDB lui confèrent un avantage architectural en matière de haute disponibilité : les jeux de réplicas avec basculement automatique et les clusters partitionnés avec mise à l'échelle horizontale sont des fonctionnalités natives et non ajoutées après coup. Mais ces primitives doivent être configurées correctement et utilisées avec discipline pour offrir les garanties de disponibilité exigées par les systèmes de production.

Un déploiement de production MongoDB nécessite trois membres d'ensemble de réplicas porteurs de données dans les domaines de défaillance, un souci d'écriturew: majoritypour la durabilité, un dimensionnement approprié des journaux d'opérations pour la résilience de la réplication, un réglage du cache WiredTiger pour votre ensemble de travail et une stratégie de sauvegarde testée avec une capacité de récupération à un moment précis. Les opérateurs Kubernetes — qu'il s'agisse de l'opérateur communautaire MongoDB pour les jeux de réplicas ou de l'opérateur Percona pour les déploiements complets, y compris le partitionnement et les sauvegardes intégrées — automatisent la gestion du cycle de vie qui nécessiterait autrement un investissement opérationnel important.

Les modèles de déploiement sur AWS, Azure, GCP et Bare Metal partagent la même configuration de base MongoDB. Ce qui change, c'est la classe de stockage, la destination de sauvegarde et la couche réseau. Cette cohérence constitue la valeur d'une approche basée sur l'opérateur : votre équipe apprend un seul outil, un seul modèle opérationnel et un seul ensemble de runbooks qui fonctionnent partout.

Commencez avec un jeu de réplicas de trois membres, des écrituresw: majority, une sauvegarde PBM quotidienne avec archivage continu des oplogs et les alertes Prometheus principales concernant le décalage de réplication, la saturation de la connexion et la pression du cache. Testez votre basculement dès le premier jour, et non lors de votre premier incident. Étendez-vous au partitionnement, à la localisation des données basée sur des zones et aux déploiements multirégionaux à mesure que vos besoins en matière de volume de données et de disponibilité augmentent. L'infrastructure s'occupe de la mécanique ; votre responsabilité est de comprendre l'architecture suffisamment profondément pour faire les bons compromis pour votre charge de travail et de tester ces hypothèses sans relâche.