Retour au blog

Comment configurer la réplication MongoDB et le basculement automatique

Comment configurer la réplication MongoDB et le basculement automatique

Un ensemble de réplicas est défini comme un cluster de bases de données de plusieurs nœuds avec réplication et basculement automatique configurés entre eux. Pour s'assurer que la base de données PRIMARY est élue correctement, il est important d'avoir un nombre impair de membres dans l'ensemble (en incluant ou en excluant le Arbiter nœud). 

La base de données sélectionnée est responsable de toutes les tâches majeures. Elle traite les opérations d'écriture entrantes et stocke leurs informations dans l'oplog. Ces informations peuvent être consultées et répliquées par les membres réplicas SECONDARY pour les appliquer à leurs propres ensembles de données. Par conséquent, tous les serveurs de l'ensemble représenteront le même contenu et assureront sa disponibilité :

How to Configure MongoDB Replication and Automated Failover 1-Replica set- graphic

Considérez maintenant une situation où un problème inattendu (comme une panne matérielle ou de connexion) entraîne une interruption de service de la base de données principale. Dans ce cas, le système lancera automatiquement un nouveau processus d'élection pour rétablir le fonctionnement normal sans nécessiter d'intervention manuelle. L'avantage d'un tel système est que vous bénéficiez du meilleur de la réplication, telle qu'une disponibilité accrue, une redondance de basculement et une reprise après sinistre, sans avoir à vous soucier de gérer plusieurs bases de données séparément.

Si vous souhaitez utiliser un système similaire, ce tutoriel vous montrera comment configurer un ensemble de réplicas MongoDB avec le PaaS CloudSigma. Comme vous le verrez dans ce guide, nous utiliserons trois membres, ce qui est généralement suffisant pour offrir une bonne marge de sécurité des informations et un rendement permettant de gérer les opérations d'E/S pour les applications les plus courantes. En plus de la configuration réelle de la réplication, nous apprendrons également à préparer l'environnement, à configurer l'authentification entre les nœuds de base de données et à nous assurer que votre travail a réussi.

Étape 1 : Créer un nouvel environnement

Pour commencer, vous aurez besoin d'au moins 3 nœuds MongoDB pour configurer un ensemble de réplicas. Créez donc un nouvel environnement comme suit :

2-Create an Environment How to Configure MongoDB Replication and Automated Failover

Dans notre exemple, nous attribuons toutes les instances MongoDB de la version 4.0.2 au même environnement. Vous pouvez modifier le Nom de l'environnement si nécessaire dans l'espace prévu et poursuivre le processus d'installation.

La prochaine étape du processus consistera à gérer la sécurité de la communication entre ces nœuds à l'aide du fichier de clé d'authentification.

Étape 2 : Ajouter un fichier de clé d'authentification

L'authentification est un composant essentiel de toute réplication. Il s'agit d'un processus d'assurance de sécurité qui ne donne accès à un membre de l'ensemble de réplicas qu'après qu'il s'est correctement identifié avec un fichier de clé d'authentification unique. Cela protège vos données des regards indiscrets et des tiers. Voici comment générer votre propre fichier de clé d'authentification :

  1. Cliquez sur l'option Web SSH pour l'un des nœuds de base de données et connectez-vous :

3- Web SSH How to Configure MongoDB Replication and Automated Failover

    2. Ensuite, vous pouvez saisir votre propre fichier de clé ou en générer un nouveau avec openssl en utilisant la commande suivante :

Dans cette commande, 741 représente la taille de la clé en octets et my.key est le nom de la clé.

    3. Il est temps de distribuer le nouveau fichier de clé sur toutes vos instances MongoDB. Voici comment procéder :

  • Ouvrez le Gestionnaire de fichiers en cliquant sur le bouton Config à côté de l'un des nœuds de base de données :

4-Click on the Config

  • Localisez le fichier my.key dans l'onglet de configuration sous le chemin : /home/jelastic/my.key. Ouvrez-le et copiez le contenu du fichier :

5- configuration tab How to Configure MongoDB Replication and Automated Failover

  • Sous le chemin /var/lib/jelastic/keys vous trouverez le répertoire keys. Créez un Nouveau fichier que les instances MongoDB utiliseront pour authentifier leurs identités respectives. Dans notre cas, nous allons créer un fichier nommé mongo-set.key:

