| Scroll Ignore | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Introduction
La haute disponibilité de la base mongo MongoDB passe par la mise en place d'un cluster de plusieurs instances de mongod ( pour dupliquer les données en plusieurs endroits des réplications des données ).
Un cluster mongo doit forcément être composé d'au moins trois instances ( nœud ) pour fonctionner, principalement pour la notion d'élection ( être capable de choisir le mongo primaire ).
- Il est cependant possible de n'avoir que 2 nœuds de stockage :
- il faudra utiliser une architecture Primaire - Secondaire - Arbiter ( Voir la page Mise en place de l'architecture Primaire - Secondaire - Arbiter ).
- La 3ᵉ instance ( l'Arbiter ) ne contient pas de donnée, mais permet juste de voter lorsqu'il y a une élection du primaire ( l'élection est le choix d'un nouveau nœud qui prendre le relais du traitement des requêtes quand le primaire disparait ).
- Sinon, il faudra utiliser une architecture Primaire - Secondaire - Secondaire ( Voir la pageMise en place de l'architecture Primaire - Secondaire - Secondaire ).
Comment choisir l'une des deux architectures ?
C'est une question de sécurité opposée au coût d'avoir plusieurs serveurs de redondance :
- Les Plus les données sont répliquées sur chaque élément du cluster donc plus vous en avait et moins le risque de , moins vous avez de risque d'être impacté par le crash, incendie,... de 1 ou plusieurs serveurs sont inquiétantsà la fois.
- Comme Mais, comme les quantités de données stockées nécessitent de l'espace disque et de la RAM ( dépendant du volume de donnée et de traitement fait ), mettre plusieurs serveurs peut devenir un problème de coût.