Auto-clustering MongoDB

Pour MongoDB, l’auto-clustering de Stack Harbor PaaS construit un replica set depuis l’assistant de topologie. Le set est tolérant aux pannes de nœud, s’étend automatiquement quand vous ajoutez des nœuds à la couche, et récupère proprement quand un nœud en panne revient.

Ce que vous obtenez :

• Redondance et haute disponibilité des données — plusieurs copies des données réparties sur les nœuds.
• Scalabilité et auto-découverte — les nœuds ajoutés par redimensionnement horizontal rejoignent le replica set avec la bonne configuration ; ceux retirés par scale-in en sortent proprement.
• Bascule automatique — les nœuds injoignables ou trop en retard sont exclus automatiquement et réintégrés à leur retour.

Comportement d’un replica set MongoDB

Un replica set est un groupe d’au moins trois instances MongoDB qui maintiennent les mêmes données. L’une est le primaire ; elle traite toutes les écritures et les consigne dans l’oplog. Les secondaires rejouent l’oplog. Si le primaire devient indisponible, les secondaires tiennent une élection et l’un d’eux est promu après un bref délai.

La plateforme applique ces valeurs par défaut au set auto-configuré :

• chainingAllowed: true — les secondaires peuvent répliquer depuis d’autres secondaires.
• heartbeatIntervalMillis: 2000 — fréquence des battements de cœur.
• heartbeatTimeoutSecs: 10 — temps d’attente d’un battement réussi avant de marquer un nœud injoignable.
• electionTimeoutMillis: 10000 — délai pour détecter un primaire injoignable.
• catchUpTimeoutMillis: -1 — un primaire fraîchement élu attend indéfiniment pour rattraper les membres qui ont des écritures plus récentes.
• catchUpTakeoverDelayMillis: 30000 — un secondaire en avance sur le primaire courant attend ce délai pour le rattrapage avant d’initier une élection de remplacement.

Vous pouvez modifier n’importe lequel ensuite depuis le shell Mongo avec rs.reconfig().

Authentification entre membres

Les membres s’authentifient entre eux via un fichier clé partagé. La plateforme écrit le fichier dans /home/jelastic/mongodb.key, applique la configuration requise dans /etc/mongod.conf et ajoute la clé à redeploy.conf afin qu’elle survive aux opérations de cycle de vie du conteneur.

Moteur de stockage

MongoDB utilise WiredTiger par défaut. Les options par défaut de la plateforme sont réglées pour un seul mongod par conteneur. Le cache interne WiredTiger est dimensionné à 50 % de la RAM totale moins 1 Gio (avec un minimum de 256 Mio) ; la mémoire libre au-delà sert au cache du système de fichiers.

Auto-jointure au redimensionnement horizontal

Quand vous ajoutez des nœuds à la couche, ils sont détectés, configurés et ajoutés au replica set automatiquement — aucune action manuelle. La même mécanique opère en sens inverse pour le scale-in.

Créer la grappe

1. Cliquez sur New Environment en haut à gauche, choisissez MongoDB, activez Auto-Clustering.
2. À savoir :
   • 4 Gio de RAM (32 cloudlets) est la taille recommandée pour les nœuds du replica set. Par défaut, c’est positionné comme limite dynamique, donc vous n’êtes facturé que pour la consommation réelle.
   • Le nombre minimal de nœuds pour un auto-cluster MongoDB est de 3.
3. Configurez région, IP publiques, le reste de la topologie — puis appliquez.
4. Au bout de quelques minutes, la plateforme vous envoie les identifiants du replica set par courriel.

Se connecter à la grappe

Un replica set MongoDB élit un nouveau primaire à chaque défaillance du primaire courant — et peut élire un nouveau primaire après un redémarrage. Une chaîne de connexion à un seul hôte est donc fragile. Construisez toujours une chaîne qui liste tous les membres, avec une préférence de lecture et un nom de replica set :

client = new MongoClient(
  "mongodb://admin:cbfef7418d@node540102-mongo-cluster.madrid.jele.io:27017,node540096-mongo-cluster.madrid.jele.io:27017,node540099-mongo-cluster.madrid.jele.io:27017/admin",
  { useUnifiedTopology: true, readPreference: 'primaryPreferred', replicaSet: 'rs0' }
);

Où :

• useUnifiedTopology: true — force l’utilisation du nouveau moteur Server Discovery and Monitoring.
• readPreference: 'primaryPreferred' — lire depuis le primaire, basculer sur un secondaire s’il est indisponible.
• replicaSet: 'rs0' — nom de replica set par défaut sur la plateforme. Vous pouvez le confirmer sur n’importe quel nœud dans mongod.conf ou dans l’invite du shell Mongo.

Si la connexion vient de l’extérieur de la plateforme — par exemple, une application hébergée ailleurs qui se connecte via SLB — connectez-vous via le endpoint du nœud primaire pour les écritures seulement. Si votre application lit explicitement sur des secondaires, retirez replicaSet de la chaîne de connexion et connectez-vous à chaque secondaire directement dans votre chemin de code de lecture :

client = new MongoClient(
  "mongodb://admin:bfef7418d@node540102-mongo-cluster.madrid.jele.io:11013/admin",
  { useUnifiedTopology: true }
);

Opérer la grappe

• Mongo Express est inclus par défaut comme UI d’administration. Il prend en charge les replica sets.

• Shell Mongo est le bon outil pour l’introspection du replica set. Depuis une session Web SSH sur n’importe quel nœud :

  mongosh -u {user} -p {password} {DB_name}

  Utilisez mongo au lieu de mongosh pour MongoDB 3.x / 4.x ; les deux acceptent les mêmes paramètres.

• Statut du replica set :

  rs.status()

  Et rs.conf() pour voir la configuration active.

Pages connexes

• Qu’est-ce que l’auto-clustering et auto-clustering via l’assistant de topologie — modèle de plus haut niveau.
• Auto-clustering de bases de données — MariaDB / MySQL / Percona.
• Auto-clustering PostgreSQL — équivalent PostgreSQL.
• Mise en place manuelle d’un replica set — si vous devez construire une grappe MongoDB personnalisée en dehors de l’assistant.