MongoDB est une base de données NoSQL qui utilise des documents de type JSON avec des schémas dynamiques. Lorsque vous travaillez avec des bases de données, il est toujours bon d’avoir un plan d’urgence au cas où l’un de vos serveurs de base de données tomberait en panne. En outre, vous pouvez réduire les risques de défaillance en utilisant un outil de gestion astucieux pour votre site WordPress.

C’est pourquoi il est utile d’avoir plusieurs copies de vos données. Cela permet également de réduire les temps de latence en lecture. En même temps, cela peut améliorer l’évolutivité et la disponibilité de la base de données. C’est là qu’intervient la réplication. Elle est définie comme la pratique consistant à synchroniser les données entre plusieurs bases de données.

Dans cet article, nous allons nous plonger dans les différents aspects saillants de la réplication de MongoDB, comme ses caractéristiques et son mécanisme, pour n’en citer que quelques-uns.

Qu’est-ce que la réplication dans MongoDB ?

Dans MongoDB, les ensembles de répliques effectuent la réplication. Il s’agit d’un groupe de serveurs qui conservent le même ensemble de données par le biais de la réplication. Vous pouvez même utiliser la réplication MongoDB dans le cadre de l’équilibrage de la charge. Dans ce cas, vous pouvez répartir les opérations d’écriture et de lecture sur toutes les instances, en fonction du cas d’utilisation.

Qu’est-ce qu’un ensemble de répliques MongoDB ?

Chaque instance de MongoDB qui fait partie d’un ensemble de répliques donné est un membre. Chaque ensemble de répliques doit avoir un membre principal et au moins un membre secondaire.

Le membre principal est le premier point d’accès aux transactions avec l’ensemble de répliques. C’est également le seul membre qui peut accepter des opérations d’écriture. La réplication commence par copier l’oplog (journal des opérations) du membre principal. Ensuite, elle répète les modifications enregistrées sur les ensembles de données respectifs des membres secondaires. Ainsi, chaque ensemble de répliques ne peut avoir qu’un seul membre primaire à la fois. Plusieurs membres primaires recevant des opérations d’écriture peuvent provoquer des conflits de données.

En général, les applications n’interrogent que le membre primaire pour les opérations d’écriture et de lecture. Vous pouvez concevoir votre configuration pour lire à partir d’un ou de plusieurs membres secondaires. Le transfert asynchrone de données peut faire en sorte que les lectures des nœuds secondaires servent de vieilles données. Une telle configuration n’est donc pas idéale pour tous les cas d’utilisation.

Fonctionnalités de l’ensemble de répliques

Le mécanisme de basculement automatique différencie les ensembles de répliques de MongoDB de leurs concurrents. En l’absence d’un nœud primaire, une élection automatisée parmi les nœuds secondaires désigne un nouveau nœud primaire.

Ensemble de répliques MongoDB vs Cluster MongoDB

Un ensemble de répliques MongoDB crée plusieurs copies du même ensemble de données sur les nœuds de l’ensemble de répliques. L’objectif principal d’un ensemble de répliques est :

  • D’offrir une solution de sauvegarde intégrée
  • D’augmenter la disponibilité des données

Un cluster MongoDB est une toute autre affaire. Il répartit les données sur plusieurs nœuds au moyen d’une clé de partage (shard key). Ce processus fragmente les données en plusieurs morceaux appelés « shards ». Ensuite, chaque morceau est copié sur un nœud différent. Un cluster vise à prendre en charge des ensembles de données volumineux et des opérations à haut débit. Il y parvient en échelonnant horizontalement la charge de travail.

Voici la différence entre un ensemble de répliques et un cluster, en termes simples :

  • Un cluster distribue la charge de travail. Il stocke également des fragments de données (shards) sur de nombreux serveurs.
  • Un ensemble de répliques duplique complètement l’ensemble de données.

MongoDB vous permet de combiner ces fonctionnalités en créant une cluster de données (sharded cluster). Dans ce cas, vous pouvez répliquer chaque shard sur un serveur secondaire. Cela permet à un shard d’offrir une redondance et une disponibilité des données élevées.

La maintenance et la configuration d’un ensemble de répliques peuvent être techniquement difficiles et prendre beaucoup de temps. Et trouver le bon service d’hébergement ? C’est un tout autre casse-tête. Avec la multitude d’options disponibles, il est facile de perdre des heures à faire des recherches au lieu de développer votre entreprise.

Permettez-moi de vous présenter brièvement un outil qui fait tout cela et bien plus encore, afin que vous puissiez vous consacrer pleinement à votre service/produit.

La solution d’hébergement d’applications de Kinsta, à laquelle plus de 55.000 développeurs font confiance, vous permet d’être opérationnel en seulement 3 étapes simples. Si cela vous semble trop beau pour être vrai, voici d’autres avantages liés à l’utilisation de Kinsta :

  • Profitez de meilleures performances grâce aux connexions internes de Kinsta : Oubliez vos difficultés avec les bases de données partagées. Passez à des bases de données dédiées avec des connexions internes qui n’ont pas de limites de nombre de requêtes ou de nombre de lignes. Kinsta est plus rapide, plus sûr et ne vous facturera pas la bande passante/le trafic interne.
  • Un ensemble de fonctionnalités conçu pour les développeurs : Faites évoluer votre application sur la plateforme robuste qui prend en charge Gmail, YouTube et Google Search. Soyez assuré que vous êtes entre de bonnes mains.
  • Profitez de vitesses inégalées avec le centre de données de votre choix : Choisissez la région qui vous convient le mieux, à vous et à vos clients. Avec plus de 25 centres de données au choix, les 260+ PoP de Kinsta  garantissent une vitesse maximale et une présence mondiale pour votre site web.

