MongoDB - système de base de données orienté document populaire qui ne nécessite pas de développer et de créer des schémas de base de données.
Largement utilisé dans le développement d'applications Web et également pour tout type de logiciel où NoSQL est plus efficace et utile que la base de données relationnelle.
Le seul serveur de base de données suffit souvent pour développer une application ou la tester.
Avant de commencer à utiliser une application dans un environnement de production, il est recommandé de réfléchir aux risques éventuels : que peut-il se passer si les données sont stockées sur le seul serveur de base de données ?
Si les données ne sont pas critiques (par exemple, à des fins de cache), une application continuera à fonctionner sans ces données, le temps nécessaire à la restauration de la base de données (en cas de panne) est acceptable - alors le seul serveur suffit.
Sinon, si la donnée est considérée comme critique, sa perte ou son inaccessibilité affecte une application (donc un service dont clients reçoivent) — dans ce cas, la recommandation est d'utiliser un cluster pour le stockage des données.
MongoDB permet de construire deux types de cluster :
- Ensemble de répliques : ensemble de serveurs stockant les mêmes données, l'accessibilité des données est assurée par réplication.
- Cluster partagé : répartir des parties des données sur plusieurs serveurs, signifie une mise à l'échelle horizontale.
Ci-dessous est illustré le processus de configuration d'un cluster de jeux de répliques.
Jeu de réplicas — rôles de serveurs.
Le cluster MongoDB nécessite au minimum trois serveurs (nœuds) (ou nombre impair) :
- Serveur principal — gère toutes les requêtes de lecture/écriture. Toutes les opérations modifiant les données sont stockées dans une collection spéciale nommée "oplog" (journal des opérations) - les entrées de cette collection sont utilisées pour effectuer la réplication.
- Serveur secondaire (minimum deux serveurs) — réplique la collection oplog et applique les modifications aux données stockées. Ce processus garantit que les données sont identiques sur tous les serveurs.
Régime commun :
Jeu de réplicas — configuration.
Coordonnées des serveurs utilisés :
- Serveur principal : nom — serveur1, IP 10.20.30.10
- Serveur secondaire : nom — serveur2, IP 10.20.30.20
- Serveur secondaire : nom — serveur3, IP 10.20.30.30
Remplacez les noms et adresses IP par les vôtres.
Étapes pour tous les serveurs avant de continuer :
- Installez MongoDB.
- Configurer firewall s'il est utilisé pour autoriser les paquets in\out sur le port 27017.
- Définir la résolution des noms de serveurs : si non DNS serveur est en cours d'utilisation, cela peut être fait en ajoutant des entrées au fichier /etc/hosts comme ceci :
10.20.30.20 serveur2.domaine.local serveur2
10.20.30.30 serveur3.domaine.local serveur3
Remarque importante : toutes les commandes de configuration ci-dessous doivent contenir uniquement des noms de serveurs ! À partir de la version 5.0, il n'est pas autorisé d'utiliser des adresses IP — MongoDB vérifie la configuration et ne démarrera pas s'il y a des adresses IP.
Étapes de configuration du cluster :
1. Démarrez MongoDB sur tous les serveurs :
"rs0" - nom de la réplique (choisissez un autre nom si nécessaire)
nom_serveur — nom d'un serveur sur lequel MongoDB démarre.
2. Sur le serveur principal, démarrez le shell MongoDB nommé "mongo" (en utilisant vos informations d'identification au lieu du nom d'utilisateur et du mot de passe) :
3. Initialisez la réplication et ajoutez tous les serveurs au cluster :
_id : "rs0",
membres: [
{ _id : 0, hôte : "server1.domain.local:27017" },
{ _id : 1, hôte : "server2.domain.local:27017" },
{ _id : 2, hôte : "server3.domain.local:27017" },
]
})
Cette étape doit être effectuée sur le serveur principal uniquement, pas besoin de la répéter sur le serveur secondaire.
4. Vérifiez les paramètres de réplication à l'aide de la commande "rs.conf()" - la sortie de cette commande affiche parammètres de chaque serveur. Pour le serveur principal, cela devrait ressembler à ceci :
"_id" : "rs0",
"version 1,
"protocolVersion" : NumberLong(1),
"membres" : [
{
"_id" : 0,
"hôte" : "serveur1.domaine.local:27017",
"arbitreSeul" : faux,
"buildIndex" : vrai,
"caché" : faux,
"priorité" : 1,
"Mots clés" : {
},
"slaveDelay" : NombreLong(0),
"voix" : 1
},
5. On peut remarquer que chaque serveur a une priorité par défaut — 1 : la chaîne « priorité : 1 ».
La valeur de priorité est utilisée lors de l'élection : la valeur la plus basse signifie la possibilité la plus élevée de devenir un nouveau serveur principal.
Il pourrait être défini avant quel serveur exactement secondaire sera élu comme nouveau primaire par ces commandes :
conf['membres'][0].priority = 1
conf['membres'][1].priority = 2
conf['membres'][2].priority = 3
rs.reconfig(conf)
Ainsi,
- server1 est toujours principal.
- le serveur2 sera le nouveau serveur principal si le serveur1 est inaccessible.
- le serveur3 restera le seul serveur principal du cluster si le serveur1 et le serveur2 sont inaccessibles.
6. Vérifiez l'état de la réplication avec la commande « rs.status() ». La présence de tous les serveurs doit être vérifiée dans la sortie ainsi que son état (la chaîne "stateStr").
Exemple pour le serveur principal :
{
"_id" : 0,
"nom" : "serveur1:27017",
"santé" : 1,
"état" : 1,
"stateStr" : "PRIMAIRE",
"uptime" : 87986,
"optimal" : {
"ts" : horodatage(1526936047, 1),
"t" : NombreLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : horodatage(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"soi" : vrai
},
La valeur de "stateStr" est "PRIMARY", cela signifie que le serveur1 est bien le primaire.
Pour le serveur secondaire2 :
"_id" : 0,
"nom" : "serveur2:27017",
"santé" : 1,
"état" : 2,
"stateStr" : "SECONDAIRE",
"uptime" : 97453,
"optimal" : {
"ts" : horodatage(1526936047, 1),
"t" : NombreLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : horodatage(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"soi" : vrai
},
"stateStr" est "SECONDAIRE", signifie que le serveur2 fait partie du cluster et secondaire comme prévu. Une sortie similaire devrait être pour server3.
Par défaut, les serveurs vérifient l'état (santé) les uns des autres toutes les 10 secondes (la période est modifiable).
Comme indiqué précédemment, si le serveur principal est inaccessible, le processus d'élection est lancé.
Selon les valeurs de priorité, le serveur2 deviendra un nouveau primaire - cela peut être vu dans la sortie "rs.status()" : "stateStr" sera changé de "SECONDARY" à "PRIMARY".
Pour le serveur1 "stateStr" sera "non accessible/sain" en même temps.
Une fois que le serveur1 est à nouveau disponible dans le cluster (les données sont répliquées à partir du serveur2 et après le démarrage de cette nouvelle élection), le serveur1 devient le serveur principal en raison de sa priorité.
Le cluster configuré permet également d'effectuer la maintenance sur n'importe quel serveur sans impact sur une application car les données sont accessibles depuis un autre serveur.
Conclusion
Ces étapes suffisent pour configurer un cluster "jeu de réplicas" de base.
Une configuration plus complexe pourrait être utilisée, y compris une combinaisonnation des deux types de clusters.
Des exemples de ce type de configurations seront discutés dans les articles suivants.