6-keys directory

  • Collez le contenu précédemment copié dans ce fichier et appliquez les modifications en cliquant sur Save pour toutes les instances :

7-Paste the clipboard content

À la suite de ce processus, le fichier mongo-set.key a été distribué sur tous nos nœuds MongoDB.

Étape 3 : Configurer la réplication MongoDB

Maintenant que nous avons assuré la sécurité des instances, nous pouvons passer à la configuration réelle de l'ensemble de réplicas. Commençons :

  1. Commencez par aller dans l'onglet de configuration des nœuds MongoDB et ouvrez le fichier mongo.conf dans le dossier etc dossier. Faites défiler vers le bas jusqu'à ce que vous trouviez la section de réplication. Décommentez-la et ajoutez la chaîne suivante avec un nom unique pour votre ensemble de réplicas. Pour notre exemple, nous le nommerons db-replication:
      2. Ensuite, nous allons ajouter un nouveau paramètre appelé keyFile dans la section sécurité. Cela servira à spécifier un chemin vers le fichier clé qui se trouve actuellement à l'emplacement : /var/lib/jelastic/keys/mongo-set.key:

8-Add parameter keyFile

      3. Cliquez sur le bouton approprié pour Enregistrer les modifications pour toutes les instances dans la fenêtre de l'éditeur. 

      4. Maintenant, vous devez Redémarrer tous vos nœuds de BD pour appliquer les nouveaux paramètres de configuration :

9-Restart your DB nodes How to Configure MongoDB Replication and Automated Failover

Une chose à garder à l'esprit est que lorsque vous avez terminé de configurer l'ensemble de réplicas et que vous redémarrez tous les nœuds ou le nœud PRIMARY, le processus d'élection de la nouvelle base de données PRIMARY commencera pendant le redémarrage.

     5. Choisissez le serveur MongoDB que vous souhaitez utiliser comme PRIMARY et accédez-y en utilisant le protocole SSH :

10-access the MongoDB server How to Configure MongoDB Replication and Automated Failover

Rappel : une fois la base de données PRIMARY élue, les autres membres de l'ensemble de réplicas ne seront plus accessibles pour les opérations d'écriture directe. Cela signifie que toutes les modifications et configurations ne peuvent être effectuées et appliquées que sur le nœud PRIMARY actuel. Ainsi, à moins que vous n'ayez organisé des priorités, vous devrez modifier la chaîne de connexion dans votre application vers le nouveau nœud PRIMARY.

     6. Ensuite, accédez à la base de données répliquée en utilisant vos identifiants respectifs :

11-Access the database How to Configure MongoDB Replication and Automated Failover