Essayez gratuitement la solution d’hébergement d’applications de Kinsta dès aujourd’hui !

Comment fonctionne la réplication dans MongoDB ?

Dans MongoDB, vous envoyez des opérations d’écriture au serveur primaire (nœud). Le serveur primaire attribue les opérations aux serveurs secondaires, répliquant ainsi les données.

Illustration du processus de réplication de MongoDB
Illustration du processus de réplication de MongoDB (Image Source : MongoDB)

Trois types de nœuds MongoDB

Parmi les trois types de nœuds MongoDB, deux ont déjà été évoqués : les nœuds primaires et les nœuds secondaires. Le troisième type de nœud MongoDB qui s’avère utile lors de la réplication est un arbitre. Le nœud arbitre n’a pas de copie de l’ensemble de données et ne peut pas devenir un nœud primaire. Cela dit, l’arbitre participe aux élections du nœud primaire.

Nous avons déjà mentionné ce qui se passe lorsque le nœud primaire tombe en panne, mais que se passe-t-il si les nœuds secondaires ont mordu la poussière ? Dans ce cas, le nœud primaire devient secondaire et la base de données devient inaccessible.

Élection des membres

Les élections peuvent avoir lieu dans les scénarios suivants :

  • Initialisation d’un ensemble de répliques
  • Perte de connectivité avec le nœud primaire (qui peut être détectée par des battements de cœur)
  • Maintenance d’un ensemble de répliques à l’aide des méthodes rs.reconfig ou stepDown
  • Ajout d’un nouveau nœud à un ensemble de répliques existant

Un ensemble de répliques peut posséder jusqu’à 50 membres, mais seuls 7 ou moins peuvent voter lors d’une élection.

Le temps moyen avant qu’un cluster n’élise un nouveau primaire ne doit pas dépasser 12 secondes. L’algorithme d’élection essaiera d’avoir le secondaire avec la plus haute priorité disponible. En même temps, les membres ayant une valeur de priorité de 0 ne peuvent pas devenir primaires et ne participent pas à l’élection.

Nœud secondaire devenant primaire
Nœud secondaire devenant primaire (Image Source : Medium)

Préoccupation d’écriture

En ce qui concerne la durabilité, les opérations d’écriture disposent d’un framework pour copier les données dans un nombre spécifié de nœuds. Vous pouvez même offrir un retour d’information au client. Ce framework est également connu sous le nom de « préoccupation d’écriture » Il comporte des membres porteurs de données qui doivent accuser réception d’un problème d’écriture avant que l’opération ne soit considérée comme réussie. En général, les ensembles de répliques ont une valeur de 1 comme préoccupation d’écriture. Par conséquent, seul le primaire doit accuser réception de l’écriture avant de renvoyer l’accusé de réception de la préoccupation d’écriture.

Vous pouvez même augmenter le nombre de membres nécessaires pour acquitter l’opération d’écriture. Il n’y a pas de limite au nombre de membres que vous pouvez avoir. Cependant, si ce nombre est élevé, vous devrez faire face à une latence importante. En effet, le client doit attendre l’accusé de réception de tous les membres. Vous pouvez également définir la préoccupation d’écriture de la « majorité », qui calcule plus de la moitié des membres après avoir reçu leur accusé de réception.

Préférence de lecture

Pour les opérations de lecture, vous pouvez mentionner la préférence de lecture qui décrit comment la base de données dirige la requête vers les membres de l’ensemble de répliques. En général, le nœud principal reçoit l’opération de lecture, mais le client peut indiquer une préférence de lecture pour envoyer les opérations de lecture aux nœuds secondaires. Voici les options possibles pour la préférence de lecture :

  • primaryPreferred : En général, les opérations de lecture proviennent du nœud principal, mais s’il n’est pas disponible, les données sont extraites des nœuds secondaires.
  • primary : Toutes les opérations de lecture proviennent du nœud primaire.
  • secondary : Toutes les opérations de lecture sont exécutées par les nœuds secondaires.
  • nearest : Ici, les demandes de lecture sont acheminées vers le nœud accessible le plus proche, qui peut être détecté en exécutant la commande ping. Le résultat des opérations de lecture peut provenir de n’importe quel membre de l’ensemble de répliques, qu’il s’agisse du nœud principal ou du nœud secondaire.
  • secondaryPreferred : Ici, la plupart des opérations de lecture proviennent des nœuds secondaires, mais si aucun d’entre eux n’est disponible, les données sont extraites du nœud primaire.

Synchronisation des données de l’ensemble de réplication

Pour maintenir des copies à jour de l’ensemble de données partagé, les membres secondaires d’un ensemble de répliques répliquent ou synchronisent les données des autres membres.

MongoDB exploite deux formes de synchronisation des données. La synchronisation initiale pour alimenter les nouveaux membres avec l’ensemble des données. La réplication pour exécuter les modifications en cours sur l’ensemble des données.

Synchronisation initiale

Lors de la synchronisation initiale, un nœud secondaire exécute la commande init sync  pour synchroniser toutes les données du nœud principal avec un autre nœud secondaire contenant les données les plus récentes. Par conséquent, le nœud secondaire utilise systématiquement la fonction tailable cursor  pour interroger les dernières entrées oplog dans la collection local.oplog.rs du nœud primaire et applique ces opérations dans ces entrées oplog.

Depuis MongoDB 5.2, les synchronisations initiales peuvent être basées sur la copie de fichiers ou logiques.

Synchronisation logique

