Compte tenu de l'architecture mise en place et du nombre plus élevé de démons qui entrent en compte dans le fonctionnement d'un cluster Mongodb que dans une installation classique, la maintenance et la résolution des problèmes peut être plus complexes.

Cette page recense et détaille les opérations de maintenance et des recherches/résolutions de problèmes courants

Vérification de l'état d'un cluster Mongodb

La vérification de l'état d'un cluster Mongo peut se faire de plusieurs manières:

• En vérifiant l'état des services Linux et les logs
• Directement via la console Mongodb
• Par les checks Mongodb livrés avec Shinken Entreprise

Services Linux

Avant de vérifier l'état détaillé du cluster Mongodb avec la console Mongodb ou les checks Shinken, on peut d'abord commencer par vérifier sur chaque nœud, l'état des services Linux associés aux différents démons Mongo.

La syntaxe à utiliser pour la vérification de ces services dépend de la version de CentOS utilisée:

Lorsqu'un démon du cluster n'est pas correctement démarré, on peut commencer les recherches en analysant les logs de chaque démon du cluster Mongodb.

Sur chaque noeud du cluster, on trouve les logs suivants:

• Démon mongod: /var/log/mongodb/mongod.log
• Démon mongo-configsrv: /var/log/mongodb/mongo-configsrv.log
• Démon mongos: /var/log/mongodb/mongos.log

Console Mongodb

La console Mongodb permet de récupérer des informations détaillées sur l'état de chaque démon ainsi que leur statut au sein du cluster (primaire, secondaire, en récupération, injoignable etc...).

Pour accéder à la console Mongodb, il se connecter depuis n'importe quel noeud du cluster sur le démon "mongod" avec la commande suivante:

mongo --port 27018

Une fois la console Mongo lancée, on se retrouve avec un invite de commande différent, qui nous permet de vérifier directement l'état du cluster:

rs.status()

On obtient le résultat suivant:

rs-shinken:SECONDARY> rs.status();
{
    "set" : "rs-shinken",
     "date" : ISODate("2018-05-04T07:29:15Z"),
    "myState" : 2,
    "syncingTo" : "node2:27018",
    "members" : [
         {
              "_id" : 0,
              "name" : "node1:27018",
              "health" : 0,
               "state" : 8,
               "stateStr" : "(not reachable/healthy)",
               "uptime" : 0,
               "optime" : Timestamp(0, 0),
               "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
               "lastHeartbeat" : ISODate("2018-05-04T07:29:13Z"),
               "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
               "pingMs" : 0
        },
         {
               "_id" : 1,
               "name" : "node2:27018",
               "health" : 1,
               "state" : 1,
              "stateStr" : "PRIMARY",
              "uptime" : 81988,
               "optime" : Timestamp(1525250222, 106),
               "optimeDate" : ISODate("2018-05-02T08:37:02Z"),
               "lastHeartbeat" : ISODate("2018-05-04T07:29:14Z"),
               "lastHeartbeatRecv" : ISODate("2018-05-04T07:29:14Z"),
               "pingMs" : 1,
               "electionTime" : Timestamp(1525336975, 1),
              "electionDate" : ISODate("2018-05-03T08:42:55Z")
         },
        {
               "_id" : 2,
               "name" : "node3:27018",
               "health" : 1,
               "state" : 2,
               "stateStr" : "SECONDARY",
              "uptime" : 81988,
               "optime" : Timestamp(1525250222, 106),
               "optimeDate" : ISODate("2018-05-02T08:37:02Z"),
              "self" : true
        }
        ],
        "ok" : 1
}

Avec l'affichage ci-dessus, on tire par exemple les informations suivantes sur notre cluster:

• Le cluster comporte 3 nœuds (node1, node2, node3)
• Le nœud node2 est le nœud primaire, et le nœuds node3 est un nœud secondaire
• Le noeud node1 n'est pas joignable
• Le noeud node2 a été élu comme noeud primaire le 03 Mar 2018 à 07h29 (GMT)

Checks Shinken

Un cluster Mongo peut être supervisé avec Shinken. Shinken Entreprise met à votre disposition un Pack MongoDB

Le modèle d'hôte "mongodb" prend également en compte les aspects de réplication de la base avec les checks "Mongodb-replicaset" et "Mongodb-replication-lag".

En pratique, pour superviser un cluster Mongo avec Shinken Entreprise, on associe un hôte Shinken à un nœud du cluster. Chaque hôte aura le modèle "mongodb" accroché, ce qui permet de superviser ces 3 nœuds de manière indépendante. On effectue également la supervision sur le port 27018 au lieu du port 27017 utilisé par défaut.

Voici un aperçu du résultat des checks concernant la réplication de Mongo, pour un nœud primaire et pour un nœud secondaire:

Le modèle mongodb permet d'utiliser un tunnel SSH pour la connexion aux serveurs et l'exécution des checks. L'utilisation du tunnel SSH se fait en modifiant la donnée MONGO_CONNECTION_METHOD. Précisez la valeur "ssh" au lieu de "direct".

L'utilisateur et la clé SSH utilisés pour créer ce tunnel peuvent se configurer en modifiant les données MONGO_SSH_USER et MONGO_SSH_KEY sur l'hôte.

Le modèle mongodb se connecte aux démons mongod pour effectuer les vérifications sur le cluster Mongo. Dans une installation classique, ce démon utilise le port 27017.

Dans le cas du cluster, on a modifié le port que ce démon utilise pour utiliser le port 27018. Il faut donc également modifier le port utilisé dans Shinken en modifiant la donnée MONGO_PORT en 27018 sur l'hôte.

La configuration et le fonctionnement du pack MongoDB sont décrits en détail sur la page de documentation du pack Mongodb: Pack Mongodb.

Manipulation d'un cluster Mongodb

Redémarrage du cluster

Les démons du cluster Mongo sont dépendants les uns des autres et doivent être démarrés dans un ordre particulier pour pouvoir fonctionner.

Pour rappel, chaque noeud du cluster contient les démons Mongo suivants:

• mongod: responsable du stockage des données
• mongo-configsrv: gère la configuration des éléments du cluster
• mongos: Sert d'interface à Shinken. Route les requêtes reçues à l'intérieur du cluster Mongo

L'ordre de démarrage des démons est donc le suivant: mongod → mongo-configsrv → mongos

• On démarre le démon mongod en premier, qui s'occupe de stocker les données.
• On démarre ensuite le démon mongo-configsrv
• On démarre enfin le démon mongos, qui a besoin du démon mongo-configsrv pour pouvoir démarrer

La séquence de démarrage est donc la suivante:

• Sur tous les noeuds du cluster, on démarre mongod: 

  # CentOS 6 service mongod start # CentOS 7 systemctl start mongod

  
  

Résolution des problèmes

Erreurs lors du redémarrage des démons

PID chibrés si le démon crash, il faut les virer à la main avant de redémarrer sinon le script d'init est pas d'accord

Resynchronisation manuelle d'un noeud Mongodb

Symptomes

Résolution