Dans cette commande :

  • {user} –fait référence au nom d'utilisateur de l'administrateur qui sera envoyé à votre adresse e-mail (il s'agit généralement d'admin par défaut).
  • {password} –il s'agit du mot de passe envoyé à votre adresse e-mail avec le nom d'utilisateur correspondant.
  • {DB_name}- représente le nom de la base de données que vous souhaitez répliquer dans cet ensemble de réplicas (nous utilisons l'admin par défaut dans notre exemple).

En cas de nouvelle élection, vous pouvez utiliser les mêmes identifiants d'utilisateur admin pour vous connecter à une nouvelle base de données PRIMARY.

     7. Maintenant que la connexion est établie, vous devrez exécuter les lignes suivantes pour définir les paramètres du nœud MongoDB actuel et initier l'ensemble de réplicas :

Dans les lignes ci-dessus, vous remplacerez les valeurs entre crochets par vos propres données correspondantes :

  • {replica_set} – il s'agit du nom de votre groupe de bases de données de réplication que vous avez spécifié au début de cette section. Dans notre cas, il s'agissait de db-replication.
  • {current_db_ip} – indique l'adresse IP du conteneur de base de données que vous avez sélectionné :

12-initiate your replica set How to Configure MongoDB Replication and Automated Failover

Dans notre cas, les lignes exécutées sont :

13-config

14-rs.initiate()

        8. Ensuite, exécutez la commande suivante pour toutes les bases de données restantes :

Ici, {db_ip} fait référence à l'adresse IP de chaque base de données :

15-rs.add(

       9. Une fois que vous avez ajouté tous les membres de réplication, vous obtiendrez un ensemble de réplicas entièrement fonctionnel. Nous vous recommandons de vous assurer que tout a été correctement configuré à la fin du processus. Pour ce faire, exécutez la commande : rs.status(). Cela vous affichera toutes les informations concernant votre ensemble de réplicas, comme suit :

16-execute the rs.status()

Step 4: Set Up the ReplicaSet Arbiter

Nous recommandons d'utiliser un nœud Arbiter dans certains cas. Qu'est-ce qu'un nœud Arbiter ? Généralement, la réplication est plus fiable si l'ensemble de réplicas contient un nombre impair de nœuds. Donc, si vous avez actuellement un nombre pair de nœuds dans votre ensemble, vous pouvez ajouter un nœud Arbiter pour maintenir un quorum car il répond aux requêtes de pulsation (heartbeat) et d'élection des autres membres de l'ensemble. Voici quelques détails sur les nœuds Arbiter :

  • L'Arbitre ne stocke aucune donnée ; il vote simplement lors des élections au cas où un autre nœud aurait échoué.
  • Il est très léger et ne consomme pas trop de ressources.
  • Il a échangé les identifiants des utilisateurs entre les réplicas chiffrés.
  • Pour maintenir la disponibilité la plus élevée, essayez d'exécuter l'Arbitre sur un nœud distinct.

Voici comment vous pouvez ajouter un nœud Arbitre à votre ensemble de réplicas :

  1. Tout d'abord, nous allons effectuer une mise à l'échelle horizontale et ajouter un nœud supplémentaire au cluster :

17-ReplicaSet Arbiter

18-Scale out database cluster

2. Une fois le nœud ajouté, nous avons besoin d'un nouveau fichier de clé. Allez dans le répertoire keys et créez un fichier de clé mongo-set.key. Copiez le contenu de la clé depuis l'un des nœuds de base de données précédemment configurés et collez-le ici comme nous l'avons fait auparavant.

3. Allez dans le fichier de configuration mongod.conf. Décommentez la section de réplication et ajoutez repISetName (il s'agit de db-replication dans notre cas). De plus, rendez-vous dans la section security et ajoutez le paramètre keyFile ( /var/lib/jelastic/keys/mongo-set.key dans notre cas).

4. Enfin, redémarrez le nouveau nœud pour appliquer ces nouveaux paramètres de configuration :

19- Restart newly

Il est important de se rappeler que vous n'avez PAS besoin de redémarrer tous les nœuds du cluster à ce stade. Redémarrez uniquement le nœud Arbitre nouvellement ajouté. Le redémarrage de tous les nœuds entraînera une nouvelle élection du PRIMARY (à moins que vous n'ayez spécifié des priorités pour sélectionner un nœud de base de données particulier comme PRIMARY).

 5. Enfin, l'Arbitre peut être ajouté à l'ensemble de réplicas. Pour ce faire, lancez la commande suivante sur le nœud PRIMARY :

Ici, {db_ip} est l'adresse IP du nouveau nœud :

20-IP address of a newly added node

 6. Maintenant, vous pouvez vérifier si le nouveau nœud est bien devenu l'Arbitre. Vous pouvez le faire en vous connectant au nouveau nœud via SSH et en vous connectant à l'instance MongoDB avec les identifiants que vous avez reçus par e-mail lors de la création du nœud :

21-connect MongoDB instance

Cela montre que le nouveau nœud que nous venons d'ajouter au cluster agit en tant qu'Arbitre de db-replication. Cela garantit un quorum dans n'importe quelle situation, rendant l'ensemble de réplicas plus fiable.

Étape 5 : Tester la disponibilité du cluster de bases de données

Ensuite, nous pouvons configurer notre cluster MongoDB pour nous connecter et effectuer des opérations à distance. Dans l'exemple suivant, nous allons nous connecter et exécuter quelques commandes de vérification à l'aide d'une simple applet PHP.

Pour cela, vous aurez besoin d'un serveur d'applications, tel qu'un serveur Apache. Vous pouvez en ajouter un à votre environnement comme nous l'avons fait ou en créer un nouveau dans un environnement distinct.

  1. Commencez par cliquer sur Change Environment Topology et en ajoutant le serveur :

22-Press Change Environment Topology

23-Press Change Environment Topology button

    2. Ouvrez l'onglet Configuration Manager pour le serveur Apache en cliquant sur le bouton Config comme indiqué ci-dessous :

3. Localisez et ouvrez le fichier index.php dans le répertoire /var/www/webroot/ROOT et collez le code suivant à la place du contenu par défaut :

Les valeurs suivantes dans le code ci-dessus doivent être remplacées par vos données respectives :

  • {replica_set_name} – saisissez le nom de votre replica set.
  • {db_username} – ajoutez l'utilisateur administrateur de la base de données principale choisie (c'est admin par défaut).
  • {db_password} – saisissez le mot de passe de l'utilisateur administrateur.
  • {NodeID} – indiquez le numéro d'identification du nœud correspondant. Vous pouvez le trouver sur le tableau de bord CloudSigma PaaS.
  • {environment_domain} – ajoutez le domaine de l'environnement. Vous pouvez également le trouver sur le tableau de bord CloudSigma PaaS :

Assurez-vous de spécifier les identifiants de chaque nœud de votre replica set dans la section mongodbConnectionURI appropriée.

Saisir les valeurs correspondantes et exécuter le code vous montrera un ensemble de chaînes similaires à ceci :

Assurez-vous de Sauvegarder le fichier à ce stade !

4. Pour qu'Apache puisse interagir avec le serveur MongoDB, il nécessite un module spécial. Vous pouvez ajouter ce module dans configs. Rendez-vous dans le dossier etc et ouvrez le php.ini fichierLocalisez la [mongodb] section. Ici, tout ce que vous avez à faire est de supprimer le point-virgule devant la ligne extension=mongodb.so pour activer cette extension :

      5. Appliquez les nouvelles configurations en cliquant sur Sauvegarder dans la fenêtre de l'éditeur. Comme toujours, nous devons redémarrer les nœuds pour appliquer les modifications. Cliquez sur le bouton Redémarrer les nœuds à côté du Serveur d'application pour ce faire :

    6. Cliquez maintenant sur le bouton Ouvrir dans le navigateur pour tester :

Cliquer sur cette icône ouvrira un nouvel onglet de navigateur qui affichera toutes les informations sur les membres/nœuds de votre replica set et leur accessibilité comme ceci :

Puisque nous avons utilisé la commande ping (ligne 6 du index.php ), la première ligne affiche le résultat de la vérification de la disponibilité du replica set :

Cela signifie que le replica set a été testé avec succès. 

Le bloc suivant dans les résultats montre des informations détaillées sur les hôtes du replica set. Ces données sont acquises grâce à la fonction getServers (ligne 11 du index.php). De même, vous pouvez également vérifier certaines valeurs attribuées lors du processus de création de ce replica set :

  • host – l'adresse IP d'une base de données spécifique.
  • port – c'est le port du membre de réplication actuel.
  • [“is_primary”] et [“is_secondary”] – paramètres qui indiquent le statut du serveur. Les valeurs correspondantes pour le serveur MongoDB principal choisi sont true, false et pour les deux autres serveurs MongoDB – false, true respectivement.

De plus, vous pouvez démarrer et arrêter les nœuds de base de données à tout moment pour suivre les modifications. Vous pouvez également rafraîchir la page pour faire de même. Cela vous permet de vous assurer que votre cluster MongoDB est toujours disponible, actif et fonctionne comme vous l'avez configuré.

CloudSigma PaaS permet à ses utilisateurs de tirer parti des avantages de l'utilisation de replica sets sans trop se soucier de la configuration et de la partie back-end. Ce tutoriel montre à quel point la configuration de votre propre cluster MongoDB peut être simple en quelques étapes seulement. Vous pouvez en savoir plus sur MongoDB, comment le configurer pour Ubuntu ou pour des serveurs cloud publics, ainsi que les autres fonctionnalités avancées que le CloudSigma PaaS a à offrir. Nous vous invitons également à faire un essai gratuit de la PaaS pour vous familiariser avec le tableau de bord et la place de marché et ce qu'ils proposent. 

Essayez la PaaS gratuitement pendant 7 jours

author

Preslav Dobrev

Auteur · CloudSigma

Preslav Dobrev est un designer créatif chez CloudSigma, axé sur une identité commerciale cohérente à travers des canaux marketing traditionnels et innovants. Il excelle à fusionner la vision artistique avec le marketing stratégique pour créer des récits de marque percutants.

Commentaires

Aucun commentaire pour l'instant. Soyez le premier.