Lorsque vous exécutez une synchronisation logique, MongoDB :

  1. Développe tous les index de collection au fur et à mesure que les documents sont copiés pour chaque collection.
  2. Duplique toutes les bases de données à l’exception de la base de données locale. mongod  analyse chaque collection dans toutes les bases de données sources et insère toutes les données dans ses duplications de ces collections.
  3. Exécute toutes les modifications sur l’ensemble des données. En s’appuyant sur l’oplog de la source, mongod  met à jour son ensemble de données pour décrire l’état actuel de l’ensemble de répliques.
  4. Extrait les enregistrements oplog nouvellement ajoutés pendant la copie des données. Assurez-vous que le membre cible dispose de suffisamment d’espace disque dans la base de données locale pour stocker provisoirement ces enregistrements oplog pendant la durée de cette étape de copie de données.

Lorsque la synchronisation initiale est terminée, le membre passe de STARTUP2   à SECONDARY .

Synchronisation initiale basée sur la copie de fichiers

D’emblée, vous ne pouvez exécuter ce processus que si vous utilisez MongoDB Enterprise. Ce processus exécute la synchronisation initiale en dupliquant et en déplaçant les fichiers sur le système de fichiers. Cette méthode de synchronisation peut être plus rapide que la synchronisation initiale logique dans certains cas. Gardez à l’esprit que la synchronisation initiale basée sur la copie de fichiers peut entraîner des comptages inexacts si vous exécutez la méthode count() sans prédicat de requête.

Mais cette méthode a aussi ses limites :

  • Lors d’une synchronisation initiale basée sur une copie de fichier, vous ne pouvez pas écrire dans la base de données locale du membre en cours de synchronisation. Vous ne pouvez pas non plus exécuter de sauvegarde sur le membre vers lequel la synchronisation est effectuée ou sur le membre à partir duquel la synchronisation est effectuée.
  • Lorsque vous utilisez le moteur de stockage crypté, MongoDB utilise la clé source pour crypter la destination.
  • Vous ne pouvez exécuter une synchronisation initiale qu’à partir d’un seul membre à la fois.

Réplication

Les membres secondaires répliquent les données de manière cohérente après la synchronisation initiale. Les membres secondaires dupliquent l’oplog de leur synchronisation à partir de la source et exécutent ces opérations dans le cadre d’un processus asynchrone.

Les membres secondaires sont capables de modifier automatiquement leur synchronisation à partir de la source en fonction des changements dans le temps de ping et de l’état de la réplication des autres membres.

Réplication en continu

Depuis MongoDB 4.4, la synchronisation des sources envoie un flux continu d’entrées oplog à leurs secondaires de synchronisation. La réplication en continu réduit le délai de réplication dans les réseaux à forte charge et à forte latence. Elle peut également :

  • Diminuer le risque de perdre des opérations d’écriture avec w:1 en raison d’un basculement primaire.
  • Diminuer la stagnation des lectures à partir des serveurs secondaires.
  • Réduire la latence des opérations d’écriture avec w:“majority” et w:>1. En bref, tout problème d’écriture qui nécessite une attente de réplication.
Réplication multithread

MongoDB a l’habitude d’écrire des opérations par lots à travers plusieurs threads pour améliorer la concurrence. MongoDB regroupe les lots par identifiant de document et applique chaque groupe d’opérations avec un thread différent.

MongoDB exécute toujours les opérations d’écriture sur un document donné dans son ordre d’écriture original. Cela a changé dans MongoDB 4.0.

À partir de MongoDB 4.0, les opérations de lecture qui ciblent les secondaires et sont configurées avec un niveau de préoccupation de lecture de “majority” ou “local” liront désormais à partir d’un instantané WiredTiger des données si la lecture a lieu sur un secondaire où les lots de réplication sont appliqués. La lecture à partir d’un instantané garantit une vue cohérente des données et permet à la lecture de se produire simultanément avec la réplication en cours sans avoir besoin d’un verrou.

Par conséquent, les lectures secondaires nécessitant ces niveaux de lecture n’ont plus besoin d’attendre que les lots de réplication soient appliqués et peuvent être traitées au fur et à mesure qu’elles sont reçues.

Comment créer un ensemble de répliques MongoDB ?

Comme nous l’avons mentionné précédemment, MongoDB gère la réplication par le biais d’ensembles de répliques. Dans les prochaines sections, nous mettrons en évidence quelques méthodes que vous pouvez utiliser pour créer des ensembles de répliques pour votre cas d’utilisation.

Méthode 1 : Créer un nouvel ensemble de répliques MongoDB sur Ubuntu

Avant de commencer, vous devez vous assurer que vous avez au moins trois serveurs fonctionnant sous Ubuntu 20.04, avec MongoDB installé sur chaque serveur.

Pour configurer un ensemble de répliques, il est essentiel de fournir une adresse à laquelle chaque membre de l’ensemble de répliques peut être joint par les autres membres de l’ensemble. Dans ce cas, nous conservons trois membres dans l’ensemble. Il est possible d’utiliser des adresses IP, mais ce n’est pas recommandé car les adresses peuvent changer de manière inattendue. Une meilleure alternative consiste à utiliser les noms d’hôtes DNS logiques lors de la configuration des ensembles de répliques.

Nous pouvons le faire en configurant le sous-domaine pour chaque membre de réplication. Bien que cela puisse être idéal pour un environnement de production, cette section explique comment configurer la résolution DNS en éditant les fichiers hosts respectifs de chaque serveur. Ce fichier nous permet d’attribuer des noms d’hôtes lisibles à des adresses IP numériques. Ainsi, si votre adresse IP change, il vous suffit de mettre à jour les fichiers hosts sur les trois serveurs plutôt que de reconfigurer le jeu de répliques à partir de zéro !

