Exercice 3 : Réponses

1. Numéros de Ports Logiques Identiques pour les Serveurs de Réplicas

Non, cela ne pose pas de problème tant que les serveurs de réplicas sont sur des machines distinctes
avec des adresses IP différentes. Les numéros de port doivent être uniques au sein d'une seule
machine, mais peuvent être identiques sur des machines différentes. Chaque serveur dans un
ensemble de réplicas peut écouter le même port tant qu'il est hébergé sur une machine (ou adresse
IP) distincte.

2. Commandes pour Configurer le Replica Set RSnet

Supposons que les adresses IP des serveurs sont 192.168.1.1 (primaire), 192.168.1.2 à 192.168.1.5
(secondaires) et 192.168.1.6, 192.168.1.7 (arbitres).

Sur chaque Serveur (Primaire et Secondaires) :

bashCopy code

mongod --replSet RSnet --port <port_number> --dbpath <data_directory> --bind_ip <server_ip>

Remplacez <port_number> par le numéro de port, <data_directory> par le répertoire de données et

<server_ip> par l'adresse IP du serveur.

Sur le Serveur Primaire :

javascriptCopy code

rs.initiate({ _id: "RSnet", members: [ { _id: 0, host: "192.168.1.1:<port>", priority: 1 }, { _id: 1, host:
"192.168.1.2:<port>", priority: 0.6 }, { _id: 2, host: "192.168.1.3:<port>", priority: 0.5 }, { _id: 3, host:
"192.168.1.4:<port>", priority: 0.7 }, { _id: 4, host: "192.168.1.5:<port>", priority: 0.8 }, { _id: 5, host:
"192.168.1.6:<port>", arbiterOnly: true }, { _id: 6, host: "192.168.1.7:<port>", arbiterOnly: true } ] });

3. Fonctionnement Normal Après un Crash Momentané

Lorsqu'un serveur dans RSnet reprend son fonctionnement après un crash, il tente de rattraper son
retard en synchronisant les données manquantes depuis le dernier checkpoint. Si c'est un serveur
secondaire, il reprend la réplication depuis le serveur primaire ou un autre secondaire. Si le primaire
redémarre, une élection sera déclenchée pour choisir un nouveau primaire parmi les secondaires.

4. Configuration de l'Ordre de Priorité dans le Replica Set

Pour configurer l'ordre de priorité, ajustez les valeurs de priority lors de l'initialisation du Replica Set :

Sur le Serveur Primaire :

javascriptCopy code

Primaire> rs.reconfig({ _id: "RSnet", members: [ { _id: 0, host: "192.168.1.1:<port>", priority: 1 },

{ _id: 1, host: "192.168.1.2:<port>", priority: 0.6 }, { _id: 2, host: "192.168.1.3:<port>", priority: 0.5 }, {
_id: 3, host: "192.168.1.4:<port>", priority: 0.7 }, { _id: 4, host: "192.168.1.5:<port>", priority: 0.8 },
{ _id: 5, host: "192.168.1.6:<port>", arbiterOnly: true }, { _id: 6, host: "192.168.1.7:<port>",
arbiterOnly: true } ] }, { force: true });

Les priorités sont ajustées pour que le secondaire 4 ait la plus haute priorité après le primaire, suivi
par le secondaire 2, le secondaire 3, puis le secondaire 1.
You

1. Dans le serveur MongoDB en retrouve toujours les deux bases de données « admin » et «local »,
qui sont instaurées par défaut et qui sont utilisées par le serveur lui-même. Quelle est la nature des
informations stockées dans chacune de ces bases ? 2. Quand est ce que l'indexation d'un champ est
utile, et quand est ce qu'elle n'est pas utile ? donnez des explications.

ChatGPT

ChatGPT

Réponses aux Questions

1. Nature des Informations dans les Bases de Données « admin » et « local » de MongoDB

 Base de données "admin" : Elle est principalement utilisée pour les tâches administratives.
La base de données "admin" contient des informations liées à la sécurité et à l'administration
de l'ensemble de l'instance MongoDB. Elle inclut les comptes d'utilisateurs avec leurs rôles et
privilèges au niveau du serveur (pas limités à une base de données spécifique). Les
opérations d'administration globale, comme la création de nouveaux utilisateurs et rôles,
sont également exécutées dans cette base de données.

 Base de données "local" : Cette base de données est spécifique à chaque serveur et n'est pas
répliquée dans les ensembles de réplicas. Elle contient des informations propres à l'instance
locale de MongoDB, telles que les enregistrements de l'oplog pour la réplication. L'oplog
(journal des opérations) est crucial dans les ensembles de réplicas pour maintenir la
cohérence des données entre les serveurs. La base de données "local" peut également
contenir d'autres informations spécifiques à un nœud qui ne doivent pas être partagées avec
les autres nœuds de l'ensemble.

2. Utilité de l'Indexation d'un Champ

Quand l'Indexation est Utile :

 Requêtes Fréquentes sur un Champ : Si un champ est souvent utilisé dans les clauses find(),
sort(), ou dans les jointures, l'indexation peut considérablement accélérer ces requêtes.

 Grands Volumes de Données : Sur des collections volumineuses, l'indexation permet de

trouver des documents spécifiques plus rapidement qu'en parcourant toute la collection.

 Triage des Résultats : Pour les requêtes qui nécessitent un tri, un index sur le champ de tri
améliore les performances.

Quand l'Indexation n'est Pas Utile :

 Champs Rarement Recherchés : Si un champ n'est que rarement utilisé dans les requêtes,
l'indexation peut être superflue.

 Écritures Fréquentes, Lectures Rares : Si la collection est sujette à de nombreuses opérations

d'écriture mais peu de lectures, l'indexation peut être contre-productive, car chaque écriture
nécessite une mise à jour de l'index, ce qui peut ralentir les opérations.
 Faible Diversité de Valeurs (faible cardinalité) : Si un champ a très peu de valeurs uniques
(par exemple, un champ "sexe" avec des valeurs "M" et "F"), l'indexation peut ne pas
apporter d'amélioration significative des performances.