Aller au contenu

Bases de données Mis à jour le 2026-05-29

MongoDB haute disponibilité

Options de haute disponibilité pour MongoDB sur Stack Harbor PaaS — auto-clustering avec replica sets, configuration manuelle de replica set et comportement au basculement.

La HA de MongoDB passe par le replica set — un groupe de nœuds MongoDB avec une primaire et une ou plusieurs secondaires, en réplication asynchrone, avec élection automatisée de la primaire en cas de panne. Stack Harbor PaaS provisionne les replica sets depuis l’assistant de topologie, et supporte la configuration manuelle quand vous voulez un contrôle total.

Auto-clustering

Le chemin le plus simple est l’assistant de topologie :

  1. Cliquer Nouvel environnement dans le tableau de bord.
  2. Choisir MongoDB dans la ligne base de données.
  3. Activer Auto-Clustering.
  4. Choisir le nombre de membres du replica set (3 est le minimum conventionnel pour la HA).
  5. Définir la limite de cloudlets par nœud et le nom de l’environnement.
  6. Cliquer Créer.

La plateforme provisionne les membres, les configure comme un replica set avec un nom généré (p. ex. rs0), et envoie les identifiants initiaux par courriel.

Installation manuelle de replica set

Pour un contrôle total sur la configuration du replica set — nom personnalisé, priorités de membres personnalisées, paramètres de write concern personnalisés — installer à la main.

1. Provisionner les nœuds

Créer un environnement MongoDB avec le nombre de nœuds voulu comme membres de replica set, sans auto-clustering. Chaque nœud démarre comme une instance MongoDB autonome.

2. Configurer mongod pour la réplication

Sur chaque nœud, éditer /etc/mongod.conf et ajouter (ou positionner) le bloc replication :

replication:
  replSetName: rs0

Redémarrer mongod sur chaque nœud après l’édition. Les nœuds sont maintenant prêts à participer à un replica set nommé rs0, mais aucun membre n’en fait encore partie.

3. Initier le replica set

Ouvrir la console Web SSH sur le nœud que vous voulez comme primaire initiale, et se connecter avec mongosh :

mongosh --host node{node_id}-{environment_name}.{domain} -u root -p

Puis initier le replica set :

rs.initiate({
  _id: 'rs0',
  members: [
    { _id: 0, host: 'node{a}-{env}.{domain}:27017' },
    { _id: 1, host: 'node{b}-{env}.{domain}:27017' },
    { _id: 2, host: 'node{c}-{env}.{domain}:27017' },
  ],
});

Vérifier le statut :

rs.status();

Vous devriez voir un nœud marqué PRIMARY et les autres SECONDARY.

4. Configurer le write concern

Pour une charge d’écritures à enjeu HA, positionner le write concern par défaut à majority. Depuis mongosh sur la primaire :

db.adminCommand({
  setDefaultRWConcern: 1,
  defaultWriteConcern: { w: 'majority', wtimeout: 5000 },
});

Cela bloque chaque écriture jusqu’à ce qu’une majorité de membres du replica set ait accusé réception. Cela coûte un peu de latence en échange de la garantie qu’une écriture validée survit à un basculement de primaire.

Comportement au basculement

Quand la primaire tombe, les membres restants élisent une nouvelle primaire. L’élection prend quelques secondes ; dans cette fenêtre, les écritures applicatives échouent avec NotMasterError (ou NotWritablePrimary dans les pilotes récents).

Les pilotes MongoDB récents gèrent cela de façon transparente — le pilote réessaie les écritures contre la nouvelle primaire une fois l’élection terminée. L’application voit un bref pic de latence plutôt qu’une panne. Utiliser l’option retryable writes (retryWrites=true dans la chaîne de connexion, par défaut dans les pilotes courants) pour rendre cela automatique.

Préférence de lecture

Par défaut, le pilote route toutes les lectures vers la primaire. Pour équilibrer la charge de lecture entre les secondaires, positionner la préférence de lecture sur la connexion ou par requête :

  • primary — lectures depuis la primaire seulement (défaut).
  • primaryPreferred — depuis la primaire si disponible, sinon depuis une secondaire.
  • secondary — depuis une secondaire seulement. Échoue si aucune secondaire n’est disponible.
  • secondaryPreferred — depuis une secondaire si disponible, sinon depuis la primaire.
  • nearest — depuis le membre à la plus faible latence réseau, primaire ou secondaire.

Les lectures secondaires ne sont pas fortement cohérentes — une secondaire peut traîner derrière la primaire d’un certain délai. Éviter les lectures secondary pour les flux lecture-après-écriture où l’application lit une valeur qu’elle vient d’écrire.

Voir aussi