La plupart du temps, hosts est stocké dans le répertoire /etc/. Répétez les commandes ci-dessous pour chacun de vos trois serveurs :

sudo nano /etc/hosts

Dans la commande ci-dessus, nous utilisons nano comme éditeur de texte, mais vous pouvez utiliser n’importe quel éditeur de texte. Après les premières lignes qui configurent l’hôte local, ajoutez une entrée pour chaque membre de l’ensemble de répliques. Ces entrées prennent la forme d’une adresse IP suivie du nom lisible par l’homme de votre choix. Vous pouvez leur donner le nom que vous souhaitez, mais veillez à ce qu’il soit descriptif afin de pouvoir différencier chaque membre. Pour ce tutoriel, nous utiliserons les noms d’hôtes ci-dessous :

  • mongo0.replset.member
  • mongo1.replset.member
  • mongo2.replset.member

En utilisant ces noms d’hôtes, vos fichiers /etc/hosts ressembleraient aux lignes surlignées suivantes :

Noms d'hôtes
Noms d’hôtes

Enregistrez et fermez le fichier.

Après avoir configuré la résolution DNS pour l’ensemble de répliques, nous devons mettre à jour les règles du pare-feu pour leur permettre de communiquer entre eux. Exécutez la commande ufw suivante sur mongo0 pour permettre à mongo1 d’accéder au port 27017 de mongo0 :

sudo ufw allow from mongo1_server_ip to any port 27017

À la place du paramètre mongo1_server_ip, entrez l’adresse IP réelle de votre serveur mongo1. De plus, si vous avez mis à jour l’instance Mongo sur ce serveur pour utiliser un port autre que celui par défaut, assurez-vous de modifier 27017 pour refléter le port utilisé par votre instance MongoDB.

Ajoutez maintenant une autre règle de pare-feu pour permettre à Mongo2 d’accéder au même port :

sudo ufw allow from mongo2_server_ip to any port 27017

À la place du paramètre mongo2_server_ip, saisissez l’adresse IP réelle de votre serveur mongo2. Mettez ensuite à jour les règles de pare-feu pour vos deux autres serveurs. Exécutez les commandes suivantes sur le serveur mongo1, en veillant à modifier les adresses IP à la place du paramètre server_ip pour refléter celles de mongo0 et mongo2, respectivement :

sudo ufw allow from mongo0_server_ip to any port 27017
sudo ufw allow from mongo2_server_ip to any port 27017

Enfin, exécutez ces deux commandes sur mongo2. Encore une fois, assurez-vous que vous saisissez les adresses IP correctes pour chaque serveur :

sudo ufw allow from mongo0_server_ip to any port 27017
sudo ufw allow from mongo1_server_ip to any port 27017

L’étape suivante consiste à mettre à jour le fichier de configuration de chaque instance de MongoDB afin d’autoriser les connexions externes. Pour ce faire, vous devez modifier le fichier de configuration de chaque serveur afin de refléter l’adresse IP et d’indiquer l’ensemble de répliques. Bien que vous puissiez utiliser l’éditeur de texte de votre choix, nous utiliserons une fois de plus l’éditeur de texte nano. Effectuons les modifications suivantes dans chaque fichier mongod.conf.

Sur mongo0 :

# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo0.replset.member# replica set
replication:
replSetName: "rs0"

Sur mongo1 :

# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo1.replset.member
replication:
replSetName: "rs0"

Sur mongo2 :

# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo2.replset.member
replication:
replSetName: "rs0"
sudo systemctl restart mongod

Vous avez ainsi activé la réplication pour l’instance MongoDB de chaque serveur.

Vous pouvez maintenant initialiser l’ensemble de répliques en utilisant la méthode rs.initiate(). Cette méthode ne doit être exécutée que sur une seule instance MongoDB de l’ensemble de réplicas. Assurez-vous que le nom et le membre de l’ensemble de répliques correspondent aux configurations que vous avez effectuées dans chaque fichier de configuration précédemment.

rs.initiate(
  {
    _id: "rs0",
    members: [
      { _id: 0, host: "mongo0.replset.member" },
      { _id: 1, host: "mongo1.replset.member" },
      { _id: 2, host: "mongo2.replset.member" }
    ]
  }
)

Si la méthode renvoie « ok » : 1, cela signifie que l’ensemble de répliques a été démarré correctement. Vous trouverez ci-dessous un exemple de ce à quoi la sortie doit ressembler :

 "ok": 1,
  "$clusterTime": {
    "clusterTime": Timestamp(1612389071, 1),
    "signature": {
      "hash": BinData(0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
      "keyId": NumberLong(0)
    }
  },
  "operationTime": Timestamp(1612389071, 1)
}

Arrêter le serveur MongoDB

Vous pouvez arrêter un serveur MongoDB en utilisant la méthode db.shutdownServer(). Vous trouverez ci-dessous la syntaxe de cette méthode. Les paramètres

db.shutdownServer({
  force: <boolean>,
  timeoutSecs: <int>
})

Cette méthode peut échouer si le membre de l’ensemble de répliques MongoDB exécute certaines opérations telles que la construction d’index. Pour interrompre ces opérations et forcer le membre à s’arrêter, vous pouvez saisir le paramètre booléen force   à true.

Redémarrer MongoDB avec –replSet

Pour réinitialiser la configuration, assurez-vous que chaque nœud de votre ensemble de répliques est arrêté. Supprimez ensuite la base de données locale de chaque nœud. Redémarrez-le en utilisant le drapeau –replSet et exécutez rs.initiate() sur une seule instance de MongoDB pour l’ensemble de répliques.

mongod --replSet "rs0"

rs.initiate() peut prendre un document optionnel de configuration de l’ensemble de répliques, à savoir :

  • L’option Replication.replSetName ou —replSet pour spécifier le nom de l’ensemble de répliques dans le champ _id.
  • Le tableau des membres, qui contient un document pour chaque membre de l’ensemble de répliques.

La méthode rs.initiate() déclenche une élection et choisit l’un des membres comme membre principal.

Ajouter des membres à l’ensemble de répliques

Pour ajouter des membres à l’ensemble, démarrez des instances mongod sur plusieurs machines. Ensuite, démarrez un client Mongo et utilisez la commande rs.add().

La commande rs.add() a la syntaxe de base suivante :

rs.add(HOST_NAME:PORT)

Par exemple,

Supposez que mongo1 est votre instance mongod et qu’elle écoute sur le port 27017. Utilisez la commande client Mongo rs.add() pour ajouter cette instance à l’ensemble de répliques.

rs.add("mongo1:27017")

Vous ne pouvez ajouter une instance mongod à l’ensemble de répliques que si vous êtes connecté au nœud principal. Pour vérifier que vous êtes connecté au nœud principal, utilisez la commande db.isMaster().

Supprimer des membres

Pour supprimer un membre, vous pouvez utiliser la commande rs.remove()

Pour cela, arrêtez tout d’abord l’instance de mongod que vous souhaitez supprimer en utilisant la méthode db.shutdownServer() dont nous avons parlé plus haut.

Ensuite, connectez-vous à l’instance primaire actuelle de l’ensemble de répliques. Pour déterminer le primaire actuel, utilisez db.hello() lorsque vous êtes connecté à n’importe quel membre de l’ensemble de répliques. Une fois que vous avez déterminé le primaire, exécutez l’une des commandes suivantes :

rs.remove("mongodb-node-04:27017")
rs.remove("mongodb-node-04")
L'image ci-dessus montre que le nœud a été supprimé avec succès de l'ensemble de répliques.
L’image ci-dessus montre que le nœud a été supprimé avec succès de l’ensemble de répliques. (Source de l’image : Bmc)

Si l’ensemble de répliques doit élire un nouveau primaire, MongoDB peut déconnecter brièvement le shell. Dans ce cas, il se reconnecte automatiquement. En outre, il peut afficher une erreur DBClientCursor::init call() failed même si la commande réussit.

Méthode 2 : Configuration d’un ensemble de répliques MongoDB pour le déploiement et les tests

En général, vous pouvez configurer les ensembles de répliques pour les tests soit avec RBAC activé, soit avec RBAC désactivé. Dans cette méthode, nous allons configurer les ensembles de répliques avec le contrôle d’accès désactivé pour les déployer dans un environnement de test.

Tout d’abord, créez des répertoires pour toutes les instances qui font partie de l’ensemble de répliques à l’aide de la commande suivante :

mkdir -p /srv/mongodb/replicaset0-0  /srv/mongodb/replicaset0-1 /srv/mongodb/replicaset0-2

Cette commande créera des répertoires pour trois instances MongoDB : replicaset0-0, replicaset0-1 et replicaset0-2. Démarrez maintenant les instances MongoDB pour chacune d’entre elles à l’aide de la série de commandes suivante :

Pour le serveur 1 :

mongod --replSet replicaset --port 27017 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0  --oplogSize 128

Pour le serveur 2 :

mongod --replSet replicaset --port 27018 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0  --oplogSize 128

Pour le serveur 3 :

mongod --replSet replicaset --port 27019 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0  --oplogSize 128

Le paramètre –oplogSize est utilisé pour éviter que la machine ne soit surchargée pendant la phase de test. Il permet de réduire l’espace disque consommé par chaque disque.

Maintenant, connectez-vous à l’une des instances à l’aide du shell Mongo en utilisant le numéro de port ci-dessous.

mongo --port 27017

Nous pouvons utiliser la commande rs.initiate() pour lancer le processus de réplication. Vous devrez remplacer le paramètre hostname par le nom de votre système.

rs conf = {

  _id: "replicaset0",

  members: [

    {  _id: 0,  host: "<hostname>:27017},

    {  _id: 1,  host: "<hostname>:27018"},

    {  _id: 2,  host: "<hostname>:27019"}

   ] }

Vous pouvez maintenant passer le fichier objet de configuration en paramètre de la commande initiate et l’utiliser comme suit :

rs.initiate(rsconf)

Et voilà ! Vous avez réussi à créer un ensemble de répliques MongoDB à des fins de développement et de test.

Méthode 3 : Transformer une instance autonome en un ensemble de répliques MongoDB

MongoDB permet à ses utilisateurs de transformer leurs instances autonomes en ensembles de répliques. Alors que les instances autonomes sont principalement utilisées pour la phase de test et de développement, les ensembles de répliques font partie de l’environnement de production.

Pour commencer, arrêtons notre instance mongod à l’aide de la commande suivante :

db.adminCommand({"shutdown":"1"})

Redémarrez votre instance en utilisant le paramètre –repelSet dans votre commande pour spécifier l’ensemble de répliques que vous allez utiliser :

mongod --port 27017 – dbpath /var/lib/mongodb  --replSet replicaSet1 --bind_ip localhost,<hostname(s)|ip address(es)>

Vous devez spécifier le nom de votre serveur ainsi que l’adresse unique dans la commande.

Connectez le shell à votre instance MongoDB et utilisez la commande initiate pour lancer le processus de réplication et convertir avec succès l’instance en un ensemble de répliques. Vous pouvez effectuer toutes les opérations de base telles que l’ajout ou la suppression d’une instance à l’aide des commandes suivantes :

rs.add(“<host_name:port>”)
rs.remove(“host-name”)

En outre, vous pouvez vérifier l’état de votre ensemble de répliques MongoDB à l’aide des commandes rs.status() et rs.conf().

Méthode 4 : MongoDB Atlas – Une alternative plus simple

La réplication et le sharding peuvent fonctionner ensemble pour former ce que l’on appelle un cluster shardé. Bien que l’installation et la configuration puissent prendre beaucoup de temps, MongoDB Atlas est une meilleure alternative que les méthodes mentionnées ci-dessus.

Il automatise vos ensembles de répliques, ce qui rend le processus facile à mettre en œuvre. Il peut déployer des ensembles de répliques globalement partagés en quelques clics, ce qui permet la reprise après sinistre, une gestion plus facile, la localité des données et des déploiements multi-régionaux.

Dans MongoDB Atlas, nous devons créer des clusters – il peut s’agir d’un ensemble de répliques ou d’un cluster partagé. Pour un projet particulier, le nombre de nœuds dans un cluster dans d’autres régions est limité à un total de 40.

Cela exclut les clusters gratuits ou partagés et les régions du cloud de Google qui communiquent entre elles. Le nombre total de nœuds entre deux régions doit respecter cette contrainte. Par exemple, s’il existe un projet dans lequel :

  • La région A a 15 nœuds.
  • La région B a 25 nœuds
  • La région C a 10 nœuds

Nous ne pouvons attribuer que 5 nœuds supplémentaires à la région C,

  1. Région A+ Région B = 40 ; respecte la contrainte de 40, qui est le nombre maximum de nœuds autorisé.
  2. Région B+ Région C = 25+10+5 (nœuds supplémentaires alloués à C) = 40 ; respecte la contrainte de 40 qui est le nombre maximal de nœuds autorisé.
  3. Région A+ Région C = 15+10+5 (nœuds supplémentaires attribués à C) = 30 ; respecte la contrainte de 40, qui est le nombre maximal de nœuds autorisé.

Si nous attribuons 10 nœuds supplémentaires à la région C, ce qui fait que la région C a 20 nœuds, alors la région B + la région C = 45 nœuds. Cela dépasserait la contrainte donnée, et il se peut donc que vous ne puissiez pas créer un cluster multi-régions.

Lorsque vous créez un cluster, Atlas crée un conteneur réseau dans le projet pour le fournisseur de cloud s’il n’était pas présent auparavant. Pour créer un cluster d’ensembles de répliques dans MongoDB Atlas, exécutez la commande suivante dans Atlas CLI :

atlas clusters create [name] [options]

Veillez à donner un nom de cluster descriptif, car il ne peut pas être modifié après la création du cluster. L’argument peut contenir des lettres ASCII, des chiffres et des traits d’union.

Plusieurs options sont disponibles pour la création d’un cluster dans MongoDB en fonction de vos besoins. Par exemple, si vous souhaitez une sauvegarde continue dans le cloud pour votre cluster, définissez --backup sur true.

Gestion du délai de réplication

Le délai de réplication peut être assez déconcertant. Il s’agit d’un délai entre une opération sur le primaire et l’application de cette opération de l’oplog au secondaire. Si votre entreprise traite de grands ensembles de données, un délai est attendu dans une certaine limite. Cependant, des facteurs externes peuvent parfois contribuer à augmenter le délai. Pour bénéficier d’une réplication à jour, assurez-vous que :

  1. Vous acheminez votre trafic réseau dans une bande passante stable et suffisante. La latence du réseau joue un rôle important dans votre réplication, et si le réseau est insuffisant pour répondre aux besoins du processus de réplication, il y aura des retards dans la réplication des données à travers l’ensemble de répliques.
  2. Vous disposez d’un débit de disque suffisant. Si le système de fichiers et l’unité de disque du nœud secondaire ne sont pas en mesure de transférer les données sur le disque aussi rapidement que le nœud primaire, le nœud secondaire aura du mal à suivre. Par conséquent, les nœuds secondaires traitent les requêtes d’écriture plus lentement que le nœud principal. Il s’agit d’un problème courant dans la plupart des systèmes multi-locataires, y compris les instances virtualisées et les déploiements à grande échelle.
  3. Vous demandez un accusé de réception d’écriture après un certain temps pour permettre aux nœuds secondaires de rattraper le nœud principal, en particulier lorsque vous souhaitez effectuer une opération de chargement en masse ou d’ingestion de données nécessitant un grand nombre d’écritures sur le nœud principal. Les tâches secondaires ne seront pas en mesure de lire l’oplog assez rapidement pour suivre les changements, en particulier avec les problèmes d’écriture non acquittés.
  4. Vous identifiez les tâches d’arrière-plan en cours d’exécution. Certaines tâches telles que les tâches cron, les mises à jour de serveur et les vérifications de sécurité peuvent avoir des effets inattendus sur l’utilisation du réseau ou du disque, entraînant des retards dans le processus de réplication.

Si vous n’êtes pas sûr qu’il y ait un délai de réplication dans votre application, ne vous inquiétez pas – la section suivante traite des stratégies de dépannage !

Dépannage des ensembles de répliques MongoDB

Vous avez configuré avec succès vos ensembles de répliques, mais vous remarquez que vos données ne sont pas cohérentes d’un serveur à l’autre. Cette situation est très alarmante pour les entreprises à grande échelle. Cependant, grâce à des méthodes de dépannage rapides, vous pouvez trouver la cause ou même corriger le problème ! Vous trouverez ci-dessous quelques stratégies courantes de dépannage des déploiements d’ensembles de répliques qui pourraient s’avérer utiles :

Vérifier l’état des répliques

Nous pouvons vérifier l’état actuel de l’ensemble de répliques et l’état de chaque membre en exécutant la commande suivante dans une session mongosh connectée à l’ensemble de répliques primaire.

 rs.status()

Vérifier le délai de réplication

Comme nous l’avons vu précédemment, le délai de réplication peut être un problème sérieux car il rend les membres « retardés » inéligibles pour devenir rapidement primaires et augmente la possibilité que les opérations de lecture distribuées soient incohérentes. Nous pouvons vérifier la longueur actuelle du journal de réplication en utilisant la commande suivante :

rs.printSecondaryReplicationInfo()

Cette commande renvoie la valeur syncedTo, qui correspond à l’heure à laquelle la dernière entrée oplog a été écrite sur le serveur secondaire pour chaque membre. Voici un exemple de démonstration :

source: m1.example.net:27017
    syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
source: m2.example.net:27017
    syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary

Un membre retardé peut afficher un retard de 0 seconde par rapport au membre principal lorsque la période d’inactivité sur le membre principal est supérieure à la valeur members[n].secondaryDelaySecs.

Tester les connexions entre tous les membres

Chaque membre d’un ensemble de répliques doit pouvoir se connecter à tous les autres membres. Veillez toujours à vérifier les connexions dans les deux sens. La plupart du temps, les configurations de pare-feu ou les topologies de réseau empêchent la connectivité normale et nécessaire, ce qui peut bloquer la réplication.

Par exemple, supposons que l’instance mongod se lie à la fois à localhost et au nom d’hôte « ExampleHostname » qui est associé à l’adresse IP 198.41.110.1 :

mongod --bind_ip localhost, ExampleHostname

Pour se connecter à cette instance, les clients distants doivent spécifier le nom d’hôte ou l’adresse IP :

mongosh --host ExampleHostname
mongosh --host 198.41.110.1

Si un ensemble de répliques se compose de trois membres, m1, m2 et m3, et utilise le port par défaut 27017, vous devez tester la connexion comme suit :

Sur m1 :

mongosh --host m2 --port 27017
mongosh --host m3 --port 27017

Sur m2 :

mongosh --host m1 --port 27017
mongosh --host m3 --port 27017

Sur m3 :

mongosh --host m1 --port 27017
mongosh --host m2 --port 27017

Si une connexion échoue dans n’importe quelle direction, vous devez vérifier la configuration de votre pare-feu et la reconfigurer pour autoriser les connexions.

Garantir des communications sécurisées avec l’authentification par fichier clé

Par défaut, l’authentification par fichier clé dans MongoDB repose sur le mécanisme d’authentification par réponse à un défi salé (SCRAM). Pour ce faire, MongoDB doit lire et valider les informations d’identification fournies par l’utilisateur, qui comprennent une combinaison du nom d’utilisateur, du mot de passe et de la base de données d’authentification connue par l’instance spécifique de MongoDB. Il s’agit du mécanisme exact utilisé pour authentifier les utilisateurs qui fournissent un mot de passe lors de la connexion à la base de données.

Lorsque vous activez l’authentification dans MongoDB, le contrôle d’accès basé sur les rôles (RBAC) est automatiquement activé pour l’ensemble de répliques, et l’utilisateur se voit attribuer un ou plusieurs rôles qui déterminent son accès aux ressources de la base de données. Lorsque le contrôle d’accès basé sur les rôles est activé, cela signifie que seul l’utilisateur Mongo authentifié et disposant des privilèges appropriés peut accéder aux ressources du système.

Le fichier clé agit comme un mot de passe partagé pour chaque membre du cluster. Cela permet à chaque instance Mongo de l’ensemble de répliques d’utiliser le contenu du fichier clé comme mot de passe partagé pour authentifier les autres membres du déploiement.

Seules les instances mongod ayant le bon fichier clé peuvent rejoindre l’ensemble de répliques. La longueur d’une clé doit être comprise entre 6 et 1024 caractères et ne peut contenir que des caractères de l’ensemble base64. Veuillez noter que MongoDB supprime les caractères d’espacement lors de la lecture des clés.

Vous pouvez générer un fichier clé à l’aide de différentes méthodes. Dans ce tutoriel, nous utilisons openssl pour générer une chaîne complexe de 1024 caractères aléatoires à utiliser comme mot de passe partagé. Il utilise ensuite chmod pour modifier les autorisations de fichiers afin de fournir des autorisations de lecture uniquement au propriétaire du fichier. Évitez de stocker le fichier clé sur des supports de stockage qui peuvent être facilement déconnectés du matériel hébergeant les instances de mongod, tels qu’une clé USB ou un périphérique de stockage connecté au réseau. Vous trouverez ci-dessous la commande permettant de générer un fichier clé :

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

Copiez ensuite le fichier clé dans chaque membre de l’ensemble de répliques. Assurez-vous que l’utilisateur qui exécute les instances mongod est le propriétaire du fichier et qu’il peut accéder au fichier clé. Une fois que vous avez fait ce qui précède, arrêtez tous les membres de l’ensemble de répliques en commençant par les secondaires. Une fois que tous les secondaires sont hors ligne, vous pouvez arrêter le primaire. Il est essentiel de respecter cet ordre afin d’éviter d’éventuels retours en arrière. Arrêtez maintenant l’instance mongod en exécutant la commande suivante :

use admin
db.shutdownServer()

Une fois la commande exécutée, tous les membres de l’ensemble de répliques seront hors ligne. Redémarrez maintenant chaque membre de l’ensemble de répliques avec le contrôle d’accès activé.

Pour chaque membre de l’ensemble de répliques, démarrez l’instance mongod avec le paramètre du fichier de configuration security.keyFile ou l’option de ligne de commande --keyFile.

Si vous utilisez un fichier de configuration, définissez

  • security.keyFile au chemin du fichier clé, et
  • replication.replSetName au nom de l’ensemble de répliques.
security:
  keyFile: <path-to-keyfile>
replication:
  replSetName: <replicaSetName>
net:
   bindIp: localhost,<hostname(s)|ip address(es)>

Démarrez l’instance mongod à l’aide du fichier de configuration :

mongod --config <path-to-config-file>

Si vous utilisez les options de la ligne de commande, démarrez l’instance mongod avec les options suivantes :

  • –keyFile qui correspond au chemin d’accès du fichier clé, et
  • –replSet le nom de l’ensemble de répliques.
mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

Vous pouvez inclure des options supplémentaires en fonction de votre configuration. Par exemple, si vous souhaitez que des clients distants se connectent à votre déploiement ou si les membres de votre déploiement sont exécutés sur des hôtes différents, spécifiez l’option –bind_ip. Pour plus d’informations, reportez-vous à la section Modifications de la compatibilité de la liaison avec l’hôte local.

Ensuite, connectez-vous à un membre de l’ensemble de réplicas via l’interface localhost. Vous devez exécuter mongosh sur la même machine physique que l’instance de mongod. Cette interface n’est disponible que si aucun utilisateur n’a été créé pour le déploiement et se ferme automatiquement après la création du premier utilisateur.

Nous lançons ensuite l’ensemble de répliques. À partir de mongosh, exécutez la méthode rs.initiate():

rs.initiate(
  {
    _id: "myReplSet",
    members: [
      { _id: 0, host: "mongo1:27017" },
      { _id: 1, host: "mongo2:27017" },
      { _id: 2, host: "mongo3:27017" }
    ]
  }
)

Comme nous l’avons vu précédemment, cette méthode permet d’élire l’un des membres comme membre principal de l’ensemble de répliques. Pour localiser le membre principal, utilisez rs.status(). Connectez-vous au membre principal avant de continuer.

Créez maintenant l’utilisateur administrateur. Vous pouvez ajouter un utilisateur en utilisant la méthode db.createUser(). Veillez à ce que l’utilisateur ait au moins le rôle userAdminAnyDatabase dans la base de données d’administration.

L’exemple suivant crée l’utilisateur « batman » avec le rôle userAdminAnyDatabase dans la base de données de l’administrateur :

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "batman",
    pwd: passwordPrompt(), // or cleartext password
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

Saisissez le mot de passe créé précédemment lorsque vous y êtes invité.

Ensuite, vous devez vous authentifier en tant qu’utilisateur administrateur. Pour cela, utilisez db.auth() pour vous authentifier. Par exemple :

db.getSiblingDB(« admin »).auth(« batman », passwordPrompt()) // ou mot de passe en clair

Vous pouvez également connecter une nouvelle instance de mongosh au membre de l’ensemble de répliques primaire en utilisant les paramètres -u <username>, -p <password> et --authenticationDatabase.

mongosh -u "batman" -p  --authenticationDatabase "admin"

Même si vous ne spécifiez pas le mot de passe dans le champ de ligne de commande -p, mongosh vous demande le mot de passe.

Enfin, créez l’administrateur du cluster. Le rôle clusterAdmin permet d’accéder aux opérations de réplication, telles que la configuration de l’ensemble de répliques.

Créons un utilisateur administrateur de cluster et attribuons-lui le rôle clusterAdmin dans la base de données admin :

db.getSiblingDB("admin").createUser(
  {
    "user": "robin",
    "pwd": passwordPrompt(),     // or cleartext password
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

Saisissez le mot de passe lorsque vous y êtes invité.

Si vous le souhaitez, vous pouvez créer des utilisateurs supplémentaires pour permettre aux clients d’interagir avec l’ensemble de répliques.

Et voilà ! Vous avez bien activé l’authentification par fichier clé !

Résumé

La réplication est une exigence essentielle en matière de bases de données, en particulier à mesure que les entreprises se développent. Elle améliore considérablement les performances, la sécurité des données et la disponibilité du système. En parlant de performance, il est essentiel pour votre base de données WordPress de surveiller les problèmes de performance et de les rectifier à temps, par exemple avec Kinsta APM, Jetpack et Freshping, pour n’en citer que quelques-uns.

La réplication permet d’assurer la protection des données sur plusieurs serveurs et empêche vos serveurs de souffrir de temps d’arrêt importants (ou pire encore – de perdre toutes vos données). Dans cet article, nous avons abordé la création d’un jeu de répliques et quelques conseils de dépannage, ainsi que l’importance de la réplication. Utilisez-vous la réplication MongoDB dans votre entreprise et s’est-elle avérée utile ? Faites-nous part de vos commentaires dans la section ci-dessous !

Jeremy Holcombe Kinsta

Rédacteur en chef du contenu et du marketing chez Kinsta, développeur web WordPress et rédacteur de contenu. En dehors de WordPress, j'aime la plage, le golf et le cinéma. J'ai aussi des problèmes avec les personnes de grande taille ;).